> 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?
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.
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"
OK, so: zero. It is relevant because if you did, you probably wouldn't feel so entitled.
> The maintainer is clearly engaging and knows what the problem is but stalls on the "last mile" which is issue creation. Do you agree?
No, I don't agree. This is just your interpretation, done in bad faith.
> wolfSSL also sells commercial licenses so it's not like they're going uncompensated for their work.
The user in question does not have a commercial license, so in this case, the maintainer was not compensated for assisting that user.
> Regardless, we shouldn't put people on pedestals because their title is "FOSS maintainer"
We shouldn't shit on other people's work we got for free just because they asked for a tiny little thing we might do to help them. It's you who needs to get down from that pedestal.
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?
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".
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.
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.
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".
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.
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
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"
> Out of interest, how is that relevant?
OK, so: zero. It is relevant because if you did, you probably wouldn't feel so entitled.
> The maintainer is clearly engaging and knows what the problem is but stalls on the "last mile" which is issue creation. Do you agree?
No, I don't agree. This is just your interpretation, done in bad faith.
> wolfSSL also sells commercial licenses so it's not like they're going uncompensated for their work.
The user in question does not have a commercial license, so in this case, the maintainer was not compensated for assisting that user.
> Regardless, we shouldn't put people on pedestals because their title is "FOSS maintainer"
We shouldn't shit on other people's work we got for free just because they asked for a tiny little thing we might do to help them. It's you who needs to get down from that pedestal.
> 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.
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..
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
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 :-(
there is https://github.com/RustCrypto/rustls-rustcrypto fwiw
rustls doesn't have its own implementation of cryptography, you have to choose a provider like openssl or aws lc
You're obviously looking for lastLs.
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.
Usability-wise (I do not need many features or compliance for FIPS) I have been happy with Botan: https://botan.randombit.net/
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.
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...
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.
Now what? BearSSL.
NanoSSL by DigiCert https://dev.digicert.com/trustcore-sdk/nanossl.html
It's opensource -> https://github.com/digicert/trustcore