Please sign commits

[svenstaro]

Some of your signatures in mumble-gpg-signatures are signed but some are not. Critically, the most recent ones are not signed. Could you start signing them?

[TerryGeng]

UPDATE: In my previous comment, I misunderstood your intention.

I think it would be better you start an issue directly in https://github.com/mumble-voip/mumble-gpg-signatures 🤔️.

[svenstaro]

The project you linked doesn't allow for issues, hence I'm submitting this here.

[Krzmbrzl]

Why does this even matter? After all the amount of people that have write access to this repo is limited anyways 🤔

[svenstaro]

That's exactly the point, though. Write access to the repo does not prove the authenticity of the change as an attacker might gain access to the GitHub account without gaining access to the private GPG key.

[Krzmbrzl]

But a commit being signed does nor proof anything in this scenario (to my understanding).
A commit is marked as signed if it was created directly on GitHub since GitHub does that automatically for you. Thus if someone was to e.g. hijack my account, they could commit to this repo through my account and the commit would still be marked as signed 🤔

And I am rather certain that this is actually the exact reason why the previous commits were signed: They were created directly on GitHub 🤷

[dvzrv]

But a commit being signed does nor proof anything in this scenario (to my understanding).

It does. @svenstaro 's request is about ensuring a usable chain of trust between the keys that are used for release signing.
Without a signed commit when introducing a new key, there is no chain of trust.

A commit is marked as signed if it was created directly on GitHub since GitHub does that automatically for you. Thus if someone was to e.g. hijack my account, they could commit to this repo through my account and the commit would still be marked as signed

No, that is not correct. A signed commit is also marked as signed if the github PGP signature is used. However, the PGP signature done by GitHub is actually not useful and should not be used, as several users have access to it via a website).
Every user involved with the signing and releasing of mumble should connect their respective PGP key to their account, so that commits appear as "verified" when signed with that user's PGP key.

More specifically it would be great if you could establish a trust chain between 76B50270322F0E3D78DCE8298AA328A315175AE3 and 6A24D225AAE02DD6352C3D269F179B6BF48ADF25, as the latter is now used for signing the releases and has been added in cf89161

Upon further review, the key 76B50270322F0E3D78DCE8298AA328A315175AE3 has also been added without a signed commit in 0dad89f#diff-24c6fc7f60faf22bbca2c882d0408223406a33cbc3f505a18163358b702f5e52

The last commit signed by a person (@mkrautz) and with a still intact chain of trust has been done for the change in 2019: f9ce071

Without a chain of trust between these commits the use of PGP signatures for releases has no meaning.

A way to establish the chain of trust can be for @mkrautz to amend the latest four commits and sign them.
This can be done e.g. similar to this example or probably also by plain rebase with the -S flag:

git rebase -S -i HEAD~4

Afterwards also the keys added in the recent commits can be considered "trusted".

For downstreams there is currently no way of telling whether a supply chain attack is in motion or not and we will wait with an upgrade until this is resolved.

[davidebeatrici]

I amended the last commit signing it with my GPG key for 2021: 3b139d7

[Krzmbrzl]

Lol now the commit is explicitly marked as "unverified" xD

[davidebeatrici]

I was surprised to see that too. It's because I have a dedicated email address for Git and another for GPG.

I would expect the commit to show up as verified though, as both addresses are verified in my GitHub account.

[dvzrv]

@davidebeatrici unfortunately it is of no use, if you sign these commits (especially not when you sign them with a key that is not part of the trust chain). It has to be done by @mkrautz.

[Krzmbrzl]

That will most likely not happen since he is no longer actively involved in the project.

[davidebeatrici]

Also, we don't have his current key in the repository, mkrautz.asc was expired on 2016-06-12.

[svenstaro]

I'd already be happy if you used the old release key to cross sign the current one.

…

On Wed, Feb 10, 2021, 21:09 Davide Beatrici ***@***.***> wrote: Also, we don't have his current key in the repository, mkrautz.asc was expired on 2016-06-12. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAANAB5L4DCKBMIC7FCDMLS6LRXFANCNFSM4XNQIYVA> .

[davidebeatrici]

mumble-auto-build-2020?

[svenstaro]

Yes, since I decided to trust mumble-auto-build-2020 last year, if you now sign mumble-auto-build-2021 with mumble-auto-build-2020 it's good enough for me to update the package and apparently, also we can't restore the perfect chain of trust anyhow.

[davidebeatrici]

It expired on 2021-01-01.

[Krzmbrzl]

Can we sign the commits with the the cert we are using e.g. for the Windows binaries? 🤔

[svenstaro]

Latest commit is signed by a developer so if we can just get signed commits (and cross-signatures on release keys, please!) from this point forward, we can consider this closed.

[davidebeatrici]

I'm going to ask @mkrautz whether he can sign my commit with his GPG key.

[davidebeatrici]

@svenstaro Is ded4a4f okay?

[svenstaro]

Seems good to me!

[davidebeatrici]

Excellent, thanks for checking!

[dvzrv]

@davidebeatrici I'm sorry, but the chain of trust is actually broken again.

In ded4a4f you add the PGP public key with the ID 62FADA3E97B879796A45AAC19FF5C2DB7FDCC3BC:

$ sq inspect davidebeatrici-2022.asc
-: OpenPGP Certificate.

    Fingerprint: 62FADA3E97B879796A45AAC19FF5C2DB7FDCC3BC
Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
Public-key size: 256 bits
  Creation time: 2021-12-31 23:36:55 UTC
Expiration time: 2023-01-01 23:36:55 UTC (creation time + P366D)
      Key flags: certification, signing

         Subkey: F296DB843DD5D0C1FD86C02F5692A49984C578B2
Public-key algo: ECDH public key algorithm
Public-key size: 256 bits
  Creation time: 2021-12-31 23:36:55 UTC
Expiration time: 2023-01-01 23:36:55 UTC (creation time + P366D)
      Key flags: transport encryption, data-at-rest encryption

         UserID: Davide Beatrici <gpg@davidebeatrici.dev>

You then signed that commit with that same key (62FADA3E97B879796A45AAC19FF5C2DB7FDCC3BC):

$ git verify-commit ded4a4f39d8c3920dda039dd19f99e68dd725a3d
gpg: Signature made 2022-01-01T01:28:08 CET
gpg:                using EDDSA key 62FADA3E97B879796A45AAC19FF5C2DB7FDCC3BC
gpg: Good signature from "Davide Beatrici <gpg@davidebeatrici.dev>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 62FA DA3E 97B8 7979 6A45  AAC1 9FF5 C2DB 7FDC C3BC

Whereas in the previous commit 3b139d7 you establish the PGP public key with the ID (A280DBCC2740107F54A7BB55030D670D00CAAE9C):

$ sq inspect davidebeatrici-2021.asc
-: OpenPGP Certificate.

    Fingerprint: A280DBCC2740107F54A7BB55030D670D00CAAE9C
                 Invalid: Expired on 2022-01-01T21:37:03Z
Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
Public-key size: 256 bits
  Creation time: 2021-02-09 21:37:03 UTC
Expiration time: 2022-01-01 21:37:03 UTC (creation time + P326D)
      Key flags: certification, signing

         Subkey: E40EECB8BB521E3188C54711081B33C6F2BD5AB7
                 Invalid: Expired on 2022-01-01T21:37:03Z
Public-key algo: ECDH public key algorithm
Public-key size: 256 bits
  Creation time: 2021-02-09 21:37:03 UTC
Expiration time: 2022-01-01 21:37:03 UTC (creation time + P326D)
      Key flags: transport encryption, data-at-rest encryption

         UserID: Davide Beatrici <gpg@davidebeatrici.dev>

That commit has also been signed with that exact same key (A280DBCC2740107F54A7BB55030D670D00CAAE9C):

git verify-commit 3b139d71674091e969b932d3626a7b5ddd2f60cf
gpg: Signature made 2021-02-10T20:25:19 CET
gpg:                using EDDSA key A280DBCC2740107F54A7BB55030D670D00CAAE9C
gpg: Good signature from "Davide Beatrici <gpg@davidebeatrici.dev>" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: A280 DBCC 2740 107F 54A7  BB55 030D 670D 00CA AE9C

For posterity, I also checked whether any of the keys that are used for signing releases, added in 3b139d7 and ded4a4f (respectively), have any relevant signatures on them (but unfortunately they do not):

$ sq inspect --certifications mumble-auto-build-2021.asc
mumble-auto-build-2021.asc: OpenPGP Certificate.

    Fingerprint: 6A24D225AAE02DD6352C3D269F179B6BF48ADF25
                 Invalid: Expired on 2022-01-01T21:25:14Z
Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
Public-key size: 256 bits
  Creation time: 2021-02-09 21:25:14 UTC
Expiration time: 2022-01-01 21:25:14 UTC (creation time + P326D)
      Key flags: certification, signing

         Subkey: AB3C82FE224FCCD232FB7569DB26751B0D8788E7
                 Invalid: Expired on 2022-01-01T21:25:14Z
Public-key algo: ECDH public key algorithm
Public-key size: 256 bits
  Creation time: 2021-02-09 21:25:14 UTC
Expiration time: 2022-01-01 21:25:14 UTC (creation time + P326D)
      Key flags: transport encryption, data-at-rest encryption

         UserID: Mumble Automatic Build Infrastructure 2021 <mumble-auto-build-2021@mumble.info>

and

$ sq inspect --certifications mumble-auto-build-2022.asc
mumble-auto-build-2022.asc: OpenPGP Certificate.

    Fingerprint: 1EDEBE2A93CB97FA9903D52E25F63C66245DFC60
Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
Public-key size: 256 bits
  Creation time: 2022-01-01 00:00:37 UTC
Expiration time: 2023-01-02 00:00:37 UTC (creation time + P366D)
      Key flags: certification, signing

         Subkey: CA3A621DADA25D673C1D5ECD09BFEC6471D41937
Public-key algo: ECDH public key algorithm
Public-key size: 256 bits
  Creation time: 2022-01-01 00:00:37 UTC
Expiration time: 2023-01-02 00:00:37 UTC (creation time + P366D)
      Key flags: transport encryption, data-at-rest encryption

         UserID: Mumble Automatic Build Infrastructure 2022 <mumble-auto-build-2022@mumble.info>

As there are no signatures of the 2021 key (A280DBCC2740107F54A7BB55030D670D00CAAE9C) on the 2022 key (62FADA3E97B879796A45AAC19FF5C2DB7FDCC3BC) and the addition for 2022 in ded4a4f has also not been signed with the 2021 key A280DBCC2740107F54A7BB55030D670D00CAAE9C, the trust chain is again broken.

Additionally, it seems that the mail address gpg@davidebeatrici.dev which is used as UID for the keys used to sign the two latest commits is not (yet) tied to @davidebeatrici 's github account.

I'm sorry to say this, but the additions (or signatures done with the keys) have absolutely no meaning from a supply chain trust perspective at this point and can not be used this way.

[davidebeatrici]

The GPG email address is tied to my account, but for some reason GitHub expects it to be the same one as the committer's.

gpg.txt is signed using my 2021 key.

[dvzrv]

gpg.txt is signed using my 2021 key.

I see. That indeed does establish the chain of trust between the builder keys of 2021 (6A24D225AAE02DD6352C3D269F179B6BF48ADF25) and 2022 (1EDEBE2A93CB97FA9903D52E25F63C66245DFC60). 🎉

However, what will be done with 2022 -> 2023, given that you have no (at least known) signature of your personal key A280DBCC2740107F54A7BB55030D670D00CAAE9C (2021) on 62FADA3E97B879796A45AAC19FF5C2DB7FDCC3BC (2022) and that ded4a4f which introduces 62FADA3E97B879796A45AAC19FF5C2DB7FDCC3BC has been signed with that same key?

It becomes quite evident in this ticket, that the setup is very complex and not easy to follow for downstreams, because there is neither a clear instruction nor does it become instantly apparent by looking at the files alone how to check up on the chain of trust.
@davidebeatrici why do you not rely on cross-signatures on the public keys? That, plus a README with a short explanation of the files would make this much easier to understand for outsiders in the context of this repository.

In broader terms: A section in a README that is only introduced/altered using signed commits and/or states the (cross-signed) keys used for release signing would be even more easy to follow up on (e.g. see how qtile does that) and could even live in the main mumble repository.

[davidebeatrici]

However, what will be done with 2022 -> 2023, given that you have no (at least known) signature of your personal key A280DBCC2740107F54A7BB55030D670D00CAAE9C (2021) on 62FADA3E97B879796A45AAC19FF5C2DB7FDCC3BC (2022) and that ded4a4f which introduces 62FADA3E97B879796A45AAC19FF5C2DB7FDCC3BC has been signed with that same key?

The idea is to sign the Update for 2023. commit using my 2023 key and gpg.txt using the current (2022) one.

It becomes quite evident in this ticket, that the setup is very complex and not easy to follow for downstreams, because there is neither a clear instruction nor does it become instantly apparent by looking at the files alone how to check up on the chain of trust.
@davidebeatrici why do you not rely on cross-signatures on the public keys? That, plus a README with a short explanation of the files would make this much easier to understand for outsiders in the context of this repository.

In broader terms: A section in a README that is only introduced/altered using signed commits and/or states the (cross-signed) keys used for release signing would be even more easy to follow up on (e.g. see how qtile does that) and could even live in the main mumble repository.

Thank you very much for the suggestion, it would be much better.

Should we perhaps just create a new repository called something like gpg-keys, gpg-keychain or gpg-keyring?

[dvzrv]

The idea is to sign the Update for 2023. commit using my 2023 key and gpg.txt using the current (2022) one.

Okay, but where is the trust chain between your personal 2021 and 2022 key?

Thank you very much for the suggestion, it would be much better.

Should we perhaps just create a new repository called something like gpg-keys, gpg-keychain or gpg-keyring?

I believe this could just be added to the README.md of the mumble repository. What is really key to that type of setup though is to have cross-signatures amongst those keys and to make them available on keyservers (and potentially also in the repository). Once you introduce a new one, it needs to be signed by the previous one. If you remove/replace an existing key it should be done in a commit signed by your already trusted key (e.g. that from 2021 in this case, which is now expired unfortunately).

[davidebeatrici]

0ebe468

I used my 2022 key to sign both gpg.txt and commit.