Re: [Arx-users] Adding crypto to ArX

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> On Thu, 2004-12-02 at 22:17 -0500, Walter Landry wrote:
> > For signing, normally you would specify that an archive will be signed
> > when you create it.  This puts your public gpg key in the archive in
> > ,meta-info/public_keys.  
> 
> I trust it will be possible to add signing to an existing archive.

That is now documented in the manual.

> > > When someone else registers your archive in
> > the most ordinary way, then the public keys will be downloaded and
> > stored in ~/.arx/archives/(archive name)/public_keys.  Then, when they
> > download a patch or revision, the signature is checked to make sure
> > that it is in that public keyring.
> 
> It should probably display the fingerprint(s) at that point to allow
> visual confirmation that we got the expected key.

I am not sure which point you are talking about, but when signatures
are verified, you get output like

gpg: Signature made Tue Dec  7 16:25:37 2004 EST using DSA key ID 4CACD81D
gpg: Good signature from "Walter Landry <address@hidden>"

> > Running "arx archives" will list the archive names, locations, and
> > public keys associated with it.
> 
> Good.
> 
> > It is possible to add and remove keys from the public_keys file in the
> > archive.  This is useful as developers join and leave a project.  
> (snipped a sentence to below)
> > However, ArX will not update the public_keys
> > file on your machine unless you unregister and reregister.  So if
> > someone breaks in, they can only fool new users, not old.
> 
> To clarify: Each archive has a public_keys file. Each client also has 
> a public_keys file associated with each registered archive. Each client 
> does not normally update it's copy of public_keys, so to force an 
> update, the client must un- and re-register that archive. 

Correct.

> It would be nice if ArX would detect that the two files are not 
> identical and notify the user so they can choose how to proceed. 
> At that point, a quick way for the user to accept the new keys 
> might be a nice touch (to avoid the un/re-register thing).

I don't think I want to do this.  Adding and deleting keys from an
archive that you have already registered should be a rare occurance.
If it is too quick and easy to accept new keys, then people may not
notice an intrusion.

> > > You
> > can then delete signatures on patches and revisions and resign with a
> > currently trusted key.  
> 
> Hopefully there would be a batch command to do this, eventually.

I just changed it so that you can sign a whole branch all at once.

> So let's say I have my own local archive, and it includes patches from
> you (that were signed by you). Would you be in my archive's public_keys
> file? I wouldn't think so. Does that mean that each time I commit your
> patches to my archive, I would add my own signature?

Correct.  When you integrate my patches into your tree, you will end
up with a different tree.  So you are the one vouching for that tree,
not me.

> > The trickiest part as I see it is getting the manifest right so that
> > you can't modify the files without changing the manifest.
> 
> Can you say more about that?

You just have to make sure that you have accounted for all of the data
and metadata, and you have to be sure that you can't replace one
manifest with another.  For example, suppose you have foo.stable and
foo.gaping_security_hole branches, both signed by you.  You want to
make sure that someone getting foo.stable isn't tricked into getting
foo.gaping_security_hole.

<snip>
> > Also, it currently asks for
> > passwords twice when committing: once for the patch and once for the
> > revision.  I haven't been able to get gpg to make multiple detached
> > signatures in one go.
> 
> Unfortunately, that looks like a deep limitation of gpg. I guess that's
> what key agents are for. Sounds like one should be "strongly
> recommended" if you do signing in ArX.

I would say that it depends on your workflow.  Agents introduce their
own problems, and not everyone commits to a signed archive every five
minutes.

In any case, there is a section in the manual detailing how to set up
ArX to use an agent.

> > [1] Note that tla only signs patches, not revisions.  This suffers
> > from a weakness that if you branch from an unsigned archive, the
> > results of getting something from your signed archive can still be
> > trojaned.
> 
> Interesting. Is the hole because of cached and/or pristine archive
> contents that are held outside of patches?

The signed archive doesn't have any cached revisions, then tla will
grab patches from the unsigned archive.  If the signed archive does
have cached revisions, then someone who breaks into the host may be
able to delete them anyway.  They only have to have a copy of the
archive when that revision was not archived.  Since cached revisions
are often created and destroyed, that should not be too hard in
practice.

This problem arises because tla does not sign revisions, only patches.
I would imagine it would take a lot of work to be able to sign
revisions.  It was certainly non-trivial for ArX.

Walter