Announcement

Collapse
No announcement yet.

BoringTun v0.4 Released For CloudFlare's Rust-Based WireGuard

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

  • BoringTun v0.4 Released For CloudFlare's Rust-Based WireGuard

    Phoronix: BoringTun v0.4 Released For CloudFlare's Rust-Based WireGuard

    Back in 2019 the folks at CloudFlare announced BoringTun as a Rust-written WireGuard user-space implementation. Yesterday marked the first tagged release of BoringTun in the form of version 0.4...

    https://www.phoronix.com/scan.php?pa...n-0.4-Released

  • #2
    I fail to see the point. Simply rewriting in a different language is not a plus on its own. They might as well could've sent patches for the things they want to achieve.

    Comment


    • #3
      Originally posted by anarki2 View Post
      I fail to see the point. Simply rewriting in a different language is not a plus on its own. They might as well could've sent patches for the things they want to achieve.
      You are missing a lot of context, it's not just about the language, refer to https://blog.cloudflare.com/boringtu...ireguard-rust/

      Comment


      • #4
        Cue the posts pointing out how Rust is going nowhere

        Comment


        • #5
          Originally posted by anarki2 View Post
          I fail to see the point. Simply rewriting in a different language is not a plus on its own.
          It's a well established fact that about 70% of all high- and critical-severity security vulnerabilities are the result of memory unsafety, that would have been avoided had software been written in a memory-safe language. The world's most well funded development team working on Google Chrome have acknowledged that security critical parts of it need to be rewritten in a memory-safe language.

          Anyone who still fails to see the value of rewriting in rust are choosing blindness. The only reason the whole industry isn't migrating to memory-safe languages now that it's possible for pretty much every use-case is the sheer amount of work, not the lack of value. Starting to write new security-critical software in an unsafe language today would be reckless negligence.

          Comment


          • #6
            Originally posted by jntesteves View Post

            It's a well established fact that about 70% of all high- and critical-severity security vulnerabilities are the result of memory unsafety, that would have been avoided had software been written in a memory-safe language. The world's most well funded development team working on Google Chrome have acknowledged that security critical parts of it need to be rewritten in a memory-safe language.

            Anyone who still fails to see the value of rewriting in rust are choosing blindness. The only reason the whole industry isn't migrating to memory-safe languages now that it's possible for pretty much every use-case is the sheer amount of work, not the lack of value. Starting to write new security-critical software in an unsafe language today would be reckless negligence.
            In a way, this is similar to garbage collection: sure you can collect your garbage in C, but who has really mastered that art? The difference would be that, unlike a garbage collector, compiler enforced correctness/memory safety comes with zero overhead. A win-win if there ever was one.

            Comment


            • #7
              Originally posted by jntesteves View Post
              The only reason the whole industry isn't migrating to memory-safe languages now that it's possible for pretty much every use-case is the sheer amount of work, not the lack of value.
              And going between language boundaries (i.e bindings between C and Rust) also introduce a number of potential memory / security vulnerabilities. In many cases you completely lose type safety.

              Comment


              • #8
                Originally posted by kpedersen View Post

                And going between language boundaries (i.e bindings between C and Rust) also introduce a number of potential memory / security vulnerabilities. In many cases you completely lose type safety.
                Do you have an example of C <-> Rust language binding causing security issues that wasn't otherwise an inherent security vulnerability?

                In any case, that doesn't seem to apply here, BoringTun is a pure Rust implementation although it does offer bindings to be called from C which itself is safe to do.

                Comment


                • #9
                  Originally posted by jntesteves View Post
                  Anyone who still fails to see the value of rewriting in rust are choosing blindness. The only reason the whole industry isn't migrating to memory-safe languages now that it's possible for pretty much every use-case is the sheer amount of work, not the lack of value. Starting to write new security-critical software in an unsafe language today would be reckless negligence.
                  I really don't see this as a matter of having to migrate everything. But kids learning to program these days now have a choice of C or Rust. This is what will change the landscape 20 years down the road.

                  Comment


                  • #10
                    Originally posted by RahulSundaram View Post
                    Do you have an example of C <-> Rust language binding causing security issues that wasn't otherwise an inherent security vulnerability?
                    Binding to C code is why unsafe was introduced in the first place. And probably the only place t should ever be used.

                    Comment

                    Working...
                    X