Aftercare for Users of Versions with Potentially Exposed Secrets

[ryo-kagawa]

I propose this suggestion while acknowledging that it may be considered a non-recommended flow.
I understand that rejection of this proposal is a natural possibility.

Necessity for Aftercare

• There's a possibility that users might unknowingly continue using the latest version without realizing that Secrets have been exposed.

Here's the detailed proposal

1. Append the build metadata "+org" to all existing tags.
2. Update all existing tags to a commit that outputs the following error message

Please take the following actions:
1. Rotate your Secrets as they may have been compromised.
2. Either update to version v46.0.0 or later, or if you need to use the current version, specify vX.Y.Z+org.

This will at least let you know that secrets need to be rotated if the user is using a problematic version at the time of the action.

[samdenty]

Could GitHub not just do a site-wide scan of all the affected tokens printed in logs, and use the secret scanning revocation infra to mark them as leaked?

[jackton1]

Hi @ryo-kagawa Thank you for your thoughtful proposal and for raising an important point about addressing potential exposure of secrets. I completely understand your concern and the intent to proactively notify users about potential risks.

However, modifying existing tags and appending build metadata can create significant challenges. These changes would break workflows that rely on immutable tags, violate Git best practices, and introduce unnecessary complexity that could confuse users. Such actions might unintentionally disrupt processes for many users, which is something we want to avoid.

Instead, we’ve chosen a more stable and user-friendly approach. We are addressing the issue through clear communication in release notes, repository advisories, and other channels.

This ensures users are informed about the need to rotate secrets without disrupting their workflows or introducing changes that could lead to misunderstandings.

I truly appreciate the care and thoughtfulness behind your suggestion, and I hope this explanation provides clarity on why we’ve taken this approach. Thank you again for raising this, and we consider the matter resolved. If you have any further concerns or ideas, I’m happy to discuss them.

[alper]

These changes would break workflows that rely on immutable tags

It's fine to break the workflows I'd say in this case.