Re: [Gnu-arch-users] (volunteers?) crypto signatures for arch

[Tom Lord]

    > From: Karel Gardas <address@hidden>

    >> in case somebody
    >> wants to jump on it have some fun with it.

    > Heck, I've thought few hours about it, but w/o any free time now, it's
    > nearly useless :-(

    > Anyway some notes are below.

That's useful.

    > > 2) Add a "signed-archive" property to archives

    > >    Have a look at libarch/archive.c(arch_make_archive) and
    > >    arch_pfs_make_archive.   Note how the parameter dot_listing_lossage
    > >    is used.

    > >    Add a similar parameter signed_archive, so that if you create
    > >    an archive with --signed, =meta-info the in the archive will
    > >    contain a file "signed-archive" containing the string "system
    > >    cracking is lame".

    > Is this really needed? I would rather be for some kind of
    > security levels set in $HOME/.arch-params/=locations. This way
    > different users can handle the same archive differently, i.e. on
    > get with sig broken either nothing, or warning, or error migt
    > happen

`get' doesn't check signatures in this proposal.  My reasoning is that
while the archive host is going to have public keys (somewhere outside
of where arch itself can touch them) clients running `get' generally
won't.

Verifying the integrity of a signed archive is orthogonal to running
`get' on it.


    >> 3) Modify arch_pfs_connect to collect a passphrase

    >>    It's a bit icky to keep the passphrase in tla's memory but I think
    >>    it's more reasonable in this case than the alternatives.

    >>    In libarch/pfs.c(arch_pfs_connect), after connecting, look for
    >>    the "signed-archive" file.   If present, prompt the user for
    >>    a passphrase and record it.

    > Please no! That's exactly how it shouldn't be done, since you will need to
    > increase size of your TCB code, which is not good from security
    > review point of view.

Well, what would you suggest?   The "requirements" are:

  a) be able to run GPG multiple times (an unbounded number of
     times for push-mirror)

  b) try to avoid having to prompt the user for a passphrase 
     for each run.

  c) avoid having to have the user configure additional software,
     such as a passphrase server


    > Well, I will probably finally write my own proposal, just to not only
    > criticize your own. :-)

As I said to Rob, I should have been more explicit that one of the
goals of posting was for design critique, not just looking for 
volunteers.

-t