Security gap: Activity tab retains history after force push

[laitifranz]

Select Topic Area

Product Feedback

Body

Related: https://github.com/orgs/community/discussions/53140#discussioncomment-6052248 (closed without resolution)

When a developer accidentally commits a secret (API key, token, etc.), or doesn't want anyone to see older commits, and force-pushes a rewritten history to remediate it, the /activity tab still publicly shows the old commit SHAs (3 dots > Compare changes) and branch events, visible to anyone, including unauthenticated users.

This creates a silent false sense of security: the developer thinks the leak is fixed, but the activity log keeps a permanent breadcrumb trail pointing to the exposed commits.

Suggested fixes

• Warn the user at force push time that activity history is retained
• Allow repo owners to clear the activity log, or restrict its visibility to repo owners only, or disable the feature by default

This is a common real-world scenario and the current behavior directly undermines GitHub's own recommended remediation steps for secret leakage.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[jlceaser]

This is a legitimate and underappreciated security concern. I want to add some technical context for anyone reading this.

The core problem:

Even after a force push, Git objects are not immediately garbage-collected on GitHub's servers. This means:

• Old commit SHAs remain accessible via direct URL (github.com/user/repo/commit/) for some time
• The /activity tab retains a permanent log of branch events with old SHAs
• Anyone who knows (or discovers) the old SHA can still view the exposed content
• GitHub's own docs say "force push to remove the commit" as a remediation step, which gives a false sense of security

What this means in practice:

1. Developer accidentally commits an API key
2. Developer follows GitHub's remediation guide: rewrite history + force push
3. Developer rotates the key (hopefully)
4. But if they don't rotate the key — thinking the force push was enough — the secret is still reachable via the activity tab or cached
   SHAs

What affected users should do right now:

• Always rotate exposed secrets immediately. Never rely solely on force push.
• Use git-filter-repo or BFG Repo Cleaner to scrub secrets from all refs
• Contact https://support.github.com to request a server-side garbage collection on your repo — they can do this manually
• Check if GitHub's https://docs.github.com/en/code-security/secret-scanning caught the exposure and revoked the token automatically

+1 on the suggested fixes. At minimum, GitHub should:

• Display a warning on force push that activity history is retained
• Allow repo admins to purge activity log entries
• Document this behavior clearly in the
  https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository

This isn't just a UI issue — it's a gap in the security remediation workflow.