Add PGP signatures

[smege1001]

There's no way to check if the SHA256 signature files are authentic.

MITM attacks can modify files and make verifying useless

[stripedpajamas]

Are you asking for PGP signatures to live on this repo's readme? How will that help?

[GitMensch]

The PGP signatures can be shared anywhere, including the VSCodium website. A tinkered download and an accordingly tinkered SHA256 is possible as it is possible to re-sign the binaries - but they will never have the public known PGP key that is used by VSCodium - whichever this is. Using PGP signatures solve all issues but "the CI that builds the binaries was attacked and distributes bad binaries to everyone with the correct PGP key".

[stripedpajamas]

Ok, I get the idea. I need some help in understanding what needs to change here. Currently the only signing that is taking place is on the Mac binaries, with my own Apple developer certificate.

What other signing would need to occur (and how)? Would it work to sign the sha256 files?

[d-damien]

Just make one file of all fingerprints and sign this file (that would also make your download section easier to read). Once you have setup your GPG key :

sha512sum * > releases.sha512
gpg --armor --sign releases.sha512

You include both files, releases.sha512 & releases.sha512.asc with releases. And we will verify with instructions you can include in readme & download section :

sha512sum --ignore-missing -c < releases.sha512
gpg --verify releases.sha512.asc

Considering the number of stars of this project, the next step if to protect the private key well. Keep it encrypted, on a safe computer where you don't install just anything. Have a backup off-site on some SD card, encrypted too. With only you and your best friend, or a few other major contributors, having the key's password (that can itself be kept in an offline password manager like KeepassXC).

I also recommend you use the key only for signing this software (or closely related softwares) ; use another one for personal use like E2E emails and such.

Getting familiar with key procedures (key renewal, key revoking if said computer gets hacked) would help.

Don't let all of that discourage you. Even a basic setup with only the first 2 bash lines up there is considerably better than nothing.

[GitMensch]

@daiyam Could you have a look at signing the binaries (or at least provide hash sums in the release page)?

[GitMensch]

Checking back one year later - we do have sh256 and sha1 sums now, the "only" missing part is a pgp key pair that is provided in the CI builder (only the public one may be checked in) and an adjustment in the build script to use that key - if available - to sign either each executable or the list of sha256 sums.

[d-damien]

It would be nice to have the checksums in a single file too. Just to reduce the number of files in releases.

Would it not be better to keep the private key offline ?

[daiyam]

Which private key?

[GitMensch]

The private key file for the gpg armored signatures. In any case it should be a special key that is only used in the CI build.

Obviously the password for this key file should not be added in this script but be used similar to the tokens that are currently used; and I think those tokens can be quite long, so a separate token may be used that contains the private key file's content (and then could be either temporary stored or used from stdin, if that works with gpg).

[daiyam]

Would it not be better to keep the private key offline ?

I did understand that question like if there were a private key in the repository and so public. It must never be the case since it will defeat the purpose of a private key...

[d-damien]

Now I'm wondering if online CI defeats the purpose of CI signed releases... I guess CI is fine for static analysis and similar (reading process), but technically any writing process in a CI could corrupt a release.

Disclosure : no expertise in CI.

Other suggestion : publish a copy of the checksums & signatures (small files) on a separate website. Signatures should already cover for this, but if the signing process gets broken, it's added security. vscodium.com doesn't seem to be hosted on github.

Also why not sha512 ?

[daiyam]

@d-damien CI signed releases are fine since the private won't be exposed to the public. But, yes, there is a risk. If the CI is hacked, then the hacker can access the private key (same as any computer)...

vscodium.com is hosted on github: https://github.com/VSCodium/vscodium.github.io

[d-damien]

Well the point of signing anything in the first place is E2E. Otherwise that's not inherently better than the signing that happens with HTTPS.

[daiyam]

For reference: https://www.linuxbabe.com/security/verify-pgp-signature-software-downloads-linux https://www.devdungeon.com/content/how-verify-gpg-signature And maybe adding OpenSSL signature will also be good: https://lindevs.com/sign-and-verify-file-signature-with-public-and-private-key-using-openssl

Just how to manage all those files in the github release???

[d-damien]

Do you mean there are too many files ? With my comment there would only be two files : https://github.com/VSCodium/vscodium/issues/402#issuecomment-822808599

Idk about OpenSSL, I think the principle is the same, so not necessarily more secure unless you want to limit implementation flaws risks.

[github-actions[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment, and we'll keep it open. If you have any new additional information, please include it with your comment!

[daiyam]

+1

[github-actions[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment, and we'll keep it open. If you have any new additional information, please include it with your comment!

[daiyam]

+1