Announcement

Collapse
No announcement yet.

FreeBSD Re-Introduces WireGuard Support Into Its Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FreeBSD Re-Introduces WireGuard Support Into Its Kernel

    Phoronix: FreeBSD Re-Introduces WireGuard Support Into Its Kernel

    Back in late 2020 FreeBSD initially landed WireGuard support ahead of FreeBSD 13. But then during the FreeBSD 13 release candidate phase, the WireGuard driver was removed over concerns over the quality of the initial implementation...

    https://www.phoronix.com/news/FreeBS...ard-Lands-2022

  • #2
    The wireguard debacle was what made me decide on OpenBSD vs FreeBSD, the fact that just because someone has a commit bit in FreeBSD they can introduce whatever code they want into the head of the OS is scarry with no peer review. I think they have wisely changed their policy now to include peer review but why it was lacking in the first place was scary enough.

    Comment


    • #3
      Originally posted by kylew77 View Post
      The wireguard debacle was what made me decide on OpenBSD vs FreeBSD, the fact that just because someone has a commit bit in FreeBSD they can introduce whatever code they want into the head of the OS is scarry with no peer review. I think they have wisely changed their policy now to include peer review but why it was lacking in the first place was scary enough.
      AFAIK OpenBSD has the same policy.

      Anyway, on topic, it's nice to see WG to become supported across more platforms. I think it's a vast improvement over status quo, but it's the kind of thing that is pretty much useless if it's not interoperable.

      Comment


      • #4
        Originally posted by kylew77 View Post
        The wireguard debacle was what made me decide on OpenBSD vs FreeBSD, the fact that just because someone has a commit bit in FreeBSD they can introduce whatever code they want into the head of the OS is scarry with no peer review. I think they have wisely changed their policy now to include peer review but why it was lacking in the first place was scary enough.
        There is no large project that has not had a developer make mistakes. Even when you have required code review by senior developers, there are still issues missed. For example, I have been finding regressions in OpenZFS that were missed despite its code review policy.

        Comment


        • #5
          Originally posted by sinepgib View Post
          AFAIK OpenBSD has the same policy.
          Some areas, but a lot that is not the case. But what happened with FreeBSD is more the exception than the norm for how things are handled.
          Last edited by brad0; 29 October 2022, 09:40 PM.

          Comment


          • #6
            Originally posted by ryao View Post

            There is no large project that has not had a developer make mistakes
            In FreeBSD case it was not a mistake, but a plain incompetence. If your project allows incompetent people implement security-related features (without review), it tells a lot about the project itself.

            Comment


            • #7
              Originally posted by ryao View Post

              There is no large project that has not had a developer make mistakes. Even when you have required code review by senior developers, there are still issues missed. For example, I have been finding regressions in OpenZFS that were missed despite its code review policy.
              the point of having peer review is reducing the chance of issues, so even if not 100% perfect it's definitely a lot better than not having it

              not to mention it is ultimately peer review that keeps malicious actors from gaining trust and sending security holes upstream (which that irresponsible american university proved beyond doubt is not an unreal threat model for big opensource projects)

              Comment


              • #8
                I love artist impressions of FreeBSD
                freebsd-beastie-this-is-fine.jpg

                Comment


                • #9
                  Originally posted by marlock View Post

                  the point of having peer review is reducing the chance of issues, so even if not 100% perfect it's definitely a lot better than not having it

                  not to mention it is ultimately peer review that keeps malicious actors from gaining trust and sending security holes upstream (which that irresponsible american university proved beyond doubt is not an unreal threat model for big opensource projects)
                  Only if peer review actually happens outside of an echo chamber. This is why open source (as in freely viewable, not the OSI TM) exists. It removes the echo chamber effect of insular project management and limited direct contributer attention due to interest or lack of time. The Wire Guard removal is the system working as designed to catch and remove mistakes like this.

                  Comment


                  • #10
                    Originally posted by stormcrow View Post

                    Only if peer review actually happens outside of an echo chamber. This is why open source (as in freely viewable, not the OSI TM) exists. It removes the echo chamber effect of insular project management and limited direct contributer attention due to interest or lack of time. The Wire Guard removal is the system working as designed to catch and remove mistakes like this.
                    I could argue that even a 2nd pair of eyes from inside the same echo chamber is better than none, at least to catch silly mistakes...

                    ...but i imagine it can also lead to a false sense of security with regards to broader logical flaws (which seems to be what this removal was about) and I have no idea how those things balance out in practice...

                    obviously having a robust peer-review process is best, but do BSD projects even have that many eyes available in a steady manner like linux does? (actually a question)

                    Comment

                    Working...
                    X