• Bene7rddso@feddit.de
    link
    fedilink
    arrow-up
    8
    arrow-down
    3
    ·
    9 months ago

    It’s an experimental feature. It doesn’t need a bugfix release because you’re not supposed to run it in production, and it’s just a DoS, not privilege escalation or something

    • ysjet@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      5
      ·
      9 months ago

      Experimental features are explicitly defined as requiring CVEs. You are supposed to run them in production, that’s why they’re available as expiermental features and not on a development branch somewhere. You’re just supposed to run them carefully, and examine what they’re doing, so they can move out of experiment into mainline.

      And that requires knowledge about any vulnerabilities, hence why it’s required to assigned CVEs to experimental features.

      And I’m not sure why you think a DoS isn’t a vulnerability, that’s literally one of the most classic CVEs there are. A DoS is much, much more severe than a DDoS.

      • Bene7rddso@feddit.de
        link
        fedilink
        arrow-up
        2
        ·
        9 months ago

        If you do examine what it’s doing you will catch this as soon as an attacker exploits it, and can disable it. Also, you should maybe not run the entire production with experimental features enabled. In a stable feature this would absolutely be a CVE, but this is marked experimental because it might not work right or even crash, like here

        • ysjet@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          9 months ago

          Correct, I agree you run it with an eye on it (which you should probably do anyway) instead of firing and forgetting (which, to nginx’s credit, is typically stable enough you can do that just fine).

          That said, nginx treats experimental as something you explicitly run in production- when they announced they added it into experimental they actually specifically say to run it in prod in an A/B setup.

          https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/

          • Bene7rddso@feddit.de
            link
            fedilink
            arrow-up
            2
            ·
            9 months ago

            If you run large‑scale Internet services,

            That means if you’re large enough that A can pick up the slack if B shits the bed. The only impact would be that you have to use HTTP2

      • ieatpillowtags
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        9 months ago

        You’re completely full of shit, as it’s just simply not the case that you’re “supposed” to run experimental features in production. But run it carefully??? What does that even mean? You obviously have zero experience on either side of the equation.

        • ysjet@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          9 months ago

          Nnnnnot really? Nginx literally asks for people to do that. Here they are announcing that experimental QUIC/HTTP3 support: https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/

          You’ll notice they literally outright ask

          • If you run large‑scale Internet services, experiment with A/B testing by deploying nginx-quic for some users or some services.

          They literally ask for you to try it in production, so… yeah, you’re supposed to use this experimental feature in prod. As for ‘run it carefully’, just that- don’t just fire it off and assume all is good, keep an eye on it like the say. A/B deploy it, see how it works, and let NGINX know if you happen to run into anything.