Ok, das hier ist ein echt kniffliges Problem, ich hoffe, jemand kann mir helfen.

Ich versuche mit Perl eine Datei auf einen FTP-Server hochzuladen. Das wäre ja soweit kein Problem. Ich möchte die Datei jedoch "on-the-fly" komprimieren und verschlüsseln und hier fangen meine Probleme an.

Um das Ganze möglichst trivial zu halten benutze ich für Kompression und Verschlüsselung Standardwerkzeuge (gzip+openssl). Der Code sieht dabei im Moment wie folgt aus.

$stor_fh = $ftp->stor('TESTFILE');


open(DATA, "cat $ARGV[0] | gzip -fc | openssl enc -aes-128-cbc -salt -pass pass:supersecret |");

while (read(DATA,$buffer,1024)) {

  $read += length($buffer);

  print $stor_fh $buffer;

}

print "Read $read bytes\n";

close(DATA);

$stor_fh->flush;

$stor_fh->close;


print "Wrote ".$ftp->size('TESTFILE')." bytes\n";

Rufe ich das Script nun mit meiner Testdatei auf erhalte ich folgende Ausgabe:

Read 12720 bytes

Wrote 12660 bytes

Mir gehen also Bytes verloren Ich vermute stark, das es sich hierbei um das Padding von OpenSSL handelt, was die Daten mit NULL bytes auffüllt und Perl diese irgendwie unter den Tisch fallen lässt. Das Ergebnis ist auf jeden Fall, das ich die Datei nicht wieder sauber entschlüsselt und entpackt kriege ...

Ich habe zwar lange kein Perl mehr gemacht, aber nur so eine Vermutung:

Stimmt das length($buffer). Wenn ich von C/C++ ausgehe, dann wird ein String immer mit \0 abgeschlossen, d.h. es wäre die Frage ob length die Größe des Buffers oder die Länge der Zeichenfolge bis zum \0 liefert oder wie Du es vermutest, die real gelesene Anzahl an Zeichen inkl \0.

Ist denn die Datei überhaupt verarbeitbar?

Phil

Um das Ganze mo:glichst trivial zu halten benutze ich fu:r Kompression und Verschlu:sselung Standardwerkzeuge (gzip+openssl).

Erster Gedanke: Vielleicht brauchst du einen passiven FTP-Modus.

Zweiter Gedanke: Kein Wunder, dass Daten verloren gehen, wenn du durch mehrere Pipes auf ein synchrones Filehandle schreibst.

Mein Vorschlag:

Erst Verschluesseln, dann komprimieren, MD5-Pruefsumme erstellen, hochladen, Upload verifizieren. Gegebenenfalls PASSV verwenden, falls du hinter Router/Firewall/etc... sein solltest.

mfg

Unix

Also ich habe jetzt nochmal etwas experimentiert.

Wenn ich OpenSSL den Parameter -a (für Base64-Kodierung) mitgebe kommt auf dem FTP genau das an, was lokal erzeugt wurde und es kann auch wieder ordentlich entschlüsselt und entpackt werden.

Der FTP-Server ist nicht das Problem, der steht im selben LAN

Es muß also irgendwas mit den Binary-Daten zu tun haben. Meine Vermutung, das am Ende NULL-Bytes sind ist übrigens falsch. Diese werden zwar zum Padding verwendet, dann aber logischerweise mit verschlüsselt.

Mein Vorschlag:

Erst Verschluesseln, dann komprimieren, MD5-Pruefsumme erstellen, hochladen, Upload verifizieren. Gegebenenfalls PASSV verwenden, falls du hinter Router/Firewall/etc... sein solltest.

Wenn man erst verschlüsselt und dann komprimiert ist die Kompressionsrate nahe 0...

Wenn man erst verschlu:sselt und dann komprimiert ist die Kompressionsrate nahe 0...

Hab grade das Script fuer das Backup meiner Konfigurationsdateien angeschaut. Mit tar und bzip2 werden die Komprimiert und anschliessend per gpg --armor verschluesselt. Kann sein, dass du Recht hast. Hab ich noch nie getestet.

Dennoch macht es einen Unterschied ob du alles durch Pipes jagst oder stor() eine fertige Datei gibst. Zumindest laut dem Sourcecode von Net::FTP 2.75.

Zum Thema "-a": Vielleicht solltest du ohne "-a" vorher die binary() Methode von Net::FTP aufrufen, da ASCII default ist.

Hab grade das Script fuer das Backup meiner Konfigurationsdateien angeschaut. Mit tar und bzip2 werden die Komprimiert und anschliessend per gpg --armor verschluesselt. Kann sein, dass du Recht hast. Hab ich noch nie getestet.

Brauchst du auch nicht zu testen. Ein guter Cipher liefert als Output etwas, das von /dev/random (im Optimalfall) nicht zu unterscheiden ist und das lässt sich logischerweise sehr schlecht komprimieren.

Dennoch macht es einen Unterschied ob du alles durch Pipes jagst oder stor() eine fertige Datei gibst. Zumindest laut dem Sourcecode von Net::FTP 2.75.

Der würde mich wirklich interessieren !

Zum Thema "-a": Vielleicht solltest du ohne "-a" vorher die binary() Methode von Net::FTP aufrufen, da ASCII default ist.

Ja, so einfach ist es manchmal. Ich hatte einfach vergessen $ftp->binary zu setzen :upps