bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22883: Authenticating a Git checkout


From: Ludovic Courtès
Subject: bug#22883: Authenticating a Git checkout
Date: Fri, 01 May 2020 18:50:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi Justus,

Justus Winter <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:

[...]

>> Signature verification in (guix openpgp) does just that: signature
>> verification.  It does not validate signature and key metadata, in
>> particular expiration date.  I guess it should at least error out when a
>> signature creation time is newer than its key expiration time.
>
> Indeed.  I skimmed both the original and the adapted code, and it
> notably does no attempt to canonicalize the certificates in the keyring
> (i.e. checking binding signatures, lifetimes, revocations, (sub)key
> flags...).  While that is a bit dangerous, it is okay for a point
> solution for Guix, provided that this is properly documented and
> communicated.
>
> One can forgo canonicalization if one assumes that the keyring is
> curated, and one has a good-list of (sub)keys fingerprints that are
> allowed to create signatures.  Reading git-authentiate.scm that does
> seem to be the case.

Yeah, the (guix openpgp) module is good enough for this narrow use case,
but I agree that people shouldn’t view it as a viable signature-only
OpenPGP implementation in the general case.

I’ll clarify this at least in the source file.

> (I bet that certificate canonicalization is the major reason why calling
> out to gpgv is so slow:  it does that every time, and it involves
> signature verification, which is slow (yes, I'm looking at you, RSA).)

I see.

>> It should also reject SHA1 signatures, at least optionally (I haven’t
>> checked whether our Git history has any of these).
>
> I believe it should.  For reference, we reject SHA1 signatures for
> signatures created since 2013.

Sounds good, I’ll do that.

>> Next steps:
>>
>>   • Clean up the (guix openpgp) API a bit, for instance by using proper
>>     SRFI-35 error conditions.  Perhaps handle v5 packets too.
>
> Don't bother with v5 packets for now.  The RFC is nowhere near
> completion, and even if it is one day, it will be quite some time until
> you see these packets in the wild.

Alright, even better.

Thanks for taking the time to look into it!

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]