Re: [Gnu-arch-users] crypto signing take 2

[Tom Lord]

    > From: Robert Collins <address@hidden>



    > On Tue, 2003-12-09 at 07:51, Tom Lord wrote:
    >> 1) As before, the existence of =meta-info/signed-archive
    >>    indicates that files are supposed to be signed.

    > Done.

    [...]

    >> 3) (internals) the arch_pfs_put_file routine will sign files
    >>    a new arch_pfs_put_atomic routine will be added

    > Done.

Wow!  Thanks.


    >> 2) A user can have files:

    >>      ~/.arch-params/=gpg/=default
    >>      ~/.arch-params/=gpg/<archive-name>

    >>    containing the commands to use to sign by default or for
    >>    a particular archive.   The contents of those files would be
    >>    something like:

    >>  agpg --detatch-sign --local-user FOO %F

    >>    where tla replaces %F by a file name.

    >>    (The default default command should presumably be

    >>         gpg --detatch-sign %F
    >>    )

    > What about stuffing this into hook? It'd be simpler (use the existing
    > run-hook framework, allow the user to choose which keys/commands to use
    > on a more granular level - i.e. the user could sign each branch
    > separately.)

[Ah -- now the #arch raising of this question (that I had to dash
from) now makes a lot more sense to me.]

The granularity question -- and for that matter the passing of extra
parameters in environment variables -- is an orthogonal question.  You
could do that with either a hook mechanism or with a
.arch-params/=gpg/*.   It's a red herring to raise it in this context.

I don't see a really compelling reason to have "finer granularity"
signing than per-archive.   If the maintainers of a project want to
use a different key to sign some branches, why wouldn't they just put
those branches in a different archive?

So, no, I'm against eagerly deciding to build support for
finer-granularity signing.

So now:  what about hooks vs. ~/.arch-params/=gpg/* files?

Short answer, no:  it should be =gpg files.

Longer answer:

The =gpg/* files have a number of distinct advantages:


   ~ hooks are for extensibility, not for activating core
     functionality or making customizations of core parameters
   

     We have reached a situation in which the hook script is
     used _only_ for "local policy" above and beyond the functionality
     of arch.

     By that I mean that the hooks script should _never_ be used as
     part of "how to get some bit of core arch functionality working
     at all" and should _never_ be "where you set the FOO parameter to
     arch."

     For a long time, in the area of revision libraries, this design
     goal was violated.   If you wanted your revision libraries to
     work reasonably, you _had_ to write some hook code for them.

     The recent additions of the two library paths and the greedy and 
     sparse flags for libraries have fixed that:  you can manage your
     libraries quite nicely now without having to install any hooks.

     Putting signing stuff in .arch-params/hook would be a step
     backwards in that regard.


     
   ~ =gpg/* files are easier to write

     For example, users won't be required to write shell scripts that
     take conditional branches based on the name of an archive passed
     in the environment.  All they need to do is to write or copy is a
     single command line with %F where a filename goes.

     The number of potential users is very large.  The languages they
     speak, their skill levels, and their computing environments will
     vary pretty wildly.

     It is easier to explain making the =gpg file than to explain "you
     need to write a hook in sh(1) that does so and so".



   ~ =gpg/* files are easier to cut and paste

     It is easy to publish example =gpg files that will work anywhere
     that gpg is called "gpg" or agpg is called "agpg".

     It is even easy to publish a trivial template =gpg file that has
     a --local-user FOO parameter the user will have to edit.

     But the contents of .arch-params/hook are unconstrained.  It is
     impossible to publish a similarly portable boilerplate to stick
     in .arch-params/hook.   

     You can publish boilerplate for the hook script but it will 
     have two problems:  (a) it won't work at all in the hook scripts
     of _some_ users;  (b) each time a user wants to install such
     boilerplate, he'll have to figure out where in the hook script to
     install it and whether or not it requires changes to fit in with
     signing hooks previously installed.



   ~ =gpg/* files are less error prone

     The hook approach relies on the user getting or writing code
     that reliably dispatches on the archive name.   With the =gpg
     method, that dispatching is built-in to tla.

     If we do wind up with many arch users on a project host using
     signatures, my guess is that the =gpg method will result in
     distinctly fewer cries for help, trouble reports, incorrectly 
     applied signatures, and on-going user frustration.   There will
     never be a need to explain, for example, the syntax of sh `if' or
     `case'. 

     Along the same lines -- when a user is getting help, someone can
     ask them: "What does `cat ~/.arch-params/=gpg/=default' say?" and
     "What does `cat ~/.arch-params/=gpg/address@hidden' say?" and
     tell at a glance what's going on (rather than having to analyze
     an entire hook script).



   ~ they are easier to automate

     We could, in fact, look for gpg, agpg, or whatever at config
     time and add convenience commands that help the user to manage
     =gpg files.

     It would be far more difficult and less robust to try to automate
     editing of .arch-params/hook.



   ~ they are easier to edit

     What happens when a user needs to change some signing command
     setting?   With the .arch-params/hook approach, the user is 
     required to make the change without perturbing any of the other
     hook code.   With the =gpg approach, all the user has to do is 
     get right _which_ file to edit (the one named after the archive
     in question or the =default file) and, aside from the risks of
     making that choice incorrectly, none of the settings for other
     archives (nor the definitions of other hooks) will be disturbed.

     Even if the user gets the edit wrong for a given archive, odds
     are he won't break signing of other archives (=default setting
     excepted).


Against this, the only real advantage I see for the hook script is
that nobody will later scoff "Why didn't you use the hook script for
this?" about the =gpg files.


-t