[ZendTo] manually retrieve an encrypted file?
Jules at Zend.To
Tue Oct 23 15:02:07 BST 2018
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.
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 126.96.36.199 [ZendTo]: Info: successfully
> delivered notification email to RECIPIENT at EMAIL.ADDRESS for claimID
> 2018-10-10 21:13:19 188.8.131.52 [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!
> *From:*ZendTo <zendto-bounces at zend.to> *On Behalf Of *Jules Field via
> *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?
> 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).
> 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.
> ZendTo mailing list
> ZendTo at zend.to <mailto:ZendTo at zend.to>
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ZendTo