[Top][All Lists]

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

Re: [Monotone-devel] while i'm on the subject, other things that ought t

From: Zack Weinberg
Subject: Re: [Monotone-devel] while i'm on the subject, other things that ought to be done to key handling...
Date: Mon, 4 Feb 2008 12:33:38 -0500

On Mon, Feb 4, 2008 at 11:38 AM, Ethan Blanton <address@hidden> wrote:
>  I'm a big fan of breaking this key into two parts.  I take care of
>  installing keys on the Pidgin monotone server, and I most often see
>  one of two things:
>  The output of 'monotone ls keys' for the key in question;
>  The entire file ~/.monotone/keys/keyid.

Aha.  I think yours was the case I was trying to remember.

>  > The keystore should be paranoid about reading private key files, the
>  > same way ssh is
>  I'm not as big a fan of this.  I agree that the keys should be created
>  properly, but after that ... let me manage my own permissions.  ;-)
>  That said, I'm not going to cry if monotone is pickier.

Thinking about it a bit more, there are fewer meaningful attacks
against monotone keystores than .ssh directories, so perhaps we don't
need to be as picky.

* Mallory can read your private key -> Mallory can impersonate you
(assuming they can crack your passphrase, but that's the way to bet).
Clearly key files should be created mode 600. However, I can't see it
being useful to error out if a key file is group- or world-readable;
in fact I can think of some dubious but legit use cases.  Maybe a
warning at most.

* Mallory can write your private key, or any containing directory ->
Mallory can trick you into signing your work with the wrong key.  How
much of a problem this is depends on how policy branches play out.  It
is certainly less of a problem than if Mallory has write access to
.ssh/authorized_keys, which is the file that SSH gets really uptight

All in all, I'd be fine with leaving as is until we see what the worst
case for scenario 2 is.


reply via email to

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