> 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.
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.
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?
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"?
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.
Exactly, that's all his PR had to be. The history of finding the issue could be an interesting story (I bet it involves Elixir!), but in places it reads as almost malicious. If I received a PR anything like that on something I maintained, it would be received very poorly. The author comes off as overly aggressive toward the maintainers and far too sensitive to their response.
...that's what they are asking, yes.
[deleted]
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.
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.
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.
> 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.
Reading the issue tracker, why would he do that unless he could repro?
> Hi @feld , I can't really tell if this is related to the ticket that you pointed out. I'll be helping you with this issue as well as looking into the other ticket. Can you give me step by step instructions on how to reproduce what you are seeing? Please note that I have limitted experience with HAProxy and Erlang.
> ...
> I've successfully connected to the server with the examples/client/client and I cannot reproduce what you are seeing. I've built with both WOLFSSL_TLS13_MIDDLEBOX_COMPAT defined and undefined.
He only gets a reply six months later!
This, I feel, clearly shows Feld's intentions - he wasn't interested in agetting it fixed, it was not a bug for him, but he was interested in spreading the word about it. i.e. To me, anyway, it looks like Feld is more interested in writing outrage-bait than getting a working product.
I've used WolfSSL in anger and the experience was much better than OpenSSL and AWS-lc.
Looking at the ticket itself, I consider the responses from the dev team to be pretty good support - better than some paid products I have used.
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.
> The maintainer should just
Out of interest: which FOSS projects are you maintaining, and how many users do these have, approximately?
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"
Unless you're paying you are not entitled to anything apart from forking and fixing it yourself.
You are especially not entitled to bullying maintainers as has been unfortunately the standard in infosec.
You know a social movement went full circle when a criticism that is so scathing, you couldn't have possibly come up with it and make it trend before, even if you gave it your all, is now a motto and a point of pride for those who follow it.
This is happening at the same time where hundreds of millions of regular variety consumers are being fed propaganda daily about how it's "finally time to switch to Linux", because it's so much better for them, the individual. If only they knew it's apparently not actually about them, never has been, and never will be.
When exactly is 'before'? Before Github existed to put front and center your code and its issues? Before it became an expectation to have a a rich Github profile when you're considered for a job position?
Of course I wouldn't have been able to come up with this statement because the perverted view of OSS devs owing free work to the users of their software was not so pervaisive.
On your edit: a bit rich saying the calls for switching to Linux propaganda, especially with the downturn of UX of windows and macos... Also why just hundreds of millions.. Go for hundreds of billions if you're just going to pull out numbers. Apart from that - even if Linux is not about the users, it is in many cases better for them as-is. Funny how that works with no conflict.
> When exactly is 'before'?
"Exactly"? I'm afraid that's not a very physically sound request. But let's say, prior to 2026-02-14T03:46:03Z then. I hope that suffices.
> Of course I wouldn't have been able to come up with this statement
> Also why just hundreds of millions.. Go for hundreds of billions if you're just going to pull out numbers
You see, that would be because I did not just pull out an arbitrary number. "How many Windows users there are" is a reported fact you can just search for, and even the total is not "billions" (plural). I know, I was surprised too. From the horse's mouth: https://blogs.windows.com/windowsexperience/2025/06/24/stay-...
[flagged]
> 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.
I maintain several FOSS projects, although none as popular as wolfssl and if I want to make a new issue to make it more clean, I usually do it myself, because then I can write it the way I want, and include the information, and only the information, that I think is important. If I ask someone else to do it, there's a pretty good chance they won't write it the way I would like, if they write it up at all.
Why should that be the maintainer's burden?
Presumably, the maintainer wants the best for the product and its users. So they have a definite interest in documenting a todo list.
Presumably, the user wants the best for the product and their ability to use the product. So they have a definite interest in documenting a todo list.
It doesn't make sense for the two to be at war with each other. It is no big deal for the maintainer to ask a favor. It's not too big of a deal for the user to decline. There's no need to attack.
I have often dropped a note to the maintainer of a project I bumped into. I'm sure they would prefer a bug report in their official forge. But I don't really use their software except for this one time. I'm not willing to jump through the hoops to create an account in yet another SaaS just to file this one report. Just dropping them an email was a courtesy. But often they don't interpret it that way. I'm perfectly un-insulted if they just delete my note and never "fix" the issue because it didn't come through proper channels.
No attacks. No war. Just well wishes. But I might very likely avoid the product if I'm ever back in those woods. Not out of anger or retribution. Just because I'll remember that the product had at least one sharp edge for my use case and the maintainer was a bit overwhelmed by the weight of supporting my niche use case. That doesn't make the maintainer a bad person or even a bad maintainer.
If the maintainer is trying to write something RFC-compliant, and someone reports a violation of the RFC, it sure seems reasonable for the maintainer to want to track that.
If they don't want to, that's certainly their right, but it also tells us something about that project.
Because they're the ones asking for the administrative burden of refiling a basic RFC violation bug?
If they're doing this and bothering to interact with tickets at all, presumably they've willingly taken on a duty to the software's quality and all that that entails.
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)".
This issue has a similar conversational rhythm that led to the AI agent hit piece that was trending yesterday:
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..
I was reading through the complete issue thread and I have to say I probably would side with the wolfSSL maintainers in part but they could have handled it in a nicer way.
"Anthu" only responded with this after "feld" asked why the issue was closed by them, and only then the response you mentioned was written.
"Anthu" could have simply asked before closing the issue and the reporter would have been fine. Like, say "So, this issue meanwhile evolved into RFC compliance and got a bit off track in my opinion. Can you please open up a separate issue for this so we can get this fixed in a more focused manner? That would be very helpful for our workflow. If not, I would open up an issue and reference this one if that's okay with you."
My point is that feld felt a little ignored in their problem, and the support role could have handled it a little nicer. I get that maintainer time is limited, but I would probably recommend an issue template for these matters where there's checkboxes in them like "keep it short, keep it reproducible" and maybe a separate issue template and tag for RFC matters.
On the other hand, "feld"'s blog post reaction was also quite trigger happy and in part in bad faith. They could've communicated the same things in a "non rage mode" after things have calmed down a bit.
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.
I don't think it's fair to judge the whole FreeBSD community by one person.
Seriously, where the hell did that come from?
Where did I judge the FreeBSD community?
Probably where you said:
> If this is what the FreeBSD community is like, I want nothing to do with them.
>If
“If you break the law, then you go to jail” is not “you broke the law, you are going to jail”. I didn’t judge the entire FreeBSD community based on this blog post.
Fun game, let's keep playing.
Where did they say you did?
I'm not "playing a game". "Feld" purports to be a FreeBSD ports committer. Someone with commit rights on a major project would know how to properly file issues and work with other maintainers. But "feld" doesn't seem to know how to do that. Perhaps "feld" had a bad day, or maybe him and the rest of the FreeBSD ports contributors/maintainers just operate in this way, I don't know.
>Where did they say you did?
They said it in the part where you got all confused and responded to me.
You're not playing a game? Could have fooled me.
What you originally responded to above:
> I don't think it's fair to judge the whole FreeBSD community by one person.
So they just like, gave us a fun fact, right?
Conversely, I was also apparently just speculating:
> Probably where you said
So many things are possible when we don't want to be found wrong. Including pretending that figurative speech only exists when it's convenient.
Otherwise, I really don't see what would be so hard in understanding why throwing an "if" at the start would still lead to people taking what you said the way they did.
For the record, contrary to your assertion, even your example is affected by this:
> If you break the law, then you go to jail
If you posted this (and even only just this) under a random thread, people would think you're accusing someone (whoever the given thread is most about) to be somehow guilty of some untold crimes and/or that some chatbot got loose. I hope you can appreciate how people would be absolutely correct to think that way.
What really gets me is the commenter at the end of the GH issue lecturing a maintainer on policy in their own tracker.
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.
rustls is there. It has TLS in the name, it is good and there is a C FFI wrapper.
A c wrapper to rust feels like we've gone full circle
That would be amazing and really cement the proven value of Rust.
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 :-(
The primitives aren't a problem. You can't write them in any vaguely modern high level language. And when I say "High level" I mean that the way K&R does when they describe their new C programming language as high level. The reason you can't write cryptographic primitives in a high level language is that optimising compilers love clever tricks which offer data dependent performance, across every layer of their design - but in cryptography we want constant execution time regardless of either the plaintext or keys used.
The problem with OpenSSL isn't these cryptographic primitives, that's why you will see basically the same primitives re-used in lots of different places. It's like finding out that the guy who was just arrested for murder also eats pizza. Yeah, people do that. The problem wasn't the pizza, it was the murder. OpenSSL's implementation of the AES cipher isn't broken, the problem is elsewhere.
The author also doesn't specify what that even means and what problems it causes
> USE THIS AT YOUR OWN RISK! DO NOT USE THIS IN PRODUCTION
rustls doesn't have its own implementation of cryptography, you have to choose a provider like openssl or aws lc
Or rustcrypto. Rustls is a TLS layer that can wrap any cryptography layer providing the necessary primitives.
But then how will we spot the pedants.
You're obviously looking for lastLs.
There is also s2n-tls. I'm working on a GSS-based interface to TLS, much like SChannel is an SSPI-based interface to TLS.
> Asking me to open a new issue to discuss this behavior instead of it being a high priority for them to open up a new issue internally to fix this is odd. I'm not here to do their homework for them.
Why are people so entitled? How much is the author paying WolfSSL to make demands of them?
> Currently I've only identified one victim of this decision, but there's bound to be more out there.
Oh yes, he has become a victim of using a FOSS library.
> Oh yes, he has become a victim of using a FOSS library.
many such cases
Neither person is entitled to the work of the other and neither wants to do the work which seems to be how we ended up here. The author can't make demands of the project and so wrote a blog post warning others that it's not production ready and you'll have broken software if you use it. Their conclusion isn't that they must fix it but that you should use a more mature library.
Two adults both defected in the social prisoner's dilemma and so here we are. Both individuals believing to have done free labor for the other and that they should be grateful.
Usability-wise (I do not need many features or compliance for FIPS) I have been happy with Botan: https://botan.randombit.net/
> I have been happy with Botan
Botan is under rated.
It is nowhere as optimized as OpenSSL but its APIs are one order of magnitude better to use.
The team behind also demonstrated a pretty serious handling of non-trivial issues like timing attacks.
Can confirm, used Botan in the past and I didn't curse at it a lot. Certainly less than OpenSSL.
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.
I have systematically and successfully banned OpenSSL across all of my Rust projects. Sure, RusTLS shares a few C crypto primitives with OpenSSL forks. But I've never been happier with the overall library.
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
Go can create C ABI shared libraries, I think OpenSSL-compatible C bindings to Go's crypto/tls would be a really interesting option.
Do you want garbage collection in your SSL?
[deleted][deleted]
> 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.
There’s always rustls.
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 :-(
FIPS compliant?
It is if you use the FIPS compliance feature - then you also depend on aws-lc, but only for the crypto primitives.
In the age of GPT Codex 5.3 and Claude Opus 4.6. Just write your own.
Now what? BearSSL.
MbedTLS
I don't know if it's still the case, but MbetTLS used to change its API as often as I change my socks.
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
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.
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?
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"?
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.
Exactly, that's all his PR had to be. The history of finding the issue could be an interesting story (I bet it involves Elixir!), but in places it reads as almost malicious. If I received a PR anything like that on something I maintained, it would be received very poorly. The author comes off as overly aggressive toward the maintainers and far too sensitive to their response.
...that's what they are asking, yes.
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.
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.
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.
> 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.
Reading the issue tracker, why would he do that unless he could repro?
> Hi @feld , I can't really tell if this is related to the ticket that you pointed out. I'll be helping you with this issue as well as looking into the other ticket. Can you give me step by step instructions on how to reproduce what you are seeing? Please note that I have limitted experience with HAProxy and Erlang.
> ...
> I've successfully connected to the server with the examples/client/client and I cannot reproduce what you are seeing. I've built with both WOLFSSL_TLS13_MIDDLEBOX_COMPAT defined and undefined.
He only gets a reply six months later!
This, I feel, clearly shows Feld's intentions - he wasn't interested in agetting it fixed, it was not a bug for him, but he was interested in spreading the word about it. i.e. To me, anyway, it looks like Feld is more interested in writing outrage-bait than getting a working product.
I've used WolfSSL in anger and the experience was much better than OpenSSL and AWS-lc.
Looking at the ticket itself, I consider the responses from the dev team to be pretty good support - better than some paid products I have used.
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.
> The maintainer should just
Out of interest: which FOSS projects are you maintaining, and how many users do these have, approximately?
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"
Unless you're paying you are not entitled to anything apart from forking and fixing it yourself.
You are especially not entitled to bullying maintainers as has been unfortunately the standard in infosec.
Open source is not about you.
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
IMO more projects have to explicitly state this for example in a terms document, like https://github.com/mhoye/maintenance-terms/blob/main/MAINTEN...
> Open source is not about you.
You know a social movement went full circle when a criticism that is so scathing, you couldn't have possibly come up with it and make it trend before, even if you gave it your all, is now a motto and a point of pride for those who follow it.
This is happening at the same time where hundreds of millions of regular variety consumers are being fed propaganda daily about how it's "finally time to switch to Linux", because it's so much better for them, the individual. If only they knew it's apparently not actually about them, never has been, and never will be.
When exactly is 'before'? Before Github existed to put front and center your code and its issues? Before it became an expectation to have a a rich Github profile when you're considered for a job position?
Of course I wouldn't have been able to come up with this statement because the perverted view of OSS devs owing free work to the users of their software was not so pervaisive.
On your edit: a bit rich saying the calls for switching to Linux propaganda, especially with the downturn of UX of windows and macos... Also why just hundreds of millions.. Go for hundreds of billions if you're just going to pull out numbers. Apart from that - even if Linux is not about the users, it is in many cases better for them as-is. Funny how that works with no conflict.
> When exactly is 'before'?
"Exactly"? I'm afraid that's not a very physically sound request. But let's say, prior to 2026-02-14T03:46:03Z then. I hope that suffices.
> Of course I wouldn't have been able to come up with this statement
That would make sense, because you specifically I never expected to: https://en.wikipedia.org/wiki/Generic_you
> Also why just hundreds of millions.. Go for hundreds of billions if you're just going to pull out numbers
You see, that would be because I did not just pull out an arbitrary number. "How many Windows users there are" is a reported fact you can just search for, and even the total is not "billions" (plural). I know, I was surprised too. From the horse's mouth: https://blogs.windows.com/windowsexperience/2025/06/24/stay-...
[flagged]
> 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.
I maintain several FOSS projects, although none as popular as wolfssl and if I want to make a new issue to make it more clean, I usually do it myself, because then I can write it the way I want, and include the information, and only the information, that I think is important. If I ask someone else to do it, there's a pretty good chance they won't write it the way I would like, if they write it up at all.
Why should that be the maintainer's burden?
Presumably, the maintainer wants the best for the product and its users. So they have a definite interest in documenting a todo list.
Presumably, the user wants the best for the product and their ability to use the product. So they have a definite interest in documenting a todo list.
It doesn't make sense for the two to be at war with each other. It is no big deal for the maintainer to ask a favor. It's not too big of a deal for the user to decline. There's no need to attack.
I have often dropped a note to the maintainer of a project I bumped into. I'm sure they would prefer a bug report in their official forge. But I don't really use their software except for this one time. I'm not willing to jump through the hoops to create an account in yet another SaaS just to file this one report. Just dropping them an email was a courtesy. But often they don't interpret it that way. I'm perfectly un-insulted if they just delete my note and never "fix" the issue because it didn't come through proper channels.
No attacks. No war. Just well wishes. But I might very likely avoid the product if I'm ever back in those woods. Not out of anger or retribution. Just because I'll remember that the product had at least one sharp edge for my use case and the maintainer was a bit overwhelmed by the weight of supporting my niche use case. That doesn't make the maintainer a bad person or even a bad maintainer.
If the maintainer is trying to write something RFC-compliant, and someone reports a violation of the RFC, it sure seems reasonable for the maintainer to want to track that.
If they don't want to, that's certainly their right, but it also tells us something about that project.
Because they're the ones asking for the administrative burden of refiling a basic RFC violation bug?
If they're doing this and bothering to interact with tickets at all, presumably they've willingly taken on a duty to the software's quality and all that that entails.
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)".
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..
I was reading through the complete issue thread and I have to say I probably would side with the wolfSSL maintainers in part but they could have handled it in a nicer way.
"Anthu" only responded with this after "feld" asked why the issue was closed by them, and only then the response you mentioned was written.
"Anthu" could have simply asked before closing the issue and the reporter would have been fine. Like, say "So, this issue meanwhile evolved into RFC compliance and got a bit off track in my opinion. Can you please open up a separate issue for this so we can get this fixed in a more focused manner? That would be very helpful for our workflow. If not, I would open up an issue and reference this one if that's okay with you."
My point is that feld felt a little ignored in their problem, and the support role could have handled it a little nicer. I get that maintainer time is limited, but I would probably recommend an issue template for these matters where there's checkboxes in them like "keep it short, keep it reproducible" and maybe a separate issue template and tag for RFC matters.
On the other hand, "feld"'s blog post reaction was also quite trigger happy and in part in bad faith. They could've communicated the same things in a "non rage mode" after things have calmed down a bit.
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.
I don't think it's fair to judge the whole FreeBSD community by one person.
Seriously, where the hell did that come from?
Where did I judge the FreeBSD community?
Probably where you said:
> If this is what the FreeBSD community is like, I want nothing to do with them.
>If
“If you break the law, then you go to jail” is not “you broke the law, you are going to jail”. I didn’t judge the entire FreeBSD community based on this blog post.
Fun game, let's keep playing.
Where did they say you did?
I'm not "playing a game". "Feld" purports to be a FreeBSD ports committer. Someone with commit rights on a major project would know how to properly file issues and work with other maintainers. But "feld" doesn't seem to know how to do that. Perhaps "feld" had a bad day, or maybe him and the rest of the FreeBSD ports contributors/maintainers just operate in this way, I don't know.
>Where did they say you did?
They said it in the part where you got all confused and responded to me.
You're not playing a game? Could have fooled me.
What you originally responded to above:
> I don't think it's fair to judge the whole FreeBSD community by one person.
So they just like, gave us a fun fact, right?
Conversely, I was also apparently just speculating:
> Probably where you said
So many things are possible when we don't want to be found wrong. Including pretending that figurative speech only exists when it's convenient.
Otherwise, I really don't see what would be so hard in understanding why throwing an "if" at the start would still lead to people taking what you said the way they did.
For the record, contrary to your assertion, even your example is affected by this:
> If you break the law, then you go to jail
If you posted this (and even only just this) under a random thread, people would think you're accusing someone (whoever the given thread is most about) to be somehow guilty of some untold crimes and/or that some chatbot got loose. I hope you can appreciate how people would be absolutely correct to think that way.
What really gets me is the commenter at the end of the GH issue lecturing a maintainer on policy in their own tracker.
Regarding HAProxy, they ended up using AWS-LC in their new Debian/Ubuntu “performance” packages: https://www.haproxy.com/blog/fresh-from-aws-reinvent-superch...
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
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.
Where is Bellard when we need him?
Most relevantly here, selling a commercial implementation of ASN.1: https://bellard.org/ffasn1/.
We need something with TLS in the name for the next one so people stop getting confused.
MbedTLS[1] got your back!
[1]: https://www.trustedfirmware.org/projects/mbed-tls/
rustls is there. It has TLS in the name, it is good and there is a C FFI wrapper.
A c wrapper to rust feels like we've gone full circle
That would be amazing and really cement the proven value of Rust.
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 :-(
The primitives aren't a problem. You can't write them in any vaguely modern high level language. And when I say "High level" I mean that the way K&R does when they describe their new C programming language as high level. The reason you can't write cryptographic primitives in a high level language is that optimising compilers love clever tricks which offer data dependent performance, across every layer of their design - but in cryptography we want constant execution time regardless of either the plaintext or keys used.
The problem with OpenSSL isn't these cryptographic primitives, that's why you will see basically the same primitives re-used in lots of different places. It's like finding out that the guy who was just arrested for murder also eats pizza. Yeah, people do that. The problem wasn't the pizza, it was the murder. OpenSSL's implementation of the AES cipher isn't broken, the problem is elsewhere.
The author also doesn't specify what that even means and what problems it causes
there is https://github.com/RustCrypto/rustls-rustcrypto fwiw
It's a great effort, but it's far from usable:
> USE THIS AT YOUR OWN RISK! DO NOT USE THIS IN PRODUCTION
rustls doesn't have its own implementation of cryptography, you have to choose a provider like openssl or aws lc
Or rustcrypto. Rustls is a TLS layer that can wrap any cryptography layer providing the necessary primitives.
But then how will we spot the pedants.
You're obviously looking for lastLs.
There is also s2n-tls. I'm working on a GSS-based interface to TLS, much like SChannel is an SSPI-based interface to TLS.
> Asking me to open a new issue to discuss this behavior instead of it being a high priority for them to open up a new issue internally to fix this is odd. I'm not here to do their homework for them.
Why are people so entitled? How much is the author paying WolfSSL to make demands of them?
> Currently I've only identified one victim of this decision, but there's bound to be more out there.
Oh yes, he has become a victim of using a FOSS library.
> Oh yes, he has become a victim of using a FOSS library.
many such cases
Neither person is entitled to the work of the other and neither wants to do the work which seems to be how we ended up here. The author can't make demands of the project and so wrote a blog post warning others that it's not production ready and you'll have broken software if you use it. Their conclusion isn't that they must fix it but that you should use a more mature library.
Two adults both defected in the social prisoner's dilemma and so here we are. Both individuals believing to have done free labor for the other and that they should be grateful.
Usability-wise (I do not need many features or compliance for FIPS) I have been happy with Botan: https://botan.randombit.net/
> I have been happy with Botan
Botan is under rated.
It is nowhere as optimized as OpenSSL but its APIs are one order of magnitude better to use.
The team behind also demonstrated a pretty serious handling of non-trivial issues like timing attacks.
Can confirm, used Botan in the past and I didn't curse at it a lot. Certainly less than OpenSSL.
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.
I have systematically and successfully banned OpenSSL across all of my Rust projects. Sure, RusTLS shares a few C crypto primitives with OpenSSL forks. But I've never been happier with the overall library.
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
Go can create C ABI shared libraries, I think OpenSSL-compatible C bindings to Go's crypto/tls would be a really interesting option.
Do you want garbage collection in your SSL?
> 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.
There’s always rustls.
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 :-(
FIPS compliant?
It is if you use the FIPS compliance feature - then you also depend on aws-lc, but only for the crypto primitives.
In the age of GPT Codex 5.3 and Claude Opus 4.6. Just write your own.
Now what? BearSSL.
MbedTLS
I don't know if it's still the case, but MbetTLS used to change its API as often as I change my socks.
NanoSSL by DigiCert https://dev.digicert.com/trustcore-sdk/nanossl.html
It's opensource -> https://github.com/digicert/trustcore
AGPLv3 so not exactly a drop in replacement, license-wise.