Hello! Ricardo Wurmus <rek...@elephly.net> skribis:
> Ludovic Courtès <l...@gnu.org> 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’.
