A little background. Before we issue errata, we have to decide whether we should. That's usually pretty simple, but sometimes a bug looks exploitable when it isn't, or is exploitable when it looks benign. Clearly issuing zero errata isn't a workable solution, so we could issue errata for everything, but that leads to "patch fatigue". Instead, we pick and choose as best we are able. Sometimes that's hard.
Our primary focus is not on developing exploits. We have limited time and many other things to work on, and there is no reward for us to continue investigating exploit potential beyond a certain point. Referring now to a specific commit by jsing, see the commit for details. The bug's existence was publicly disclosed 3 years ago; I'm not about to reveal anything particularly secret. http://marc.info/?l=openbsd-cvs&m=139913610412127&w=2 The first issue is being able to trigger a memcpy with a small negative (huge unsigned) length. In general, any memory corruption can lead to code execution, but the specifics are application dependent. It's only a problem if there's privilege escalation involved. PEM encoded certs aren't used in the TLS wire protocol, for example, so network services are not affected. The second issue is that the incorrect handling of base64 padding will also decode to different bytes than a correct implementation. In general, any time two parsers process the same input and generate two different outputs that can lead to a security bypass, but again, the specifics are app dependent. We looked at these issues for a while and couldn't see a means to exploit them that would justify issuing a patch, but we can't rule out that possibility either. We neither want to cry wolf nor hide the truth. Lacking a clear consensus that we should patch or not patch, what you're getting instead is this email. (I initially proposed a patch and an email saying the patch was unnecessary, but it seems less confusing to simply send the email.) This email doesn't offer a lot of guidance about what to do, for which I apologize. At least now you know what we know.
