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.
>
>
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
> Subje
On Nov 1, 2006, at 23:25, Michael Brennen wrote:
On Wed, 1 Nov 2006, Robert Nelson wrote:
On top of the issue with the reversed processing during restore
that I
previously mentioned, there is a fundamental flaw in the
processing of
compressed+gzipped data. The problem is that boundaries a
On Nov 2, 2006, at 13:22, Robert Nelson wrote:
The problem is that currently there are three filters defined:
compression,
encryption, and sparse file handling. The current implementation of
compression and sparse file handling both require block boundary
preservation. Even if zlib streamin
On Nov 2, 2006, at 08:30, Robert Nelson wrote:
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 decompressio
eforge.net
Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
On Nov 2, 2006, at 13:22, Robert Nelson wrote:
> The problem is that currently there are three filters defined:
> compression,
> encryption, and sparse file handling. The current implementation of
> compr
t: 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 e
Hi,
On 11/2/2006 12:20 PM, Alan Brown wrote:
> On Wed, 1 Nov 2006, Arno Lehmann wrote:
>
>
>>>Not if compression happens prior to encryption. :)
>>
>>Theoretically - yes, but I'm quite sure that encryption usually also
>>compresses data.
>
>
> If the encryption routines also contain compressio
file handling would be broken.
-Original Message-
From: Landon Fuller [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 11:06 AM
To: Robert Nelson
Cc: 'Michael Brennen'; [EMAIL PROTECTED];
bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Encryption/C
On Thursday 02 November 2006 10:30, Robert Nelson wrote:
> 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.
Excellent. Is t
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 PRO
eforge.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
>>>> encryp
On Wed, 1 Nov 2006, Arno Lehmann wrote:
>> Not if compression happens prior to encryption. :)
>
> Theoretically - yes, but I'm quite sure that encryption usually also
> compresses data.
If the encryption routines also contain compression routines.
> This is completely unverified and refers to en
On Wed, 1 Nov 2006, Robert Nelson wrote:
> On top of the issue with the reversed processing during restore that I
> previously mentioned, there is a fundamental flaw in the processing of
> compressed+gzipped data. The problem is that boundaries aren't preserved
> across encrypt/decrypt.
>
> What
ailto:[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 Novem
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 compres
On Wed, 1 Nov 2006, Landon Fuller wrote:
>> 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.
>
> The encryption does not include compression -- It made more sense
> to piggyback on the
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. :)
>
>
Hi,
On 11/1/2006 6:00 PM, Michael Brennen wrote:
> On Wednesday 01 November 2006 05:43, Arno Lehmann wrote:
>
>
>>>So... in my testing the combination of encryption and compression is
>>>either not writing files correctly to tape (in which case there is a
>>>lot of tape space taken up needlessly
ednesday, November 01, 2006 3:43 AM
> To: bacula-users@lists.sourceforge.net
> Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
>
> Hi,
>
> On 11/1/2006 5:43 AM, Michael Brennen wrote:
> > I posted a couple of days ago that restoring files from 1.39
On Wednesday 01 November 2006 05:43, Arno Lehmann wrote:
> > So... in my testing the combination of encryption and compression is
> > either not writing files correctly to tape (in which case there is a
> > lot of tape space taken up needlessly :) or the files are being
> > corrupted in the restor
PROTECTED] On Behalf Of Arno
Lehmann
Sent: Wednesday, November 01, 2006 3:43 AM
To: bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] Encryption/Compression Conflict in CVS
Hi,
On 11/1/2006 5:43 AM, Michael Brennen wrote:
> I posted a couple of days ago that restoring files from 1.3
Hi,
On 11/1/2006 5:43 AM, Michael Brennen wrote:
> I posted a couple of days ago that restoring files from 1.39.27
> (current CVS) with both encryption and compression turned on
> resulted in 0 length files being restored.
>
> I was able to test that further tonight by archiving and restoring a
I posted a couple of days ago that restoring files from 1.39.27
(current CVS) with both encryption and compression turned on
resulted in 0 length files being restored.
I was able to test that further tonight by archiving and restoring a
file in the 4 combinations of encryption/compression off/
24 matches
Mail list logo
