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

[Sebastian Rose]

Hi Robert,


Maybe, I shouldn't answer in the way I do, since you worked all
the weekend and now... oh gosh, it's monday in a few hours!
I'm not an 'expert' in monotone or security, so some of my statements
might be wrong or incomplete. But, as a fan of monotone, I just have to
shout back, regarding the subject of your email and the way you blame
people for your own failures.


Puuha, I use monotone for two years now, and I never heard of the
possibility to store the private keys in a database. And, I wouldn't
want to carry my private key around on an USB stick, neither would
I like to know it's somewhere on the network.

I wonder how old those databases were. Given the pace of the mtn
project, migrating from a nearly three years old version to a current
one without infos seems odd. I use to work on copies first, to make
shure everything is allright (if business critical data).


But I think this problem is not unsolvable, is it?


Wait a moment... (monotone.ca .....) ....


monotone just migrated your damned old database from version < 2.4 to
4.1 - WOW! What did you expect?

I think after all those years with that old system, it's time to RTM.


From the file 'UPGRADING' in the source distribution:


>>>>>>

  - 0.25 or earlier: Please read this section carefully.  We have
    modified the textual format used by revisions and manifests; old
    monotones cannot parse the new format, and new monotones cannot
    parse the old format, except to convert it to the new format.  See
    NEWS before upgrading.  Your project must rebuild its history;
    this is irreversible and creates a flag day -- everyone in your
    project must switch over at the same time.

    .....

<<<<<<

As you can see on 
http://viewmtn.angrygoats.net/all/revision/info/cb8355151f3dede0dd59d1af3721984d2e804409
V. 0.25 is from 12. Dec. 2005



Your version WAS older than 0.24 even, as proved by
http://viewmtn.angrygoats.net/all/revision/file/59a49a49965a02a2b2a3205a462c248218f4a952/NEWS

Note the date of the release (In spring we all updated from a few days
old Debian version, and by that prevented our systems from booting :-):

>>>>>>>

Sat Nov 27 22:29:38 PST 2005

        0.24 release.

.... etc. some lines removed .....

        Major key management changes:
        - Private keys are no longer stored in your database.  They
          are stored in ~/.monotone/keys/ (Unix, OS X) or
          %APPDATA%\monotone\keys\ (Windows).  'db migrate' will
          automatically move your keys out of your database and into
          their proper location.  Consequences:
          - 'genkey' no longer requires a database.  Simply run it
            once when you first start using monotone, even before you
            have created a database.
          - Running 'genkey' once will suffice to give all databases
            on one computer access to your key.  No more fiddling with
            'read'.
<<<<<<<

This was nearly 3 years ago. Release 0.10 was 2004-03-01, not even two
years before that (20 mounth). Wouldn't you tink a two year old project
is likely to change?



Robert White wrote:
> For various reasons It is desirable to use the same real world
> identity, q.v. address@hidden, in several different databases with
> different keys behind them for each database.  This is hugely
> unworkable with one default keystore. This was not previously a problem.


Why? You may have as many keys as you like in your keystore. I use the
same keys on all my machines.

You're looking for the -k option.


> 3) It makes walking around with a database on your flash drive much
> more annoying in every way.


It makes walking around with a database on your flash drive much more
secure, if there is NO private key in it.

Flash drive is my main use case. I figured, that monotone repos are
at about half the size as mercurials or gits repos. Given the fact,
that monotone plays much better with VFAT (executabes etc.) and tracks
empty directories ... Great, ey?


> 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; 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 Don't get you here. My email address is my email address, and my keys
are my keys. Please enlighten me.


"two or more development stations that _can_ _not_ reach each other over 
a network"

...this is how I work all the time. What's the problem? How do you
handle your SSH keys? Or the GPG key you signed this email with? Are
they somewhere on the net in a MTN repo?


> Anything that presumes just one database or allows two databases on
> the same machine owned by the same user to cross-pollinate or disrupt
> each other is a misfeature.

You should REALLY try this before stating things like this.
Please give an example.

It's possible to commit to the wrong database, but you have to really
want to do it. And you have to commit to a branch, that has no common
ancestor with any of the existing revisions. I can't see a problem here.
Sorry.


> I recently updated from a much older version and I now have two
> databases that are essentially screwed.


A VERRYY OOOOLD database.


        Luckyly you used a distributed system.


I know how it feels to do something stupid when in a hurry (it's sunday,
and soon it's monday). I did an 'rm -r *' in the wrong console lately
:-D



Cheers,

  Sebastian