monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL


From: Ethan Blanton
Subject: Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL
Date: Sun, 19 Oct 2008 19:45:00 -0400
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

Robert White spake unto us the following wisdom:
> Daniel Carrera wrote:
> > Robert White wrote:
> >> If you don't believe in these use cases, consider contractors who may
> >> need to keep work separate for different employers but will want to
> >> use their one business email address for all their business;
> > One thing I don't understand is why this contractor needs different
> > keys for each employer.
>
> Try things like wanting to be able to revoke/destroy one key when the
> contract is over etc.

I have used keys of the form address@hidden when I
needed throwaway key IDs.

> >> or consider the need to have two or more development stations that _can_
> >> _not_ reach each other over a network, so sneaker-netting a secondary
> >> store would be required.  (and so on).
> >
> > I also don't understand why this scenario requires different keys for
> > each store.
> 
> Try things like wanting to be able to revoke/destroy one key when the
> contract is over, or maybe because the keys were made at different times
> for different purposes.
> 
> Seriously, just because you don't understand any use case where you
> would want more than one key doesn't mean they don't exist...

Robert was asking for clarification, which is a reasonable thing to
do.  There is no need to be snide or rude about it.  If you have a
legitimate use case, and can articulate it, then software can be built
to accomodate it.  If you cannot articulate it, then it is hard to
build an appropriate solution which benefits all parties.  It is
reasonable to ask for clarification.

That said, the conflation of email address and key ID is an
unfortunate early design decision in monotone which pretty much
everyone now understands was not ideal.  Keys in databases are not
ideal for other reasons (databases should not be sensitive, as it is
reasonable to share them, primarily).  Unfortunately, changing key IDs
to something more sensible (such as hashes, as used in most crypto
systems) will require a re-issuance of all certs, which is a pretty
big deal.  Because of this, it has been put off until other
backwards-incompatible changes which are known to be necessary can
also be implemented, so that there needs to be only one more flag day
in the foreseeable future.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

Attachment: signature.asc
Description: Digital signature


reply via email to

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