--- In IB-Architect@egroups.com, Jim Starkey <jas@n...> wrote:

> ... let's try to not get too silly on the security issues.
>
> The principles I think we need to adopt include these:
>
> 1. Implement nothing with a known hole; security by
> obscurity is out.
>
> 2. For each piece, pick the best available technology,
> even if that piece isn't the weakest link. Crypt()
> is bad; SHA or MD5 are good. Better than SHA or MD5,
> for firebird, is overkill. DES on passwords is bad;
> DES for single session line encryption is probably
> good enough. A better legal alternative would be
> worth considering.
>
> 3. Don't get silly. If the server needs a PKI key pair,
> let it generate one. Requiring a certificate is
> a burden and is unnecessary.
>
> ... [etc]

I think that we have two main threads here. The first is comms
security and the second is security on the OS/IB interface. They are
obviously closely related but I personaly feel more competent to
address archetectural questions on the second issue: other people may
lean the other way.

Does it make sense to distinguish between network communications stuff
and questions of file security, UDFs, user/group IDs etc? Where the
lists of users, their passwords are stored and how can be addressed
jointly. Both threads can proceed in parallel.

I know that Mark O'Donohue has been working hard on the second set of
issues with other people. It would be great to see a map of how this
is going given the current code base. If there is no map, then we can
help draw one.

Julian