[TacticalCoder]

Well... To me there are two very serious issues with typical packages for Linux (and I'm a long time and a die-hard Linux user, so I'm not criticizing Linux here).

One of them being that you typically must be root to install packages. This mean that if anyone manages to slip a backdoor in any moderately used package, it probably means "root" on many Linux systems.

Some people have been complaining about that for years. Thankfully we're now beginning to see things like "functional package managers", where packages can not only be installed without admin rights but can also be "reverted" back to exactly the same "pre-package-installation" state if wanted.

The other very serious issue is that most package builds are not deterministic. I think everybody should begin to take security very seriously into account and realize that deterministic are the first (and certainly not only) step to take towards software which can be trusted a bit more.

There are thankfully quite some people who are now taking the deterministic builds route and one day we should, at last, be able to create the exact same package on different architectures and cross-check that we've got the same results. This won't help with backdoors already present in the source code but it's already going to be a huge step forward.

So, yup, I take it that, of course, as a packager you know how to pwn all your users.

As a user I wish we had a) deterministic builds, b) functional package managers, c) packages which can be installed without being root.

If we had that, there would be less ways to pwn all the users of one package at once. I'm a Debian user since forever (and I love the rock-stable Debian distro) and I'm not expecting Debian and other big distros to move to such a scheme anytime soon (it's probably too complicated) but there may be a real opportunity here for newer distros who'd want to focus on security.

[deathanatos]

> One of them being that you typically must be root to install packages.

  ./configure --prefix=$HOME/opt/$pkgname && make && make install

It's not pretty, I'll admit, and package managers could probably help here, if they're building from source.

> but can also be "reverted" back to exactly the same "pre-package-installation" state if wanted.

For system-wide packages, most package managers do support this. Since they don't support user-only packages, of course reverting an install isn't going to happen.

If you've installed it yourself, `rm -rf $HOME/opt/$pkgname`.

> The other very serious issue is that most package builds are not deterministic.

Deterministic builds are hard.

> be able to create the exact same package on different architectures and cross-check that we've got the same results

Unless you're cross-compiling, different architectures by definition nets you different builds. Even within an architecture, differences in feature sets (take advantage of Intel's shiniest instruction?) and compile time options (use this library?), where to install, etc. cause the number of possible build combinations to multiply quickly. Binary distros like Debian have it a bit easier, as they usually distribute a lowest-common-denominator binary with all features, but some distributions (I'm a Gentoo user) let you tune the system more.

Even if you had all the things you name, you still have to trust whomever is packaging your software. Or build it yourself after reading the entire source. (And then there's the chicken-and-egg problem with the compiler.)

[Dylan16807]

Manual builds work fine for some programs, but when you have to have a dozen dependencies that now also have to be built manually, and those have their own dependencies...

[e12e]

Just a quick note for those following along at home, I recommend having a look at xstow for managing custom package(trees). Basically it's:

    mkdir ~/opt/xstow
    cd /tmp
    # get package (verify signature)
    cd package
    ./cofigure --prefix=$HOME/opt
    make
    make install prefix=$HOME/opt/xstow/package-version
    cd ~/opt/xstow
    xstow package-version # xstow -D to "uninstall"

I find that helps a lot when you need to install new versions, and don't want to worry about cruft left over -- and also simplifies handling of PATH, MANPATH, LD_LIBRARY_PATH and LD_RUN_PATH.

Some packages are a little harder, but can sometimes be tricked to behave by moving ~/opt/xstow out of the way, doing a make install and then moving ~/opt to ~/opt/xstow/package-version-etc and xstow'ing.

[e12e]

That's: http://xstow.sourceforge.net/

[peterwwillis]

> The other very serious issue is that most package builds are not deterministic.

It's virtually impossible to create deterministic builds of common software. There's random sources of data and variables all over the place. And more importantly, deterministic software != secure software. You could make a perfectly deterministic piece of code, compile it, run it, all the same on all hosts. It can still be rife with security holes.

I don't know what you mean by 'functional package managers'. There's plenty of 'functional' package management software out there used by millions of people every day. If you just mean easier to use, there's that too.

You can already install software without being root, very easily in fact. It just won't work very well because a lot of software is designed to operate with varying levels of user and group permissions, and varying system capabilities. And again, more importantly, there are plenty of privilege escalation exploits released all the time that could get to root from your user. Malware doesn't even need to be root if all it wants is control over your browser sessions or to siphon off your data. Root-installed software is as big a deal to a single user system as a vuln in your copy of Adobe Flash.

[TacticalCoder]

> It's virtually impossible to create deterministic builds of common software.

Nope, it's definitely not. If projects like Tor and Mozilla (they're working on it) can do it, then the 99.99% of packages out there which are less complicated than Tor / Mozilla can do it too.

> It can still be rife with security holes.

You're just rewriting what I wrote: I didn't said it would mean the software would be secure. I wrote it would already be a huge step forward.

> "I don't know what you mean by 'functional package managers'."

I mean for example this:

nixos.org

> Root-installed software is as big a deal to a single user system as a vuln in your copy of Adobe Flash.

Definitely not. Especially in a system like Linux where it's easy to have multiple user accounts (including one used just for surfing). I'm a "single user" and I do have several user accounts on a single machine (including a user account which I use only for surfing the Web). No Adobe Flash here btw and no Java applets either (I'm a dev and I do typically target the JVM, but there's no way I'm allowing Java applets in a browser) ^ ^

You say: "deterministic builds cannot be done", "there's no point in having deterministic builds because there could still be security holes", "local exploit is as bad as root exploit on a single-user machine"...

And I disagree with all that. And thankfully there are people disagreeing with you too and working on tomorrow's software packaging/delivery methods.

I thank Tor, for example, for showing us the way. The mindset really need to change from: "it cannot be done, it's too complicated" to "we can do it, let's follow the lead of the software projects showing the way". There's a very real benefit for users.

The "why":

https://blog.torproject.org/blog/deterministic-builds-part-o...

The "how":

https://blog.torproject.org/blog/deterministic-builds-part-t...

Honestly I simply cannot understand why there are still people arguing that deterministic builds aren't a good thing or people arguing that it cannot be done.

It can be done. And it's a good thing.