Live data from Hacker News

WolfSSL sucks too, so now what?

blog.feld.me

91–100 of 136 posts

Re: WolfSSL sucks too, so now what?

#91
post #27

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?

That's actually impossible to answer. I maintain or contribute to or have contributed to several FOSS projects whose number varies depending on how you want to count them, and neither myself nor anyone else who contributes to any FOSS project has the faintest idea how many people use them, especially if they're included in widely-used distros where the number is anything from zero to $number_of_distro_users.

Re: WolfSSL sucks too, so now what?

#92

Earlier 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…

My first comment on this site pointing out that a FOSS user sounds entitled is from 2021. I've been saying it outside the site for 10+ years, spanning back to the time when it wasnt cringe to have a Github sticker on your laptop.

Re: WolfSSL sucks too, so now what?

#94
post #18

Earlier 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 :-(

What? Ring is not even close to a fork of BoringSSL; it merely borrows subroutines from BoringSSL.

Re: WolfSSL sucks too, so now what?

#95
post #88

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…

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…

What tis missing there is a support team and maybe a difference between a customer (user) facing support system and a big tracker.

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?

#96
post #49

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?

Better than no memory safety, sure. Also a kernel should be memory safe, so garbage collected.

Re: WolfSSL sucks too, so now what?

#97
Nothing wrong with LibreSSL, really.

If 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?

#98
post #87
post #19

Earlier 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…

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).

Re: WolfSSL sucks too, so now what?

#99
post #18

Earlier 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.

Ok, maybe not a fork outright. But the project description says: Most of the C and assembly language code in ring comes from BoringSSL.

Re: WolfSSL sucks too, so now what?

#100
post #98
post #87

Earlier 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).

The article is about TLS. The arguments against those libs don't apply if using them just for the low level crypto algorithms. (Also of course rustls can use other crypto providers besides those)
Post reply on HN