{"id":15752675,"url":"https://github.com/remram44/rhp-secret","last_synced_at":"2026-03-18T03:58:27.008Z","repository":{"id":66117860,"uuid":"382092265","full_name":"remram44/rhp-secret","owner":"remram44","description":"A proposal for reportable secrets","archived":false,"fork":false,"pushed_at":"2021-07-01T16:35:18.000Z","size":3,"stargazers_count":1,"open_issues_count":1,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2026-02-11T21:05:26.124Z","etag":null,"topics":["proposal","rfc","secret","secrets","security"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/remram44.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-07-01T16:20:40.000Z","updated_at":"2022-12-12T20:40:16.000Z","dependencies_parsed_at":"2023-02-20T19:45:37.269Z","dependency_job_id":null,"html_url":"https://github.com/remram44/rhp-secret","commit_stats":{"total_commits":4,"total_committers":1,"mean_commits":4.0,"dds":0.0,"last_synced_commit":"64dd7d0615b2a6d60114c2b03b5b947ed55176b6"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/remram44/rhp-secret","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/remram44%2Frhp-secret","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/remram44%2Frhp-secret/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/remram44%2Frhp-secret/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/remram44%2Frhp-secret/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/remram44","download_url":"https://codeload.github.com/remram44/rhp-secret/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/remram44%2Frhp-secret/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30646444,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-18T02:48:56.676Z","status":"ssl_error","status_checked_at":"2026-03-18T02:48:55.747Z","response_time":104,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["proposal","rfc","secret","secrets","security"],"created_at":"2024-10-04T07:04:00.971Z","updated_at":"2026-03-18T03:58:26.990Z","avatar_url":"https://github.com/remram44.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"A Proposal for Reportable Secrets\n=================================\n\nIntroduction\n------------\n\nThis documents proposes a new format for secrets, for example API key, to address the shortcomings of current systems.\n\nUse of \"secret tokens\" is common across systems. Historically, each system has used their own format, but it is common to make them recognizable in some way. For example, Amazon Web Services uses an `AKIA` prefix for access keys, SendGrid uses an `SG.` prefix on API keys, PyPI uses a `pypi-` prefix for their tokens, GitHub a `ghp_` prefix, etc.\n\nTo prevent accounts being hacked, code platforms have been automatically detecting tokens and reporting them. For example, [GitHub's \"secret scanning\"](https://docs.github.com/en/code-security/secret-security/about-secret-scanning) checks uploaded code for tokens in a variety of formats and reports them to both the code's author and the API service, which can revoke the leaked token. However because each token and service is different, this is done each service giving GitHub a regular expression to identify their token, and an API endpoint they can use to report and revoke found tokens.\n\nThe problems with that approach are:\n\n* While the API specified by GitHub is implemented by multiple services, it is useless to everyone except GitHub in practice\n* Building the list of token formats and reporting endpoints is an unnecessarily manual process, and currently only GitHub possess the list\n* Platforms (in particular code hosting platforms) not being able to implement scanning increases risk for users\n\nIn this document, I propose a way to fix those issues via a new unified secret format. The format would make it clear that the token is a secret, eliminating the need for multiple regular expressions, and would contain enough information to enable automated reporting, eliminating the need for a registry.\n\nAlternatives\n------------\n\nBuilding an open registry of regular expressions and reporting endpoints, available to everyone and not only GitHub, would also work. It would allow a new code hosting platform to scan for all those services without having to be contacted by each one. One such list is in [gitleaks](https://github.com/zricethezav/gitleaks/blob/master/config/default.go)\n\n[RFC 8959](https://www.rfc-editor.org/rfc/rfc8959.html) introduced a `secret-token:` URI scheme to make tokens recognizable, however it does not help with reporting in any way. We could extend this format, however there is a risk of collision with existing tokens, and this specification would be hard to discover.\n\nUsing a URL is another option. For example Sentry uses the format `https://123456789@sentry.io/12345` (Sentry is self-hostable, and they chose to include the user ID, domain, and key in the same string they call DSN).\n\nDesign\n------\n\nThe proposed format is:\n\n```\nrhp-secret:example.org/mysecretcontent\n```\n\n* The string `secret` makes this easily recognizable as a secret. Simply using `secret` might be too ambiguous, so I propose `rhp-secret` for \"reporting host prefixed secret\". This can be changed/improved. Using a unique string has the advantage of making this specification more discoverable.\n* The next part is a domain name. This allows for easy discovery of the related service and its leak reporting endpoint.\n* The rest of the string is service-specific, allowing each service to put whatever data they need there, for example a JWT token, a random string, a private key, etc.\n\nThe reporting protocol is close to [the GitHub one](https://docs.github.com/en/developers/overview/secret-scanning-partner-program#create-a-secret-alert-service), to avoid services having to implement a brand new endpoint. The endpoint is built from the included domain name by using the path `.well-known/report-leaked-secrets`, e.g. `https://example.org/.well-known/report-leaked-secrets`.\n\n```\nPOST /.well-known/report-leaked-secrets HTTP/1.1\nHost: example.org\nContent-Type: application/json\n\n[\n  {\n    \"token\": \"rhp-secret:example.org/mysecretcontent\",\n    \"type\": \"rhp-secret\",\n    \"url\": \"https://github.com/remram44/rhp-secret/blob/master/README.md\"\n  }\n]\n```\n\nLimitations and drawbacks\n-------------------------\n\n* This needs services to change their token format\n* There is now a competing IETF scheme (though it hasn't seen much adoption)\n* The format is kind of verbose (`rhp-secret:sendgrid.com/91on9SIkbUfSsfvfznkrVx.vAqI9VLmlANMdA7I5dc2TEwla_bkPCIK_6tFaq7FsTV` instead of `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`)\n\n### Potential drawbacks\n\n* You need to allow leaked tokens to be submitted from everywhere, not just GitHub. The security implications of this are not clear (e.g. potential for denial of service); this is not the way GitHub designed their protocol, as they recommend checking the included signature, but no motivation was provided\n* The reporting mechanism needs a service to have a domain name and to deploy the endpoint at the root, so it might not work for a service used from an IP or deployed in a subdirectory of a shared host.\n* GitHub provides a mechanism to report false-positives which is not part of this specification, though it could be added without breaking compatibility (as HTTP request header?).\n\nDiscussions\n-----------\n\n* [2021-01-31, Hackernews, on RFC 8959](https://news.ycombinator.com/item?id=25979908)\n* [2021-03-24, Hackernews, on GitHub adding PyPI secret scanning](https://news.ycombinator.com/item?id=26568651)\n  * Asked PyPI developer why their reporting endpoint needed to be protected by a GitHub signature\n    * He mentioned it might be used as an Oracle to check tokens, as that can be done without knowing the username (API use needs username + token)\n    * Someone mentioned denial-of-service related to revoking someone's token, however possession of the token leads to worse attacks, and you can always commit it to GitHub to get it revoked\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fremram44%2Frhp-secret","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fremram44%2Frhp-secret","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fremram44%2Frhp-secret/lists"}