[jglick]

Alternative to jenkinsci/credentials-plugin#1088, for testing in jenkinsci/cursor-origin-branch-source-plugin#28.

[jglick]

@MarkEWaite @dwnusbaum what do you think about an API like this? Obviously it is missing Javadoc, could be Beta, interface could be a top-level type, API-visible identifiers could be changed, etc.

While I have tested a usage in the Origin branch source plugin, the more important target by far is the GitHub branch source plugin. As discussed in the linked issue, currently you are advised to use an inherently less-secure mode of GitHub App credentials if you want to use the App to check out Pipeline Groovy libraries. This is because the ultimate call to getPassword() from the git plugin omits any context. GitHubAppCredentials is thus forced to offer an unrestricted installation token, risking abuse by jobs which expose that token to user build scripts on agents. Multibranch checkout scm can use a restricted token only because jenkinsci/credentials-plugin#293 gives a crude signal as to what repository is involved—but this is better suited to more accurately finding static credentials defined in folders, not to actually affect a dynamically generated “password” as it is used in jenkinsci/github-branch-source-plugin#527 + jenkinsci/github-branch-source-plugin#822.

[MarkEWaite]

I like the idea very much. It could also be useful in some other contexts where a credential needs to be scoped to a specific git repository. The idea for the other contexts is not yet fully formed in my mind, but @mikecirioli and I have been discussing a case where something like this might be a real help.

[jglick]

OK, let me clean up the API. I will definitely update the proposed usage in origin-branch-source. If I have time I will look into whether github-branch-source can be (compatibly) made to take advantage of the option.

[dwnusbaum]

I don't quite follow the impl in jenkinsci/cursor-origin-branch-source-plugin#31. It looks like any clone for a repo in the org would get a repo-specific token, but there's no check about whether that repo should be allowed to be cloned or not. If so, then this doesn't address the same issue as jenkinsci/github-branch-source-plugin#1456, since it seems like anyone with write access to a repo could use the git step in a Pipeline and pass the credentialsId parameter to a "restricted" Cursor Origin credential and clone any repo in the org.

If you have not already seen it, https://www.jenkins.io/doc/book/security/securing-org-folders-and-multibranch-pipelines describes the general class of issues we were trying to fix with the github-branch-source changes.\

(Maybe I misunderstand, and you have to use withCredentials in this case, because the git step would fail to use the origin-specific credentials directly, but IDK. If so, then I think it's fine, since withCredentials wouldn't support inference.)

[jglick]

any clone for a repo in the org would get a repo-specific token

So long as the app is installed on that repo, yes. Otherwise the token request would fail (or produce an invalid token).

anyone with write access to a repo

Well, generally, ability to write & run Pipeline script in a job to which the credential is made accessible.

could use the git step in a Pipeline and pass the credentialsId parameter to a "restricted" Cursor Origin credential and clone any repo

Yes. The resulting token would be r/o and scoped to the selected repo.

I can research whether it is possible to distinguish this case from the others. The credential class has only very indirect clues as to how it is being used:

• whether forRun(Run) was called, and if so, whether that seems to be on a branch project (or CpsScmFlowDefinition)
• whether the API defined in this PR was called
• whether getPassword was called from the controller (e.g., withCredentials) or an agent (e.g., checkout)

If you have not already seen it

I had not, only the github-branch-source docs.

[jglick]

@dwnusbaum I think I addressed the problem you found in jenkinsci/cursor-origin-branch-source-plugin#31, at the cost of no longer simplifying the impl as much: I still need an optional dep to reimplement some of the logic of SCMVar. (I hoped to just be able to check if SCMRevisionAction is set on the build. Unfortunately this does not help because that action does not record which repo the revision comes from, only the hash and branch name.)

[dwnusbaum]

@jglick Yes from a quick look I think that the repoTrusted flag addresses the issue I noticed.

[Copilot]

Copilot review overview

🟡 Changes recommended

The implementation passes nullable URLs to a non-null API, accepts unsupported replacement credentials, and lacks integration tests.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1

Open (2)

• Avoid passing nullable URLs to non-null contextualizer · New
• Add tests for credential contextualizer replacement and fallback · New

What changed in this PR

Adds a beta extension point for contextualizing Git credentials using build and repository URL context.

Changes:

• Defines GitCredentialContextualizer.
• Invokes contextualizers during GitSCM credential lookup.

File	Description
GitCredentialContextualizer.java	Defines the contextualization API.
GitSCM.java	Applies contextualizers to checkout credentials.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[jglick]

jenkinsci/cursor-origin-branch-source-plugin#31 is still blocked waiting for this. I have not had time to check whether github-branch-source can be simplified by it.

[jglick]

Thanks @MarkEWaite! I guess this plugin is still not using CD; what sort of release schedule do you use? Seems like every couple months or so?

[MarkEWaite]

Thanks @MarkEWaite! I guess this plugin is still not using CD; what sort of release schedule do you use? Seems like every couple months or so?

I'll likely release this week. I release when I feel there are enough changes to justify a release. In this case, there are several bug fixes and this enhancement that seem like a good fit for a release.

I need to run the release candidate through the plugin BOM just to be sure that it has not created any surprises. That should be possible this week.

[MarkEWaite]

Included in git plugin release 5.11.0