[ZendTo] Quietly not encrypting in V6

[John Thurston]

I'm looking at moving from V5 to V6. During testing, we turned up 
interesting behavior.

While creating a drop-off, the authenticated customer was prompted for a 
passphrase. This was entered and accepted. Checksum was also requested.

When the upload was complete, the 'Outbox' showed the files with an "X" 
in the encrypted column. When later performing the pickup, no passphrase 
was requested.

When I later looked in the logs, I found:
> Error: Should be encrypting files but failed to read the passphrase, so not encrypting. If this drop-off came from a request, the encoded passphrase in the request got corrupted!

which I traced to line 2531 of NSSDropoff.php
which is preceded with the comment block

> // If we got the encryption passphrase from a request, but failed to
> // be able to read it, the user won't have been prompted to enter one.
> // So we have no way of finding it! So if that failed, don't encrypt
> // at all.

But this drop/pickup didn't originate with a 'request'. It was done by 
an interactive, authenticated user. The user requested encryption, 
supplied the phrase, and the application seems to have quietly failed to 
encrypt an otherwise acceptable (not too large) file.

I'm unable to reproduce this failure.

If the customer asks to encrypt an over-sized file, it is plainly 
refused. If encryption has been requested and can't be done for some 
other reason, shouldn't that be a blocking-situation?



-- 
--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska