On Friday 16 April 2010 12:06:09 Craig Ringer wrote: > On 16/04/10 16:38, Kern Sibbald wrote: > > Yes, I think that is a good idea. It seems to me that the default should > > be to use hardware encryption if it exists, but it will be important to > > be able to disable it via a directive, and possibly specify what hardware > > device is permitted. > > Yep. Anything more complex than on/off means it'll be necessary to load > openssl.cnf . That's probably best anyway, as it's good practice for > openssl-using apps and it gives users the greatest degree of control > without inventing a whole new set of Bacula config extensions to do the > same thing. > > I'm inclined to add one new directive, specifying the location of > openssl.cnf to override the default, but otherwise leave configuration > to openssl.cnf.
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. I would much prefer just a directive that specifies to turn hardware crypto off/on. Anything addition, should be left to the user to configure himself. 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. > > >> If the unconditional patch works I'll post it, then see if I can get the > >> sd (at least) to read openssl.cnf and follow up with a second patch. > > > > If I understand correctly, your patch adds encryption to the SD. Is that > > correct? > > Er, oops. I meant "fd". OK, understood. 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. > > >> Oh, by the way, newer VIA chips like the 2nd revision C7 and the Nano > >> support hardware SHA-1 and SHA-256 too :-) > > > > Hmm. That is also interesting ... > > Yep, especially since Bacula will automatically get that speed-up > wherever it uses OpenSSL's implementation of those routines :-) > Great. Kern 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 :-) ------------------------------------------------------------------------------ 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
