Re: [Botan-devel] [Monotone-devel] upgrade of included botan for mtn

[Jack Lloyd]

On Sat, Sep 27, 2008 at 06:04:57PM +0200, Markus Wanner wrote:

> > This is OK (and might be more secure in some scenarios, for example if
> > randomness seeding failed catastrophically 1/3 of the time) but it was
> > particularly the intent for this change that single-threaded programs
> > like Monotone would be able to use a single RNG instance across its
> > entire execution.
>
> We had exactly that as well with the Global_RNG before, didn't we?

Yes, but the global RNG had locking (or no-op locking, in Monotone's
single threaded case) around it before.

Basically the idea of this was to remove any locking overhead unless
it was actually required. The best way to do that was to force any
syncronization to be guaranteed by the application, which is in the
best position to understand the right sorts of sync needed (and in
particular, it allows RNG-per-thread implementations, or even a pool
of RNG threads if that were desirable), both in terms of policy and
mechanism. I'm hoping to remove all shared mutable state out of Botan,
so that less concern has to be made about locking and concurrency
correctness. However there is a long way to go on that and who knows
if/when it will be finished (though quite a bit has already been done
in the 1.7 tree).

> I'm now calling make_rng() once when initializing the app_state and
> passing on a boost::shared_ptr. (Do I have to seed the RNG after
> make_rng()?)

Not normally - make_rng will do everything it can to seed the RNG
before returning it (or, rather, to give it entropy sources that it
will use to seed itself later on when asked to produce output). Of
course if there are zero entropy source modules loaded, or /dev/random
got deleted, etc, it might not be seeded. But normally you can expect
that it will.

> That's what I intended to do. The problem is that I'm not sure how to
> pass it to that lua extension.

Ah, might be trouble :/

> I don't think it's much of an issue, though, because the RNG there is
> only used to create a name for a temporary directory AFAICT.

You could always do basically what Botan did and store the pointer (or
smart pointer) as a global or class variable, something that mkstemp
would be able to get a reference to no matter what and without relying
on its arguments.

> This limitation is due to not using botan's configure logic but stuffing
> all the cc and hh files into our own Makefile.am. Monotone's included
> botan lacks modularization and only distinguishes between unix/win32 (by
> adding es_win32.cpp for the later). I'm not sure how well that works for
> Windozen at all, but so far we had no complaints...

OK yeah that was basically my understanding of the situation.

> n.v.m.library-build as a dev. branch of monotone which tries to allow
> linking monotone against external libraries instead of the current "we
> don't rely on external dependencies - we re-bundle them instead"
> approach. This would solve the issue by letting botan use its own
> configure script and build infrastructure, which would be a very good thing.

[this is good]

> The current curse of action is to propagate from your botan repository
> into a staging branch, where we do necessary adjustments for integration
> into monotone.
>
> To prevent pulling in the complete botan history we do only copy files
> from the staging branch and mtn add/remove manually.

Yeah I know. I had hoped to do the Monotone port work myself on this
last bump, especially the RNG changes, but the whole merge into one
branch and then another, etc, etc... I didn't want to deal with it and
ended up working on other things. It would be great to be able to
simply compile Monotone directly against my local workspace for
testing, profiling, and keeping Mtn following any API changes made
along the dev branch.

-Jack