Re: [Monotone-devel] project status

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 04.08.2010 13:03, schrieb Stephen Leake:
>> Patrick Georgi <address@hidden> writes:
>> 
>>> 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.
>> 
>> Yes, but is 'mtn sync --key-to-push' enough?
>> 
>> What is actually needed by indefero?
>
> A way to inject a new key from a (remote_)stdio connection into a
> database to be used later for authentication purposes.

Ok; does 'sync --key-to-push' via 'mtn automate stdio' do that?
Seems like it should, but I haven't tried it.

On the other hand, why does it have to be 'via a stdio connection'? 'mtn
sync --key-to-push mtn:server' should get the desired key into the
server's database.

Hmm. Maybe the server host rules don't allow a standard mtn: connection,
but require an ssh: connection. That makes sense. But that still means
'mtn sync --key-to-push ssh:server' should work. 'automate' does not
need to be involved.

Doing key operations should be rare, so the convenience of using an
existing 'automate stdio' connection to do key management should not be
an issue.

>>> 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)
>> 
>> Keys on the server are only used to verify signatures; a key put there
>> by mistake will simply never be used. While it makes sense to clean up
>> the mistake, it opens the door to deleting other keys by mistake.
>
> Thats why there is a new selector in monotone 0.99 - the k: selector. If
> this returns empty, the key is save to be deleted. There are a couple of
> shoot-yourself-in-the-foot commands in automate, but hey, this is
> automate, not a user interface.

ok. 

There is also the race condition of deleting a key that is currently
being used to commit something; we'd need the keystore interface to
enforce a lock, and provide an atomic 'delete if unused' operation.
That's a big change for a minor use case.

I gather the indefero server does not give shell access to a project
admin? That seems to be a bigger problem; I'm not sure we should be
putting project admin operations in the automate interface that are
already provided by a shell interface.

-- 
-- Stephe