Zum Inhalt springen

Empfohlene Beiträge

Geschrieben

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

Geschrieben

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

Geschrieben
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

Geschrieben

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.

Geschrieben

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

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

Geschrieben
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

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...