Add page that instructs on how to verify downloads

[patrickbkr]

This is non typical in that it encourages users to check the fingerprints with third party sources.
Currently it states that devs list their gpg fingerprint on their Github profile. Unsure if we want to enforce that. But I'd like to provide some way where users can verify a key other than just downloading it. It might even be different for each user.
I didn't bother adding keys for the uploaders of rather early (coke, masak, pmichaud, froggs, ...). Should I?

I'm looking for feedback on how to improve this. Pinging @jdv @coke because I have the feeling you might have valuable input here.

Does anyone have Zoffix' public key available? I didn't find it on any keyserver.

ps. My local repo already contains the public keys the page offers for download. I intentionally left that out it this PR until we decide this is the way we want to go.

[coke]

I don't have anything particularly insightful to add, and I'm not sure I ever signed any of the releases I did.

[patrickbkr]

@AntonOks, @Altai-man, @jdv I'd like to have your feedback on this PR. Merging it would require your action. It would at least be necessary for you to list your PGP key fingerprint on your GitHub profile (like I did: https://github.com/patrickbkr) and if possible also on other sites.

I am open for statements like: "This is stupid. Why don't we do it this other way that's much saner?"

[patrickbkr]

Some more information on the "why". (The usage of the words "key" and "key fingerprint" are intentional, they are not interchangeable.)

Why should we sign releases?

The reason why releases should be signed is to provide protection from malicious modification of release files. If release files are always signed with the same key, the users can verify, that the release they have downloaded now was made by the same person that did the release the last time they downloaded something.

Why should releasers provide their keys on rakudo.org when they are already available on a keyserver?

The very popular keys.openpgp.org strips signings off of keys. This means that keys uploaded to that site can not be used to build a web of trust. So having the keys including the signings available for download somewhere makes sense.
It would also be a good idea to have a key signing event at the next conference, where core developers sign each others keys.

Why should I, a releaser, put my key fingerprint on GH?

The more sites connect a releasers key to their identity, the more difficult it will be for an attacker to successfully mount a plausible attack on our releases. If we only have keys on a keyserver and on rakudo.org, then an attacker will only have to break into the rakudo.org server to be able to upload a malicious release file signed with a freshly generated key impersonating a real releaser uploaded to some key server and replaced on the rakudo.org server. If the key fingerprints are also listed on GH then the attacker will also have to break into GH to change the fingerprint listed there. (Or create a new fake GH account impersonating a releaser. But that account will not be related to anything Raku.)

[AntonOks]

Some more information on the "why". (The usage of the words "key" and "key fingerprint" are intentional, they are not interchangeable.)

Why should we sign releases?

The reason why releases should be signed is to provide protection from malicious modification of release files. If release files are always signed with the same key, the users can verify, that the release they have downloaded now was made by the same person that did the release the last time they downloaded something.

Why should releasers provide their keys on rakudo.org when they are already available on a keyserver?

The very popular keys.openpgp.org strips signings off of keys. This means that keys uploaded to that site can not be used to build a web of trust. So having the keys including the signings available for download somewhere makes sense. It would also be a good idea to have a key signing event at the next conference, where core developers sign each others keys.

Why should I, a releaser, put my key fingerprint on GH?

The more sites connect a releasers key to their identity, the more difficult it will be for an attacker to successfully mount a plausible attack on our releases. If we only have keys on a keyserver and on rakudo.org, then an attacker will only have to break into the rakudo.org server to be able to upload a malicious release file signed with a freshly generated key impersonating a real releaser uploaded to some key server and replaced on the rakudo.org server. If the key fingerprints are also listed on GH then the attacker will also have to break into GH to change the fingerprint listed there. (Or create a new fake GH account impersonating a releaser. But that account will not be related to anything Raku.)

Hi there. My 5cents...

• I never signed a piece of SW so far and don't even "own" / have a PGP key.
• For my "Rakudo Star" involvement, I don't think this is needed or helpful anyhow, because
  • Both, the bash-based RSTAR tool and the Windows MSI releases, are build by the GitHub bot and not me ;) so signing it with my private key and by that saying, "YES I SWEAR IT WAS ME BUILDING THIS SW" feels wrong. And remember, the Star releases are build "automatically" just after a Rakudo release tag was pushed, by intention nowadays via GH Actions...
    • See https://github.com/rakudo/star/actions/workflows/sync_latest_rakudo_release.yml and (new, tested but not in "production" so far... should run with the next release and I'll move it also to rakudo/star then) https://github.com/AntonOks/cronactions/blob/main/.github/workflows/publish_rakudo-star_on_rakudo.org.yml
• To give someone the security, the SW is as it was build (on GitHub in the Star case), we create HASH sums, right? Those HASH sums should be used from the various "installers" and "package manages" IMHO... like here

[patrickbkr]

@AntonOks Would it be possible to let GH Actions pipeline automatically sign the files with its own key (so a key that is different from your key)?

[AntonOks]

That's a good question... I stopped to think about that one because if you look at the releases page (also possible to query this info via the GH API ;) ) you see on the left side it say's clearly (for my understanding :O ) it's build by "github-actions"... so...

Another thought some time back was about "signed commits". But. as said. I skipped such thoughts some time ago...

[patrickbkr]

I agree that the benefit of automatically signing autogenerated files is diminished for files that stay on GH and are immutable. But those files are then copied over to rakudo.org, right? Then it makes sense to have those files (automatically) signed by GH. Users can then verify that the files they download from rakudo.org are actually the files that were generated by your GH toolchain.

[patrickbkr]

@AntonOks Do I suspect correctly, that you do not oppose this PR and would be willing to introduce a a signing into the automated Rakudo Star release process?

[AntonOks]

I agree that the benefit of automatically signing autogenerated files is diminished for files that stay on GH and are immutable.

For Star, there are also SHA checksums on GH.

But those files are then copied over to rakudo.org, right?

Exactly, the release binaries AND the checksum files (should be / are) copied. They "belong together".

Then it makes sense to have those files (automatically) signed by GH.

Why? See next...

Users can then verify that the files they download from rakudo.org are actually the files that were generated by your GH toolchain.

1. It is not "my" GH toolchain!!! Community! Everyone is (please!) invited to add more "automations" and smartness. Let's say i.e. "modules updates" ;)

2. Users can verify already today, if they want. As you write, assuming the GH chain is not in doubt and "immutable", there are checksums there and those have to be the same wherever the Star release binaries / files show up. If a checksum file, lets say in our case here on raku.org, shows a different SHA then the "original / "immutable" one on GH, something is "wrong" with the binary on rakudo.org.

[AntonOks]

@AntonOks Do I suspect correctly, that you do not oppose this PR and would be willing to introduce a a signing into the automated Rakudo Star release process?

1. I'll never "oppose" a PR if the majority / community is up for something
2. Not sure if I'm willing to "introduce signing"... depends what it rely means and takes and solves and...

[patrickbkr]

@AntonOks I'll see if I can put together a PR.

[patrickbkr]

A PR to adapt the automated Star Bundle release pipeline is available here: rakudo/star#173 Ideally that other PR is merged prior to this one.

[rba]

I have merged the PR rakudo/star#173. I hope you can go ahead now.

[patrickbkr]

I have removed ancient releasers from the key list. The list now contains:

• jdv
• patrickbkr
• Altai-man
• The Rakudo GitHub automation key (used by the fully autonomous Star bundle release process)

@jdv, @Altai-man: Before merging this you should add your key fingerprint to your GitHub profile. I think there is nothing else left to do. This PR is thus now blocking on your action / approval.

[Altai-man]

@patrickbkr is there an instruction on how to do it? :)

[patrickbkr]

@patrickbkr is there an instruction on how to do it? :)

Go to your profile page, click on edit profile, then enter into the bio field something like PGP Fingerprint: DB2B A39D 1ED9 67B5 84D6 5D71 C09F F113 BB64 10D0 (That's my fingerprint, put in yours instead.)
You can retrieve your fingerprint with gpg2 --fingerprint --show-keys. (I can't verify that command right now, I only have my mobile phone available.)

[jdv]

I added my fiingerprint to my profile page. Note that my name is spelled "Justin DeVuyst" as can be seen on my profile page. It is misspelled in this PR.

[Altai-man]

Oh, so that's how it is, I thought there is something special. Done.

[patrickbkr]

Thanks everyone!

[AntonOks]

@patrickbkr @Altai-man @jdv @rba @coke

Hi all.

Have you seen / noticed rakudo/star#175 ?
Can I revert rakudo/star#173 or will someone "fix" it... soon?

Thanks & regards