3.0.1 is not signed/ can not be packaged

[dvzrv]

Hi! I'm packaging python-smmap for Arch Linux.
When trying to build 3.0.1 I noticed that there is no detached PGP signature for the tarball on pypi.

As we have established 2CF6E0B51AAF73F09B1C21174D1DA68C88710E60 as a valid signing key (per TOFU), I can not package version 3.0.1, until this is resolved.

Due to a missing USB dongle (?), both gitpython and gitdb now have a broken chain of trust for their PGP signatures as well.
It would be really great to resolve this.

[Harmon758]

I believe v3.0.0 has a different signature key, due to the same reason as provided in the linked issues.
As for the lack of a signature key for v3.0.1, see the note at the bottom of #44.

[dvzrv]

Thanks for the clarification!

As soon as access to the signing key is established again, it would be great to add your key id as an additional valid signing key to the README in a signed commit (using the former key) to the respective repositories, so that the bus factor != 1 and downstreams can add this key as well. :)

[Byron]

I will do that! And I will work with @Harmon758 on setting up CI to gain the capability of signing and deploying tags automatically.
That doesn't only reduce the maintenance effort, but also allows maintainers to cut valid releases themselves. This is a necessary step to assure GitPython may live on and deliver to its users, as I prove to be too disconnected from Python and GitPython to even meet the low bar.

[Byron]

@dvzrv I have just released v3.0.2, which should be signed with the key you have been seeing so far.

Right now I still don't have the means to establish a chain of trust, but that should become possible in May, which is when I hope we can help our CI to package valid releases automatically.

CC @Harmon758

[Byron]

Never mind the above, I used the wrong key.

[Byron]

Version 3.0.4 was just released and it should be signed with 2CF6E0B51AAF73F09B1C21174D1DA68C88710E60 .
If indeed valid, please feel free to close this issue.

[dvzrv]

@Byron it seems your public key is invalid since last July (also the one I can get from github):

$ gpg --keyid-format long --list-keys 27C50E7F590947D7273A741E85194C08421980C9
pub   rsa4096/85194C08421980C9 2020-07-17 [SC]
      27C50E7F590947D7273A741E85194C08421980C9
uid                 [ unknown] Sebastian Thiel (YubiKey USB-C) <[email protected]>
uid                 [ unknown] Sebastian Thiel (In Rust I trust) <[email protected]>
sub   rsa2048/0C63F0D9347C9843 2020-07-17 [A]
sub   rsa4096/AA962CF063C2F55A 2020-07-17 [E]
sub   rsa4096/9CB5EE7895E8268B 2020-07-17 [S]

[Byron]

That's interesting - to me this looks very different. Is there confusion between creation and expiry date?

Signature key ....: 27C5 0E7F 5909 47D7 273A  741E 8519 4C08 4219 80C9
      created ....: 2020-07-17 02:26:28
Encryption key....: 424B 4EAD 5099 AC35 4FD5  06FA AA96 2CF0 63C2 F55A
      created ....: 2020-07-17 02:26:28
Authentication key: FC57 210E 3468 C75E A4F3  3812 0C63 F0D9 347C 9843
      created ....: 2020-07-17 02:32:40
General key info..:
pub  rsa4096/85194C08421980C9 2020-07-17 Sebastian Thiel (YubiKey USB-C) <[email protected]>
sec>  rsa4096/85194C08421980C9  created: 2020-07-17  expires: never
                                card-no: 0006 07676842
ssb>  rsa4096/AA962CF063C2F55A  created: 2020-07-17  expires: never
                                card-no: 0006 07676842
ssb>  rsa2048/0C63F0D9347C9843  created: 2020-07-17  expires: never
                                card-no: 0006 07676842

[dvzrv]

Argh, you are right (seems it got too late yesterday). I was fooled by the build system, which complained about an invalid key, but that was actually due to a different key from before being used for the tarball signature.

I actually wanted to refer to the 2CF6E0B51AAF73F09B1C21174D1DA68C88710E60 key. That one has been used to sign the releases before, whereas it is now 27C50E7F590947D7273A741E85194C08421980C9. Both never expire, but it would be awesome to have a chain of trust between the first and the 2nd (sign the new one with the previous).

Currently there is no signature available, that indicates this:

$ gpg --list-sig 27C50E7F590947D7273A741E85194C08421980C9
pub   rsa4096 2020-07-17 [SC]
      27C50E7F590947D7273A741E85194C08421980C9
uid           [ unknown] Sebastian Thiel (YubiKey USB-C) <[email protected]>
sig 3        85194C08421980C9 2020-07-17  Sebastian Thiel (YubiKey USB-C) <[email protected]>
uid           [ unknown] Sebastian Thiel (In Rust I trust) <[email protected]>
sig 3        85194C08421980C9 2020-07-17  Sebastian Thiel (YubiKey USB-C) <[email protected]>
sub   rsa2048 2020-07-17 [A]
sig          85194C08421980C9 2020-07-17  Sebastian Thiel (YubiKey USB-C) <[email protected]>
sub   rsa4096 2020-07-17 [E]
sig          85194C08421980C9 2020-07-17  Sebastian Thiel (YubiKey USB-C) <[email protected]>
sub   rsa4096 2020-07-17 [S]
sig          85194C08421980C9 2020-07-17  Sebastian Thiel (YubiKey USB-C) <[email protected]>

Digging around further, I remembered this ticket for gitpython, where you explained the hardware failure.
It would be awesome to mention the key in use for tarball signatures in a document (e.g. the README), using a signed commit (and introducing changes to this fact also only with a signed commit using the key that introduced it), similar to how it is done for gitpython (you may even mention previous keys). This can establish a chain of trust towards any other future key even without signing that key (and documented it is much easier for users to find).

I will do that! And I will work with @Harmon758 on setting up CI to gain the capability of signing and deploying tags automatically.

While I understand the desire for automation, it is not feasible or secure to do PGP signing on a remote machine.

[Harmon758]

Would 119cc41 suffice?
If not, how about if I linked this issue and the GitPython issue(s) in the changelog?

[dvzrv]

It's not very visible but I guess it'll do. In the README it would be more accessible right away. It should be enough to specify the current (and/or previous) key ids used for tarball signing.

[Harmon758]

I'll defer to @Byron for that then.
There are tentative plans to merge this library into GitDB (and GitDB into GitPython), so this might become a non-issue in the future.

[Byron]

It's not very visible but I guess it'll do.

Since @dvzrv is OK with this, I think it's sufficient to go with a changelog note, knowing that smmap will definitely cease to exist as standalone crate to ease future maintenance.

Version v4.0 was just released on pypi: https://pypi.org/project/smmap/4.0.0/