arx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Arx-users] Playing with sig command


From: Walter Landry
Subject: Re: [Arx-users] Playing with sig command
Date: Tue, 14 Dec 2004 21:43:51 -0500 (EST)

Kevin Smith <address@hidden> wrote:
> On Sun, 2004-12-12 at 00:21 -0500, Walter Landry wrote:
> > Kevin Smith <address@hidden> wrote:
> > This is, partly, yet another manifestation of ArX being silent when
> > you specify an incorrect branch.  Yet another reason to fix it
> > (arx.2.1,153).
> 
> I'll be interested to see this fix. I just fixed the silent failure of
> the "browse" command locally, and there didn't seem to be a general
> place to fix it that would have affected other commands. I'll look at
> what you did...

I made a check in recursive_browse.hpp.

> > > Of course, since quintuple agent is installed but not yet working on my
> > > machine (for unknown reasons), I now have an invalid archive, where a
> > > key is specified, but only a couple patches are signed. Not good.
> > 
> > Hmm. Invalid is a bit strong.  I can get those few revisions you
> > signed, and it will verify those signatures.  In any case, you can't
> > prevent this from happening, even with an agent, because you can press
> > Ctrl-C in the middle.
> 
> True, but we can make it harder to create the case.

I don't know how to prevent this case, since I would guess that you
signed a few revisions manually but quickly tired of typing in your
password.

> > > Also, you should be able to sign an entire archive, rather than just a
> > > branch. That's what you want to do when you have an existing archive.
> > 
> > Ask, and you shall receive (arx.2.1,148).  This will also make the
> > first two commands you typed
> 
> Sweet. Thanks. Makes the docs cleaner, too.
> 
> > > Ah. I guess it would be if a few patches were signed by a key that has
> > > recently been deleted. Seems like it would be better to handle that as
> > > part of the delete process, so things never become invalid. The act of
> > > deleting a key could automatically sign the now-orphaned items with a
> > > key you specify.
> > 
> > I think that will make things even more complicated.
> 
> Ok, but deleting a key from an archive should warn the user that any
> corresponding patches need to be re-signed before they can be retrieved.
> Hopefully sig --add for an archive will leave existing valid signatures
> alone, but will sign anything that is unsigned OR was signed by someone
> not listed in the archive. If not, that's going to be a lot of tedious
> work on the part of the user. That's not high priority (since it's a
> rare case), but is high value when needed.

Right now, "sig --add" will overwrite all existing signatures.  It
wouldn't be too hard to only add signatures where they don't exist.

> Also, I would argue that deleting keys from archives, and deleting
> signatures from items this should probably prompt "are you sure?" unless
> --force is specified (Unless they are deleting a signature made by a key
> that has already been removed from the archive). These operations are
> almost never what the user would actually want to do, and are not easily
> reversible.

I am not entirely sure that it will be a disaster if you delete
signatures.  For the single user case, it certainly doesn't matter.
The multi-user case is probably rare enough right now such that we can
worry about it when we get feedback.

Plus, the sig command is really something that should be rarely used.

> > > If signing individual patches really is a necessary feature, it should
> > > be shoved way in the back where normal folks won't get confused by it. 
> > 
> > I think this is a documentation issue.  Most people will never have to
> > use the sig command.
> 
> Exactly.
> 
> Thanks for your quick work on these items. It's great to feel like I am
> making worthwhile suggestions, and being heard. I'll take another pass
> through the latest docs and online help later today.

You're welcome.  It is nice to hear feedback.

Walter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]