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-44860] UsernameCredentials.isUsernameSecret #205

Merged
merged 9 commits into from
Jun 2, 2021

Conversation

jglick
Copy link
Member

@jglick jglick commented May 6, 2021

@@ -90,7 +90,11 @@ Result name(@NonNull Credentials credentials, @NonNull Class<?> clazz) {
if (nameWith != null) {
try {
CredentialsNameProvider nameProvider = nameWith.value().newInstance();
return new Result(nameProvider.getName(credentials), nameWith.priority());
String name = nameProvider.getName(credentials);
if (!name.isEmpty()) {
Copy link
Member Author

Choose a reason for hiding this comment

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

Make it possible to just return credentials.getDescription() and if that happens to be the empty string, still behave reasonably (choose a different provider).

@@ -53,6 +55,9 @@
@NonNull
private final Secret password;

@Nullable
private Boolean usernameSecret = false;
Copy link
Member Author

Choose a reason for hiding this comment

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

Default false in the Java constructor which would be used only from tests or scripts.

@@ -72,6 +77,13 @@ public UsernamePasswordCredentialsImpl(@CheckForNull CredentialsScope scope,
this.password = Secret.fromString(password);
}

private Object readResolve() {
if (usernameSecret == null) {
usernameSecret = true;
Copy link
Member Author

Choose a reason for hiding this comment

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

Default true for deserialized credentials, either from settings predating the upgrade, or REST uploads as XML.

@@ -28,6 +28,9 @@
<f:entry title="${%Username}" field="username">
<f:textbox/>
</f:entry>
<f:entry field="usernameSecret">
<f:checkbox title="${%Treat username as secret}"/>
Copy link
Member Author

Choose a reason for hiding this comment

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

Default false for new credentials created from the GUI.

@Wadeck Wadeck self-requested a review May 12, 2021 08:15
Copy link
Contributor

@Wadeck Wadeck left a comment

Choose a reason for hiding this comment

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

Manually tested:

  • ✔️ Existing credentials are not changing behavior
  • ✔️ New credentials let the checkbox uncheck (but this could be changed)

Of course, no masking until credentials-masking is merged as well.

Will merge this for next release

@bitwiseman
Copy link

bitwiseman commented May 12, 2021

@jglick @Wadeck
Why not default to usernameSecret=true in all cases?
We want to allow users to show user names, but what the reasoning behind making show the user name the default for UI and script?

@jglick
Copy link
Member Author

jglick commented May 12, 2021

@bitwiseman #205 (comment) for the GUI.

Copy link
Contributor

@car-roll car-roll left a comment

Choose a reason for hiding this comment

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

I'm fine with making username not secret as default going forward since the behavior for legacy credentials is to keep them hidden. Either way works for me.

@bitwiseman
Copy link

@bitwiseman #205 (comment) for the GUI.

I don't understand. Yes, I know it defaults to false in GUI. Why does it default to false? The GUI couldn't default to true/checked?

@jglick
Copy link
Member Author

jglick commented May 13, 2021

I know it defaults to false in GUI. Why does it default to false?

Sorry, did not get your question. We expect the username to be nonsecret in most cases, and until now it was displayed in credentials dropdowns to anyone with view configuration permissions. In fact the originally submitted PRs just unconditionally began showing usernames in logs, merely by virtue of updating the credentials-binding plugin, which I was uncomfortable with. So here I am trying to walk a compromise path that poses no risk of unwanted surprise for an existing installation, while guiding new configurations to display the username.

@@ -65,7 +65,7 @@
</scm>

<properties>
<revision>2.4.2</revision>
<revision>2.5</revision>
Copy link
Member Author

Choose a reason for hiding this comment

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

Just proposing a version bump. Do we really need to keep the micro version? Can revert if desired.

@bitwiseman
Copy link

I know it defaults to false in GUI. Why does it default to false?

Sorry, did not get your question. We expect the username to be nonsecret in most cases, and until now it was displayed in credentials dropdowns to anyone with view configuration permissions. In fact the originally submitted PRs just unconditionally began showing usernames in logs, merely by virtue of updating the credentials-binding plugin, which I was uncomfortable with. So here I am trying to walk a compromise path that poses no risk of unwanted surprise for an existing installation, while guiding new configurations to display the username.

Understood. Sounds good, thanks for the explanation.

@jglick
Copy link
Member Author

jglick commented Jun 2, 2021

@jglick jglick merged commit a1d8809 into jenkinsci:master Jun 2, 2021
@jglick jglick deleted the show-username-JENKINS-44860 branch June 2, 2021 22:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants