# The pandemic of incomplete OpenSSL error handling

A short, pointed post by Julian Andres Klode (APT maintainer) arguing that a widely-copied OpenSSL "best practice" is a systemic, dangerous anti-pattern: sprinkling `ERR_clear_error()` around TLS operations to make inconvenient errors disappear.

## The trigger

Someone reported that TLS in APT was failing on FIPS systems with MD5 errors and suggested wrapping TLS operations in `ERR_clear_error()`. Klode refused, on the principle that one component failing to handle its errors doesn't license discarding *all* errors somewhere else — the program should have failed earlier, or discarded the specific error only once it was determined safe. He then discovered this workaround has been treated as a best practice for years: codebases everywhere call `ERR_clear_error()` before TLS operations, and OpenSSL upstream itself suggests doing so.

## The core mistake: OpenSSL has an error *stack*

The root problem is that many authors don't realize OpenSSL maintains a *stack* of errors, not a single error slot. Two anti-patterns follow:

1. **Blanket clearing.** Call `ERR_clear_error()` before a TLS operation to wipe whatever is on the stack. This silently discards *unrelated* errors that were left there by earlier code — errors that may signal a real problem. The error that caused the entry should be fixed (or handled where it occurred), not swept away later because it's now inconvenient.
2. **Check-the-top-then-discard.** Call an OpenSSL operation, inspect the top-level error, and if it's deemed "not too bad," discard the whole stack. Same defect: unrelated errors below the top get silently thrown away.

Both patterns convert "an error happened somewhere" into "no error," which is exactly the failure that breaks trust in security-sensitive code. This is the [[error-stack-anti-pattern]] — discarding an entire error channel to suppress one entry.

## The fix

Use OpenSSL's mark mechanism to scope your own error context instead of clearing globally: `ERR_set_mark()` to push a mark, then `ERR_pop_to_mark()` to pop back to it — a guard around a group of OpenSSL operations that removes only the errors *you* generated, leaving anything from other code intact. Klode's call to action: audit your codebase for every `ERR_clear_error()` call and determine whether it's safe or one of the bad patterns above; and to OpenSSL's authors, stop encouraging practices that "fundamentally break any trust in software."

## Why it matters beyond OpenSSL

The general lesson is about error-handling hygiene at library boundaries: when a library exposes a shared, stateful error channel, "clear it so my happy path works" is nearly always wrong, because you're discarding information that belongs to other code. Relatedly, it's the kind of subtle, easy-to-get-wrong C error handling that [[reviewing-ai-code]] and [[testing-heavy-no-review-workflow]] both flag as hard to catch by review alone — the anti-pattern spread precisely because it looks locally correct and passes review. Compare the broader supply-chain-and-correctness concerns in [[supply-chain-security]].