Announcement

Collapse
No announcement yet.

FreeBSD 14.1 Bringing Reproducibly Built Kernels, OpenZFS 2.2.4

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

  • FreeBSD 14.1 Bringing Reproducibly Built Kernels, OpenZFS 2.2.4

    Phoronix: FreeBSD 14.1 Bringing Reproducibly Built Kernels, OpenZFS 2.2.4

    Following last week's release of FreeBSD 14.1 Beta 1, this weekend brought the second beta candidate right on time...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why are reproducible builds so important? How does it improve security?

    Comment


    • #3
      Originally posted by kylew77 View Post
      Why are reproducible builds so important? How does it improve security?
      If something is actually reproducable you can ensure that what you are getting is actually what you think your getting and not something that was modified by for example the packager during their build without it being documented (think xz but by the packager).

      Comment


      • #4
        While NetBSD in 2017 https://blog.netbsd.org/tnf/entry/ne...ducible_builds

        Comment


        • #5
          Originally posted by kylew77 View Post
          Why are reproducible builds so important? How does it improve security?
          It allows you to verify that the binaries you are running were actually built from a given source code and don't contain some "secret" modifications.

          Comment


          • #6
            That actually looks like a nice release.

            Comment


            • #7
              Originally posted by jacob View Post
              That actually looks like a nice release.
              Assuming the WiFi Stack gets better in this one. Buggy drivers and WiFi g speeds don't sit well, but they have invested a lot of money in fixing this issue!

              Comment


              • #8
                Originally posted by NekkoDroid View Post

                If something is actually reproducable you can ensure that what you are getting is actually what you think your getting and not something that was modified by for example the packager during their build without it being documented (think xz but by the packager).
                Thanks for that. In a post xz attack world, I see why that is needed!

                Comment


                • #9
                  Originally posted by kylew77 View Post

                  Assuming the WiFi Stack gets better in this one. Buggy drivers and WiFi g speeds don't sit well, but they have invested a lot of money in fixing this issue!
                  WiFi has always been Kryptonite to FreeBSD.

                  Comment


                  • #10
                    Originally posted by kylew77 View Post

                    Thanks for that. In a post xz attack world, I see why that is needed!
                    Better security is a happy coincidence. There's a lot of semi-random data that can change enough things to skew checksums, think time stamps, build directory location, and user names, so that if you and I both built the same kernel from the same sources with the same config we'd get different checksums and, technically speaking, different results. By feeding in a specific reproduction config all that semi-random becomes fixed so we all know we've built the same thing and if we don't get the same thing then there could be an issue with the compiler, linker, hardware, or any other number of things that may or may not be security related. It'll probably make parsing logs easier, too, like when someone with a 22 character username and a build directory located 15 folders deep posts something.

                    Comment

                    Working...
                    X