search

rakudo / rakudo.org

Code for rakudo.org website
https://rakudo.org/
Artistic License 2.0
8 stars 18 forks source link

Add page that instructs on how to verify downloads #78

Closed patrickbkr closed 2 years ago

patrickbkr commented 2 years ago

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 commented 2 years ago

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

patrickbkr commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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...

patrickbkr commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

patrickbkr commented 2 years ago

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

rba commented 2 years ago

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

patrickbkr commented 2 years ago

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

@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 commented 2 years ago

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

patrickbkr commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

patrickbkr commented 2 years ago

Thanks everyone!

AntonOks commented 2 years ago

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

Hi all.

Have you seen / noticed https://github.com/rakudo/star/issues/175 ? Can I revert https://github.com/rakudo/star/pull/173 or will someone "fix" it... soon?

Thanks & regards