[ZendTo] manually retrieve an encrypted file?

Tue Oct 23 15:02:07 BST 2018

Michael,

I've written a command-line utility "extractdropoff" which just takes a 
ClaimID on the command-line.
If the drop-off is encrypted, it will prompt you to enter the passphrase 
(which it won't echo).
It then saves the files in the current directory.
Nice and simple. :-)

It will be in the next release.

Cheers,
Jules.

On 19/10/2018 18:00, MICHAEL R MASSE via ZendTo wrote:
>
> 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
>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://jul.es/mailman/listinfo/zendto

Jules

-- 
Julian Field MEng CEng CITP MBCS MIEEE MACM

'I have lost friends, some by death ... others through sheer inability
  to cross the street.' - Virginia Woolf

www.Zend.To
Twitter: @JulesFM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20181023/d9b6d315/attachment.html>