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

#782: Make runtime registration of bouncycastle skippable #828

Closed
wants to merge 1 commit into from

Conversation

Hayvon
Copy link

@Hayvon Hayvon commented Oct 28, 2022

Adressing #782 by adding a system property check which makes the runtime registration of bouncycastle skippable.

@sonatype-lift
Copy link

sonatype-lift bot commented Oct 28, 2022

⚠️ 14 God Classes were detected by Lift in this project. Visit the Lift web console for more details.

@@ -275,17 +275,20 @@ public static synchronized void setSecurityProvider(String securityProvider) {
}

private static void register() {
if (!registrationDone) {
String noBCRegistrationAtRuntime = System.getProperty("bouncycastle.registration.runtime");
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of doing it like this, let's make it just a configuration in the config object. This will allow a user of the library to choose how to configure it, either through an env variable or through his own config.
Now we would be forcing them to set an env variable.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the quick feedback! 👍 Please take another look.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any updates? :)

Comment on lines 103 to 105
Properties properties = new Properties();
properties.load(DefaultConfig.class.getClassLoader().getResourceAsStream("sshj.properties"));
String property = properties.getProperty("sshj.bouncycastle.runtime.registration");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This approach requires reading a file from the class path, it seems like it would be better to avoid the lookup and make this a simple member variable of the DefaultConfig class.

Copy link
Author

@Hayvon Hayvon Nov 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its already possible to set the variable programmatically by using the DefaultConfig.

def config = new DefaultConfig()
config.setBouncycastleRuntimeRegistrationEnabled(true)

With my approach you can additionally add it via properties file. As @hierynomus already mentioned, this way the user can decide for himself what to use.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification, that makes sense.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you've misunderstood. It's up to the application that integrates sshj to decide how to pass the config to sshj. This kind of property or env reading code does not belong in the lib but rather in the surrounding app

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback. I actually misunderstood. I have taken out the property so that you can only set it via the DefaultConfig. Any other feedback you have?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any updates? :)

@@ -73,6 +73,7 @@
public DefaultConfig() {
setLoggerFactory(LoggerFactory.DEFAULT);
setVersion(readVersionFromProperties());
SecurityUtils.setBouncycastleRuntimeRegistration(isBouncycastleRuntimeRegistrationEnabled());
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you would add some tests, you'd see that you can never ever change the configuration flag, as it is already passed down in the constructor of the config if you do it like this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, you are right. Will address it asap

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any updates?

@Hayvon
Copy link
Author

Hayvon commented Nov 24, 2022

The current approach disables the bouncycastle runtime registration using the defaultconfig, but it does not work for GraalVM Native Image because the defaultconfig is called too late at runtime.

@Hayvon Hayvon reopened this Feb 17, 2023
@Hayvon
Copy link
Author

Hayvon commented Feb 17, 2023

New approach to skip the bouncycastle registration at runtime is to use a system property set by GraalVM. This is also used by Spring to determine if a native image is running.

@hierynomus
Copy link
Owner

I will reiterate on what I've said:

I think you've misunderstood. It's up to the application that integrates sshj to decide how to pass the config to sshj. This kind of property or env reading code does not belong in the lib but rather in the surrounding app

@exceptionfactory
Copy link
Contributor

@Hayvon, I opened pull request #861 that attempts to address the Bouncy Castle registration issue. Registration can be disabled in the current version of SSHJ using the SecurityUtils.setRegisterBouncyCastle() method, but there are a couple other places that expect it to be registered, so the pull request includes some additional changes that should help support this use case more generally.

@exceptionfactory
Copy link
Contributor

@Hayvon and @hierynomus is this pull request still necessary? With the changes in PR #861 supporting SSHJ configuration with Bouncy Castle registration, the changes here no longer appear to be required.

@hierynomus
Copy link
Owner

Indeed, I'll close this PR as the changes have been addressed in a better way in #861

@hierynomus hierynomus closed this Oct 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants