I think that it's fine -- as was just discussed on the list, the expectation was that the encryption format was likely to change prior to 1.4.0.
Maybe there are conversion options for those users who have written the old format (that don't involve shoehorning ir into the app itself)? -----Original Message----- From: Robert Nelson <[EMAIL PROTECTED]> Subj: Re: [Bacula-users] Encryption/Compression Conflict in CVS Date: Thu Nov 2, 2006 11:30 am Size: 2K To: 'Landon Fuller' <[EMAIL PROTECTED]>, 'Michael Brennen' <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], bacula-users@lists.sourceforge.net Landon, I've changed the code so that the encryption code prefixes the data block with a block length prior to encryption. The decryption code accumulates data until a full data block is decrypted before passing it along to the decompression code. The code now works for all four scenarios with encryption and compression: none, encryption, compression, and encryption + compression. Unfortunately the code is no longer compatible for previously encrypted backups. I could add some more code to make the encryption only case work like before. However, since this is a new feature in 1.39 and there shouldn't be a lot of existing backups, I would prefer to invalidate the previous backups and keep the code simpler. Also I think we should have a design rule that says any data filters like encryption, compression, etc must maintain the original buffer boundaries. This will allow us to define arbitrary, dynamically extensible filter stacks in the future. What do you think? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Landon Fuller Sent: Wednesday, November 01, 2006 7:08 PM To: Michael Brennen Cc: bacula-users@lists.sourceforge.net Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS On Nov 1, 2006, at 2:20 PM, Michael Brennen wrote: > On Wednesday 01 November 2006 15:33, Arno Lehmann wrote: > >>>> This sounds like compression should be automatically disabled when >>>> encrypton is enabled. Should be useless anyway as encrypted data >>>> should >>>> no longer be compressible. >>> >>> Not if compression happens prior to encryption. :) >> >> Theoretically - yes, but I'm quite sure that encryption usually also >> compresses data. This is completely unverified and refers to >> encryption >> programs that are rather outdated by now, though... >> >> But I suppose you could inform us if encryption in Bacula also >> compresses :-) > > Landon, what is your take on this? Since you wrote the code you > seem to be > the best source on whether the openssl functions you are using > compress data. Howdy, The encryption does not include compression -- It made more sense to piggyback on the existing compression code. Also, thanks for catching this! I'm embarrassed that I forgot to test backup+restore with both compression and encryption enabled. -landonf ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
