Re: [Arx-users] Adding crypto to ArX

[Kevin Smith]

On Thu, 2004-12-02 at 22:17 -0500, Walter Landry wrote:
> There are two kinds of entities in ArX: patches and revisions.  A
> revision is just a complete source tree, and a patch is what gets you
> from one revision to another.  ArX signs both of them [1], invoking gpg to
> do the actual signing.  Patches are signed directly.  Revisions are
> signed indirectly by signing a SHA-256 hash of the manifest.  The
> manifest is mostly a listing of the files, their properties, and
> SHA-256 hashes of their contents.  It also has a manifest version
> (currently ArX-2.0) and the full revision name
> (e.g. foo/bar.baz.1.0,22).  

Sounds reasonable, based on my limited knowlege of ArX data internals.

> 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.

> > 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.

> 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. 

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).

> > 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.

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?

> 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?

> ArX uses gpg, but it does not use the web of trust (as opposed to
> tla's implementation).  I see that as a feature.  If I want to
> download a revision from a random place on the web, I don't want to
> have to extend my trust for other things to this particular public
> key.  Moreover, if someone manages to compromise one person's key, they
> may be able to subvert a larger number of projects.

I think I agree with your decision (without having looked at arch's
design). 

> It turns out that making gpg do what you want is rather difficult.  I
> considered using X.509 certificates like monotone does.  But a number
> of people already have a gpg key, so an X.509 certificate would just
> be another secret to protect, another password to remember, etc.  In
> addition, your gpg public key may be already be known to the
> recipient.

Yes. Monotone has taken some heat for not using gpg keys. Graydon had
some great reasons, but it was definitely a tradeoff.

> Finally, there will be some user-specified parameters (with "arx
> param").  The first one is so that you can define your own gpg
> program.  Normally, the command for gpg will be defined when you
> compile ArX.  You could run
> 
>   arx param gpg (gpg prog)
> 
> if, for example, you want to use quintuple-agent so that you don't
> have to type your password all of the time.
> 
> The second param will be "sign" which, if true, will be make your
> archives signed by default.
> 
> I have also thought about another param called "key" which would
> override whatever gpg thinks your default key is.

I would need to hear/think more about that one.

> I have implemented some of this already (arx.2.1,116).  The only thing
> missing is the "param" stuff.  I am appending the help for "sign" and
> "make-archive".  It is still rough.  I think the syntax for "sign"
> could still use a little improvement.  

I'm going to try to set up signing on my archive, so I may have some
feedback for you.

> 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.

> [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?

Kevin