FreeBSD 14.1 Bringing Reproducibly Built Kernels, OpenZFS 2.2.4

[phoronix]

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...

https://www.phoronix.com/news/FreeBSD-14.1-Beta-2-Released

[kylew77]

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

[NekkoDroid]

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).

[jaypatelani]

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

[jacob]

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.

[jacob]

That actually looks like a nice release.

[kylew77]

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!

[kylew77]

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!

[jacob]

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.

[skeevy420]

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.