monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] monotone-server: empty passphrase from get_passphra


From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] monotone-server: empty passphrase from get_passphrase
Date: Tue, 14 Nov 2006 09:04:21 +0100 (CET)

In message <address@hidden> on Tue, 14 Nov 2006 00:45:05 -0600, "Matthew A. 
Nicholson" <address@hidden> said:

matt> Richard Levitte - VMS Whacker wrote:
matt> > False trail!
matt> 
matt> Yeah that code is just to pull the password out of the 
matt> /etc/monotone/passphrases file (we don't store it in debconf
matt> cause that is not safe).

Good call.

matt> > The error is in monotone-server.config.  For reconfigure, it happily
matt> > gets the same input as for configure, and then saves whatever the user
matt> > gave, and does NOT regenerate a new passphrase if the user just
matt> > pressed Enter...
matt> > 
matt> > Matthew, what was the intention here?  It does look faulty to me, one
matt> > way or another.
matt> 
matt> Hmmm... that code seems strange.  If you think it should generate a 
matt> password then just add a check for a blank password and generate one if 
matt> necessary:
matt> 
matt> db_get monotone-server/passphrase
matt> MTN_KEY_PASSWD="$RET"
matt> if [ -z "$MTN_KEY_PASSWD" ]; then
matt>     gen_pass
matt>     MTN_KEY_PASSWD="$PASS"
matt> fi
matt> 
matt> The problem is if we are managing the database and we generated
matt> the keys in the beginning, then the user should not be able to
matt> change the password (cause we don't update the keys, although we
matt> could I guess).  If the user wants us to manage his database
matt> then he should enter a proper password for his key.

Uhmmm, but we're just talking about the server key here, right?  The
one that 'mtn serve' uses for server authentication.  As far as I
know, that's all that key does.  It doesn't protect the database and
it doesn't sign any content in the database, so changing it should be
harmless in itself, except that remote users who pull will get the big
fat warning that something is fishy with the server key.  On the other
hand, we're talking about *reconfiguration*, so it makes sense that
the key gets changed.

Now, the tricky part is that monotone-server.postinst will only
generate a new key when there is no database, so the end result is
that the stored passphrase, if it was changed, will suddenly not match
the previously generated key, and the result will be that 'mtn serve'
will not be able to serve any more, because it won't be able to
retrieve the server key any more.  That's definitely not a good thing!

I think I'll take a look at how the openssh-server package does it,
the maintainer has a few years of experience and it seems to work
well...

matt> That is the basic reasoning behind the way it works now.  We
matt> don't generate a key there so we should not generate a random
matt> password for it.
matt>   Perhaps we should not allow a blank password either.

Let's not prompt for it at all, maybe?

matt> Let me know if that's not clear, it's late and I am sleepy :).

Well, since you wrote monotone-server.config (or so I assume), I was
after your original intention.  I take it that you've forgotten :).

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis




reply via email to

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