Re: [Monotone-devel] project status

[Thomas Keller]

Am 04.08.2010 15:30, schrieb 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.

How should it do that? I can only push keys from one database to
another, but I want to put, i.e. store keys directly, similar to what
`mtn read` provides. Use case: Admin enters the ascii-amored version of
a public key in a web form and hits "add". The key is read and stored in
the database via automate.

> 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.

It needs to be involved for the above use case.

>>>> 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.

A more common race condition could be the usage of push and delete_key,
but then again this should be rather rare as well timing-wise. But since
both actions merely act on the database, shouldn't our transaction guard
take care of this?

> 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.

indefero will have to manage "live" monotone databases behind usher.
Shell access is not wanted for various reasons.

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

signature.asc
Description: OpenPGP digital signature