• SpacePirate@lemmy.ml
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    10 months ago

    From my understanding, the impetus was that F5 submitted a CVE for a vulnerability, for an optional, “beta” feature that can be enabled. Dounin did not think a CVE should be submitted, since he did not considered it to be “production” feature.

    That said, the vulnerability is in shipping code, regardless of whether it is optional or not, so per industry coding practices, it should either be patched or removed entirely in order to resolve the issue.

    • biscuitswalrus@aussie.zone
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      10 months ago

      The messaging around this so far doesn’t lead me to want to follow the fork on production. As a sysadmin I’m not rushing out to swap my reverse proxy.

      The problem is I’m speculating but it seems like the developer was only continuing to develop under condition that they continued control over the nginx decision making.

      So currently it looks like from a user of nginx, the cve registration is protecting me with open communication. From a security aspect, a security researcher probably needs that cve to count as a bug bounty.

      From the developers perspective, f5 broke the pact of decision control being with the developer. But for me, I would rather it be registered and I’m informed even if I know my configuration doesn’t use it.

      Again, assuming a lot here. But I agree with f5. That feature even beta could be in a dev or test environment. That’s enough reason to know.

      Edit:Long term, I don’t know where I’ll land. Personally I’d rather be with the developer, except I need to trust that the solution is open not in source, but in communication. It’s a weird situation.

      • Kogasa@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        10 months ago

        Frivolous CVEs aren’t a good thing for security. This bug was a possible DOS (not e.g. a privilege escalation) in a disabled-by-default experimental feature. It wasn’t a security issue and should have been fixed with a patch instead of raising a false alarm and damaging trust.

        • surewhynotlem@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          10 months ago

          It is WAY better to over report than under report. I don’t want vendors to have a lot of ability to say “nope that’s not a security problem, sweep it under the rug”.

              • Kogasa@programming.dev
                link
                fedilink
                English
                arrow-up
                0
                ·
                10 months ago

                “What if the boy who cried wolf got lucky and didn’t get eaten in the end”? Seems to have missed the point of the parable a bit.

                • SexyVetra@lemmy.world
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  10 months ago

                  “A liar who lies repeatedly won’t be believed” is definitely equivalent to “A company conservatively warned that one of their products was dangerous in some specific situations.”

                  Hanging out with you sounds really fun.

                  • Kogasa@programming.dev
                    link
                    fedilink
                    English
                    arrow-up
                    0
                    ·
                    10 months ago

                    That’s… not the point either. The point is that “reporting false positives isn’t a bad thing” is only true up to a point. The discussion is then “is this before or after that point.” Which, given the context of the bug, isn’t really a given. But I don’t want to have that discussion with you anymore because you’re annoying.