monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] project status


From: Thomas Keller
Subject: Re: [Monotone-devel] project status
Date: Wed, 04 Aug 2010 10:59:26 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.10) Gecko/20100520 SUSE/3.0.5 Lightning/1.0b2pre Thunderbird/3.0.5

Am 04.08.2010 10:45, schrieb Patrick Georgi:
> Am 04.08.2010 09:51, schrieb Stephen Leake:
>> From the bug discussion https://savannah.nongnu.org/bugs/?30345, it 
>> appears that the minimum necessary is already there, via 'mtn
>> automate read_packets', and/or 'mtn sync --key-to-push'.
>>
>> So what is the indefero use case, and what is still missing?
> First, the read_packet stuff might be dropped at some point (with all
> the other packet based CLI commands), as these seem to have fallen out
> of use.
> Second, Thomas proposed to add a "drop_key" command of some sort. While
> that won't help for already propagated keys (as those will come back),
> it allows the removal of just-added keys (ie. those added by mistake)
> 
> For indefero it's not crucial to have a "get_key" command, not sure if
> there's an interesting use case for that.

"get_key" should mainly be useful if you create a new key and want to
send it to someone hosting a server for authentication. A server-side
use case here could be to return / display the public key of the server
in case you want to enable a mirroring setup.

One might also think that it would have advantages when the server key
is imported into an empty database before the first pull, i.e. less
verbose server identity output ("you might want to double-check their
key's fingerprint [...]"), but thats not the case.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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