[OTR-dev] Requirements for libotr4

Len Sassaman rabbi at abditum.com
Mon Aug 4 01:01:31 EDT 2008


[Apologies if these issues have already been settled -- I'm behind on my
list mail.]

On Sat, 21 Jun 2008, Ian Goldberg wrote:

> Note: this message is long, and will only be of interest to Uli and
> others who care about asynchronous privkey generation.

[snip]

> > What do you think of that?

I'm showing my Unix systems programming background here, but is there any
objection to having a separate key generation process entirely, rather
than doing this with threads?

> otrl_privkey_generate_start checks to see if a generation for this
> account is already in progress.  If so, it returns a particular error
> code, and the application should free any data state it allocated before
> calling this routine.
>
> If not, otrl_privkey_generate_start will create an opaque data structure
> newkey, and pass it to call_when_ready, along with the data the
> application handed it.

This all seems reasonable to me.

> But I've got a question for you, Uli:  key generation usually happens
> when you get an incoming OTR Query or OTR Commit message.

Is there a reason not to generate keys at the time an account is added to
the client or registered/created? Obviously this is not a libotr issue,
but it could be encouraged in a developers notes guide. Generating keys
preemptively in the background so that the user does not need to wait for
them while a conversation is in progress seems like a good usability move.

(Obviously you still need to address the case you're talking about for
clients that choose to do things "on-demand" though.)

> So: even assuming we do the above, your create_privkey callback *must
> not* return until the key generation is complete.  You can still perform
> the key generation in a subthread, though, and your main thread can
> handle UI events to avoid appearing frozen, but it *must not* call
> any libotr functions (even in the UI handlers, hmm).

I assume we're doing a tuple check to make sure that the key generation
we're blocking on is for the account that OTR operations are being
requested for? If I have one account that is having its key generated, and
another account that already has a key, I should of course be able to
merrily perform OTR operations for the second account while the first
account is waiting on the key generation.

You'll also want a way to gracefully stop a key generation in progress,
for instance if the app exits. I didn't see a call for that.


--Len.



More information about the OTR-dev mailing list