Feature Request: Integration of a "Secret Files" Section for Public Repositories #162214
Replies: 1 comment
-
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi GitHub Team,
I’d like to propose a new feature aimed at enhancing the security of public repositories by enabling a “Secret Files” section. This feature would provide a safe and dedicated area for uploading or creating files that contain sensitive configuration data, such as API keys, private guidelines, or other confidential information, while keeping such data hidden from the public view.
Current Challenge:
In public repositories, every committed file and its history remain accessible to everyone. Although GitHub Secrets lets you store sensitive variables securely for GitHub Actions, it doesn’t provide a way to manage complete files that need to stay private. This limitation forces developers to resort to workarounds like encryption or using separate private repositories.
Proposed Solution:
I believe that integrating such a feature directly into the GitHub interface would significantly simplify and secure the management of sensitive data. This proposal aligns with GitHub’s commitment to building security into every aspect of your workflow by ensuring secrets and vulnerabilities remain out of the codebase while maintaining a robust software supply chain.
Thank you for considering this request. I look forward to your feedback on this proposal and any guidance on the best forum to discuss further enhancements.
Best regards,
dvelm
Beta Was this translation helpful? Give feedback.
All reactions