On Friday 16 April 2010 14:06:08 Craig Ringer wrote: > On 16/04/10 18:54, Kern Sibbald wrote: > > Can you explain to me the need for Bacula to read the openssl.cnf file > > and what it would do with the information? In general, I am not very > > enthusiastic about Bacula reading things like openssl.cnf, and if you > > envisioned having Bacula change the file, it wouldn't be something I > > would want to add to Bacula. > > OpenSSL provides a config loading mechanism so that users can configure > an application's use of OpenSSL without the app having to provide its > own interface to OpenSSL configuration via app-specific config language. > It lets the app specify the location of the file to load, so while it's > loading an "openssl config file" it's not *the* openssl config file, > it's the bacula config file that controls bacula's use of openssl. > > So Bacula might check for /etc/bacula/openssl.cnf (or > /etc/bacula/bacula-openssl.cnf - whatever is desired) and if found, ask > OpenSSL to read and process it.
OK, that sounds entirely reasonable to me and won't pose a problem. > > This allows users with hardware crypto engines to enable and configure > them without Bacula having to know or care about it. It's how OpenSSL is > designed to work. > > > I would much prefer just a directive that specifies to turn hardware > > crypto off/on. > > That's easy to do with hardware crypto engines like padlock and aesni > that are built into the openssl binary - and I do agree that for those a > single "UseHardwareCrypto=[yes|no]" might be useful. OTOH, nobody should > ever need to disable them, and if they do they can just drop in a > suitable config file, so I'm not sure the directive is actually necessary. Yes, if it is possible to turn off encryption (as I imagine) with a Bacula specific OpenSSL conf file, then the only Bacula directive necessary is the one to specify an alternate cnf file. > > Other hardware crypto engines require OpenSSL to load a shared library > provided by the OpenSSL distribution (see /usr/lib/ssl/engines) or the > crypto module vendor. They may also require additional configuration. > That's when reading openssl.cnf (or some alternative) comes in handy. > > > If we *really* need to have something done to the openssl.cnf script, I > > prefer to have an external program or script that is executed by a > > RunScript that makes the modification. > > No, Bacula would *never* have to modify its own openssl.cnf let alone > the system one. OK, fine. > > >> Er, oops. I meant "fd". > > > > OK, understood. > > Hardware encryption would be much, much more useful in the sd, and I > would like to look into that. I know it's on your TODO (presumably along > with increasing the sd's ability to use multiple cores/CPUs to make it > practical). > > Using hardware crypto in the fd *will* become increasingly useful, > though, as Intel servers (and hopefully desktops and/or AMD servers down > the track) get aesni instruction support. Having each server pre-encrypt > data at line speed is no bad thing, especially since you get the > inherent parallelism advantage of doing it on each client rather than > doing all the crypto on the sd. Yes, I understand, which is why we chose to favor doing it in the FD as the first cut. I can also see the advantage for extremely secure sites of doing everything in the SD where they can guarantee security much better though it doesn't scale too well at the moment to thousands of machines. > > The core libraries need support for it before it can be added to the sd > anyway, and in the process the fd gets hardware crypto for free. > > Plus, it's much easier starting point than adding it to the sd, and will > permit getting it out into the field quickly for testing, so that it's > already widespread when aesni support starts becoming common. I don't > think PadLock support is particularly relevant on the fd end as few > people will have VIA C3/C7/Nano servers. > > ( PadLock would be *awesome* on the sd end, though, permitting the use > of cheap and simple Mini-ITX or smaller Via boards and embedded systems > for crazy-fast encrypted backup servers. Can you say "network backup NAS > appliance" ? ) > > > I ask, because we are looking for someone to implement encryption in the > > Storage daemon as a funded development project. If you are interested or > > know someone who could implement it, I would appreciate getting in > > contact with them. > > I'd be interested, but (a) am drowning in existing day-job coding work, > and (b) am not sufficiently confident with my crypto knowledge. OK I understand. It is exactly the same for me. :-) > > I'd be interested in collaborating with anyone working on it, though, > and for all I know may get to the point where that's something realistic > for me to tackle. Right now, I'm not up to it in terms of my knowledge > of the Bacula code or my knowledge of OpenSSL. > > > PS: If you are going to submit a patch, please go to www.bacula.org -> > > FSFE License, fill out two copies of the FLA, and post it to me at the > > address given. Once you do so, I just need an email saying it is in the > > post to be able to accept and apply a patch (assuming it meets our > > programming standards as defined in the Developer's guide). Sorry for > > the admin stuff, but it keeps Bacula free :-) > > Urk. Sure, can do. > > -- > Craig Ringer ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
