Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spring-security-core depends on spring-security-crypto #9767

Closed
wilkinsona opened this issue May 18, 2021 · 2 comments
Closed

spring-security-core depends on spring-security-crypto #9767

wilkinsona opened this issue May 18, 2021 · 2 comments
Assignees
Labels
in: build An issue in the build status: backported An issue that has been backported to maintenance branches type: breaks-passivity A change that breaks passivity with the previous release type: bug A general bug
Milestone

Comments

@wilkinsona
Copy link
Member

wilkinsona commented May 18, 2021

Update Rather than embedding spring-security-crypto, spirng-security-core should just depend on it to avoid this scenario. This breaks passivity for applications that do not leverage transitive dependencies, but it should not impact a majority of users. Users that don't leverage transitive dependencies will need to explicitly add the spring-security-crypto jar to their classpath.

In 5.5.0, spring-security-core has started declaring a dependency on spring-security-crypto in addition to embedding spring-security-crypto's classes. This resulted in a number of Spring Boot's starters containing duplicates of the crypto classes. We've worked around it by excluding spring-security-crypto.

@wilkinsona wilkinsona added status: waiting-for-triage An issue we've not yet triaged type: bug A general bug labels May 18, 2021
@rwinch rwinch added this to the 5.5.1 milestone May 18, 2021
@rwinch rwinch added in: build An issue in the build and removed status: waiting-for-triage An issue we've not yet triaged labels May 18, 2021
@rwinch rwinch self-assigned this May 18, 2021
@rwinch rwinch closed this as completed in 56b7c66 May 18, 2021
@rwinch rwinch modified the milestones: 5.5.1, 5.6.0-M1 May 18, 2021
rwinch added a commit that referenced this issue May 18, 2021
Instead of having api extend included configuration, we should use the
*Classpath configurations.

Closes gh-9767
@rwinch rwinch added the for: backport-to-5.5.x Designates an issue for backport to 5.5.x label May 18, 2021
@spring-projects-issues spring-projects-issues added status: backported An issue that has been backported to maintenance branches and removed for: backport-to-5.5.x Designates an issue for backport to 5.5.x labels May 18, 2021
rwinch added a commit that referenced this issue May 18, 2021
rwinch added a commit that referenced this issue May 18, 2021
@rwinch rwinch added the type: breaks-passivity A change that breaks passivity with the previous release label May 19, 2021
@rwinch
Copy link
Member

rwinch commented May 19, 2021

@wilkinsona This is fixed in 5.5.1-SNAPSHOT and 5.6.0-SNAPSHOT by spring-security-core depends on spring-security-crypto without embedding the classes.
Could you give one of those a try to ensure the problem is resolved?

@wilkinsona
Copy link
Member Author

Thanks, Rob. Things look good to me with 5.5.1-SNAPSHOT. We no longer see any duplicate classes.

akohli96 pushed a commit to akohli96/spring-security that referenced this issue Aug 25, 2021
Instead of having api extend included configuration, we should use the
*Classpath configurations.

Closes spring-projectsgh-9767
akohli96 pushed a commit to akohli96/spring-security that referenced this issue Aug 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: build An issue in the build status: backported An issue that has been backported to maintenance branches type: breaks-passivity A change that breaks passivity with the previous release type: bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants