[ZendTo] Quietly not encrypting in V6

Jules Jules at Zend.To
Tue Jun 9 11:03:37 BST 2020


John,

I have just released 6.01-2 in which this occurrence now causes ZendTo 
to reject the upload attempt, with an error to the user and an error 
written to the log.

I have just upgraded my own (University of Southampton "SafeSend") 
service to the new version and all appears to be working fine.

Hopefully we can consider this one "closed".

Cheers,
Jules.

On 08/06/2020 18:31, John Thurston via ZendTo wrote:
> Jules, we've been beating on this. We are unable to reproduce the 
> failure, regardless of how we twist or hold our tongues. It is in the 
> log, so it happened once. We just can't make it happen again.
>
> If it never occurs again, that's fine.
> If it does occur and blocks, that's fine too.
>
>
> re: your earlier questions (GMT -9 here)
>
> + We're using sqlite3
>
> + /opt/zendto/sbin/cleanup.php produced nothing of interest.
>
> + 'dropoff' table schema contains "lifeseconds"
>    and "senderIP" is varchar(256)
>
> + I did generate a new cookieSecret, but that was done in the days 
> prior to performing the test which failed. I don't think it's related, 
> but if we need an explanation on which to hang our hat, that might be 
> the only thing we have.
>
> -- 
> 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
>
> On 6/6/2020 5:03 AM, Jules wrote:
>> Can anyone reproduce this?
>>
>> The only way you can reach the bit of code that generates the log 
>> message is if there is a form input called "req" which is used to 
>> hold the 9-digit number (or string of 3 words) that make up the 
>> request code. And "req" must have a non-empty value.
>>
>> Unless you're responding to a request, this form input is always empty.
>>
>> John — One final question: During the upgrade, did it tell you to 
>> generate a better cookieSecret? And did you do so? Changing the 
>> cookieSecret while it is in use can also break things for users who 
>> happen to be logged in and interacting with the website at the time 
>> you change cookieSecret.
>>
>> 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
>>
>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://jul.es/mailman/listinfo/zendto

Jules

-- 
Julian Field MEng CEng CITP MBCS MIEEE MACM

The current UK shipping forecast:
German Bight: Northwest 2 to 4 becoming variable 3 or less. Slight or moderate
becoming slight. Showers. Good.

www.Zend.To
Twitter: @JulesFM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jul.es/pipermail/zendto/attachments/20200609/07c06ee3/attachment-0001.html>


More information about the ZendTo mailing list