Travis H. wrote:

> This directory seems to have disappeared.

Sorry about that, it's back online.

> BTW, I'm willing to help at the design level of BPG and a secure update
> model for packages/ports/etc.  I don't think I'll have time to help with
> the
> implementation though.

Cool. There were two folks who were looking at the code a while ago in
an attempt to revive the project -- contact me off-list and I'll give
you some more info.

> I don't know what the licenses on the modules are, but consider using a
> HLL for _userland_ security tools that interact with the network or process
> untrused data. 

At the moment, to really allow 100% dispatching to userland of
authorization requests (I'm assuming you're talking about security
modules?) we need two things: first, a lot of our locking schemes don't
make it easy to go to usermode in some cases where kauth(9) calls are
made. We'll have to work. Second, we'll need a generic kernel-userland
communication mechanism, which can be used both by kauth(9) for the
above, and Veriexec to do signature handling stuff.

Until we have these two -- and it's going to take a while :) -- there's
still some time.

> The opportunity for a variety of implementation-related
> vulnerabilities is thereby avoided.  If you use a widespread package for
> the low-level implementation like openssl (isn't that capable of doing
> signatures and it's already in userland isn't it?) then you can avoid all
> the hassle and error-prone bit-diddling and spend your time on
> protocol-level stuff, often with an order-of-magnitude reduction in
> lines-of-code.  I use python myself but hear good things about ruby
> from the bilingual people I know.  If you want to get really crazy,
> consider a (mostly) functional language like ocaml.  Then you
> completely avoid worrying about flow-of-control and the subtle
> problems that can arise therein (e.g. the problem of testing every code
> path, the hidden bugs that lurk in infrequently-used code paths,
> off-by-one errors in loops and getting the sense of the test wrong).

OpenSSL is certainly a route we're considering...

Thanks,

-e.

-- 
Elad Efrat