Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5303

Upgrade Acegi Security to the latest Spring Security release

    • Icon: Task Task
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • 2.266

      Please upgrade Acegi Security to the latest Spring Security release. Acegi Security it's old and deprecated.

          [JENKINS-5303] Upgrade Acegi Security to the latest Spring Security release

          Alan Harder added a comment -

          FYI, as per this discussion such an upgrade was rejected by Kohsuke. The work done towards this upgrade was archived here:
          https://svn.dev.java.net/svn/hudson/branches/springframework2
          Likely only if lots of people vote for this issue will an upgrade be done.

          Alan Harder added a comment - FYI, as per this discussion such an upgrade was rejected by Kohsuke. The work done towards this upgrade was archived here: https://svn.dev.java.net/svn/hudson/branches/springframework2 Likely only if lots of people vote for this issue will an upgrade be done.

          Rob Winch added a comment -

          Acegi Security's last commit was over 7 years ago. There have been many CVE's reported and fixed within the maintained versions of Spring Security. For this reason I believe this issue should be considered a high priority.

          Note that it appears that the Hudson team has already updated to Spring Security 3.2.x.

          Rob Winch added a comment - Acegi Security's last commit was over 7 years ago. There have been many CVE's reported and fixed within the maintained versions of Spring Security. For this reason I believe this issue should be considered a high priority. Note that it appears that the Hudson team has already updated to Spring Security 3.2.x.

          In 2015 it's Blocker. Jenkins ships acegi-security released in 2008.

          Kanstantsin Shautsou added a comment - In 2015 it's Blocker. Jenkins ships acegi-security released in 2008.

          Oleg Nenashev added a comment -

          +1 for handling it.

          Oleg Nenashev added a comment - +1 for handling it.

          Rob Winch added a comment -

          I'm very glad to see this issue getting traction!

          I'd like to formally extend an offer to provide any support with the migration from a Spring Security perspective. Please let me know if you have any questions.

          Regards,
          Rob Winch
          (Spring Security Lead)

          Rob Winch added a comment - I'm very glad to see this issue getting traction! I'd like to formally extend an offer to provide any support with the migration from a Spring Security perspective. Please let me know if you have any questions. Regards, Rob Winch (Spring Security Lead)

          Kanstantsin Shautsou added a comment - - edited

          rwinch will it be possible to create Proxy or backward compatible migration? If not, could you provide some PR to core (there is a spring-security branch but with 0 work).

          Kanstantsin Shautsou added a comment - - edited rwinch will it be possible to create Proxy or backward compatible migration? If not, could you provide some PR to core (there is a spring-security branch but with 0 work).

          Rob Winch added a comment - - edited

          integer Thank you for the response.

          Rob Winch will it be possible to create Proxy or backward compatible migration?

          Unfortunately, I don't think there is a way to make the transition completely seamless (i.e. using a Proxy). There may be steps we can provide to make the transition easier. However, this is difficult to determine at this point since I'm not familiar with the Jenkins code base.

          If not, could you provide some PR to core (there is a spring-security branch but with 0 work).

          Although not clear, my initial intention was to answer any concrete questions that arose when someone else put the PR together.

          I put together a branch at rwinch/jeknins/tree/security that updates to the latest Spring and Spring Security. At the moment, mvn -Plight-test test passes, but a full build fails. One of the issues appears to be that there are external libraries that will need updating as well (i.e. matrix-auth). There is also some clean up that needs to be done (i.e. whitespace changes that should be removed, etc).

          I'm not certain I will get time to spend on this again in the near future. Perhaps someone can take what I have put together and polish it?

          Cheers,
          Rob

          PS: At this point I'm fully relying on the tests to catch any errors. it is possible there are logic errors in my changes as I went through them rather abruptly

          Rob Winch added a comment - - edited integer Thank you for the response. Rob Winch will it be possible to create Proxy or backward compatible migration? Unfortunately, I don't think there is a way to make the transition completely seamless (i.e. using a Proxy). There may be steps we can provide to make the transition easier. However, this is difficult to determine at this point since I'm not familiar with the Jenkins code base. If not, could you provide some PR to core (there is a spring-security branch but with 0 work). Although not clear, my initial intention was to answer any concrete questions that arose when someone else put the PR together. I put together a branch at rwinch/jeknins/tree/security that updates to the latest Spring and Spring Security. At the moment, mvn -Plight-test test passes, but a full build fails. One of the issues appears to be that there are external libraries that will need updating as well (i.e. matrix-auth). There is also some clean up that needs to be done (i.e. whitespace changes that should be removed, etc). I'm not certain I will get time to spend on this again in the near future. Perhaps someone can take what I have put together and polish it? Cheers, Rob PS: At this point I'm fully relying on the tests to catch any errors. it is possible there are logic errors in my changes as I went through them rather abruptly

          Rob Winch added a comment -

          integer I see that the 2.0 label was removed. Is there anything that can be done to get this added back to 2.0?

          I'd even be willing to work more on the PR if I can get some guidance.

          Rob Winch added a comment - integer I see that the 2.0 label was removed. Is there anything that can be done to get this added back to 2.0? I'd even be willing to work more on the PR if I can get some guidance.

          Seems that Kohsuke doesn't want to do it. Nothing that i can help with. Seems UI is more important than security or ancient library in core.

          Kanstantsin Shautsou added a comment - Seems that Kohsuke doesn't want to do it. Nothing that i can help with. Seems UI is more important than security or ancient library in core.

          Rob Winch added a comment - - edited

          Thanks for the response integer. It is a real shame if that is the case

          kohsuke is this just a matter of resources? Is there anything I can do (i.e. get a complete Pull Request together) to get this back into 2.0?

          Rob Winch added a comment - - edited Thanks for the response integer . It is a real shame if that is the case kohsuke is this just a matter of resources? Is there anything I can do (i.e. get a complete Pull Request together) to get this back into 2.0?

          Daniel Beck added a comment -

          rwinch The problem we have is that core exposes Acegi Security to plugins which we'd rather not break. Is there a reasonably sane way to upgrade to Spring Security without breaking all of these?

          Daniel Beck added a comment - rwinch The problem we have is that core exposes Acegi Security to plugins which we'd rather not break. Is there a reasonably sane way to upgrade to Spring Security without breaking all of these ?

          Daniel Beck added a comment -

          rwinch If you get a build of Jenkins with Spring Security, https://github.com/jenkinsci/plugin-compat-tester will be able tell you what plugins will (likely) break. matrix-auth will just be the tip of the iceberg.

          Daniel Beck added a comment - rwinch If you get a build of Jenkins with Spring Security, https://github.com/jenkinsci/plugin-compat-tester will be able tell you what plugins will (likely) break. matrix-auth will just be the tip of the iceberg.

          Obviously not easy and time consuming. After security-170 i see no sense in discussing unbreakable changes.

          Kanstantsin Shautsou added a comment - Obviously not easy and time consuming. After security-170 i see no sense in discussing unbreakable changes.

          Daniel Beck added a comment -

          integer I'd rather not have a repeat of

          The most sucking security fix

          if it could be avoided. It's certainly not something we do for shits and giggles. Problems with acegi seem hypothetical – please report to SECURITY if I'm wrong – while SECURITY-170 was very real, and trivial to exploit. But as you apparently know that

          acegi upgrade would break less plugins than STUPID-170

          please provide a complete list.

          Daniel Beck added a comment - integer I'd rather not have a repeat of The most sucking security fix if it could be avoided. It's certainly not something we do for shits and giggles. Problems with acegi seem hypothetical – please report to SECURITY if I'm wrong – while SECURITY-170 was very real, and trivial to exploit. But as you apparently know that acegi upgrade would break less plugins than STUPID-170 please provide a complete list.

          danielbeck you are mixing my words from my personal services with jenkins infra that contains CoC. That not polite. Please keep in mind contexts.

          List would be all auth plugins that using any acegisecurity classes.
          Btw, rwinch would spring-security be able to work before acegi in Filter routines?

          Kanstantsin Shautsou added a comment - danielbeck you are mixing my words from my personal services with jenkins infra that contains CoC. That not polite. Please keep in mind contexts. List would be all auth plugins that using any acegisecurity classes. Btw, rwinch would spring-security be able to work before acegi in Filter routines?

          Daniel Beck added a comment -

          integer Well, you did claim publicly that fixing this wouldn't result in as much plugins breaking as SECURITY-170. So I had assumed you had some data to back that claim, which would help us in assessing how to proceed here. Is that not the case? (FWIW I don't care about how you phrased things, just the content.)

          Daniel Beck added a comment - integer Well, you did claim publicly that fixing this wouldn't result in as much plugins breaking as SECURITY-170. So I had assumed you had some data to back that claim, which would help us in assessing how to proceed here. Is that not the case? (FWIW I don't care about how you phrased things, just the content.)

          Rob Winch added a comment -

          danielbeck Thanks for the response and the link to the tester.

          I'm not sure I'm willing to commit to the work unless the work will be merged. I am even willing to entertain the idea of fixing the plugins that would break. However, I want to ensure that my work will not be in vain.

          Cheers,
          Rob

          Rob Winch added a comment - danielbeck Thanks for the response and the link to the tester. I'm not sure I'm willing to commit to the work unless the work will be merged. I am even willing to entertain the idea of fixing the plugins that would break. However, I want to ensure that my work will not be in vain. Cheers, Rob

          Daniel Beck added a comment -

          jglick You mentioned yesterday that this cannot be implemented, period? Could you update this issue accordingly?

          Daniel Beck added a comment - jglick You mentioned yesterday that this cannot be implemented, period? Could you update this issue accordingly?

          Jesse Glick added a comment -

          “Cannot” is too strong. But it would certainly be hard, since ACEGI types are baked into Jenkins core API signatures and widely used. We would have to replace the ACEGI JAR with a stub containing just those types observed to be used in the field, and then create some sort of façade letting the original (but now deprecated) signatures continue to be used compatibly. I would consider this a research project—could be attempted, may or may not prove feasible.

          Or we could try to do tricks with bytecode loading of plugins. We have done such tricks in the past—@AdaptField, etc. For a lot of cases it works, but we have also encountered crippling, hard-to-diagnose errors from subtle mistakes in workarounds like this. So I do not really advocate that approach.

          For some cases of proposed breaking API changes we just try to add suggested replacements, update & release affected plugins, and finally delete the old API. Given that just among the @jenkinsci plugins there are too many usages to count, and I know of many more among closed-source plugins, that does not seem practical in this case.

          Jesse Glick added a comment - “Cannot” is too strong. But it would certainly be hard, since ACEGI types are baked into Jenkins core API signatures and widely used. We would have to replace the ACEGI JAR with a stub containing just those types observed to be used in the field, and then create some sort of façade letting the original (but now deprecated) signatures continue to be used compatibly. I would consider this a research project—could be attempted, may or may not prove feasible. Or we could try to do tricks with bytecode loading of plugins. We have done such tricks in the past— @AdaptField , etc. For a lot of cases it works, but we have also encountered crippling, hard-to-diagnose errors from subtle mistakes in workarounds like this. So I do not really advocate that approach. For some cases of proposed breaking API changes we just try to add suggested replacements, update & release affected plugins, and finally delete the old API. Given that just among the @jenkinsci plugins there are too many usages to count , and I know of many more among closed-source plugins, that does not seem practical in this case.

          Cyrille Le Clerc added a comment - - edited

          I suspect that JENKINS-23844 is caused by a bug in the LDAP search used by the jenkins-ldap-plugin. This bug in the LDAP search has been fixed many many years ago in Spring Security

          Cyrille Le Clerc added a comment - - edited I suspect that JENKINS-23844 is caused by a bug in the LDAP search used by the jenkins-ldap-plugin. This bug in the LDAP search has been fixed many many years ago in Spring Security

          Daniel Beck added a comment -

          Repurposing https://github.com/jenkins-infra/deprecated-usage-in-plugins indicates that ~130 plugins currently use types from org.acegisecurity. Ignoring uses of exceptions and SecurityContext/SecurityContextHolder, there are still 70+ plugins left.

          Daniel Beck added a comment - Repurposing https://github.com/jenkins-infra/deprecated-usage-in-plugins indicates that ~130 plugins currently use types from org.acegisecurity . Ignoring uses of exceptions and SecurityContext/SecurityContextHolder, there are still 70+ plugins left.

          Oleg Nenashev added a comment -

          It's still actual. But it requires a huge chunk of time to be invested.

           

          Oleg Nenashev added a comment - It's still actual. But it requires a huge chunk of time to be invested.  

          Rob Winch added a comment -

          I'm still willing to try and help with this update but would like some guidance from the Jenkins team on how to ensure we can get something merged.

           

          Can anyone provide the list of the API's in Acegi that are being used by external plugins? Perhaps that would allow us to figure out a shim jar.

          Rob Winch added a comment - I'm still willing to try and help with this update but would like some guidance from the Jenkins team on how to ensure we can get something merged.   Can anyone provide the list of the API's in Acegi that are being used by external plugins? Perhaps that would allow us to figure out a shim jar.

          Could springsecurity be added as separate Filter and new plugins implented for it?

          Kanstantsin Shautsou added a comment - Could springsecurity be added as separate Filter and new plugins implented for it?

          Rob Winch added a comment -

          It's possible, but it would be using completely different security systems which wouldn't work. I'm wondering if we can Bridge the SecurityContextHolder and SecurityContext types if that would allow them to work simultaneously. This would depend on what public APIs are being used by external plugins.

          Rob Winch added a comment - It's possible, but it would be using completely different security systems which wouldn't work. I'm wondering if we can Bridge the SecurityContextHolder and SecurityContext types if that would allow them to work simultaneously. This would depend on what public APIs are being used by external plugins.

          Oleg Nenashev added a comment -

          > Could springsecurity be added as separate Filter and new plugins implented for it?

          Maybe, if we talk only about UI-facing logic and request routing. Routing Spring Security model to core-internal objects like Queue Authentication will be tricky. I doubt that shim will be enough. I believe we will need to...

          1) Fork acegi security

          2) Remove everything excepting Data Model and API being really used in Jenkins plugins

          3) Create bridges between Acegi methods and Spring Security

          With such approach we will have to keep Spring Security as a core dependency. But I think we will have to deal with it, detaching the entire user management and authorization logic is, ehm, mission impossible

           

          Oleg Nenashev added a comment - > Could springsecurity be added as separate Filter and new plugins implented for it? Maybe, if we talk only about UI-facing logic and request routing. Routing Spring Security model to core-internal objects like Queue Authentication will be tricky. I doubt that shim will be enough. I believe we will need to... 1) Fork acegi security 2) Remove everything excepting Data Model and API being really used in Jenkins plugins 3) Create bridges between Acegi methods and Spring Security With such approach we will have to keep Spring Security as a core dependency. But I think we will have to deal with it, detaching the entire user management and authorization logic is, ehm, mission impossible  

          Rob Winch added a comment -

          What are the APIs that are being used by plugins? Is there also a count for each API that is in use? This might help me to understand the current state of things.

          Rob Winch added a comment - What are the APIs that are being used by plugins? Is there also a count for each API that is in use? This might help me to understand the current state of things.

          Daniel Beck added a comment -

          rwinch

          What are the APIs that are being used by plugins? Is there also a count for each API that is in use? This might help me to understand the current state of things.

          Plugins using anything from org.acegisecurity, by API:


          org/acegisecurity/AccessDeniedException

          Daniel Beck added a comment - rwinch What are the APIs that are being used by plugins? Is there also a count for each API that is in use? This might help me to understand the current state of things. Plugins using anything from org.acegisecurity, by API: org/acegisecurity/AccessDeniedException authorize-project build-failure-analyzer build-token-root cloudbees-folder docker-traceability jobtemplates metrics node-sharing-orchestrator ownership pipeline-model-definition pubsub-light slave-squatter svnmerge workflow-cps org/acegisecurity/AccountExpiredException crowd2 org/acegisecurity/AcegiMessageSource reverse-proxy-auth-plugin org/acegisecurity/acls/NotFoundException artifactory org/acegisecurity/acls/sid/PrincipalSid role-strategy ssh2easy org/acegisecurity/Authentication active-directory assembla-auth authorize-project azure-ad block-same-builds blueocean-jwt blueocean-pipeline-api-impl blueocean-pipeline-scm-api blueocean-rest-impl build-failure-analyzer claim coding-webhook concurrent-login-plugin createjobadvanced credentials crowd2 DotCi favorite gcm-notification gerrit-trigger git-server github-oauth gitlab-oauth greenballs hp-application-automation-tools-plugin job-fan-in jwt-support kerberos-sso ldap literate m2release monitoring NegotiateSSO parameterized-trigger pipeline-input-step project-inheritance prometheus promoted-builds pwauth remote-terminal-access reverse-proxy-auth-plugin saml script-security splunk-devops statistics-gatherer support-core teamconcert-git typetalk view-job-filters windows-azure-storage workflow-cps workflow-durable-task-step workflow-job wwpass-plugin org/acegisecurity/AuthenticationException active-directory gitlab-oauth pwauth redmine org/acegisecurity/AuthenticationManager assembla-auth authorize-project azure-ad bitbucket-oauth cas-plugin coding-webhook crowd2 DotCi github-oauth gitlab-oauth google-login ibm-continuous-release keycloak ldap oic-auth openid openshift-login pwauth saml skype-notifier urbancode-velocity url-auth-sso wso2id-oauth wwpass-plugin org/acegisecurity/AuthenticationServiceException active-directory cas-plugin crowd2 reverse-proxy-auth-plugin script-realm org/acegisecurity/BadCredentialsException active-directory assembla-auth azure-ad backlog bitbucket-oauth cas-plugin coding-webhook crowd2 delivery-pipeline-plugin github-oauth gitlab-oauth google-login keycloak mock-security-realm oic-auth openid openshift-login pam-auth pwauth reverse-proxy-auth-plugin saml script-realm wso2id-oauth wwpass-plugin org/acegisecurity/context/SecurityContext assembla-auth azure-ad backup bitbucket-oauth blueocean-jwt cas-plugin coding-webhook credentials crowd2 DotCi elasticbox extended-choice-parameter gcm-notification ghprb gitbucket github-oauth gitlab-oauth google-login hp-application-automation-tools-plugin ibm-continuous-release instant-messaging jclouds-jenkins jwt-support kerberos-sso keycloak NegotiateSSO oic-auth openid openshift-login periodicbackup promoted-builds reverse-proxy-auth-plugin saml subversion teamconcert-git thinBackup urbancode-velocity url-auth-sso wso2id-oauth wwpass-plugin xpdev org/acegisecurity/context/SecurityContextHolder alauda-devops-sync assembla-auth azure-ad backlog backup bitbucket bitbucket-oauth blueocean-bitbucket-pipeline blueocean-github-pipeline blueocean-jwt branch-api build-token-root buildresult-trigger cas-plugin cloudbees-disk-usage-simple cloudbees-folder coding-webhook credentials crowd2 deploydb docker-slaves dockerhub-notification DotCi elasticbox embeddable-build-status extended-choice-parameter feature-branch-notifier gcm-notification gearman-plugin generic-webhook-trigger gerrit-code-review gerrit-trigger ghprb git gitbucket gitea github-oauth github-pullrequest gitlab-oauth gogs-webhook google-login ibm-continuous-release instant-messaging jclouds-jenkins jms-messaging job-fan-in jobcopy-builder jwt-support kerberos-sso keycloak mercurial metrics NegotiateSSO node-sharing-executor oic-auth openid openshift-login openshift-sync ownership periodicbackup PrioritySorter project-inheritance promoted-builds rabbitmq-consumer random-job-builder reverse-proxy-auth-plugin saml scm-api script-security security-inspector seed slack ssh-slaves subversion support-core teamconcert-git tfs thinBackup throttle-concurrents urbancode-velocity url-auth-sso windows-azure-storage workflow-durable-task-step wso2id-oauth wwpass-plugin xpdev zanata org/acegisecurity/context/SecurityContextImpl blueocean-jwt jwt-support org/acegisecurity/CredentialsExpiredException crowd2 org/acegisecurity/DisabledException cas-plugin org/acegisecurity/GrantedAuthority active-directory azure-ad crowd2 job-restrictions ldap literate oic-auth pipeline-input-step promoted-builds reverse-proxy-auth-plugin role-strategy saml org/acegisecurity/GrantedAuthorityImpl active-directory bitbucket-oauth cas-plugin crowd2 github-oauth gitlab-oauth keycloak ldap mock-security-realm oic-auth openid pam-auth pwauth reverse-proxy-auth-plugin script-realm org/acegisecurity/InsufficientAuthenticationException crowd2 org/acegisecurity/ldap/LdapCallback ldap org/acegisecurity/ldap/LdapDataAccessException ldap reverse-proxy-auth-plugin org/acegisecurity/ldap/LdapEntryMapper ldap org/acegisecurity/ldap/LdapTemplate ldap reverse-proxy-auth-plugin org/acegisecurity/ldap/LdapUserSearch ldap reverse-proxy-auth-plugin org/acegisecurity/LockedException cas-plugin org/acegisecurity/providers/AbstractAuthenticationToken assembla-auth bitbucket-oauth blueocean-jwt cas-plugin coding-webhook crowd2 github-oauth gitlab-oauth jwt-support keycloak saml url-auth-sso wso2id-oauth wwpass-plugin org/acegisecurity/providers/dao/AbstractUserDetailsAuthenticationProvider active-directory redmine reverse-proxy-auth-plugin org/acegisecurity/providers/ldap/LdapAuthenticationProvider ldap org/acegisecurity/providers/ldap/LdapAuthoritiesPopulator ldap reverse-proxy-auth-plugin org/acegisecurity/providers/ldap/populator/DefaultLdapAuthoritiesPopulator ldap reverse-proxy-auth-plugin org/acegisecurity/providers/UsernamePasswordAuthenticationToken active-directory authorize-project cas-plugin coding-webhook copyartifact credentials github-oauth gitlab-oauth google-login ibm-continuous-release kerberos-sso ldap NegotiateSSO oic-auth openid openshift-login perfectomobile pwauth redmine reverse-proxy-auth-plugin s3 skype-notifier urbancode-velocity wso2id-oauth org/acegisecurity/ui/rememberme/RememberMeServices crowd2 org/acegisecurity/userdetails/ldap/LdapUserDetails ldap reverse-proxy-auth-plugin org/acegisecurity/userdetails/ldap/LdapUserDetailsImpl$Essence ldap reverse-proxy-auth-plugin org/acegisecurity/userdetails/User active-directory backlog cas-plugin coding-webhook github-oauth gitlab-oauth mock-security-realm pam-auth pwauth script-realm url-auth-sso wso2id-oauth org/acegisecurity/userdetails/UserDetails active-directory assembla-auth azure-ad bitbucket-oauth blueocean-jwt coding-webhook crowd2 github-oauth gitlab-oauth ibm-continuous-release job-restrictions jwt-support kerberos-sso mock-security-realm NegotiateSSO oic-auth redmine reverse-proxy-auth-plugin role-strategy saml urbancode-velocity url-auth-sso wso2id-oauth wwpass-plugin org/acegisecurity/userdetails/UserDetailsService active-directory assembla-auth azure-ad bitbucket-oauth coding-webhook crowd crowd2 github-oauth gitlab-oauth ldap oic-auth pwauth reverse-proxy-auth-plugin saml url-auth-sso wso2id-oauth org/acegisecurity/userdetails/UsernameNotFoundException active-directory assembla-auth azure-ad backlog bitbucket-oauth coding-webhook crowd2 github-oauth gitlab-oauth ldap mock-security-realm pam-auth pwauth redmine reverse-proxy-auth-plugin saml script-realm wwpass-plugin

          Rob Winch added a comment -

          That's quite a bit more APIs that I expected. Given a lot of it is just repackaging.... I'm wondering if we can automate pull requests to Spring Security using https://github.com/Netflix-Skunkworks/rewrite Would this be an option you would consider?

          Rob Winch added a comment - That's quite a bit more APIs that I expected. Given a lot of it is just repackaging.... I'm wondering if we can automate pull requests to Spring Security using https://github.com/Netflix-Skunkworks/rewrite  Would this be an option you would consider?

          Daniel Beck added a comment - - edited

          rwinch

          Given a lot of it is just repackaging

          If it's mostly classes/packages being renamed, could https://github.com/jenkinsci/bytecode-compatibility-transformer/ do the trick then?

          A challenge we have is the long tail of lesser used, not well maintained plugins. If we can make old plugin releases continue to work with new versions of core for relatively low effort, that would be beneficial.

          Especially in a space where failure of the plugin would make login etc. impossible.

          Daniel Beck added a comment - - edited rwinch Given a lot of it is just repackaging If it's mostly classes/packages being renamed, could https://github.com/jenkinsci/bytecode-compatibility-transformer/ do the trick then? A challenge we have is the long tail of lesser used, not well maintained plugins. If we can make old plugin releases continue to work with new versions of core for relatively low effort, that would be beneficial. Especially in a space where failure of the plugin would make login etc. impossible.

          Rob Winch added a comment -

          Thanks for the response and thoughts. It might make sense to use bytecode-compatability-transformer since there are probably plugins that we don't know about. I'm not very familiar with this project. Is it something you would be able to take on?

          Rob Winch added a comment - Thanks for the response and thoughts. It might make sense to use bytecode-compatability-transformer since there are probably plugins that we don't know about. I'm not very familiar with this project. Is it something you would be able to take on?

          runze xia added a comment - http://forum.spring.io/forum/spring-projects/data/ldap/96508-ldap-authentication-intermittent-socket-closed-error

          Wadeck Follonier added a comment - - edited

          Update for 2020 status.
          PR for the usage-in-plugin custom search used: https://github.com/jenkins-infra/usage-in-plugins/pull/15

          Report attached to this ticket: usage-by-api_2020-07-11.html

          Important missing points: the classes used in XxxSecurityRealm.groovy used for building the beans.

          Wadeck Follonier added a comment - - edited Update for 2020 status. PR for the usage-in-plugin custom search used: https://github.com/jenkins-infra/usage-in-plugins/pull/15 Report attached to this ticket: usage-by-api_2020-07-11.html Important missing points: the classes used in XxxSecurityRealm.groovy used for building the beans.

          Jesse Glick added a comment -

          I am investigating whether this effort is feasible.

          Jesse Glick added a comment - I am investigating whether this effort is feasible.

          Rob Winch added a comment -

          Thanks jglick Please let me know if I can be of any assistance.

          Rob Winch added a comment - Thanks jglick Please let me know if I can be of any assistance.

          Jesse Glick added a comment -

          rwinch thanks for the offer! I think I am past the stage where I struggled to find Spring Security 5 equivalents to various Acegi Security idioms that could not be resolved by a simple fix of imports (could not find a clear Rosetta stone except for the 3 → 4 migration). If you can spare any time, by all means skim over the running changes to Jenkins core and comment if you notice any clear abuses of the API. The work going forward will be dealing with compatibility from plugins. There is a draft overview of the effort for background.

          Jesse Glick added a comment - rwinch thanks for the offer! I think I am past the stage where I struggled to find Spring Security 5 equivalents to various Acegi Security idioms that could not be resolved by a simple fix of imports (could not find a clear Rosetta stone except for the 3 → 4 migration ). If you can spare any time, by all means skim over the running changes to Jenkins core and comment if you notice any clear abuses of the API. The work going forward will be dealing with compatibility from plugins. There is a draft overview of the effort for background.

          Jesse Glick added a comment -

          rwinch actually, you could be of assistance if you have any time to spare: I have been struggling in https://github.com/jenkinsci/ldap-plugin/pull/49 to find the Spring Security equivalents of a number of Acegi Security API calls relating to LDAP, not made any easier by the fact that I know little about LDAP itself.

          I have filed a JEP draft for this whole effort.

          Jesse Glick added a comment - rwinch actually, you could be of assistance if you have any time to spare: I have been struggling in https://github.com/jenkinsci/ldap-plugin/pull/49 to find the Spring Security equivalents of a number of Acegi Security API calls relating to LDAP, not made any easier by the fact that I know little about LDAP itself. I have filed a JEP draft for this whole effort.

          jglickcongrats!

          Kanstantsin Shautsou added a comment - jglick congrats!

            jglick Jesse Glick
            nicusorb nicusorb
            Votes:
            22 Vote for this issue
            Watchers:
            21 Start watching this issue

              Created:
              Updated:
              Resolved: