monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] key management


From: Stephen Leake
Subject: Re: [Monotone-devel] key management
Date: Fri, 06 Aug 2010 06:23:46 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt)

Thomas Keller <address@hidden> writes:

> Am 06.08.2010 00:30, schrieb Stephen Leake:
>> Thomas Keller <address@hidden> writes:
>>> One might deprecate the reader functionality packets other than keys
>>> though.
>> 
>> The top level code in cmd_packet.cc makes no distinction between key and
>> other packets. But we could delete the non-key operations from packet.hh
>> packet_consumer.
>
> Yes, this is what I meant and what we should do some time.
>
>> There is already an 'automate read_packets' command!
>> 
>> So I think 'automate put_pub_key" is already implemented.
>
> Kind of. Surely you can put public keys through read_packets, but as
> this uses the aforementioned packet_consumer as well which might be
> refactored or even replaced some time in the future, I'm not sure if its
> a good idea to use that at all. Beside that its not obvious to the
> implementor that the orthogonal action to get_pubkey and remove_pubkey
> is read_packets. Maybe its time to do this command deprecation thing
> earlier, i.e. introduce put_pubkey nonetheless and deprecate automate
> read_packets, while having doubled functionality for the time until
> read_packets gets removed completely, i.e. in 2.0.

Ok. In terms of the roadmap and bug 30345, let's say 'automate
put_public_key' is implemented (as 'automate read_packet').

Then add another bug/roadmap entry to deprecate the non-key parts of
'automate read_packet', and rename it to 'put_public_key'.

I don't think we can use the mtn command alias function to provide a
rename now?

>> Unless the point was to have some other format for the input. Bug 30345
>> doesn't say what format is expected. ASCII-armored was mentioned in
>> chat, but I'm not sure that's a format spec?
>
> No, the input to put_pubkey can basically keep the same - I don't know
> if ascii-armored is the right term for this either, basically it should
> accept what pubkey spits out :)

Ok. So 'automate get_public_key' should output the packet format, _not_
basic_io. That is very easy to implement.

'automate remove_public_key' is an automate version of 'dropkey', but
only removes public keys from the database. That's also easy to implement.

-- 
-- Stephe



reply via email to

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