[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
about.
All in all, I'd be fine with leaving as is until we see what the worst
case for scenario 2 is.
zw