-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
JENKINS-56553 Make proxy config compatible with JCasC without workarounds on the plugin side #3935
JENKINS-56553 Make proxy config compatible with JCasC without workarounds on the plugin side #3935
Conversation
*/ | ||
public String getPassword() { | ||
return Secret.toString(secretPassword); | ||
public Secret getPassword() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This breaks compatibility but I don't know of a better way of doing this,
I've ensured that JCasC won't break jenkinsci/configuration-as-code-plugin#769
If this change isn't done, the change functionally works but introduces a security risk in that the password would be exported in plain text.
This change has a compatibility risk but is more secure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I can tell, Secret seems to migrate automatically from String. The main backward incompatibility would be if anything calls this method directly and not via Jelly or similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Binary compatibility is broken here for an user. There is no automatic type conversion in Java, not sure what @jvz means here. Migration in stapler?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The secret class has a converter that converts strings into secrets automatically.
For a user this change is individual to the best of my knowledge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We really need to retain binary compatibility here somehow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did that before with the getSecretPassword
additional getter which wasn't ideal but @daniel-beck suggested reverting and doing the change as it shouldn't impact anyone?
#3935 (comment)
open to suggestions though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oleg-nenashev We really don't; I've been unable to identify any plugins using this API.
While we could add a bridge method, I would expect the side effects of that to be potentially far worse than just fixing the return type like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change looks good apart from the compatibility but 🤷♂️
@oleg-nenashev @jglick ?
We don't generally break compatibility except for a very good reason. Saving 3 lines of code in a plugin is not a very good reason. Checking all public plugins for calls to the method yields no results -- seems they're all mostly interested in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Binary compat issue needs to be fixed, I agree with @daniel-beck's evaluation
@oleg-nenashev the password variable was deprecated 8 years ago in #130 / @daniel-beck evaluated that it was highly unlikely that anyone would be calling it, based on searching all public plugins... |
Compat issue fixed, I've changed it to use @oleg-nenashev could you re-review please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timja have you verified that password
is being passed correctly during the form submission? Unless you change the field in Jelly, it will be trying to pass a secret
field which does not longer have databinding
Thanks for the quick review @oleg-nenashev You were right it needed an update, it works now: |
core/src/main/resources/hudson/ProxyConfiguration/config.groovy
Outdated
Show resolved
Hide resolved
There's a test in the JCasc plugin, I couldn't see any examples here of core depending on a plugin for testing. |
@darxriggs https://github.com/jenkinsci/configuration-as-code-plugin/pull/784/files There's an example of the test, it's not passing on jenkins as it's ignoring my Jenkinsfile change for the version bump Tried updating it in the pom file and it kept failing for missing dependencies, added like ~12 and then gave up, seemed like transitive dependencies from core weren't being resolved from incrementals... |
Test demonstrating this working using the incrementals version: (Couple of unrelated test changes in there to make JCasC pass on higher core version) |
@oleg-nenashev could you re-review when you have a chance please? |
Nudge: @oleg-nenashev please? |
FWIW I would be fine with just changing the signature of the |
JCasC PR updated pointing at the new incrementals and it has a green build: |
…enkins into JENKINS-56553-proxy-config-jcasc
@varyvol tests pass now on JCASC PR: jenkinsci/configuration-as-code-plugin#784 |
@timja fine by me, I had already approved, I just was suggesting some test coverage in case there wasn't, which is not the case. |
CI seems flakey today... (note this build has previously been green with no code changes), i.e. see the green incrementals check |
4 approvals, adding ready for merge... |
@oleg-nenashev this is marked as you requesting a change, this was addressed. |
@oleg-nenashev you able to merge this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks right.
I plan to merge it tomorrow if no negative feedback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This caused JENKINS-61692.
@@ -11,8 +11,8 @@ f.entry(title:_("Port"),field:"port") { | |||
f.entry(title:_("User name"),field:"userName") { | |||
f.textbox() | |||
} | |||
f.entry(title:_("Password"),field:"password") { | |||
f.password(value:instance?.encryptedPassword) | |||
f.entry(title:_("Password"),field:"secretPassword") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Field renamed without adapting validateButton
arguments in https://github.com/jenkinsci/jenkins/pull/3935/files#diff-4af47ca230111a1e83ea06084040271fR25
Fix attempt in 8dcf818
public ProxyConfiguration(String name, int port, String userName, String password, String noProxyHost, String testUrl) { | ||
this.name = Util.fixEmptyAndTrim(name); | ||
this.port = port; | ||
this.userName = Util.fixEmptyAndTrim(userName); | ||
this.secretPassword = Secret.fromString(password); | ||
String tempPassword = Util.fixEmptyAndTrim(password); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better hope actual passwords never have whitespace at the beginning or end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I generally do not recommend trim
ming input unless you specifically know that leading/trailing whitespace could not be legal.
See JENKINS-56553.
Proposed changelog entries
Submitter checklist
* Use the
Internal:
prefix if the change has no user-visible impact (API, test frameworks, etc.)It's just getters and setters and requires a plugin dependency to test that configuration as code works, I've ran the test and manually tested it
Desired reviewers
@Casz @ndeloof