4 ms·

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

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 to believe that they aren't really interested in RFC compliance. There isn't a middleground here or a "different way" of implementing middlebox compatibility. It's either RFC compliant or not. And they're not. This is a bad-faith interpretation of the maintainer's response. They only asked to open a new, more specific issue report. The maintainer always answered within minutes, which I find quite impressive (even after the author ghosted for months). The author consumed the maintainer's time and shouldn't get the blame for the author's problems. [1]: https://github.com/wolfSSL/wolfssl/issues/9156 https://github.com/wolfSSL/wolfssl/issues/9156

reanimus 8mo ago
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.
hypeatei 8mo ago
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.
- deng 8mo ago
  > The maintainer should just Out of interest: which FOSS projects are you maintaining, and how many users do these have, approximately?
  - hypeatei 8mo ago
    Out of interest, how is that relevant? Are we not able to criticize a FOSS maintainers response unless we run a project of scale ourselves? The maintainer is clearly engaging and knows what the problem is but stalls on the "last mile" which is issue creation. Do you agree? wolfSSL also sells commercial licenses so it's not like they're going uncompensated for their work. Regardless, we shouldn't put people on pedestals because their title is "FOSS maintainer"
    - deng 8mo ago
      [flagged]
      - hypeatei 8mo ago
        > you probably wouldn't feel so entitled. ...what? Are we living in the same universe? What exactly did I say that makes me entitled? > The user in question does not have a commercial license Do you know that for sure or are you speculating? > We shouldn't shit on other people's work we got for free When did I shit on the work of wolfSSL? I'm saying that it appears they were engaging but got hung up on a small issue. > It's you who needs to get down from that pedestal. Respectfully, you need to get a grip.
    - phoronixrly 8mo ago
      Unless you're paying you are not entitled to anything apart from forking and fixing it yourself. You are especially not entitled to bullying maintainers as has been unfortunately the standard in infosec. Open source is not about you. https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95... IMO more projects have to explicitly state this for example in a terms document, like https://github.com/mhoye/maintenance-terms/blob/main/MAINTENANCE-TERMS.md https://github.com/mhoye/maintenance-terms/blob/main/MAINTEN...
Phemist 8mo ago
This issue has a similar conversational rhythm that led to the AI agent hit piece that was trending yesterday: https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/ https://theshamblog.com/an-ai-agent-published-a-hit-piece-on... The OPs blog post also reeks of a similar style to the hit piece. Given the large delay between the initial report and further responses by the user `feld`, I wonder if an OpenClaw agent was given free reign to try to clear up outstanding issues in some project, including handling the communication with the project maintainers? Maybe I am getting too paranoid..
teekert 8mo ago
A reasonable reply indeed from the maintainer, this happens a lot where you think together in an issue and identify whats really wrong near the end. Only then is one able to articulate an issue in a helpful, concise way. Perhaps GH could add a feature to facilitate this pattern.
SubjectToChange 8mo ago
Worse yet, despite publishing seventeen blog posts between filing the issue and finally responding to it, he has the gall to open with "Sorry I missed your replies (life gets busy)".
cookiengineer 8mo ago
I was reading through the complete issue thread and I have to say I probably would side with the wolfSSL maintainers in part but they could have handled it in a nicer way. "Anthu" only responded with this after "feld" asked why the issue was closed by them, and only then the response you mentioned was written. "Anthu" could have simply asked before closing the issue and the reporter would have been fine. Like, say "So, this issue meanwhile evolved into RFC compliance and got a bit off track in my opinion. Can you please open up a separate issue for this so we can get this fixed in a more focused manner? That would be very helpful for our workflow. If not, I would open up an issue and reference this one if that's okay with you." My point is that feld felt a little ignored in their problem, and the support role could have handled it a little nicer. I get that maintainer time is limited, but I would probably recommend an issue template for these matters where there's checkboxes in them like "keep it short, keep it reproducible" and maybe a separate issue template and tag for RFC matters. On the other hand, "feld"'s blog post reaction was also quite trigger happy and in part in bad faith. They could've communicated the same things in a "non rage mode" after things have calmed down a bit.
YZF 8mo ago
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 customer of a product, granted an open source one, and they've helped the vendor (the maintainer) figure out something is broken. Their expectation is that the vendor takes things on from there and doesn't put up some bureaucracy. That said ofcourse you paid nothing for this and you should expect nothing but the OSS project also has no expectations that their customers support them if those customers aren't getting their expectations met. In today's world one unhappy customer can give you a pretty bad rep, as is happening here. Now if you don't care then you don't care. But the argument that because your product is "free" then your customers have no voice doesn't sound that great either. Everyone seems to be pointing how the author disappeared and came back much later. Well, they disappeared because it wasn't a problem or they've worked around it, and came back when they hit the problem again. Just like the maintainer doesn't work for the author the author doesn't work for the maintainer either. It's also true the ticket now has a lot of history, but the original bug is still the same bug, it's just that now it has been root caused? The maintainer's response of now that you've found a setting that works around the issue you're good and we can close this also is a bit off. And sure, they don't work for anyone so they're welcome to do whatever they want. As isn't uncommon when two humans communicate online there is some miscommunication here. But you can argue either way. Not being an open source maintainer I don't know what the "protocol" here is but the few times I've filed bugs against an open source product I did personally put in the extra mile to make them actionable. But in my day job I have to deal with all sorts of bug reports and chasing them down to a resolution is part of what makes the product I work on a better one. And yes, I get paid to do that ;)
- johannes1234321 8mo ago
  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.

reanimus 8mo ago

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.

hypeatei 8mo ago

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.

deng 8mo ago
> The maintainer should just Out of interest: which FOSS projects are you maintaining, and how many users do these have, approximately?
- hypeatei 8mo ago
  Out of interest, how is that relevant? Are we not able to criticize a FOSS maintainers response unless we run a project of scale ourselves? The maintainer is clearly engaging and knows what the problem is but stalls on the "last mile" which is issue creation. Do you agree? wolfSSL also sells commercial licenses so it's not like they're going uncompensated for their work. Regardless, we shouldn't put people on pedestals because their title is "FOSS maintainer"
  - deng 8mo ago
    [flagged]
    - hypeatei 8mo ago
      > you probably wouldn't feel so entitled. ...what? Are we living in the same universe? What exactly did I say that makes me entitled? > The user in question does not have a commercial license Do you know that for sure or are you speculating? > We shouldn't shit on other people's work we got for free When did I shit on the work of wolfSSL? I'm saying that it appears they were engaging but got hung up on a small issue. > It's you who needs to get down from that pedestal. Respectfully, you need to get a grip.
  - phoronixrly 8mo ago
    Unless you're paying you are not entitled to anything apart from forking and fixing it yourself. You are especially not entitled to bullying maintainers as has been unfortunately the standard in infosec. Open source is not about you. https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95... IMO more projects have to explicitly state this for example in a terms document, like https://github.com/mhoye/maintenance-terms/blob/main/MAINTENANCE-TERMS.md https://github.com/mhoye/maintenance-terms/blob/main/MAINTEN...

Phemist 8mo ago

This issue has a similar conversational rhythm that led to the AI agent hit piece that was trending yesterday: https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/ https://theshamblog.com/an-ai-agent-published-a-hit-piece-on... The OPs blog post also reeks of a similar style to the hit piece. Given the large delay between the initial report and further responses by the user `feld`, I wonder if an OpenClaw agent was given free reign to try to clear up outstanding issues in some project, including handling the communication with the project maintainers? Maybe I am getting too paranoid..

teekert 8mo ago

A reasonable reply indeed from the maintainer, this happens a lot where you think together in an issue and identify whats really wrong near the end. Only then is one able to articulate an issue in a helpful, concise way. Perhaps GH could add a feature to facilitate this pattern.

SubjectToChange 8mo ago

Worse yet, despite publishing seventeen blog posts between filing the issue and finally responding to it, he has the gall to open with "Sorry I missed your replies (life gets busy)".

cookiengineer 8mo ago

I was reading through the complete issue thread and I have to say I probably would side with the wolfSSL maintainers in part but they could have handled it in a nicer way. "Anthu" only responded with this after "feld" asked why the issue was closed by them, and only then the response you mentioned was written. "Anthu" could have simply asked before closing the issue and the reporter would have been fine. Like, say "So, this issue meanwhile evolved into RFC compliance and got a bit off track in my opinion. Can you please open up a separate issue for this so we can get this fixed in a more focused manner? That would be very helpful for our workflow. If not, I would open up an issue and reference this one if that's okay with you." My point is that feld felt a little ignored in their problem, and the support role could have handled it a little nicer. I get that maintainer time is limited, but I would probably recommend an issue template for these matters where there's checkboxes in them like "keep it short, keep it reproducible" and maybe a separate issue template and tag for RFC matters. On the other hand, "feld"'s blog post reaction was also quite trigger happy and in part in bad faith. They could've communicated the same things in a "non rage mode" after things have calmed down a bit.

YZF 8mo ago

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 customer of a product, granted an open source one, and they've helped the vendor (the maintainer) figure out something is broken. Their expectation is that the vendor takes things on from there and doesn't put up some bureaucracy. That said ofcourse you paid nothing for this and you should expect nothing but the OSS project also has no expectations that their customers support them if those customers aren't getting their expectations met. In today's world one unhappy customer can give you a pretty bad rep, as is happening here. Now if you don't care then you don't care. But the argument that because your product is "free" then your customers have no voice doesn't sound that great either. Everyone seems to be pointing how the author disappeared and came back much later. Well, they disappeared because it wasn't a problem or they've worked around it, and came back when they hit the problem again. Just like the maintainer doesn't work for the author the author doesn't work for the maintainer either. It's also true the ticket now has a lot of history, but the original bug is still the same bug, it's just that now it has been root caused? The maintainer's response of now that you've found a setting that works around the issue you're good and we can close this also is a bit off. And sure, they don't work for anyone so they're welcome to do whatever they want. As isn't uncommon when two humans communicate online there is some miscommunication here. But you can argue either way. Not being an open source maintainer I don't know what the "protocol" here is but the few times I've filed bugs against an open source product I did personally put in the extra mile to make them actionable. But in my day job I have to deal with all sorts of bug reports and chasing them down to a resolution is part of what makes the product I work on a better one. And yes, I get paid to do that ;)

johannes1234321 8mo ago
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.