-
Notifications
You must be signed in to change notification settings - Fork 245
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
Conversation
…need not be touched
@@ -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()) { |
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.
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; |
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.
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; |
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.
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}"/> |
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.
Default false for new credentials created from the GUI.
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.
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 #205 (comment) for the GUI. |
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'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.
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? |
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 |
@@ -65,7 +65,7 @@ | |||
</scm> | |||
|
|||
<properties> | |||
<revision>2.4.2</revision> | |||
<revision>2.5</revision> |
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.
Just proposing a version bump. Do we really need to keep the micro version? Can revert if desired.
Understood. Sounds good, thanks for the explanation. |
@bitwiseman @car-roll @Wadeck any updates on this & jenkinsci/credentials-binding-plugin#132 & jenkinsci/ssh-credentials-plugin#70? |
JENKINS-44860
jenkinsci/credentials-binding-plugin#131 (comment)