search

timja / jenkins-gh-issues-poc-06-18

0 stars 0 forks source link

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

Closed timja closed 4 years ago

timja commented 14 years ago

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

Originally reported by nicusorb, imported from: Upgrade Acegi Security to the latest Spring Security release
  • assignee: jglick
  • status: Resolved
  • priority: Blocker
  • resolution: Fixed
  • resolved: 2020-11-06T21:13:46+00:00
  • imported: 2022/01/10
timja commented 14 years ago

mindless:

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.

timja commented 9 years ago

rwinch:

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.

timja commented 8 years ago

integer:

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

timja commented 8 years ago

oleg_nenashev:

+1 for handling it.

timja commented 8 years ago

rwinch:

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)

timja commented 8 years ago

integer:

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).

timja commented 8 years ago

rwinch:

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

timja commented 8 years ago

rwinch:

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.

timja commented 8 years ago

integer:

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.

timja commented 8 years ago

rwinch:

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?

timja commented 8 years ago

danielbeck:

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?

timja commented 8 years ago

danielbeck:

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.

timja commented 8 years ago

integer:

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

timja commented 8 years ago

danielbeck:

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.

timja commented 8 years ago

integer:

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?

timja commented 8 years ago

danielbeck:

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.)

timja commented 8 years ago

rwinch:

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

timja commented 8 years ago

danielbeck:

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

timja commented 8 years ago

jglick:

“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.

timja commented 7 years ago

cleclerc:

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

timja commented 7 years ago

danielbeck:

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.

timja commented 6 years ago

oleg_nenashev:

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

 

timja commented 6 years ago

rwinch:

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.

timja commented 6 years ago

integer:

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

timja commented 6 years ago

rwinch:

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.

timja commented 6 years ago

oleg_nenashev:

> 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

 

timja commented 6 years ago

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.

timja commented 6 years ago

danielbeck:

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

timja commented 6 years ago

rwinch:

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?

timja commented 6 years ago

danielbeck:

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.

timja commented 6 years ago

rwinch:

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?

timja commented 6 years ago

runzexia:

http://forum.spring.io/forum/spring-projects/data/ldap/96508-ldap-authentication-intermittent-socket-closed-error

timja commented 4 years ago

wfollonier:

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.

timja commented 4 years ago

jglick:

I am investigating whether this effort is feasible.

timja commented 4 years ago

rwinch:

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

timja commented 4 years ago

jglick:

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.

timja commented 4 years ago

jglick:

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.

timja commented 3 years ago

integer:

jglickcongrats!

timja commented 2 years ago

[Originally blocks: JENKINS-54015]