bug#22883: Authenticating a Git checkout

[Ludovic Courtès]

Hello!

Ricardo Wurmus <address@hidden> skribis:

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

[...]

>> While reading
>> <http://karl.kornel.us/2017/10/welp-there-go-my-git-signatures/>, I
>> realized we could store in empty Git commit messages, which would
>> address the above problem (we could use a custom object type too, but
>> that would be less convenient.)
>>
>> So the special commit could look like:
>>
>>   Authorization
>>
>>   (commit-authorizations
>>     (authorization-commit (KEY1 KEY2 …))
>>     (files ("hydra.gnu.org.pub") (KEY1 KEY2 …))
>>     (files _ (KEY1 KEY2 …))) ;all other files
>>
>> That way, to authenticate a commit, we first fetch the latest
>> authorization commit, read the authorization rules from there, and make
>> sure that the changes it makes match the rules.
>>
>> Thoughts?
>
> Does this *have* to be baked into git?  Or are we like the carpenter
> apprentice who just learned how to use a hammer and considers everything
> to be a kind of nail…?
>
> I see the appeal of having everything in git as that’s where the commits
> are that should be authenticated, but using special commit messages
> seems to me like shoehorning update authorization into a code revision
> tool.

Well, I’ve changed my mind on this topic since that message.  :-)

Now, the way I see it, we’d have a plain file listing authorized keys
(the file is under version control, but it’s a regular file).  That
still needs to be prototyped to check whether it’s acceptable
performance-wise, but I’m more confident now.

> You mentioned that checking signatures on commits is also kinda slow
> because it’s sequential and not cached.  I don’t know what I really
> want, but is there perhaps a way to aggregate signatures on past commits
> so that the client’s work is reduced…?

The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb
makes things acceptable: the first “make authenticate” run takes a bit
more than two minutes to check all the commits starting from ‘v1.0.1’,
but subsequent runs take a few seconds.

I have plans to make things faster (independently of the cache) by doing
OpenPGP signature verification entirely in Scheme instead of spawning
‘gpgv’ every time.  Again, we’ll have to get a prototype before we can
tell whether it actually is faster.

I hope I can spend some more time on this during the holidays, but
anyhow, feedback is much appreciated!

Thanks,
Ludo’.