[ZendTo] manually retrieve an encrypted file?

[MICHAEL R MASSE]

When I run the file command on the file that is sitting in the drop-offs folder with the claim ID in question, it says:
raw G3 data, byte-padded

When looking at the zendto.log file at the time the file was uploaded, it looks normal with no hint of anything wrong.   Here’s what it says with the email addresses obfiscated:

2018-10-10 21:13:19 108.85.190.41 [ZendTo]: Info: successfully delivered notification email to RECIPIENT at EMAIL.ADDRESS for claimID q3j8nGdByjV8MwSq
2018-10-10 21:13:19 108.85.190.41 [ZendTo]: Info: new encrypted dropoff q3j8nGdByjV8MwSq of 1 file created for external user SENDER SENDER at EMAIL.ADDRESS<mailto:SENDER at EMAIL.ADDRESS>

A command line utility would be fantastic!

-MIke

From: ZendTo <zendto-bounces at zend.to> On Behalf Of Jules Field via ZendTo
Sent: Thursday, October 18, 2018 9:32 AM
To: MICHAEL R MASSE via ZendTo <zendto at zend.to>
Cc: Jules Field <Jules at Zend.To>
Subject: Re: [ZendTo] manually retrieve an encrypted file?

Mike,

I have seen 1 other instance of this. It appears to be caused by the encryption process failing. Take a look in the Apache logs and let me know what error message you see in the error_log. I need to improve the checking of values read from the header I add to the encrypted file, to ensure that things like the hashing and encryption algorithm names are valid before I try to use them.

I haven't managed to reproduce this problem myself, but I'm pretty sure this is what is happening. By the time I come to decrypt the data, if it's damaged by that point then I can't retrieve it, but I can flag the error a lot better than currently!

One thing to try: given the ClaimID look in the /var/zendto/dropoffs directory for the files that belong to that ClaimID. The filenames will be random, and each file should be a bit longer than the original version uploaded. See if you can work out which one is the problem file. Is that file actually encrypted *at all*? The "file" command will help you here. Do a "file *" in the relevant dropoff directory, and it *should* say something like they are all just "data". If it identifies one as a Word document, zip file, PDF file anything like that, then the file didn't get encrypted for some reason.

If that is the case, please can you look back through your zendto.log file (either in /var/zendto or /var/log/zendto) to see if anything odd happened when the drop-off was originally uploaded.

Please can you let me know what you find?

Also, I am going to write you a command-line utility so retrieve the files from a drop-off given the claim ID and the passphrase. It will probably just write all the files with their original names into the current directory. Even for unencrypted drop-offs, it would still be a useful tool. I'll make it prompt for the passphrase if one is needed (i.e. if the drop-off is encrypted).

Cheers,
Jules.
On 12/10/2018 15:28, MICHAEL R MASSE via ZendTo wrote:
Is there a way as the administrator of the system hosting my Zendto service that I can decrypt a file that’s been uploaded if I have the passphrase?  I have direct access to the sqlite database to get the key as well, but I’m not sure what to do with either.

I’m running 5.15-1 and the system works fine except one single user is trying to receive a file from someone outside of the system and when they try to download this specific file after typing in the passphrase they just get a http 500 error.    The sender does not receive any errors when uploading.   It actually doesn’t matter if the recipient types a correct passphrase or not, they always get an http 500 error on this particular file.    As an administrator if I try to download the file and regardless of the passphrase I enter (correct or not) I get an http 500 error as well.  This does not happen for anyone else for any other files in the system sent before or after.    Also, for every other file on the system, if an incorrect passphrase is used, the system says it’s incorrect like it should instead of giving an http 500 error.   I told the person to have their sender send the file again, and it again throws an http 500 error.    It’s only a 2mb file so there’s nothing weird about it.    After telling them to upload the file twice and having it fail I’d like to just decrypt the file that’s there and manually give it to the recipient since he’s local, and then worry about troubleshooting the problem later.


-Mike




_______________________________________________

ZendTo mailing list

ZendTo at zend.to<mailto:ZendTo at zend.to>

http://jul.es/mailman/listinfo/zendto



Jules



--

Julian Field MEng CEng CITP MBCS MIEEE MACM



'What happened in the past that was painful, has a great deal to

 do with what we are today.' - William Glasser



www.Zend.To<http://www.Zend.To>

Twitter: @JulesFM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20181019/756411b5/attachment.html>