bugmonotone - Bugs: bug #30345, Key management over automate

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #30345: Key management over automate

Submitted by:  Thomas Keller <tommyd>
Submitted on:  Sun 04 Jul 2010 09:44:14 PM UTC  
 
Category: automation interfaceSeverity: 3 - Normal
Item Group: feature requestStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed
mtn version --full: 

mtn-0.48

Tue 24 Aug 2010 06:41:58 AM UTC, comment #4:

added 'automate put_public_key', 'automate get_public_key', 'automate drop_public_key'

Stephen Leake <stephen_leake>
Project Member
Tue 06 Jul 2010 07:22:57 AM UTC, comment #3:

I forgot one thing - given the fact that we want to deprecate / remove the packet functions (at least for revisions, certs, files and file deltas) on the long run, we might not want to use read_packets for put_public_key.

The removal of the packet functions is on the roadmap for a long time - I don't know if people still use these functions at all.

Thomas Keller <tommyd>
Project Administrator
Tue 06 Jul 2010 07:20:24 AM UTC, comment #2:

Interesting, totally forgot about read_packets indeed. Probably because I thought this is only able to consume packets the other packet functions can spit out...

You're right that removing public keys might cause issues when the key signed stuff and the key is likely to come back anyways when another node uses --key-to-push to upload it again, but I thought of it as a mental model from an interface point of view, i.e. you can list something, can add something new and you can also undo the previous action and remove something which you accidentially added. Maybe mtn au dropkey could check if the key signed anything and error out in this case?

Thomas Keller <tommyd>
Project Administrator
Mon 05 Jul 2010 10:37:31 PM UTC, comment #1:

"mtn automate read_packets" works for loading keys, as does sync/push with --key-to-push.

I'm not sure removing public keys is a good idea, if they've been used to sign anything then either they'll come back (if someone's already pulled those certs) or you end up with unverifiable certs.

"automate get_public_key" does sound like it could maybe be useful.

Timothy Brownawell <tbrownaw>
Project Member
Sun 04 Jul 2010 09:44:14 PM UTC, original submission:

monotone should have better key management functions in automate, to be able to inject and remove public keys "on the fly" in running server instances. This is particularily needed if the database is not directly accessed, but over remote_stdio, since `mtn read`, `mtn pubkey` and `mtn dropkey` are not available for this use case.

Proposed API methods:

automate get_public_key KEYID
automate put_public_key DATA
automate remove_public_key KEYID

Possible caveats:
- ensure that the key store picks up new keys / disregards old keys on long running stdio processes
- handle key addition / removal for currently running netsync processes gracefully, f.e. what happens if a key is removed with which is currently synced in parallel to the same server?

External reference:
http://data.softwareliber.ro/irc-logs/%23indefero/%23indefero.29-06-2010.log
http://data.softwareliber.ro/irc-logs/%23indefero/%23indefero.30-06-2010.log

Thomas Keller <tommyd>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by stephen_leake (Posted a comment)
  • -unavailable- added by tbrownaw (Posted a comment)
  • -unavailable- added by tommyd (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 24 Aug 2010 06:41:58 AM UTCstephen_leakeStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1