better error checking of key file in php

[dmorton]

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

[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.

[anonymous]

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

script and the configtest.pl script. The configtest.pl 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 configtest.pl tests proposed above were run after such an update, it would identify any new problems, I suspect.