Is there some reason "freebsd.org" and all it's subdomains don't immediately 302 over to https foreverafter? Same goes for use of svn, which has no native signable hashed commit graph, as freebsd's canonical repo... instead of git which does. Not to mention the irreproducible builds / pkgs / ISO's. These days these flaws are more than a bit ridiculous, especially for an OS, which by definition [excepting the hardware] should be your root of trust. Can we get a wiki project page and some traction on this? Thanks.
On Thu, 17 Sep 2015, grarpamp wrote:> Is there some reason "freebsd.org" and all it's > subdomains don't immediately 302 over to > https foreverafter?Is there a reason to encrypt something that is completely public? Perhaps to allow the visitor to conceal the fact that they are interested in FreeBSD? That won't work, since the IP address of the server can't be encrypted. I feel like I am missing something. dan feenberg
On Thu, Sep 17, 2015, at 22:20, grarpamp wrote:> Is there some reason "freebsd.org" and all it's > subdomains don't immediately 302 over to > https foreverafter? >What good does https on freebsd.org provide except checking a box that some people are obsessed about right now? You're adding another layer of complexity. The front page, documentation, handbooks, etc are not sensitive data. There are two different opinions on this matter throughout the project: * Encrypt all the things * Encrypt what is necessary If FreeBSD is visibly penalized by Google in the future for not hosting on https it might be worth doing.> Same goes for use of svn, which has no native > signable hashed commit graph, as freebsd's > canonical repo... instead of git which does. >svn is available over https> Not to mention the irreproducible builds / pkgs / ISO's. >Nobody is doing this successfully yet. Last I checked Debian is closest. But keep in mind this is not a security feature, it's debugging feature. You still need to solve backdoored compilers ("use this new double compiler method!" OK...) and then you need to solve backdoored hardware.> These days these flaws are more than a bit ridiculous, > especially for an OS, which by definition [excepting > the hardware] should be your root of trust. > > Can we get a wiki project page and some traction on this? > Thanks. >https://wiki.freebsd.org/ReproducibleBuilds -- Mark Felder ports-secteam member feld at FreeBSD.org
grarpamp <grarpamp at gmail.com> writes:> Not to mention the irreproducible builds / pkgs / ISO's.The base system build is 99% reproducible. ISOs should be reproducible as well, modulo timestamps. Reproducible packages are extremely difficult to get right. Baptiste spent a lot of time and effort trying to get them to work before the official switch to pkgng. Many packages compile the build host's name and / or the current date and time into various binaries. Python stores the timestamp of the original .py file into the .pyc file and will attempt to recompile it if that timestamp does not match or the .py file's mtime is equal to or greater than the .pyc file's mtime. Emacs does similar shenanigans with .el and .elc files.> These days these flaws are more than a bit ridiculous,You seem to be implying that everybody else is doing it except us. This is not true. Debian and Fedora are or have been working on it but with no success to date.> Can we get a wiki project page and some traction on this?https://wiki.freebsd.org/ReproducibleBuilds https://wiki.freebsd.org/PortsReproducibleBuilds Are you volunteering? DES -- Dag-Erling Sm?rgrav - des at des.no