Re: [Arx-users] Signature command set

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> NOTE: All of this refers to the unreleased signature features. It is
> only intended for folks interested in the design of this upcoming
> feature.
> 
> I'm trying to figure out all the crypto pieces so I can structure them
> in my mind. It may also help to structure a more coherent command set.
> Here are the "features" I can think of:

Only two are not completely true.

> * [IS THIS TRUE?] When a patch is pulled from a signed archive, all
> signatures associated with that patch will also be pulled. Thus, a patch
> may be signed by multiple keys. 

No, a patch may be signed by only one key.

> * List the key(s) that have signed a specific patch or revision

True, although you can only list who signed a particular patch or
revision keys by verifying it.

Also, you can sign a revision even if the archive does not have your
public key.

> ---
> Whew. Hopefully that's most of them. I learned some things while writing
> that, and have made a few guesses.
> 
> To start, I'm uncomfortable having "sign" as the command that performs a
> verify, or even deletes a signature. I think "sig" would be better, and
> "signature" would work, although it is long. I'm not fond of "crypto",
> and "security" doesn't feel right either. 

The original name was sig.  I changed it for reasons I can't recall.
I agree that sig is a better name (arx.2.1,145).

> It seems very weird to have this command also manage archive keys. I
> think I would also be in favor of splitting out an archive-sig or
> archive-key command. I know it's bad to have too many commands, but I
> think it is worse to have unrelated features inside the same command.

I _really_ don't want to add another command, especially for something
that a good fraction of people will never use.  45 commands is already
large.

> Being able to specify --patch or --revision and still pass a REVISION
> confused me. I'm guessing that you do always specify the revision, but
> if you give the --patch flag, it will actually sign the patch that
> produced the specified revision, rather than the revision itself?

Correct.  However, I am starting to think that we don't really need to
expose the ability to separately sign patches and revisions.  Hmm.
I've removed them (arx.2.1,145).  It makes the help page much simpler :)

> The global/per-archive key thing is probably ok if the docs and help are
> a bit clearer.

The docs can always be clearer ;) However, maybe we could also set it
up so that you can have a different default key for each archive.  It
could be something like "arx param archive-key/foo key".  Hmm.  I
don't think that there are that many people who have multiple gpg
keys.  Needs more thought.

> I definitely think that clients should be notified any time a key has
> been deleted from an archive. They should probably be forced to
> re-register before using that archive. I'm feel much less strongly about
> notifying them when a key is added, I guess. I agree with your decision
> to avoid making it easy for users to pull newly added keys.

I have just modified it to notify the user.  I don't want to force
re-registering.  I have a bad feeling that it will cause problems
somewhere.

> It might be helpful to document the "single-user" case separately from
> the case where multiple developers have write access. It seems to me
> that a fair bit of complexity comes in the multi-user scenario, and as a
> single-user user, I would like to know what I can ignore. I think
> distributed RCS's shine in single-user mode, and it's almost always the
> way I work, so it tends to be where I focus.

I am not quite sure what you mean by single-user.  For a person
working alone, they can completely ignore signatures.  Checksums are a
little interesting, but can usually be ignored.

> I hope this feedback is useful.

Always.

Walter