rsyncrypto-devel — Development discussions, bug reports, and announcements for rsyncrypto

Re: Version 1.10 is available for download

[Julian <jul...@gm...>]

Thanks Shachar.

I especially look forward to:

>> At this point, there is just one known bug open for version 1 - make
>> sure rsyncrypto does not abort entirely at the first sign of trouble.

Cheers
Julian


2008/5/23 Shachar Shemesh <sh...@sh...>:

> Hi all,
>
> Version 1.10 is available for download from the usual place.
>
> New to version 1.10:
> - A bug fix for Windows - mkdir with only drive letter would fail
> - Added an --export-changes option for optimizing rsync file list
> negotiation. Do not use without first reading the manual page!
>
> I mean it regarding the second issue. The man page has some very serious
> caveat regarding this option, so please do yourself the favor and only
> use it after you have read the man page and understood the implications.
>
> At this point, there is just one known bug open for version 1 - make
> sure rsyncrypto does not abort entirely at the first sign of trouble.
>
> Shachar
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Rsyncrypto-devel mailing list
> Rsy...@li...
> https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
>

Version 1.10 is available for download

[Shachar S. <sh...@sh...>]

Hi all,

Version 1.10 is available for download from the usual place.

New to version 1.10:
- A bug fix for Windows - mkdir with only drive letter would fail
- Added an --export-changes option for optimizing rsync file list
negotiation. Do not use without first reading the manual page!

I mean it regarding the second issue. The man page has some very serious
caveat regarding this option, so please do yourself the favor and only
use it after you have read the man page and understood the implications.

At this point, there is just one known bug open for version 1 - make
sure rsyncrypto does not abort entirely at the first sign of trouble.

Shachar

Advisory - Rsyncrypto maybe affected from Debian OpenSSL reduced entropy problem

[Shachar S. <sh...@sh...>]

Background

Rsyncrypto[1] is a file encryption tool. It has a single RSA key that
encrypts symmetric AES keys per file. The files themselves are subject
to an encryption method that is based on CBC, but does a
security-performance trade off. In particular, the files are encrypted
in such a way that re-encrypting, using the same key, a file that was
slightly modified will result in slightly modified cypher text. This is
needed so that the file will retain wire efficiency when transferred
using rsync[2].

Rsyncrypto does not generate the RSA itself. Instead, the rsyncrypto
manual instructs the user to use openssl in order to generate a private
key and a X509 certificate, and rsyncrypto will use either one of those.

Vulnerability

Rsyncrypto itself is unaffected by the openssl vulnerability introduced
into Debian[3][4]. The common use scenario, however, will lead users
toward generating predictable keys. This advisory is in place to warn
users about possible exposure.

As with the original advisory, this problem will affect you even if you
are not currently running on a vulnerable machine, or even on a Debian
or derivative OS. If your keys were generated on a vulnerable machine,
then your data is at risk.

Solution

First of all, users should make sure that they are running a version of
openssl that does not exhibit the problem. See the OpenSSL advisory for
your platform for details.

Users should regenerate the RSA key and X509 certificate used, and
re-encrypt all files using the new key. User should perform a clean
re-encryption, disregarding all context files rsyncrytpo saves,
including the file name mapping file and the symmetric key files. This
will, unfortunately, result in an encryption set that will not be
transferable in a rsync friendly way.

Less Secure Solution - Security Performance Trade Off

If the user is 100% sure that no attacker has had a chance to save an
encrypted file for later attack, one can make do with regenerating a new
RSA key and re-encrypting the files using the existing state files (file
name mapping and symmetric key files). This will result in encrypted
files that have only their header different, but otherwise have the same
name and data pay load. This should result in an easy rsync transfer of
the files to the remote location.

Be warned, however, that should the assumption of no malicious access
prove wrong, the attacker could recover the symmetric key used for
encrypting the specific file. This means that the attack could read the
file before the key update (unavoidable), but also read ALL FUTURE
ENCRYPTIONS DONE WITH THE SAME KEY. In other words, if the attacker had
any access to the file in the past, they can read all future versions as
well unless the symmetric key is also replaced.

Mitigating Factors

None that may be relied on.

Rsyncrypto does not broadcast the public key used to encrypt the file.
This makes an attacker's life harder, as she has to guess the key length
as well as the actual key. Be warned, however, that small files leak the
length of the key by nature of their size. Encrypting an empty file, for
example, will always result in a same size cypher text file. Also notice
that key lengths are rarely an arbitrary number. They are usually either
1024, 1536, 2048 or 4096 bits, which means that the attacker only has
two more bits of entropy to go through.

In short, do not rely on any of the mitigating factors.

[1] - http://sourceforge.net/projects/rsyncrypto
[2] - http://samba.anu.edu.au/rsync/
[3] - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166
[4] - http://www.debian.org/security/2008/dsa-1571

Re: rsyncrypto + Debian vuln?

[Shachar S. <sh...@sh...>]

First of all, sorry everyone for not addressing this sooner. The bug 
does not affect rsyncrypto directly, as it does not generate public 
keys, but it does affect the rsyncrypto users. I'll issue a standard 
advisory with this info there again.

Robin Lee Powell wrote:
> I did my rsycrypto key creation just like the man page said to:
>
>     openssl req -nodes -newkey rsa:1536 -x509 -keyout backup.key -out backup.crt
>
> I probably had the bad openssl at the time.
>
> Do I need to regenerate?  
>   
You, most likely, need to regenerate, and what is decidedly worse, 
re-encrypt everything.
>  How can I tell?

I haven't had time to research the various solutions thoroughly yet. The 
length you chose (1536 bits) is not one of the standard lengths for 
which known bad public key lists were made, so telling will be rather 
hard. Still, try the following:

openssl x509 -in certfile -noout -text

Look for the section headed "Subject Public Key Info", in which you will 
see "RSA Public Key", in which you will see "Modulus". Copy a section of 
the string of numbers into google and run a search. This will give you 
an idea of whether anyone else has the same public key as you.

There are a few mitigating factors for rsyncrypto, but they really 
shouldn't be relied on. The most important one is that, unlike ssh, the 
encrypted key does not advertise the key length of public key. This 
should not be heavily relied on, as the key length has only several bits 
of likely entropy (1024, 1536, 2048 and 4096 will likely cover most 
cases, which means just 4 bits of entropy), and the key itself only has 
16 bits (that's the bug, after all). As such, a determined attacker can, 
fairly easily, brute force her way through it. Also on the minus side is 
the fact that the symmetric key (what is being encrypted with public 
key) has a magic number at the beginning, so it is fairly easy to know 
whether you broke the certificate or not.

Another somewhat mitigating factor is the fact that the public lists of 
weak keys are no use to an attacker, as they do not contain the private 
keys. Their only use is to know whether your key is vulnerable, which is 
nice, because it, for once, gives the good guys an edge.

Finally, you will need to make a security/performance tradeoff decision 
revolving around the question "how likely it is that someone has already 
broken my key". If you feel it unlikely, simply generate a new private 
key and re-encrypt everything using the same symmetric keys. This will 
save re-sending everything, as only the key headers will be sent. The 
down side is that had the assumption been wrong, not only could the 
attacker read every file you had so far (which is unavoidable at this 
stage), she can also read future encryptions with the symmetric keys 
stored. Only go this route if you understand the risks and am willing to 
take them.

If, on the other hand, you want to be sure, then you will need to 
re-encrypt everything from scratch. New keys, new file map, everything. 
It is best to simply encrypt to a new location altogether, so that 
nothing from the possibly compromised keys is used.

I hope this helps

Shachar

rsyncrypto + Debian vuln?

[Robin L. P. <rlp...@di...>]

I did my rsycrypto key creation just like the man page said to:

    openssl req -nodes -newkey rsa:1536 -x509 -keyout backup.key -out backup.crt

I probably had the bad openssl at the time.

Do I need to regenerate?  How can I tell?

Thanks.

-Robin

-- 
Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo
Proud Supporter of the Singularity Institute - http://singinst.org/
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/

Re: Rsyncrypto using wrong gzip ?

[Shachar S. <sh...@sh...>]

Jan Alphenaar wrote:
> Shachar,
>
> Have you ever considered to support rsyncrypto in cygwin ? With cygwin you
> can support the windows platform, without struggling with Microsoft Visual
> Studio and all its features.
>
> I tried compiling rsyncrypto in Cygwin, but without success... The configure
> ends successfully, but the make command fails.
>
> Regards,
>
> Jan
>   
The Windows performance of rsyncrypto is bad enough as it is, thank you 
very much.

I don't know why rsyncrypto won't compile on cygwin. Post the compile 
log here and I'll have a look. Either way, rsyncrypto currently has 
support for the Windows file names, and in the future will also support 
more specific file attributes, that cannot be supported through cygwin. 
This means that cygwin will not be the only Windows support rsyncrypto 
offers. I would love it if cygwin could compile it, but it won't be the 
official Windows version one way or the other.

Shachar

RE: Rsyncrypto using wrong gzip ?

[Jan A. <jan...@do...>]

Shachar,

Have you ever considered to support rsyncrypto in cygwin ? With cygwin you
can support the windows platform, without struggling with Microsoft Visual
Studio and all its features.

I tried compiling rsyncrypto in Cygwin, but without success... The configure
ends successfully, but the make command fails.

Regards,

Jan

-----Oorspronkelijk bericht-----
Van: Shachar Shemesh [mailto:sh...@sh...] 
Verzonden: zaterdag 17 mei 2008 7:37
Aan: Jan Alphenaar
CC: 'L-rsyncrypto'
Onderwerp: Re: Rsyncrypto using wrong gzip ?

Jan Alphenaar wrote:
> Oke, that is a clear answer, thanks for that.
>
> One last question on this subject. Are you going to try to build a
> statically compiled package in one of the next versions ?
Unlikely
>  Or are you leaving
> it like it is now ?
>   

The code that crashes when stderr is passed between rsyncrypto and 
argtable has to do with thread locking. Theoretically, if we switched 
both rsyncrypto and argtable to the single threaded versions we could 
make do with statically linking both of them. In practice, there are 
several problems with that:
1. I'm not sure that will actually solve the problem
2. Even if it will, the direction we are trying to go is to make 
rsyncrypto more multi threaded, not less

So it would appear that our options are either stick to the situation as 
it is, perform the argument processing without argtable, or rewrite the 
standard library. I think it's clear we'll be staying with the situation 
as it is.

Feel free to read "INSTALL.win" from the rsyncrypto sources for details 
how to install rsyncrypto without the MSI. Also, the MSI installation 
should have a "silent install" option (though don't ask me how to 
activate it, or how to pass it a different directory to be installed into).

Shachar

Re: Rsyncrypto using wrong gzip ?

[Shachar S. <sh...@sh...>]

Jan Alphenaar wrote:
> Oke, that is a clear answer, thanks for that.
>
> One last question on this subject. Are you going to try to build a
> statically compiled package in one of the next versions ?
Unlikely
>  Or are you leaving
> it like it is now ?
>   

The code that crashes when stderr is passed between rsyncrypto and 
argtable has to do with thread locking. Theoretically, if we switched 
both rsyncrypto and argtable to the single threaded versions we could 
make do with statically linking both of them. In practice, there are 
several problems with that:
1. I'm not sure that will actually solve the problem
2. Even if it will, the direction we are trying to go is to make 
rsyncrypto more multi threaded, not less

So it would appear that our options are either stick to the situation as 
it is, perform the argument processing without argtable, or rewrite the 
standard library. I think it's clear we'll be staying with the situation 
as it is.

Feel free to read "INSTALL.win" from the rsyncrypto sources for details 
how to install rsyncrypto without the MSI. Also, the MSI installation 
should have a "silent install" option (though don't ask me how to 
activate it, or how to pass it a different directory to be installed into).

Shachar

RE: Rsyncrypto using wrong gzip ?

[Jan A. <jan...@do...>]

Oke, that is a clear answer, thanks for that.

One last question on this subject. Are you going to try to build a
statically compiled package in one of the next versions ? Or are you leaving
it like it is now ?


-----Oorspronkelijk bericht-----
Van: Shachar Shemesh [mailto:sh...@sh...] 
Verzonden: vrijdag 16 mei 2008 23:01
Aan: Jan Alphenaar
CC: 'L-rsyncrypto'
Onderwerp: Re: Rsyncrypto using wrong gzip ?

Jan Alphenaar wrote:
> Maybe that is one disadvantage of using the MSI system.
>
>   
Actually, you've got it backwards.

I have started to compile rsyncrypto using Visual Studio 9 (2008). I 
figured that upgrading the compiler once a decade is a reasonable 
request. Unfortunately, this resulted in hard dependencies on the MS 
runtime environment (MSVCR9.DLL). This is a DLL which is impossible to 
install by merely copying the file. You absolutely have to go through 
MS's annoying installer in order to get it on your system and get your 
system working. The only sane way I found of doing that is to create an 
MSI for the entire rsyncrypto installation.

So the MSI does three things:
- Copy a bunch of files, DLLs and EXEs into your chosen install 
directory. You can just copy them elsewhere, if you like.
- Copy the openssl DLLs and executable into the "legacy" location - 
usually c:\windows\system32. You will need two DLLs from there if you 
want to copy them by hand.
- Install MSVCR9. I have no clue how you can install it manually, and 
neither does Google. This is a black magic DLL which is impossible to 
manipulate by hand.

I would have gladly linked it statically in order to prevent this 
problem, however it seems that I cannot pass "stderr" between rsyncrypto 
and argtable unless they are both linking dynamically with the same run 
time environment. This is the reason that the build environment now 
compiles argtable2 as part of the rsyncrypto project - to make sure they 
are compiled with compatible options.

Thanks for debugging this.

Shachar

Re: Rsyncrypto using wrong gzip ?

[Shachar S. <sh...@sh...>]

Jan Alphenaar wrote:
> Maybe that is one disadvantage of using the MSI system.
>
>   
Actually, you've got it backwards.

I have started to compile rsyncrypto using Visual Studio 9 (2008). I 
figured that upgrading the compiler once a decade is a reasonable 
request. Unfortunately, this resulted in hard dependencies on the MS 
runtime environment (MSVCR9.DLL). This is a DLL which is impossible to 
install by merely copying the file. You absolutely have to go through 
MS's annoying installer in order to get it on your system and get your 
system working. The only sane way I found of doing that is to create an 
MSI for the entire rsyncrypto installation.

So the MSI does three things:
- Copy a bunch of files, DLLs and EXEs into your chosen install 
directory. You can just copy them elsewhere, if you like.
- Copy the openssl DLLs and executable into the "legacy" location - 
usually c:\windows\system32. You will need two DLLs from there if you 
want to copy them by hand.
- Install MSVCR9. I have no clue how you can install it manually, and 
neither does Google. This is a black magic DLL which is impossible to 
manipulate by hand.

I would have gladly linked it statically in order to prevent this 
problem, however it seems that I cannot pass "stderr" between rsyncrypto 
and argtable unless they are both linking dynamically with the same run 
time environment. This is the reason that the build environment now 
compiles argtable2 as part of the rsyncrypto project - to make sure they 
are compiled with compatible options.

Thanks for debugging this.

Shachar

RE: Rsyncrypto using wrong gzip ?

[Jan A. <jan...@do...>]

Sorry, wrong conclusion at the end.

Because eventually it worked without using the MSI, I would say that
rsyncrypto relies on the registry if you install it using the MSI or just
copying the binaries.


-----Oorspronkelijk bericht-----
Van: Jan Alphenaar [mailto:jan...@do...] 
Verzonden: vrijdag 16 mei 2008 22:42
Aan: 'L-rsyncrypto'
CC: 'Shachar Shemesh'
Onderwerp: RE: Rsyncrypto using wrong gzip ?

Hi Shachar,

After some more testing I found the reason what was blocking machine B from
decrypting my files correctly.

On machine A, I installed the MSI package and did my test. This test was
successful. After this, I just copied the test directory (including
RsynCrypto binaries, certificates etc.) to machine B and did the same test.
The test result was that my testfile.pdf could not be decrypted.

When I removed the binaries from the d:\test\rsyncrypto directory and
installed the MSI on machine B in the d:\test\rsyncrypto directory
encryption/decryption worked correctly.

Now, removing the MSI and copying back the binaries in d:\test\rsyncrypto it
stopped working again. I thought I found the source of my problems.

But, after cleaning the registry with my registry cleaner I could not
reproduce the error anymore...

Kind of disappointing, since I still do not know what the error generated.
The only thing we now know is that RsynCrypto relies on the registry. Which
makes RsynCrypto as stable as Microsoft's registry, spooky..

Maybe that is one disadvantage of using the MSI system.

Regards,

Jan

-----Oorspronkelijk bericht-----
Van: rsy...@li...
[mailto:rsy...@li...] Namens Shachar
Shemesh
Verzonden: vrijdag 16 mei 2008 16:12
Aan: Jan Alphenaar
CC: 'L-rsyncrypto'
Onderwerp: Re: Rsyncrypto using wrong gzip ?

Jan Alphenaar wrote:
> Hi Shachar,
>
> I have upgraded to the latest version of rsyncrypto 1.09 and machine B is
> still refusing to decrypt the file.
>
> I did the test on machine B first and after this I copied over the
complete
> test directory to machine A (including rsyncrypto binaries, certificate
and
> key). Because rsyncrypto on machine A is working perfectly I think we can
> say that the certficate and key are correct.
>
> In the attachements you can find the output of both machines.
>
> Regards,
>
> Jan
>
>   
Thanks. Everything seems ok from there....

Try on Machine B running rsyncrypto with --gzip=d:\test\nullgzip.exe. 
This should disable compression altogether, and leave just the 
encryption. See if you can decrypt the file.

Shachar

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Rsyncrypto-devel mailing list
Rsy...@li...
https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel

RE: Rsyncrypto using wrong gzip ?

[Jan A. <jan...@do...>]

Hi Shachar,

After some more testing I found the reason what was blocking machine B from
decrypting my files correctly.

On machine A, I installed the MSI package and did my test. This test was
successful. After this, I just copied the test directory (including
RsynCrypto binaries, certificates etc.) to machine B and did the same test.
The test result was that my testfile.pdf could not be decrypted.

When I removed the binaries from the d:\test\rsyncrypto directory and
installed the MSI on machine B in the d:\test\rsyncrypto directory
encryption/decryption worked correctly.

Now, removing the MSI and copying back the binaries in d:\test\rsyncrypto it
stopped working again. I thought I found the source of my problems.

But, after cleaning the registry with my registry cleaner I could not
reproduce the error anymore...

Kind of disappointing, since I still do not know what the error generated.
The only thing we now know is that RsynCrypto relies on the registry. Which
makes RsynCrypto as stable as Microsoft's registry, spooky..

Maybe that is one disadvantage of using the MSI system.

Regards,

Jan

-----Oorspronkelijk bericht-----
Van: rsy...@li...
[mailto:rsy...@li...] Namens Shachar
Shemesh
Verzonden: vrijdag 16 mei 2008 16:12
Aan: Jan Alphenaar
CC: 'L-rsyncrypto'
Onderwerp: Re: Rsyncrypto using wrong gzip ?

Jan Alphenaar wrote:
> Hi Shachar,
>
> I have upgraded to the latest version of rsyncrypto 1.09 and machine B is
> still refusing to decrypt the file.
>
> I did the test on machine B first and after this I copied over the
complete
> test directory to machine A (including rsyncrypto binaries, certificate
and
> key). Because rsyncrypto on machine A is working perfectly I think we can
> say that the certficate and key are correct.
>
> In the attachements you can find the output of both machines.
>
> Regards,
>
> Jan
>
>   
Thanks. Everything seems ok from there....

Try on Machine B running rsyncrypto with --gzip=d:\test\nullgzip.exe. 
This should disable compression altogether, and leave just the 
encryption. See if you can decrypt the file.

Shachar

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Rsyncrypto-devel mailing list
Rsy...@li...
https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel

Re: Rsyncrypto using wrong gzip ?

[Shachar S. <sh...@sh...>]

Jan Alphenaar wrote:
> Hi Shachar,
>
> I have upgraded to the latest version of rsyncrypto 1.09 and machine B is
> still refusing to decrypt the file.
>
> I did the test on machine B first and after this I copied over the complete
> test directory to machine A (including rsyncrypto binaries, certificate and
> key). Because rsyncrypto on machine A is working perfectly I think we can
> say that the certficate and key are correct.
>
> In the attachements you can find the output of both machines.
>
> Regards,
>
> Jan
>
>   
Thanks. Everything seems ok from there....

Try on Machine B running rsyncrypto with --gzip=d:\test\nullgzip.exe. 
This should disable compression altogether, and leave just the 
encryption. See if you can decrypt the file.

Shachar

RE: Rsyncrypto using wrong gzip ?

[Jan A. <jan...@do...>]

Hi Shachar,

I have upgraded to the latest version of rsyncrypto 1.09 and machine B is
still refusing to decrypt the file.

I did the test on machine B first and after this I copied over the complete
test directory to machine A (including rsyncrypto binaries, certificate and
key). Because rsyncrypto on machine A is working perfectly I think we can
say that the certficate and key are correct.

In the attachements you can find the output of both machines.

Regards,

Jan

-----Oorspronkelijk bericht-----
Van: Shachar Shemesh [mailto:sh...@sh...] 
Verzonden: vrijdag 16 mei 2008 7:34
Aan: Jan Alphenaar
CC: 'L-rsyncrypto'
Onderwerp: Re: Rsyncrypto using wrong gzip ?

Jan Alphenaar wrote:
> Shachar,
>
> Thanks for helping me.
>
> I am using the MSI from sourceforge, the gzip is in the same directory as
> rsyncrypto.
>
> Here are the other answers:
>
> A cannot decrypt files encrypted on B.
> B can decrypt files encrypted on A.
>
> The output is still the same, even with using the --gzip option on the
> encrypt and decrypt command.
>   
Oh dear....

Ok, here are some more things to try. First of all, please upgrade to 
1.09 and check whether the problem still happens. Make sure that 
rsyncrypto is installed into the same directory on both machines.

If it does, please be sure to try and encrypt the same file, using the 
same symmetric key and public key, on both machines. If the keys from A 
work on B, try the keys from B on A.

If the problem still only happens on one machine, please run rsyncrypto 
on both machines with three -v options (i.e. - add -vvv) and paste the 
output here.

Thanks,
Shachar

Re: Rsyncrypto using wrong gzip ?

[Shachar S. <sh...@sh...>]

Jan Alphenaar wrote:
> Shachar,
>
> Thanks for helping me.
>
> I am using the MSI from sourceforge, the gzip is in the same directory as
> rsyncrypto.
>
> Here are the other answers:
>
> A cannot decrypt files encrypted on B.
> B can decrypt files encrypted on A.
>
> The output is still the same, even with using the --gzip option on the
> encrypt and decrypt command.
>   
Oh dear....

Ok, here are some more things to try. First of all, please upgrade to 
1.09 and check whether the problem still happens. Make sure that 
rsyncrypto is installed into the same directory on both machines.

If it does, please be sure to try and encrypt the same file, using the 
same symmetric key and public key, on both machines. If the keys from A 
work on B, try the keys from B on A.

If the problem still only happens on one machine, please run rsyncrypto 
on both machines with three -v options (i.e. - add -vvv) and paste the 
output here.

Thanks,
Shachar

RE: Rsyncrypto using wrong gzip ?

[Jan A. <jan...@do...>]

Shachar,

Another thing is that I do not have this situation on machine B with
rsyncrypto version 1.06.

Currently I am using rsyncrypto version 1.07.


-----Oorspronkelijk bericht-----
Van: Jan Alphenaar [mailto:jan...@do...] 
Verzonden: donderdag 15 mei 2008 23:11
Aan: 'L-rsyncrypto'
CC: 'Shachar Shemesh'
Onderwerp: RE: Rsyncrypto using wrong gzip ?

Shachar,

Thanks for helping me.

I am using the MSI from sourceforge, the gzip is in the same directory as
rsyncrypto.

Here are the other answers:

A cannot decrypt files encrypted on B.
B can decrypt files encrypted on A.

The output is still the same, even with using the --gzip option on the
encrypt and decrypt command.

===== BEGIN COMMAND AND OUTPUT ======
"D:\test\RsynCrypto\RsynCrypto.exe" --gzip="D:\test\RsynCrypto\gzip.exe"
 "D:\Test\ClearFiles\testfile.pdf" "D:\Test\EncryptedFiles\testfile.pdf"
"D:\Test\keys\testfile.pdf" "D:\Test\Certificate\Cert.crt"

"D:\test\RsynCrypto\RsynCrypto.exe" -d --gzip="D:\test\RsynCrypto\gzip.exe"
"D:\Test\EncryptedFiles\testfile.pdf" "D:\Test\ClearFiles\testfile.pdf"
"D:\Test\keys\testfile.pdf" "D:\Test\Certificate\Cert.key"
Error in encrypted stream:

gzip: stdin: unexpected end of file
===== END COMMAND AND OUTPUT ======

Regards,

Jan

-----Oorspronkelijk bericht-----
Van: rsy...@li...
[mailto:rsy...@li...] Namens Shachar
Shemesh
Verzonden: donderdag 15 mei 2008 22:42
Aan: Jan Alphenaar
CC: 'L-rsyncrypto'
Onderwerp: Re: Rsyncrypto using wrong gzip ?

Jan Alphenaar wrote:
>
> Hi Shachar,
>
>  
>
> Today I ran into different behavior for rsyncrypto on two different 
> machines (both WinXP). I have set up the following structure on both 
> machines.
>
>  
>
> D:\Test\Certificate
>
> D:\Test\ClearFiles
>
> D:\Test\EncryptedFiles
>
> D:\Test\Keys
>
> D:\Test\Rsyncrypto
>
I'm missing the gzip file. Is this compiled from source or an 
installation from the MSI on sourceforge?
>
>
>  
>
> D:\Test>"D:\test\RsynCrypto\RsynCrypto.exe" -d 
> "D:\Test\EncryptedFiles\testfile.pdf" 
> "D:\Test\ClearFiles\testfile.pdf" "D:\Test\keys\testfile.pdf" 
> "D:\Test\Certificate\Cert.key"
>
> Error in encrypted stream:
>
>  
>
> gzip: stdin: unexpected end of file
>
> ===== END COMMAND AND OUTPUT ======
>
>  
>
> The size of the original cleartext file testfile.pdf is 2014KB, the 
> encrypted version of it is 1573KB. Looks oke for me. After executing 
> the decryption command, only a part of the file is decrypted, since 
> the size of the decrypted file is 27KB (because it raises an error 
> message). Obviously something is wrong here.
>
>  
>
> My guess is that rsyncrypto is using another (nromal) gzip, which is 
> installed in a different location. Can this be the case?
>
Doesn't seem likely.
>
>  
>
> Any other feedback is welcome.
>
Lets call the machine on which everything is working "A", and the other 
machine "B".

Can A decrypt files created on B? My guess would be "no"
Can B decrypt files created on A? My guess would be "yes"

Please try the same procedure on B again, but this time using the 
"--gzip" option to direct rsyncrypto to the specific gzip that came with 
the installation. Please let me know whether this makes any difference.

Shachar

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Rsyncrypto-devel mailing list
Rsy...@li...
https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel

RE: Rsyncrypto using wrong gzip ?

[Jan A. <jan...@do...>]

Shachar,

Thanks for helping me.

I am using the MSI from sourceforge, the gzip is in the same directory as
rsyncrypto.

Here are the other answers:

A cannot decrypt files encrypted on B.
B can decrypt files encrypted on A.

The output is still the same, even with using the --gzip option on the
encrypt and decrypt command.

===== BEGIN COMMAND AND OUTPUT ======
"D:\test\RsynCrypto\RsynCrypto.exe" --gzip="D:\test\RsynCrypto\gzip.exe"
 "D:\Test\ClearFiles\testfile.pdf" "D:\Test\EncryptedFiles\testfile.pdf"
"D:\Test\keys\testfile.pdf" "D:\Test\Certificate\Cert.crt"

"D:\test\RsynCrypto\RsynCrypto.exe" -d --gzip="D:\test\RsynCrypto\gzip.exe"
"D:\Test\EncryptedFiles\testfile.pdf" "D:\Test\ClearFiles\testfile.pdf"
"D:\Test\keys\testfile.pdf" "D:\Test\Certificate\Cert.key"
Error in encrypted stream:

gzip: stdin: unexpected end of file
===== END COMMAND AND OUTPUT ======

Regards,

Jan

-----Oorspronkelijk bericht-----
Van: rsy...@li...
[mailto:rsy...@li...] Namens Shachar
Shemesh
Verzonden: donderdag 15 mei 2008 22:42
Aan: Jan Alphenaar
CC: 'L-rsyncrypto'
Onderwerp: Re: Rsyncrypto using wrong gzip ?

Jan Alphenaar wrote:
>
> Hi Shachar,
>
>  
>
> Today I ran into different behavior for rsyncrypto on two different 
> machines (both WinXP). I have set up the following structure on both 
> machines.
>
>  
>
> D:\Test\Certificate
>
> D:\Test\ClearFiles
>
> D:\Test\EncryptedFiles
>
> D:\Test\Keys
>
> D:\Test\Rsyncrypto
>
I'm missing the gzip file. Is this compiled from source or an 
installation from the MSI on sourceforge?
>
>
>  
>
> D:\Test>"D:\test\RsynCrypto\RsynCrypto.exe" -d 
> "D:\Test\EncryptedFiles\testfile.pdf" 
> "D:\Test\ClearFiles\testfile.pdf" "D:\Test\keys\testfile.pdf" 
> "D:\Test\Certificate\Cert.key"
>
> Error in encrypted stream:
>
>  
>
> gzip: stdin: unexpected end of file
>
> ===== END COMMAND AND OUTPUT ======
>
>  
>
> The size of the original cleartext file testfile.pdf is 2014KB, the 
> encrypted version of it is 1573KB. Looks oke for me. After executing 
> the decryption command, only a part of the file is decrypted, since 
> the size of the decrypted file is 27KB (because it raises an error 
> message). Obviously something is wrong here.
>
>  
>
> My guess is that rsyncrypto is using another (nromal) gzip, which is 
> installed in a different location. Can this be the case?
>
Doesn't seem likely.
>
>  
>
> Any other feedback is welcome.
>
Lets call the machine on which everything is working "A", and the other 
machine "B".

Can A decrypt files created on B? My guess would be "no"
Can B decrypt files created on A? My guess would be "yes"

Please try the same procedure on B again, but this time using the 
"--gzip" option to direct rsyncrypto to the specific gzip that came with 
the installation. Please let me know whether this makes any difference.

Shachar

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Rsyncrypto-devel mailing list
Rsy...@li...
https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel

Re: Rsyncrypto using wrong gzip ?

[Shachar S. <sh...@sh...>]

Jan Alphenaar wrote:
>
> Hi Shachar,
>
>  
>
> Today I ran into different behavior for rsyncrypto on two different 
> machines (both WinXP). I have set up the following structure on both 
> machines.
>
>  
>
> D:\Test\Certificate
>
> D:\Test\ClearFiles
>
> D:\Test\EncryptedFiles
>
> D:\Test\Keys
>
> D:\Test\Rsyncrypto
>
I'm missing the gzip file. Is this compiled from source or an 
installation from the MSI on sourceforge?
>
>
>  
>
> D:\Test>"D:\test\RsynCrypto\RsynCrypto.exe" -d 
> "D:\Test\EncryptedFiles\testfile.pdf" 
> "D:\Test\ClearFiles\testfile.pdf" "D:\Test\keys\testfile.pdf" 
> "D:\Test\Certificate\Cert.key"
>
> Error in encrypted stream:
>
>  
>
> gzip: stdin: unexpected end of file
>
> ===== END COMMAND AND OUTPUT ======
>
>  
>
> The size of the original cleartext file testfile.pdf is 2014KB, the 
> encrypted version of it is 1573KB. Looks oke for me… After executing 
> the decryption command, only a part of the file is decrypted, since 
> the size of the decrypted file is 27KB (because it raises an error 
> message). Obviously something is wrong here.
>
>  
>
> My guess is that rsyncrypto is using another (nromal) gzip, which is 
> installed in a different location. Can this be the case?
>
Doesn't seem likely.
>
>  
>
> Any other feedback is welcome.
>
Lets call the machine on which everything is working "A", and the other 
machine "B".

Can A decrypt files created on B? My guess would be "no"
Can B decrypt files created on A? My guess would be "yes"

Please try the same procedure on B again, but this time using the 
"--gzip" option to direct rsyncrypto to the specific gzip that came with 
the installation. Please let me know whether this makes any difference.

Shachar

Rsyncrypto using wrong gzip ?

[Jan A. <jan...@do...>]

Hi Shachar,

 

Today I ran into different behavior for rsyncrypto on two different machines
(both WinXP). I have set up the following structure on both machines.

 

D:\Test\Certificate

D:\Test\ClearFiles

D:\Test\EncryptedFiles

D:\Test\Keys

D:\Test\Rsyncrypto

 

On one machine everything is working correctly. I can encrypt the file and
decrypt it back, giving me the original readable content. But on the other
machine I get an error message during the decryption of the file, see output
below.

 

===== BEGIN COMMAND AND OUTPUT ======

D:\Test>"D:\test\RsynCrypto\RsynCrypto.exe"
"D:\Test\ClearFiles\testfile.pdf" "D:\Test\EncryptedFiles\testfile.pdf"
"D:\Test\keys\testfile.pdf" "D:\Test\Certificate\Cert.crt"

 

D:\Test>"D:\test\RsynCrypto\RsynCrypto.exe" -d
"D:\Test\EncryptedFiles\testfile.pdf" "D:\Test\ClearFiles\testfile.pdf"
"D:\Test\keys\testfile.pdf" "D:\Test\Certificate\Cert.key"

Error in encrypted stream:

 

gzip: stdin: unexpected end of file

===== END COMMAND AND OUTPUT ======

 

The size of the original cleartext file testfile.pdf is 2014KB, the
encrypted version of it is 1573KB. Looks oke for me. After executing the
decryption command, only a part of the file is decrypted, since the size of
the decrypted file is 27KB (because it raises an error message). Obviously
something is wrong here.

 

My guess is that rsyncrypto is using another (nromal) gzip, which is
installed in a different location. Can this be the case? If so, would it be
possible to change the code so it automatically uses the gzip.exe which
comes with rsyncrypto ?

 

Any other feedback is welcome.

 

Warm regards,

 

Jan

Version 1.09

[Shachar S. <sh...@sh...>]

Get it from the usual place.

Only one bug fix, for the file map corruption problem I talked about 
earlier. Also in this version, however, is a tool to correct the 
corrupted filemaps. It can correct any corrupt file map, but file maps 
corrupted by version 1.07 or 1.08 will be corrected with no loss of 
important information.

Read the README for more info.

Shachar

Re: File type change == fail

[Robin L. P. <rlp...@di...>]

On Sun, May 11, 2008 at 05:26:30PM +0300, Shachar Shemesh wrote:
> Robin Lee Powell wrote:
> > I've got to say, between this and the delete bug (deletes with a
> > filemap don't actually delete anything), EncFS is looking mighty
> > tasty.  I've tested, and rsync *does* work with it (in the sense
> > of saving transfer time/data).
> >   
> Just wanted to let you know that this problem is now solved in
> SVN. Let's hope that between solving this issue and solving the
> delete bug, you will stay with rsyncrypto not only because EncFS
> is not so rsync friendly :-)

Actually, at about the same time I ended up changing how I do my
backups so I don't need to use the filemap at all anymore.
rsyncrypto is working great for me now.

-Robin

-- 
Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo
Proud Supporter of the Singularity Institute - http://singinst.org/
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/

The release cycle of FOSS

[Shachar S. <sh...@sh...>]

At least my projects live up to this pretty well.

You usually get a few releases in a row, followed by a period of no 
activity at all. This is because after releases is when all the bugs 
surface.

As you may have guessed, version 1.09 is not far away. In the mean 
while, please avoid the "--delete-keys" feature, as it may corrupt (not 
irrevocably so, but still) the filemap file by replacing the deleted 
entries with empty ones.

In the mean while, as a workaround, if the file does get corrupted, the 
following command should fix it:

tr -s '\0' < corrupt_filemap > good_filemap

Shachar

RE: Version 1.08 available for download

[Jan A. <jan...@do...>]

Hi Shachar,

Thanks for delivering this new version of rsyncrypto and actively
maintaining the software.

I can confirm that the "Win32 only - mkdir error" is indeed resolved.

Thanks again.

Regards,

Jan

-----Oorspronkelijk bericht-----
Van: rsy...@li...
[mailto:rsy...@li...] Namens Shachar
Shemesh
Verzonden: zondag 11 mei 2008 17:02
Aan: L-rsyncrypto
Onderwerp: Version 1.08 available for download

Hi all,

Like I promised, version 1.08 is now officially released. This is a bug 
fix release. The bugs fixed in this version:

    * When a directory turns into a file with --name-encrypt and
      --delete, rsyncrypto would terminate with an error
    * Make sure that using a preexisting empty filemap does not crash
      rsyncrypto
    * -d with --filelist with stdin as input created erronous "need
      --no-archive-mode".
    * Win32 only - mkdir error really fixed this time.
    * --ne-nesting would cause --delete and --delete-keys to delete the
      wrong path (and thus fail)

Two known issues not handled for 1.08, and on my todo list, are:

    * Do not abort operation in case of error
    * Generate a list of files changed to simplify rsync operation.

Feedback, as always, welcome.

Shachar

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
Rsyncrypto-devel mailing list
Rsy...@li...
https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel

Re: Version 1.08 available for download

[David V. <dav...@gm...>]

Shachar,

Thank you for this release.

I'm very happy to see that the following item is on your todo list :
* Do not abort operation in case of error

David V.

On Sun, May 11, 2008 at 11:01 AM, Shachar Shemesh <sh...@sh...>
wrote:

> Hi all,
>
> Like I promised, version 1.08 is now officially released. This is a bug
> fix release. The bugs fixed in this version:
>
>    * When a directory turns into a file with --name-encrypt and
>      --delete, rsyncrypto would terminate with an error
>    * Make sure that using a preexisting empty filemap does not crash
>      rsyncrypto
>    * -d with --filelist with stdin as input created erronous "need
>      --no-archive-mode".
>    * Win32 only - mkdir error really fixed this time.
>    * --ne-nesting would cause --delete and --delete-keys to delete the
>      wrong path (and thus fail)
>
> Two known issues not handled for 1.08, and on my todo list, are:
>
>    * Do not abort operation in case of error
>    * Generate a list of files changed to simplify rsync operation.
>
> Feedback, as always, welcome.
>
> Shachar
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Rsyncrypto-devel mailing list
> Rsy...@li...
> https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
>

Version 1.08 available for download

[Shachar S. <sh...@sh...>]

Hi all,

Like I promised, version 1.08 is now officially released. This is a bug 
fix release. The bugs fixed in this version:

    * When a directory turns into a file with --name-encrypt and
      --delete, rsyncrypto would terminate with an error
    * Make sure that using a preexisting empty filemap does not crash
      rsyncrypto
    * -d with --filelist with stdin as input created erronous "need
      --no-archive-mode".
    * Win32 only - mkdir error really fixed this time.
    * --ne-nesting would cause --delete and --delete-keys to delete the
      wrong path (and thus fail)

Two known issues not handled for 1.08, and on my todo list, are:

    * Do not abort operation in case of error
    * Generate a list of files changed to simplify rsync operation.

Feedback, as always, welcome.

Shachar