[ZendTo] Quietly not encrypting in V6

[Jules]

John,

Start by checking that the upgrade has installed all the new 
/opt/zendto/templates files.
That's often the source of weird problems.

What exact database back-end are you using?

As root, run
/opt/zendto/sbin/cleanup.php /opt/zendto/config/preferences.php 
--no-warnings
and check it doesn't produce any errors.

Also, there should have been some quiet database schema upgrades in the 
background.
Check that the schema of the "dropoff" table ('SHOW CREATE TABLE 
dropoff') contains a "lifeseconds" column.

I've just tried creating an encrypted drop-off and I can't reproduce the 
fault. I made a little drop-off and encrypted it. It correctly demanded 
the right passphrase before I could download anything from it.

But I will have a good dig through the code to see how this could 
possibly be happening.

Cheers,
Jules.

On 05/06/2020 19:53, John Thurston via ZendTo wrote:
> 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?
>
>
>

Jules

-- 
Julian Field MEng CEng CITP MBCS MIEEE MACM

'It's very unlikely indeed he will ever recover consciousness, and
  if he does he won't be the Julian you knew.'
   - A hospital consultant I proved very wrong in 2007 :-)

www.Zend.To
Twitter: @JulesFM

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