alt.hn

2/13/2026 at 10:18:56 AM

WolfSSL sucks too, so now what?

https://blog.feld.me/posts/2026/02/wolfssl-sucks-too/

by thomasjb

2/13/2026 at 11:03:37 AM

This is the WolfSSL maintainer's response[1]

> This ticket is rather long and has a lot of irrelevant content regarding this new topic. If I need to bring in a colleague I do not want them to have to wade through all the irrelevant context. If you would like, please open a new issue with regards to how we support middlebox compatibility.

The author turns this into:

> The GitHub issue comment left at the end leads me to believe that they aren't really interested in RFC compliance. There isn't a middleground here or a "different way" of implementing middlebox compatibility. It's either RFC compliant or not. And they're not.

This is a bad-faith interpretation of the maintainer's response. They only asked to open a new, more specific issue report. The maintainer always answered within minutes, which I find quite impressive (even after the author ghosted for months). The author consumed the maintainer's time and shouldn't get the blame for the author's problems.

[1]: https://github.com/wolfSSL/wolfssl/issues/9156

by meinersbur

2/13/2026 at 11:14:20 AM

I don't know, I don't think it's really a huge waste of time considering I just read the entire comment thread in a handful of minutes. And beyond that, failing to comply with RFC requirements is the bug here -- a workaround existing for a specific language isn't a fix.

by reanimus

2/14/2026 at 1:19:44 AM

It's pretty standard to open a new issue and reference the previous issue for context, while keeping the new issue specific about what needs to be addressed - ie. RFC compliance.

I don't see the problem here at all - it was a reasonable request and it would have taken `feld` all of 2 minutes to do. Certainly less time than writing that blog post.

by Alupis

2/13/2026 at 11:17:53 AM

Again: the maintainer does not say there is no bug. He says: please open a new issue, with a proper title and description for the actual underlying problem. Is that seriously too much to ask? Instead, the guy writes a whole blog post shitting on the project. Does anyone still wonder why people burn out on maintaining FOSS projects?

by deng

2/13/2026 at 11:44:48 AM

Not great behavior I agree, but what else is there to say other than "it does not match the spec at point 1.2.3"?

by halapro

2/13/2026 at 11:55:44 AM

Then opening the ticket should be easy enough?

I certainly understand the maintainer here, because that’s what I keep telling colleagues at work.

Tickets get really cumbersome if they are not clear and actionable.

by Semaphor

2/13/2026 at 11:04:28 PM

...that's what they are asking, yes.

by PunchyHamster

2/13/2026 at 12:23:44 PM

A reasonable reply indeed from the maintainer, this happens a lot where you think together in an issue and identify whats really wrong near the end. Only then is one able to articulate an issue in a helpful, concise way. Perhaps GH could add a feature to facilitate this pattern.

by teekert

2/13/2026 at 11:49:39 AM

The maintainer should just open a new issue for RFC compliance himself since that's a pretty big issue and he obviously thinks OP spams too much.

This game of stalling / obfuscating via the issue tracker gets very old.

by hypeatei

2/13/2026 at 11:43:12 PM

I can see both ways here.

If the maintainer just opens the concise bug report they want (RFC .... Section ... If TLS1.3 is negotiated and client sends session id, server must send cipherchangespec), they have what they want and can move on with their life.

However, if the maintainer can get the reporter to do it, the reporter has become a better reporter and the world has become a better place.

IMHO, the original bug report was pretty out there. Asking a library developer to debug a client they don't use with a sever they didn't write either is pretty demanding. I know openssl has a minimal server, I expect woflssl does too? that would be easier to debug.

Actually, on re-reading the original report, the reporter links to a discussion where they have all the RFC references. Had the reporter summarized that to begin with, rather than suggesting a whole lot of other stuff (like a different wolfssl issue that has to be completely unrelated), I think the issue would have gone better.

I will further add that putting a MUST in an appendix seems kind of poor editing. It should have been noted in section 4.1.2 and/or 4.1.3 that a non-empty legacy_session_id indicates that the server MUST send a cipher change spec. It's not totally obvious, but if the client requests middlebox compatability, the RFC says the server MUST do it. If the client doesn't request it by sending a legacy session id, the server can still send a superfluous change cipher spec message if it wants, although I don't know if it will help without the session id.

by toast0

2/13/2026 at 11:58:06 AM

> The maintainer should just

Out of interest: which FOSS projects are you maintaining, and how many users do these have, approximately?

by deng

2/13/2026 at 12:16:53 PM

Out of interest, how is that relevant? Are we not able to criticize a FOSS maintainers response unless we run a project of scale ourselves? The maintainer is clearly engaging and knows what the problem is but stalls on the "last mile" which is issue creation. Do you agree?

wolfSSL also sells commercial licenses so it's not like they're going uncompensated for their work. Regardless, we shouldn't put people on pedestals because their title is "FOSS maintainer"

by hypeatei

2/14/2026 at 1:25:45 AM

You are not entitled to anything apart from forking and fixing it yourself.

by phoronixrly

2/13/2026 at 12:26:29 PM

[flagged]

by deng

2/13/2026 at 12:42:02 PM

> you probably wouldn't feel so entitled.

...what? Are we living in the same universe? What exactly did I say that makes me entitled?

> The user in question does not have a commercial license

Do you know that for sure or are you speculating?

> We shouldn't shit on other people's work we got for free

When did I shit on the work of wolfSSL? I'm saying that it appears they were engaging but got hung up on a small issue.

> It's you who needs to get down from that pedestal.

Respectfully, you need to get a grip.

by hypeatei

2/13/2026 at 11:32:35 PM

Why should that be the maintainer's burden?

by otterley

2/13/2026 at 4:02:18 PM

Worse yet, despite publishing seventeen blog posts between filing the issue and finally responding to it, he has the gall to open with "Sorry I missed your replies (life gets busy)".

by SubjectToChange

2/13/2026 at 11:51:58 AM

This issue has a similar conversational rhythm that led to the AI agent hit piece that was trending yesterday:

https://theshamblog.com/an-ai-agent-published-a-hit-piece-on...

The OPs blog post also reeks of a similar style to the hit piece.

Given the large delay between the initial report and further responses by the user `feld`, I wonder if an OpenClaw agent was given free reign to try to clear up outstanding issues in some project, including handling the communication with the project maintainers?

Maybe I am getting too paranoid..

by Phemist

2/14/2026 at 1:25:47 AM

> Hell is definitely a place where middleboxes were invented and no amount of wishcasting will remove them from existence.

Counter point: They continue to exist because we (as engineers who touch these systems) allow them to. No one replaces broken tech, and it's insane to expect them to. If you want poorly behaving middleboxes to go away...

LET. THEM. BREAK.

But no one is willing to do that because... security probably? That's why everyone claims they have to when making a bad decision these days.

I'm sure you're about to reply

> We have to keep supporting middleboxes, because...

Yeah, I know... please re-read my intro statement. When competent engineers can't solve a problem within the constraints, (this material starts to melt at those temperatures). They instead, fix the constraints. (We didn't want to deal with melted components, so we added more heat shielding, you'll need a bigger hanger now... it's already being built)

Where as software engineers accept that it's fine for TLS1.3 to be a bit melted... *sigh*

(yes yes, the SR-71 is a perfect example of good engineering around heat problems... but there's a difference between making one aircraft that leaks fuel until it gets up to speed, and creating a specification that means all aircraft leak fuel now, at all speeds.)

by grayhatter

2/13/2026 at 3:26:14 PM

The blog author seems like a real piece of work. He ghosts the WolfSSL maintainer for over 160 days and when asked to open a new, more specific issue, he instead chooses to write a blog post denigrating the project. The WolfSSL maintainer was nothing but courteous and helpful throughout the entire exchange.

>...they aren't really interested in RFC compliance.

Yeah, well "feld" can't claim to be "interested in RFC compliance" either when he ghosts the issue for months and chooses to write blog posts instead of opening a new issue. Good grief.

If this is what the FreeBSD community is like, I want nothing to do with them.

by SubjectToChange

2/13/2026 at 5:00:54 PM

I don't think it's fair to judge the whole FreeBSD community by one person.

by yjftsjthsd-h

2/14/2026 at 12:05:17 AM

Seriously, where the hell did that come from?

by andrewflnr

2/13/2026 at 10:57:39 AM

BearSSL by Thomas Pornin is always worth checking in on, not sure what the current status is but looks like it received a commit last year.

[1] https://bearssl.org

by mythz

2/13/2026 at 11:12:13 AM

BearSSL is really cool, but it claims beta quality with the latest release in 2018, doesn't support TLS 1.3, and hasn't seen meaningful development in years. It's averaging about 1 commit per year recently, and they're not big ones.

by jorams

2/14/2026 at 12:34:56 AM

Where is Bellard when we need him?

by embedding-shape

2/14/2026 at 12:40:34 AM

Most relevantly here, selling a commercial implementation of ASN.1: https://bellard.org/ffasn1/.

by mananaysiempre

2/13/2026 at 10:41:59 AM

We need something with TLS in the name for the next one so people stop getting confused.

by ospray

2/13/2026 at 11:15:43 AM

rustls is there. It has TLS in the name, it is good and there is a C FFI wrapper.

by weinzierl

2/13/2026 at 11:43:53 AM

A c wrapper to rust feels like we've gone full circle

by dwedge

2/13/2026 at 3:00:19 PM

That would be amazing and really cement the proven value of Rust.

by pocksuppet

2/13/2026 at 11:34:28 AM

Rustls still outsources cryptographic primitives. I believe the currently supported providers of those are… drumroll… AWS-LC and Ring. The latter is a fork of BoringSSL. The article describes AWS-LC and BoringSSL as "Googled and Amazoned to death; they don't care about anyone but their own use cases".

The state of things sucks :-(

by gspr

2/13/2026 at 11:05:21 PM

The author also doesn't specify what that even means and what problems it causes

by PunchyHamster

2/13/2026 at 11:41:08 AM

there is https://github.com/RustCrypto/rustls-rustcrypto fwiw

by koakuma-chan

2/13/2026 at 6:41:22 PM

It's a great effort, but it's far from usable:

> USE THIS AT YOUR OWN RISK! DO NOT USE THIS IN PRODUCTION

by gspr

2/13/2026 at 11:38:52 AM

rustls doesn't have its own implementation of cryptography, you have to choose a provider like openssl or aws lc

by koakuma-chan

2/13/2026 at 4:23:39 PM

Or rustcrypto. Rustls is a TLS layer that can wrap any cryptography layer providing the necessary primitives.

by SAI_Peregrinus

2/13/2026 at 2:39:15 PM

But then how will we spot the pedants.

by account42

2/13/2026 at 11:29:56 AM

You're obviously looking for lastLs.

by zephen

2/13/2026 at 11:53:18 PM

Go can create C ABI shared libraries, I think OpenSSL-compatible C bindings to Go's crypto/tls would be a really interesting option.

by mappu

2/14/2026 at 1:16:38 AM

> Last updated on 2026-12-13

Yeah, no, I can't find a way to read this in which it's not in the future.

by tialaramex

2/13/2026 at 11:34:12 AM

Usability-wise (I do not need many features or compliance for FIPS) I have been happy with Botan: https://botan.randombit.net/

by germandiago

2/13/2026 at 1:21:47 PM

Can confirm, used Botan in the past and I didn't curse at it a lot. Certainly less than OpenSSL.

by wink

2/13/2026 at 11:28:29 AM

Many people and projects have tried to ditch OpenSSL in favor of LibreSSL, WolfSSL, MbedTLS, etc, but by now many have returned to OpenSSL. The IQ curve meme with "just use OpenSSL" applies.

by stabbles

2/13/2026 at 3:41:37 PM

I don't see how OpenSSL can recover from it's 3.0 disaster. They would basically have to write off the past few years of development work and start over from version 1.1.1

by SubjectToChange

2/13/2026 at 10:58:12 AM

There’s always rustls.

by eptcyka

2/13/2026 at 11:35:49 AM

Rustls still outsources cryptographic primitives. I believe the currently supported providers of those are… drumroll… AWS-LC and Ring. The latter is a fork of BoringSSL. The article describes AWS-LC and BoringSSL as "Googled and Amazoned to death; they don't care about anyone but their own use cases".

The state of things sucks :-(

by gspr

2/13/2026 at 11:25:22 AM

FIPS compliant?

by LtWorf

2/13/2026 at 12:02:46 PM

It is if you use the FIPS compliance feature - then you also depend on aws-lc, but only for the crypto primitives.

by eptcyka

2/13/2026 at 10:55:36 AM

Now what? BearSSL.

by MrBuddyCasino