4 ms·

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

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.

deng 8mo ago
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?
- halapro 8mo ago
  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"?
  - Semaphor 8mo ago
    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.
    - zelphirkalt 8mo ago
      > 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.
      - Semaphor 8mo ago
        Because that's incredibly entitled. The maintainer is already the one who has to fix it.
        zelphirkalt 8mo ago
        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.
  - PunchyHamster 8mo ago
    ...that's what they are asking, yes.
  - bioneuralnet 8mo ago
    Exactly, that's all his PR had to be. The history of finding the issue could be an interesting story (I bet it involves Elixir!), but in places it reads as almost malicious. If I received a PR anything like that on something I maintained, it would be received very poorly. The author comes off as overly aggressive toward the maintainers and far too sensitive to their response.
- deleted 8mo ago
  [deleted]
- bfrog 8mo ago
  Open Source is not Free Support, the sooner this reality sets in (accelerated surely by AI spam) the sooner we get to the happy place.
Alupis 8mo ago
It's pretty standard to open a new issue and reference the previous issue for context, while keeping the new issue specific about what needs to be addressed - ie. RFC compliance. I don't see the problem here at all - it was a reasonable request and it would have taken `feld` all of 2 minutes to do. Certainly less time than writing that blog post.
pseudohadamard 8mo ago
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 widely-used implementations isn't compliant, it doesn't send any of the mandatory-to-implement cipher suites in its client hello which means unless you want to trigger a rehandshake on every single connect you have to implement their non-compliant form of TLS 1.3. The real problem though is that they made a protocol that really, really wants to pretend it's TLS 1.2 when it really isn't anything like TLS 1.2. I wouldn't blame "middleboxes" for getting confused when they encounter that.
- pixl97 8mo ago
  > wants to pretend it's TLS 1.2 when it really isn't anything like TLS 1.2. 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.
- reanimus 8mo ago
  The problem is there are many middleboxes that monitor port 443 and will drop any traffic that they can't decode as TLS (which in this case means TLS 1.2 or below). The choice was between masking traffic as an earlier version of TLS or forcing the replacement of all of those middleboxes. It's a no-brainer.
  - pseudohadamard 8mo ago
    Then don't put it on 443 and pretend (badly) that it's TLS 1.2. Given that QUIC also uses 443 (and 80) without too many problems and that doesn't look anything remotely like TLS, presumably non-TLS 1.2 traffic to 443 is OK. The problem isn't really the port used, it's the uncanny-valley approach they took in creating something that looks like a creepy zombie version of TLS 1.2, which keep-suspicious-things-out appliances quite rightly get suspicious over.

deng 8mo ago

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?

halapro 8mo ago
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"?
- Semaphor 8mo ago
  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.
  - zelphirkalt 8mo ago
    > 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.
    - Semaphor 8mo ago
      Because that's incredibly entitled. The maintainer is already the one who has to fix it.
      - zelphirkalt 8mo ago
        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.
- PunchyHamster 8mo ago
  ...that's what they are asking, yes.
- bioneuralnet 8mo ago
  Exactly, that's all his PR had to be. The history of finding the issue could be an interesting story (I bet it involves Elixir!), but in places it reads as almost malicious. If I received a PR anything like that on something I maintained, it would be received very poorly. The author comes off as overly aggressive toward the maintainers and far too sensitive to their response.
deleted 8mo ago
[deleted]
bfrog 8mo ago
Open Source is not Free Support, the sooner this reality sets in (accelerated surely by AI spam) the sooner we get to the happy place.

Alupis 8mo ago

It's pretty standard to open a new issue and reference the previous issue for context, while keeping the new issue specific about what needs to be addressed - ie. RFC compliance. I don't see the problem here at all - it was a reasonable request and it would have taken `feld` all of 2 minutes to do. Certainly less time than writing that blog post.

pseudohadamard 8mo ago

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 widely-used implementations isn't compliant, it doesn't send any of the mandatory-to-implement cipher suites in its client hello which means unless you want to trigger a rehandshake on every single connect you have to implement their non-compliant form of TLS 1.3. The real problem though is that they made a protocol that really, really wants to pretend it's TLS 1.2 when it really isn't anything like TLS 1.2. I wouldn't blame "middleboxes" for getting confused when they encounter that.

pixl97 8mo ago
> wants to pretend it's TLS 1.2 when it really isn't anything like TLS 1.2. 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.
reanimus 8mo ago
The problem is there are many middleboxes that monitor port 443 and will drop any traffic that they can't decode as TLS (which in this case means TLS 1.2 or below). The choice was between masking traffic as an earlier version of TLS or forcing the replacement of all of those middleboxes. It's a no-brainer.
- pseudohadamard 8mo ago
  Then don't put it on 443 and pretend (badly) that it's TLS 1.2. Given that QUIC also uses 443 (and 80) without too many problems and that doesn't look anything remotely like TLS, presumably non-TLS 1.2 traffic to 443 is OK. The problem isn't really the port used, it's the uncanny-valley approach they took in creating something that looks like a creepy zombie version of TLS 1.2, which keep-suspicious-things-out appliances quite rightly get suspicious over.