Exactly. Host keys are about authentication, not connection security. Presumably the upthread comment is trying to say that "ssh communication with github could have been subject to an undetectable MitM attack by an attacker with access to this key"[1], which isn't remotely the same thing as "all communication with GH since the founding of the company has to be considered compromised".

[1] Which is sort of tautological and silly, because that's true of all sites and all host keys. What the comment was trying to imply was that the choice of storage of this key invalidates any trust we might have in GitHub/Microsoft regarding key management, and that therefore we shouldn't trust them. Which is also tautological and silly. Either you trust them or you don't, that's not a technological argument.

Agreed; GitHub documentation refers to repo “visibility,” not “security,” and that is an intentional distinction.

When we signed on with GH as a paying customer over a decade ago, they were quite clear that private repos should not be considered secure storage for secrets. It’s not encrypted at rest, and GitHub staff have access to it. It takes only a few clicks to go from private to public.

It is encrypted at rest: https://github.blog/changelog/2019-05-23-git-data-encryption...

Not criticizing you, your technical correction is valid, but the discussion is besides the point. "Encryption at rest" is basically meaningless for something like GitHub. Not being able to pull out a hard drive in a data center and read it at home has been table stakes for some time. But how few people are able to do that anyway? A blog post like the above is just necessary to tick some boxes to comply with this or that regulation.

The real question is how many services are able to access the data live and how many support and debug interfaces (indirectly) allow you to read it. Measure GitHub's success in securing the secrecy of private repos in how few employees can breach it without causing alarms. Even without cynicism I would be surprised if it was their main concern. Data integrity is far more important for code. (There are notable exceptions, of course. If applicable, don't put it in the cloud!)

You shouldn't commit unencrypted secrets to git anyway, public or private, on-site or in cloud.

There are plenty of tools to either keep them encrypted (we just use simple GPG, but our team is small) or just auto-generate and never show to user in the first place (various key vaults that can be used from automation like HashiCorp's Vault)

The person I'm replying to is arguing that their source code itself is the secrets they're trying to protect.

I would also add that your ability to pretend to be the client to the server is also limited, if ssh key based client authentication is used. This means that even if the host key is leaked, an attacker will not be able to push in the name of the attacked client. The attacker will be able to pretend to be the server to the client, and thus be able to get the pushed code from the client (even if the client just added one patch, the attacker can pretend to be an empty repo server side and receive the entire repo.

If ssh token based auth is used, it's different of course, because then the server gets access to the token. Ideally Github would invalidate all their auth tokens as well.

The fun fact is that a token compromise (or any other attack) can still happen any point in the future with devices that still have outdated ssh keys. That's a bit unfortunate as no revocation mechanism exists for ssh keys... ideally clients would blacklist the ssh key, given the huge importance of github.

WKD also lacks key revocation and CT Certificate Transparency.

E.g. keybase could do X.509 like Certificate Transparency.

:

  $ keybase pgp -h
  NAME:
   keybase pgp - Manage keybase PGP keys

  USAGE:
   keybase pgp <command> [arguments...]

  COMMANDS:
   gen          Generate a new PGP key and write to local secret keychain
   pull         Download the latest PGP keys for people you follow.
   update       Update your public PGP keys on keybase with those exported from the local GPG keyring
   select       Select a key from GnuPG as your own and register the public half with Keybase
   sign         PGP sign a document.
   encrypt      PGP encrypt messages or files for keybase users
   decrypt      PGP decrypt messages or files for keybase users
   verify       PGP verify message or file signatures for keybase users
   export       Export a PGP key from keybase
   import       Import a PGP key into keybase
   drop         Drop Keybase's use of a PGP key
   list         List the active PGP keys in your account.
   purge        Purge all PGP keys from Keybase keyring
   push-private Export PGP keys from GnuPG keychain, and write them to KBFS.
   pull-private Export PGP from KBFS and write them to the GnuPG keychain
   help, h      Shows a list of commands or help for one command

  $ keybase pgp drop -h
  NAME:
   keybase pgp drop - Drop Keybase's use of a PGP key

  USAGE:
   keybase pgp drop <key-id>

  DESCRIPTION:
   "keybase pgp drop" signs a statement saying the given PGP
   key should no longer be associated with this account. It will **not** sign a PGP-style
   revocation cert for this key; you'll have to do that on your own.

/?q=PGP-style revocation cert https://www.google.com/search?q=PGP-style+revocation+cert :

- "Revoked a PGP key, is there any way to get a revocation certificate now?" https://github.com/keybase/keybase-issues/issues/2963

- "Overview of Certification Systems: X.509, CA, PGP and SKIP"

...

- k8s docker vault secrets [owasp, inurl:awesome] https://www.google.com/search?q=k8s+docker+vault+secrets+owa... https://github.com/gites/awesome-vault-tools

- Why secrets shouldn't be passed in $ENVIRONMENT variables; though e.g. the "12 Factor App" pattern advises to parametrize applications mostly with environment variables that show in /proc/pid/environ but not /proc/pid/cmdline

W3C DID supports GPG proofs and revocation IIRC:

"9.6 Key and Signature Expiration" https://www.w3.org/TR/did-core/#key-and-signature-expiration

"9.8 Verification Method Revocation" https://www.w3.org/TR/did-core/#verification-method-revocati...

Blockerts is built upon W3C DID and W3C Verified Credentials, W3C Linked Data Signatures, and Merkel trees (and JSON-LD). From the Blockerts FAQ https://www.blockcerts.org/guide/faq.html :

> How are certificates revoked?

> Even though certificates can be issued to a cohort of people, the issuer can still revoke from a single recipient. The Blockcerts standard supports a range of revocation techniques. Currently, the primary factor influencing the choice of revocation technique is the particular schema used.

> The Open Badges specification allows a HTTP URI revocation list. Each id field in the revokedAssertions array should match the assertion.id field in the certificate to revoke.

Re: CT and W3C VC Verifiable Credentials (and DNS record types for cert/pubkey hashes that must also be revoked; DoH/DoT + DNSSEC; EDNS): https://news.ycombinator.com/item?id=32753994 https://westurner.github.io/hnlog/#comment-32753994

"Verifiable Credential Data Integrity 1.0: Securing the Integrity of Verifiable Credential Data" (Working Draft March 2023) > Security Considerations https://www.w3.org/TR/vc-data-integrity/#security-considerat...

If a system does not have key revocation it cannot be sufficiently secured.

> you should not store it on the cloud.

Well, at least not without encryption that is under your control.

It's worth saying that GitHub also has GitHub AE, which has some requirements (e.g. 500+ heads) but is a lot better for paranoid administrators, offering stricter audit results (FedRAMP High is no joke), data residency, stricter auth requirements, etc etc. I'd _imagine_ that such an environment is deployed as an isolated managed GitHub Enterprise instance, and at the very least in that environment I'd expect all data to be secured encrypted at rest.