Page MenuHomeFreeBSD

cryptocheck: Don't treat OpenSSL errors as fatal
ClosedPublic

Authored by jhb on May 20 2024, 11:45 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Dec 19, 5:58 PM
Unknown Object (File)
Mon, Dec 9, 2:15 AM
Unknown Object (File)
Sat, Nov 30, 7:26 PM
Unknown Object (File)
Nov 16 2024, 3:26 AM
Unknown Object (File)
Nov 16 2024, 2:53 AM
Unknown Object (File)
Nov 16 2024, 12:55 AM
Unknown Object (File)
Nov 1 2024, 2:22 AM
Unknown Object (File)
Nov 1 2024, 2:22 AM
Subscribers

Details

Summary

Abort the current test but keep running additional tests if OpenSSL
reports an error during a test. This matches the behavior for other
tests such as an error from OCF.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jhb requested review of this revision.May 20 2024, 11:45 PM

Why would openssl return an error?

These errors don't get propagated up so cryptocheck may still exit with status 0 after an error. Is that reasonable?

Why would openssl return an error?

When OpenSSL 3.0 removes support for IV sizes for chacha20 for example. :(

These errors don't get propagated up so cryptocheck may still exit with status 0 after an error. Is that reasonable?

That is true of non-OpenSSL errors today, so is at least consistent. If we wanted to propagate errors we could perhaps add a global boolean that determines the return value from main. Some errors we might want to ignore though which is the hard part. OCF doesn't implement AES-XTS with small payload sizes for example, and I think two of the small tests (single byte payload) when doing -a all -z have identical cipher and plain text because the first byte of the keystream is 0x00. I generally redirect stdout/stderr to a file and use diff or a side-by-side tool like kompare.

This revision is now accepted and ready to land.Jun 5 2024, 5:03 PM
This revision was automatically updated to reflect the committed changes.