Opened 14 years ago

Closed 12 years ago

#429 closed defect (invalid)

better error checking of key file in php

Reported by: dmorton Owned by: dmorton
Priority: normal Milestone: 1.0.3
Component: PHP scripts Version: 1.0.2
Severity: normal Keywords:


Like #196, the php side should have a fatal error when attempts to read a

key fails... especially when performing a rescue operation, as this could cause loss of data

Change History (3)

comment:1 Changed 14 years ago by anonymous

It would be nice if the perl side could insert the encrypted result of

some known plaintext and have the php side check it, to make sure they're both talking the same. Maybe have one of the periodic cronjobs could insert a special message (eg. instead of 'S' for spam, use another flag that it's a test message?) and the php makes sure it gets the known plaintext out of decrypting that.

comment:2 Changed 14 years ago by anonymous

Not a bad idea, though I'd probably just test it within the configtest.php

script and the script. The script could do a test encryption and decryption of a standard test phase (e.g. "THIS IS A TEST") to verify that the decrypted output is the same as the plaintext input, and the configtest.php script could do the same. This would test both the Perl and PHP encryption engines, and implicitly verify that the key files are accessible. This would likely identify 98% of the encryption-related problems people encounter.

What it would not do is test the interoperability of the two encryption engines, or verify that the same key files are being used at each end. Doing that sort of end-to-end encryption testing is trickier, especially when the two ends could be located on different hosts. For this kind of test, the simplest solution is just to try sending an email through the system and verifying the received result and that the quarantined/cached intermediate version is readable in the GUI.

I'm not so convinced of the value of a periodic, cron-scheduled test, however. Generally, once you get encryption set up properly it doesn't need to be re-tested unless for some reason the tool chain gets broken during an update. If the configtest.php and tests proposed above were run after such an update, it would identify any new problems, I suspect.

comment:3 Changed 12 years ago by mortonda@…

  • Resolution set to invalid
  • Status changed from new to closed

Looks like a die() statement in there already...

Note: See TracTickets for help on using tickets.