Hi Robert!
Sorry to read that you've lost your keys during upgrade - no chance to
have a backup laying around somewhere?
You wrote:
1) It presumes that any given login ID and key id uniquely identifies
a database. To whit
mtn --db Employer1.db db migrate
mtn --db Employer2.db db migrate
Hi,
Daniel Carosone wrote:
I'm not so sure.. I'd happily go for 'strange' or some other word,
rather than 'wrong'. At the very least, I'd like to try and work
through all the cases we can think of where this might arise, and just
confirm whether a sensible or legitimate interpretation
Ethan Blanton wrote:
Robert White spake unto us the following wisdom:
Daniel Carrera wrote:
Robert White wrote:
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).
Robert White wrote:
Why would I want to do that?
The question isn't whether _you_ would want to do that, its whether or
not a non-trivial number of users might...
Have you honestly never heard of a contract that requires complete
surrender or destroy of materials etc? That is the default for
Hi,
as mentioned in other threads already, I'm currently analyzing date
certs and comparing them against the revision ancestry. The obvious
first test database includes all of net.venge.monotone* (and nothing
else). At the time of testing, it had 14156 revisions with 17737
relations between them
Markus Wanner [EMAIL PROTECTED] writes:
[...]
What surprised me about the pidgin repository is, that there are some
date certs with six digits (!) for milliseconds in the date, i.e.:
2006-11-01T21:39:36.807940
IIRC Tailor did that at one point, so likely that's a result of
converting from
Robert White wrote:
Howdy all,
I don't know who decided that .monotone/keys was a good idea but it is
a DISASTER for me.
For various reasons It is desirable to use the same real world
identity, q.v. [EMAIL PROTECTED], in several different databases with
different keys behind them for
Ethan Blanton wrote:
Monotone generally settles on security first; many users (myself
included) consider this a good thing.
I second that. Security is one of the most interesting features of
Monotone. It's what brought me to this list.
A single, well-known key store
is much easier to keep
On Mon, 2008-10-20 at 10:57 +0200, Markus Wanner wrote:
Hi,
Robert White wrote:
Try things like wanting to be able to revoke/destroy one key when the
contract is over etc.
I fail to see how that's even possible in a distributed environment. The
only thing one single party can do is
On Mon, Oct 20, 2008 at 10:31:32AM +0200, Markus Wanner wrote:
In particular, my concern is that despite agreeing and acknowleding
that there can't be a global clock, warnings or errors like this help
to encourage in the users' minds that there is a global clock anyway.
Can we really get
On Mon, Oct 20, 2008 at 10:49:12AM +0200, Markus Wanner wrote:
(Yes, this currently includes counting
dependent revisions with equal timestamps as invalid, which is certainly
bogus, just highly unlikely).
If we're only storing up to seconds, it could happen readily for a
multi-way merge that
Hi all.
I was lurking from time to time in this thread, and...
I also have an idea to help Monotone migrate from its current
system to a PGP-like system: Internally Monotone would have to
use the key fingerprint, there's no getting around that.
Would it be ever possible to have an option to
Hi,
Daniel Carosone wrote:
That's kind of my point about the separate date certs we have
currently. You propose a mechanism whereby an out-of-order or
future-dated date cert would be considered invalid and untrusted --
instead of now where it's trusted but essentially ignored (other than
Hi,
Daniel Carosone wrote:
If we're only storing up to seconds, it could happen readily for a
multi-way merge that created several intermediate merge nodes in the
one command.
Sure. See the long list of revisions I've posted, there's one such case
within net.venge.monotone*:
Daniel Carrera spake unto us the following wisdom:
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
Hi,
Timothy Brownawell wrote:
It's entirely possible to destroy the private half, since only one
person should ever have that. And being sure in this case sounds more
like a matter of contracts rather than technology. Something can be
useful even when technology can't guarantee it.
Good
On Mon, Oct 20, 2008 at 10:05:11AM +0200, Thomas Keller wrote:
Hi Robert!
Sorry to read that you've lost your keys during upgrade - no chance to
have a backup laying around somewhere?
Faint hope:
Is there any chance that the other keys are there somewhere, but
monotone just uses the
Robert White wrote:
Claiming it as a security action is a red herring. The key files are
encrypted anyway and physical access to the database is just as
likely-or-unlikely as physical access to the keydir.
Other security products consider it very bad practice to distribute
private keys, even
Hi,
Robert White wrote:
Try things like wanting to be able to revoke/destroy one key when the
contract is over etc.
I fail to see how that's even possible in a distributed environment. The
only thing one single party can do is distrust a key. There's no way to
make sure the other party
Bruce Stephens spake unto us the following wisdom:
Markus Wanner [EMAIL PROTECTED] writes:
What surprised me about the pidgin repository is, that there are some
date certs with six digits (!) for milliseconds in the date, i.e.:
2006-11-01T21:39:36.807940
IIRC Tailor did that at one
Marcin W. Dąbrowski wrote:
Would it be ever possible to have an option to use external
tools for signing certs? I.e. GnuPG signatures?
Not right now (and it's not planned, AFAIK), but you can do of course
things that pretty much guarantee the same thing:
1. GPG-sign your monotone public key:
On Fri, Oct 17, 2008 at 11:12:08AM +1100, Daniel Carosone wrote:
[...]
Discuss. :)
--
Dan.
I think this is a great idea. Why don't we set a date for the next
virtual summit. Perhaps the first full weekend in December (the
5th-7th)? Or is that too close to thanksgiving (US) or
Lapo Luchini wrote:
OK, using (the same) e-mail addresses in different keys may pose
additional hurdles, but why using e-mail addresses in the first place?
You need to use email addresses in order to answer the question Who
signed this revision?
Unfortunately, what we have is a poor
Lapo Luchini wrote:
1. GPG-sign your monotone public key: this way people that trust your
GPG key know that they can trust your monotone signatures (if they trust
monotone itself, that is)
You still need some way of being able to tell that the revision was
signed with the same key that was
Daniel Carrera wrote:
I think that Ethan's idea has a lot of merit. Btw, PGP allows a user
to have multiple keys associated with the same name and email. To help
the user distinguish between keys. If you list them, they look like this:
Daniel Carrera (Personal) [EMAIL PROTECTED]
Daniel
25 matches
Mail list logo
