[ZendTo] Quietly not encrypting in V6

[Jules]

John,

If you are using MyySQL as the back-end, the output from "SHOW CREATE 
TABLE dropoff" should be this:

   `rowID` int(11) NOT NULL AUTO_INCREMENT,
   `claimID` varchar(16) NOT NULL,
   `claimPasscode` varchar(16) DEFAULT NULL,
   `authorizedUser` varchar(255) NOT NULL,
   `senderName` varchar(32) NOT NULL,
   `senderOrganization` varchar(32) NOT NULL,
   `senderEmail` varchar(255) NOT NULL,
   `confirmDelivery` tinyint(1) NOT NULL DEFAULT '0',
   `senderIP` varchar(256) NOT NULL,
   `created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE 
CURRENT_TIMESTAMP,
   `note` text NOT NULL,
   `lifeseconds` int(11) NOT NULL DEFAULT '0',
   PRIMARY KEY (`rowID`),
   KEY `claimID` (`claimID`)

The length of the "senderIP" field should be at least 256. If that field 
is shorter, that could (don't ask!) explain it.

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

'Once is happenstance, twice is coincidence, three times is enemy
  action.' - Ian Fleming

www.Zend.To
Twitter: @JulesFM

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