The modern packager’s security nightmare • Hacker News Board

Re: The modern packager’s security nightmare

#251

Post by ece » Mon, Feb 22, 2021, 12:49 PM UTC

orra wrote: post #243

ece wrote: post #219

Earlier quoted context omitted.

There are scripts and daemons that help you determine what needs restarting[1,2]. NixOS installs can go in separate directory prefixes when there are conflicts. For Gentoo and other Linux distributions, maintainers usually won't mark something stable without resolving conflicts, and this usually means sticking to older stable version of libraries until newer versions of libraries are fully supported by all installed…

Thanks, checkrestart looks useful. I wasn't aware of it. Given that it's in a goodies package though, I assume it's not integrated with apt—at least by default. I'm thinking of that apt prompt that says "There are services installed on your system which need to be restarted when certain libraries, such as libpam, libc, and libssl, are upgraded." I presume then that uses a hardcoded list of important services.

I can't help with checkrestart or apt questions, but if I can plug 'needrestart -r a': it restarts services, messages outdated shells/user logins and checks for newer kernels/microcode. It will also tell you if any interpreters/containers need restarting, but YMMV here. It's never blown up for me even when restarting boot services, and should work on any distro as far as I can tell. I use it on Gentoo.

Re: The modern packager’s security nightmare

#252

Post by IshKebab » Mon, Feb 22, 2021, 1:46 PM UTC

UncleEntity wrote: post #106

IshKebab wrote: post #18

This article doesn't make a good case against static linking, and the author doesn't seem to understand what vendoring is either: > Bundling (often called vendoring in newspeak) means including the dependencies of your program along with it. No, vendoring means including a copy of the source code of dependencies in your repo. You can bundle dependencies without vendoring them. The only argument presented against stat…

> The only argument presented against static linking is that when a library is updated rebuilding dependants takes longer (and people will have to download bigger updates but I doubt many people care about that). Not really, the argument is that instead of rebuilding one library you now have to rebuild hundreds of applications to see the benefits for whatever the library update was for...assuming upstream even cares…

Right but that can be done automatically for static linking just as easily as it can for dynamic linking. So the only difference is time and downloads.

I think you're conflating static linking and bundling and vendoring a bit, like the author is. They're all different things.

Re: The modern packager’s security nightmare

#253

Post by symlinkk » Mon, Feb 22, 2021, 2:53 PM UTC

Foxboron wrote: post #209

alfiedotwtf wrote: post #203

Earlier quoted context omitted.

> We still deal with security issues I don’t see your point. In fact, you’ll most likely find that distros that follow upstream closer than “slow and stable releases” will get their patches as soon as upstream fixes them

This assumes an ideal upstream: This is not always the case. If someone publishes a CVE for a Go or Rust library it's not always the case the project is well maintained or the dev cares to update the dependency. Even if they did, there are no guarantees the upstream decides to publish a minor release just to update dependencies. Because that is what vendoring dependencies get you. Instead of applying one patch to a s…

If upstream is not keeping their software up to date, why are you using that software? Imagine if Google stopped updating Chrome. Would you keep using Chrome?

Re: The modern packager’s security nightmare

#254

Post by folkrav » Mon, Feb 22, 2021, 2:56 PM UTC

progval wrote: post #222

mixedCase wrote: post #12

Yeah well, who's hungry? No really, neither users nor developers care, nor should they. I've been using Linux on the desktop for well over a decade and I'm tired of seeing this plea for everything to behave exactly like C or scripting languages because every distro wants to be its own special snowflake and it would be too hard to adapt. The world has changed and distros have to stop pretending it hasn't. Flatpak, Nix…

> I'm tired of seeing this plea for everything to behave exactly like C or scripting languages because every distro wants to be its own special snowflake and it would be too hard to adapt. The same argument can be used the other way around: "I'm tired of seeing this plea for everything to behave exactly like Docker or static .exe because every software wants to be its own special snowflake and it would be too hard to…

This is quite literally the exact opposite of software wanting to be its own special snowflake, so not sure spinning the argument around really works.

Re: The modern packager’s security nightmare

#255

Post by symlinkk » Mon, Feb 22, 2021, 3:10 PM UTC

posix_me_less wrote: post #19

Here is the solution to this Debian/Gentoo/ packager's dilemma. Packagers realize that their numbers are small and they can't keep up fixing all the modern big software (BS) projects that go against their philosophy. They define the core of the OS that they can keep managing in this traditional way (kernel, basic userland, basic desktop, basic server services, basic libraries, security support for all that). "But peo…

Agreed, and this is basically the model that macOS / Windows have followed since the dawn of time.

Re: The modern packager’s security nightmare

#256

Post by pdonis » Mon, Feb 22, 2021, 4:22 PM UTC

lmm wrote: post #199

pdonis wrote: post #175

Earlier quoted context omitted.

>I disagree, it's proven to be inadequate for modern software development You're not disgreeing with the post you responded to; you're just stating a different priority. hctaw said the distro/maintainer/pm approach is extremely reliable at producing trustworthy software . That means trustworthy to the user . It says nothing at all about how hard producing that software is for the developer. You are saying that the di…

> And anyway, as a user, I don't care. I want my software to work, to be stable, and to not have security flaws; and if a security flaw is found, I want a fix to be pushed to me ASAP. The distro/maintainer/pm approach does that. Not my experience at all. The distro maintainer generally takes significantly longer to push out a fix than the upstream developer.

> The distro maintainer generally takes significantly longer to push out a fix than the upstream developer.

Of course this is true in a sense, because the distro maintainer has to wait for upstream to push a fix before they can package it.

However, for the upstream developer, "pushing a fix" means "pushing updated source code". For the distro maintainer, "pushing a fix" means "compiling the updated source code and packaging the resulting binaries for all supported versions".

There are some upstream developers who could probably accomplish the latter at least as fast as distros do, but not many. But the latter is what I, as a user, need.

Re: The modern packager’s security nightmare

#257

Post by zlynx » Mon, Feb 22, 2021, 5:16 PM UTC

dataflow wrote: post #33

Why do only *nix folks pull their hair out about this? On Windows programs bundle their dependencies all the time (sometimes even as shared libraries! but without the independent update benefits) and hardly anybody loses sleep over it. Heck, users actually like the fact that it minimizes friction. Nobody claims it's rock-solid security, but does it need to be? Actually, now that I wrote it above, I think I might have…

Windows also has 20 years of horrible hacks where the DLL loader will intercept or binary patch old, buggy copies of bundled libraries.

Re: The modern packager’s security nightmare

#258

Post by zrm » Mon, Feb 22, 2021, 5:20 PM UTC

josephg wrote: post #237

zrm wrote: post #170

Earlier quoted context omitted.

> This worked in a world when there wasn't much software, when releases were rare and when most programs only had one or two dependencies. None of these properties are true any more. I don't think this is even the problem. It's that upstream maintainers have stopped worrying about compatibility. Once upon a time you would have regular minor releases of some package. 3.0.2, 3.0.3, 3.0.4, but they were all backwards co…

Interesting - I didn’t know that. Can you give some examples?

https://wiki.openssl.org/index.php/Versioning

https://developer.gnome.org/gtk3/stable/gtk3-Feature-Test-Ma...

https://everything.curl.dev/libcurl/api

Re: The modern packager’s security nightmare

#259

Post by Foxboron » Mon, Feb 22, 2021, 5:21 PM UTC

symlinkk wrote: post #253

Foxboron wrote: post #209

Earlier quoted context omitted.

This assumes an ideal upstream: This is not always the case. If someone publishes a CVE for a Go or Rust library it's not always the case the project is well maintained or the dev cares to update the dependency. Even if they did, there are no guarantees the upstream decides to publish a minor release just to update dependencies. Because that is what vendoring dependencies get you. Instead of applying one patch to a s…

If upstream is not keeping their software up to date, why are you using that software? Imagine if Google stopped updating Chrome. Would you keep using Chrome?

Traditionally package maintainers has kept dependencies up to date. This has changed with vendored dependencies where upstreams have to do the work. They are not always up for that work. This isn't strange, nor weird and the comparison to chrome and google doesn't make much sense.

Re: The modern packager’s security nightmare

#260

Post by zrm » Mon, Feb 22, 2021, 6:35 PM UTC

rictic wrote: post #247

zrm wrote: post #176

Earlier quoted context omitted.

> you're able to find the first commit that introduced the issue in O(log(commits)) time, rather than needing O(commits * (num dependencies * dependency versions)) time. Try the oldest and newest compatible version of your code and the oldest and newest compatible version of each dependency. This is O(num dependencies), which is generally small N and you can often guess which to try first. Now do each version of the…

While version 3 of the dependency is innocent, commit 5678 is not. Something went wrong in the interaction between the code and its dependencies in that change and discovering that change quickly is valuable. From there you can start stepping through the code, or simplifying the situation to get a minimal repro of what's going on, or even bisecting with dependency version 3 held constant to see if that's diagnostic.…

> While version 3 of the dependency is innocent, commit 5678 is not. Something went wrong in the interaction between the code and its dependencies in that change and discovering that change quickly is valuable.

The trouble is that this will tend to point the finger at large changes that jostle many things around at once and become a rabbit hole rather than the two line commit with a typo that actually caused the problem.

The main advantage you're putting forth is to know the versions of each dependency needed to reproduce the problem. But you can get that from the person reporting the bug. You can add a switch to your software to output the versions of every dependency it's using and then it's there in the bug report. And once you have a combination that can reproduce the bug, the process of experimenting with things to identify the cause is basically the same either way.