101–110 of 136 posts
Earlier quoted context omitted.
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.
Protocol code and x.509 certficate handling will probably be better written in another language.
Earlier quoted context omitted.
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)
Earlier quoted context omitted.
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.
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.
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?
There the new runtime/secret could help.
If you change your software to comply with "middleboxes" that don't follow standards, then you're admitting your own software is faulty, not theirs. In this case, though, the TLS v1.3 standard actually carved out a portion of the standard itself just to comply with shitty middleware. You know what that says to me? Standards are pointless. Just make a middlebox, make it do whatever the hell you want, and everyone else…
Government regulation is good in that it can work, but it's terrible in that almost every other choice would be better if it works. For TLS 1.3 we made choices which work, if we'd waited for your hypothetical government intervention we'd still be using TLS 1.2 and Trump would presumably be collecting an inaugural "Super good Bank Encryption Champion" trophy from EDCO or somebody who fought against TLS 1.3 because it meant they'd have to actually do a good job.
Earlier quoted context omitted.
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.
It's not entirely WolfSSL's fault. TLS 1.3 is a mass of kludges and hacks to deal with the fact that they created a new protocol that's nothing like TLS 1.0-1.2 but dressed it up to make it look like TLS 1.2. It even lies about its protocol version in the handshake, hiding the real version in one of the many extensions they had to invent to kludge it into working. And in terms of RFC compliance, one of the most widel…
I've seen a ton of this recently as Amazon has the option for TLS 1.3 with post quantum encryption on cloudfront now. A whole ton of different middleware shits itself.
> 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…
Earlier quoted context omitted.
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?