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

JENKINS-56553 Make proxy config compatible with JCasC without workarounds on the plugin side #3935

Merged
merged 23 commits into from
Nov 14, 2019

Conversation

timja
Copy link
Member

@timja timja commented Mar 14, 2019

See JENKINS-56553.

Proposed changelog entries

  • Internal: JENKINS-56553 Make ProxyConfiguration compatible with configuration-as-code plugin. Workaround on the JCasC plugin side is no longer required

Submitter checklist

  • JIRA issue is well described
  • Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change). Examples
    * Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
  • Appropriate autotests or explanation to why this change has no tests
    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
  • NA For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@Casz @ndeloof

*/
public String getPassword() {
return Secret.toString(secretPassword);
public Secret getPassword() {
Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

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

Copy link
Member Author

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

Copy link
Member

@daniel-beck daniel-beck May 10, 2019

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.

Copy link
Member

@jetersen jetersen left a 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 ?

@daniel-beck
Copy link
Member

daniel-beck commented Mar 14, 2019

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 #createProxy. So it might be safe enough to do.

@daniel-beck daniel-beck added needs-justification This PR lacks a motivation for the proposed change. and removed needs-justification This PR lacks a motivation for the proposed change. labels Mar 14, 2019
Copy link
Member

@oleg-nenashev oleg-nenashev left a 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

@timja
Copy link
Member Author

timja commented Mar 18, 2019

@oleg-nenashev the password variable was deprecated 8 years ago in #130 /
3f13f6d

@daniel-beck evaluated that it was highly unlikely that anyone would be calling it, based on searching all public plugins...

@timja
Copy link
Member Author

timja commented Mar 20, 2019

Compat issue fixed, I've changed it to use secretPassword for JCasC

@oleg-nenashev could you re-review please?

Copy link
Member

@oleg-nenashev oleg-nenashev left a 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

@timja
Copy link
Member Author

timja commented Mar 20, 2019

Thanks for the quick review @oleg-nenashev
I did check that the form worked, but I didn't actually validate the value was correctly saved (given that it comes back as ****'s in the form, I was just assuming it was working, my bad)

You were right it needed an update, it works now:

image

@darxriggs
Copy link
Contributor

darxriggs commented Mar 21, 2019

I suggest to also implement a test for JCasC import & export.
For example see this one for a test that uses one config file to test import & export.
Using Groovy & Spock in this one I find more readable.
If there are better ways I am also interested.

@timja
Copy link
Member Author

timja commented Mar 22, 2019

There's a test in the JCasc plugin, I couldn't see any examples here of core depending on a plugin for testing.
This would be a too recent version of core to be merged to master of JCasC plugin, I can open a PR to show a passing build if you want?

@timja
Copy link
Member Author

timja commented Mar 22, 2019

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

@timja
Copy link
Member Author

timja commented Mar 24, 2019

Test demonstrating this working using the incrementals version:
jenkinsci/configuration-as-code-plugin#784

(Couple of unrelated test changes in there to make JCasC pass on higher core version)

@timja
Copy link
Member Author

timja commented Mar 25, 2019

@oleg-nenashev could you re-review when you have a chance please?

@timja
Copy link
Member Author

timja commented Mar 29, 2019

Nudge: @oleg-nenashev please?

@daniel-beck
Copy link
Member

FWIW I would be fine with just changing the signature of the password stuff since that's not actually used anywhere. I apologize for the unclear comment I left, it sort of evolved after I checked the plugin ecosystem for actual uses of this.

@timja
Copy link
Member Author

timja commented Apr 10, 2019

JCasC PR updated pointing at the new incrementals and it has a green build:
jenkinsci/configuration-as-code-plugin#784

…enkins into JENKINS-56553-proxy-config-jcasc
@timja
Copy link
Member Author

timja commented Oct 18, 2019

Code looks good. Has any automated test being implemented, maybe on JCasC side?

@varyvol tests pass now on JCASC PR: jenkinsci/configuration-as-code-plugin#784
(had to make some changes to fix upper bounds and trilead-api failures bumping the core version to 2.201)

@timja timja closed this Oct 18, 2019
@timja timja reopened this Oct 18, 2019
@varyvol
Copy link

varyvol commented Oct 18, 2019

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

@timja timja closed this Oct 18, 2019
@timja timja reopened this Oct 18, 2019
@timja
Copy link
Member Author

timja commented Oct 18, 2019

CI seems flakey today... (note this build has previously been green with no code changes), i.e. see the green incrementals check

@timja timja added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label Oct 18, 2019
@timja
Copy link
Member Author

timja commented Oct 18, 2019

4 approvals, adding ready for merge...

@timja timja closed this Oct 19, 2019
@timja timja reopened this Oct 19, 2019
@timja timja closed this Oct 30, 2019
@timja timja reopened this Oct 30, 2019
@timja timja closed this Oct 30, 2019
@timja timja reopened this Oct 30, 2019
@timja
Copy link
Member Author

timja commented Oct 31, 2019

@oleg-nenashev this is marked as you requesting a change, this was addressed.
Would you be able to take another look please or dismiss your review?

@timja timja closed this Nov 10, 2019
@timja timja reopened this Nov 10, 2019
@timja
Copy link
Member Author

timja commented Nov 12, 2019

@oleg-nenashev you able to merge this?

Copy link
Member

@oleg-nenashev oleg-nenashev left a 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

@oleg-nenashev oleg-nenashev added the rfe For changelog: Minor enhancement. use `major-rfe` for changes to be highlighted label Nov 13, 2019
@oleg-nenashev oleg-nenashev changed the title JENKINS-56553 Make proxy config compatible with JCASC JENKINS-56553 Make proxy config compatible with JCasC without workarounds on the plugin side Nov 13, 2019
@oleg-nenashev oleg-nenashev merged commit f103b78 into jenkinsci:master Nov 14, 2019
Copy link
Member

@daniel-beck daniel-beck left a 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") {
Copy link
Member

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);
Copy link
Member

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.

Copy link
Member

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 trimming input unless you specifically know that leading/trailing whitespace could not be legal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin-api-changes Changes the API of Jenkins available for use in plugins. ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback rfe For changelog: Minor enhancement. use `major-rfe` for changes to be highlighted
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants