Earlier quoted context omitted.
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?
WolfSSL sucks too, so now what?
91–100 of 136 posts
Re: WolfSSL sucks too, so now what?
#92Earlier quoted context omitted.
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 cal…
> 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: WolfSSL sucks too, so now what?
#93Re: WolfSSL sucks too, so now what?
#94Earlier quoted context omitted.
rustls is there. It has TLS in the name, it is good and there is a C FFI wrapper.
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 :-(
Re: WolfSSL sucks too, so now what?
#95This 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…
The author has spent a lot of time on this as well. I can see both sides. From the author's perspective their focus is their product/system. Any extra time they spend is not contributing to that. They've already spent a fair amount of time helping root cause the issue and from their perspective once it's clear what the issue is they're done. The author also seems to work on open source. In this case they are the cust…
Support guides the user through the discovery process, which can be messy and go circles, and the result of that is a big which is actionable by a developer.
Re: WolfSSL sucks too, so now what?
#96Re: WolfSSL sucks too, so now what?
#97If it's good enough for openbsd, it's good enough for you as well.
Particularly, they put in a lot of work on making it a drop-in replacement for openssl, and in making the portable version work well in many platforms.
Only for distributions to fail to take the sorely needed step of actually making the switch.
Re: WolfSSL sucks too, so now what?
#98Earlier quoted context omitted.
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 :-(
From safety point of view that's actually good enough for "perfect is the enemy of good" to apply here. Cryptographic primitives are much much safer in C (and assembly) than protocol handling, certificates etc. They are basically just "fixed size data block in, fixed size data block out". You can't overflow a buffer, you can't use-after-free etc, you can't confuse inner protocol serialization semantics with outer pro…
Re: WolfSSL sucks too, so now what?
#99Earlier quoted context omitted.
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 :-(
What? Ring is not even close to a fork of BoringSSL; it merely borrows subroutines from BoringSSL.
Re: WolfSSL sucks too, so now what?
#100Earlier quoted context omitted.
From safety point of view that's actually good enough for "perfect is the enemy of good" to apply here. Cryptographic primitives are much much safer in C (and assembly) than protocol handling, certificates etc. They are basically just "fixed size data block in, fixed size data block out". You can't overflow a buffer, you can't use-after-free etc, you can't confuse inner protocol serialization semantics with outer pro…
My point is that the article this thread is attached to starts out with how BoringSSL and AWS-LC won't cut it. And when rustls is suggested as an alternative, it's important to point out that it requires precisely those two (either one of them).