[Top][All Lists]
[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
- [Monotone-devel] nvm.options, Stephen Leake, 2010/08/05
- Re: [Monotone-devel] nvm.options, Thomas Keller, 2010/08/05
- Re: [Monotone-devel] nvm.options, Stephen Leake, 2010/08/05
- [Monotone-devel] key management, Stephen Leake, 2010/08/05
- Re: [Monotone-devel] key management, Thomas Keller, 2010/08/06
- Re: [Monotone-devel] key management,
Stephen Leake <=
- Re: [Monotone-devel] key management, Stephen Leake, 2010/08/09
- Re: [Monotone-devel] key management, Thomas Keller, 2010/08/09
- Re: [Monotone-devel] key management, Stephen Leake, 2010/08/09
- Re: [Monotone-devel] key management, Thomas Keller, 2010/08/10
- Re: [Monotone-devel] key management, Stephen Leake, 2010/08/10
- Re: [Monotone-devel] key management, Stephen Leake, 2010/08/18
- Re: [Monotone-devel] key management, Thomas Keller, 2010/08/18
- Re: [Monotone-devel] key management, Stephen Leake, 2010/08/18
- Re: [Monotone-devel] key management, Stephen Leake, 2010/08/23