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 Carre
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 GP
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 solut
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 ch
On Mon, Oct 20, 2008 at 02:30:27PM +0200, Markus Wanner wrote:
> Looks like we are just approaching the problem from different angles.
> I've been analyzing what's required to convert to atomic certs (or
> super-certs or whatever you'd like to call it). I'm thinking that we
> need to clean up our c
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:
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
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
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 cann
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*":
ee293e066a
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 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
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
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 real
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 p
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
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
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
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
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 w
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 "destr
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
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
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).
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 c
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 migr
26 matches
Mail list logo
