> I guess it comes down to the definition of "previous versions".  If you
> exclude previous development versions (ie 1.39.x) then it is backwards
> compatible since the problem and the fix only affect encrypted data which,
> as far as I know, wasn't available in 1.38.x.

Ah, good point.  Yes, I think it is reasonable to exclude previous
development versions from the definition of "previous versions".

>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kern
> Sibbald
> Sent: Friday, November 03, 2006 4:40 PM
> To: Robert Nelson
> Cc: [EMAIL PROTECTED]; 'Landon Fuller';
> bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] [Bacula-devel] Encryption/Compression Conflict
> in CVS
>
>
>> This code is backwards compatible for everything except encrypted data.
>> Previously compressed backups will still work fine.
>
> I'm not 100% sure what you mean, but here are my thoughts:
>
> If it breaks something that previously worked, then it is does not fit
> with the Bacula philosophy of always being able to read Volumes written by
> prior versions.
>
> If something was previously broken -- i.e. could not be read -- then we
> should attempt to fix it, if at all possible.
>
> Maintaining backward Volume compatibility and fixing the problem is the
> best solution.  Hopefully this is what you can do ...
>
> If we *must* create an incompatibility with Volumes written by prior
> versions of Bacula, then we need to think really hard about how to handle
> it because to the best of my knowledge this has never happened.
>
> If certain combinations of options created data that cannot be read under
> any conditions, then we need to carefully document it and inform the
> users.
>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Kern
>> Sibbald
>> Sent: Friday, November 03, 2006 4:15 PM
>> To: Robert Nelson
>> Cc: [EMAIL PROTECTED]; 'Landon Fuller';
>> bacula-users@lists.sourceforge.net
>> Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
>>
>>
>>> 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?
>>
>> I'm unfortuntely not in a good position to examine this problem in
>> detail,
>> but I suggest that we should do our best to keep the old data readable
>> by
>> any kludge necessary.
>>
>> One possible solution for the new code that you have implemented is to
>> put
>> the new compressed data in a new stream -- i.e. a different one from the
>> old compressed data -- this could possibly allow old Volumes to be read
>> and any new data written to Volumes will be written correctly.
>>
>> One thing to be very careful about is to make sure the length that you
>> store is bigendian-littlendian independent. Probably you have already
>> done
>> this, but if not you need to use the serialization code that is also
>> used
>> for sparse file length.
>>
>>
>>>
>>> -----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
>>>
>>
>>
>> Best regards, Kern
>>
>> -------------------------------------------------------------------------
>> 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-devel mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/bacula-devel
>>
>
>
> Best regards, Kern
>
> -------------------------------------------------------------------------
> 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
>
>


Best regards, Kern

-------------------------------------------------------------------------
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

Reply via email to