Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WolfSSL sucks too, so now what?

blog.feld.me

Post reply on HN
Print view View original

111–120 of 136 posts

Re: WolfSSL sucks too, so now what?

#111

Post by yawaramin »

phyzome wrote: post #64
otterley wrote: post #47

Earlier quoted context omitted.

Why should that be the maintainer's burden?

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.

Someone reporting an RFC violation doesn't automatically mean there is actually an RFC violation. That's why they are asking for a minimal repro, not a dump of the reporter's stream of consciousness. If your teammate at work. came to you and dumped something like this on your desk, how would you react?

Re: WolfSSL sucks too, so now what?

#112

Post by otterley »

naasking wrote: post #62
otterley wrote: post #47

Earlier quoted context omitted.

Why should that be the maintainer's burden?

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.

Maintaining an open-source software project is frequently a hobby that’s performed out of a labor of love. There’s no duty owed to anyone, nor should one be implied by past behavior. The open-source community is not a slave trade.

Re: WolfSSL sucks too, so now what?

#113

Post by tialaramex »

pocksuppet wrote: post #36
dwedge wrote: post #22

Earlier quoted context omitted.

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

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

There's even a project for a deliberately OpenSSL drop-in compatible Rustls backed library. It is intended for specific projects because OpenSSL is sprawling and they don't implement most if it, but in principle if you use the same parts of OpenSSL your C likely works with this safer + faster alternative today, why not recommend it to your users.

https://github.com/rustls/rustls-openssl-compat

Re: WolfSSL sucks too, so now what?

#114

Post by 1vuio0pswjnm7 »

"OpenBSD was probably right. We just need to focus on LibreSSL and forget about all of these other libraries."

Having compiled many of the popular SSL libraries as an end user, on underpowered computers, IMHO LibreSSL has the best compilation process, e.g., least complex, fastest

The library doesn't have all the features of the others but being able to compile it relatively quickly and easily IMHO is itself a "feature"

WolfSSL has many, many options. Accepting the defaults is not sufficient IME.^1 According to the cited HAProxy blog post, AWS-LC is perhaps the fastest SSL library. But Amazon "overlooked" a simple CMake option that actually made it slower than WolfSSL

To summarise, (a) in addition to library "features" I think the compilation process is also important, (b) IME getting what one wants from the various SSL libraries, if even possible, is needlessly complex and (c) FWIW, LibreSSL has (IMO) the least complicated and fastest compilation process

1. It seems like the author did not want to spend the time to learn about all the options. For the end user (cf. "developer") this make sense. As the HAProxy blog post suggests, the SSL libraries that are controlled by people who work for advertising companies, e-commerce companies and CDN companies are naturally going to put their own interests first. Those interests may not always align with the end user's interests

Re: WolfSSL sucks too, so now what?

#115

Post by brianpane »

koakuma-chan wrote: post #20
weinzierl wrote: post #11

Earlier quoted context omitted.

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

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

There is a rustls side project called Graviola that's building a fast crypto provider in Rust+ASM. It's taken an interesting approach: starting with an assembly library that's been formally proven correct, and then programmatically translating that into Rust with inline assembly that's easy to build with Rust tooling.

Re: WolfSSL sucks too, so now what?

#116

Post by Semaphor »

zelphirkalt wrote: post #105
Semaphor wrote: post #26

Earlier quoted context omitted.

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.

> Then opening the ticket should be easy enough? For both of them! Since both of them are aware now, either one could open that ticket. If the maintainer has very specific ideas about how a ticket should look, maybe they can do that themselves quickly, now that they are aware of not complying with the RFC. Then the ticket will perfectly match their expectations.

Because that's incredibly entitled. The maintainer is already the one who has to fix it.

Re: WolfSSL sucks too, so now what?

#117

Post by move-on-by »

randallsquared wrote: post #109
move-on-by wrote: post #60

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

The "victim" was the Elixir or Erlang library, not himself. To be clear.

I don’t think it was clear, but thanks for the insight.

Was WolfSSL forced upon Elixir or Erlang? Did they purchase it and received a defective product? Are they held hostage by WolfSSL’s decisions? Are they not allowed to modify WolfSSL as needed themselves?

I fail to see any victims beyond perhaps the WolfSSL maintainers for having to suffer such entitlement.

Re: WolfSSL sucks too, so now what?

#118

Post by zelphirkalt »

Semaphor wrote: post #116
zelphirkalt wrote: post #105

Earlier quoted context omitted.

> Then opening the ticket should be easy enough? For both of them! Since both of them are aware now, either one could open that ticket. If the maintainer has very specific ideas about how a ticket should look, maybe they can do that themselves quickly, now that they are aware of not complying with the RFC. Then the ticket will perfectly match their expectations.

Because that's incredibly entitled. The maintainer is already the one who has to fix it.

The maintainer is usually also the one who has to trace the root cause, which in this case the issue reporter did, which is certainly more work than creating an issue according to the formatting and other requirements the maintainer may have. So in that light, the reporter of the issue already did a big chunk of work for the maintainer or the project. I wouldn't really call them acting "entitled" after that. Clearly they put in effort more than could be expected already.

Re: WolfSSL sucks too, so now what?

#119

Post by codys »

rurban wrote: post #96
AtlasBarfed wrote: post #57

Earlier quoted context omitted.

Do you want garbage collection in your SSL?

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

Garbage collection is not required for memory safety.

Languages that have garbage collection are not all memory safe.

Re: WolfSSL sucks too, so now what?

#120

Post by naasking »

otterley wrote: post #112
naasking wrote: post #62

Earlier quoted context omitted.

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.

Maintaining an open-source software project is frequently a hobby that’s performed out of a labor of love. There’s no duty owed to anyone, nor should one be implied by past behavior. The open-source community is not a slave trade.

Hence why I said "voluntarily".
Post reply on HN