Could I get a review on this PR making releases on software-agent-sdk be done by openhands-release bot for consistency? github.com/OpenHands/software-agent-sdk/pull/6516

@bland-bear-604 Look at the PR and related repos. Does this shared release token mean that if there’s a compromise in one of the main open source repos (sdk, openhands, automation, extensions), then it would extend to enterprise? with write access?

Yes—if the compromise reaches CI that can read the shared App private key. That key can mint fresh tokens for enterprise with the App’s installed write permissions. A stolen repo-scoped token alone cannot expand its scope; an ordinary fork PR does not normally receive these secrets. All four repos pass the release secrets into the shared workflow. #6516 explicitly requests enterprise access; SDK main already uses a PAT to push enterprise branches and the App key for Cloud chart bumps. The release bot also already authors enterprise release PRs. So this crosses an existing boundary. Branch writes do not automatically mean permission to merge protected main. I checked the workflows, not the live org secret/install settings. If these are the same App credentials as documented, separate Apps for OSS and enterprise, with enterprise-owned bump automation, would separate that access. Narrowing the minted token alone won’t protect a leaked private key. AI check by SmolPaws on Engel’s behalf.

Cc @able-napkin-92802 do you think we should separate these tokens?

@limited-student-10747 I think maybe this workflow could work the other way around: from enterprise, have its workflow or automation, which uses the sdk? So that the sdk doesn’t need write access to enterprise. Enterprise uses the sdk, the sdk can’t write to enterprise Then enterprise team can take care of that dependency as they see fit: they may want pass it through a security check, or through a supply chain prompt, or anything really. A bit of a boundary

Yeah, I’m not in charge of this part but maybe Joe can take a look

Flipping this so that Enterprise can pull from the SDK, rather than having the SDK push to Enterprise, is probably the simplest solution here. Then we can stop giving the SDK any level of access to the Enterprise repo.

@able-napkin-92802 for the OSS team we’re discussing getting to the place so that we can auto-release from main every night (if all tests pass), and having an inconsistent process across the OSS repos is a barrier to that.

Ah, OK. For that release process, can you just use credentials per-repo that only have access to publish artifacts/create tags within that repo? I know there may be existing actions that push to other repos like enterprise. That’s not ideal, but seems like something we can leave be for a little bit longer and come back to harden.

OK, I’ll walk through that process.