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. >> 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". >> 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 :-) -- 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
