Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The modern packager’s security nightmare

blogs.gentoo.org

Post reply on HN
Print view View original

191–200 of 282 posts

Re: The modern packager’s security nightmare

#191

Post by pdonis »

secabeen wrote: post #189
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. If instead I have umpteen zillion different statically linked applications installed, each of which packages all of its own dependencies, then instead of just relying on my distro to push sec…

As a user, my response is simple: I don't use software that's built that way. Outside of code that I write myself, I simply refuse to use software that's not accompanied by a distribution and maintenance infrastructure that I trust. For most software, that means it's packaged by my distro. Some big players might be able to convince me to take their software from them directly, but they will be very few, because there are very few big players that are as reliable as my distro, and that's the standard they have to meet.

Re: The modern packager’s security nightmare

#192

Post by jjav »

hctaw wrote: post #42
bscphil wrote: post #13

Over the last several weeks I was working on an essay about this exact problem, including the connection between static linking and bundling. This one is so well done that I probably won't even publish it. But I'll add this, for people who may not immediately see why this is important. I think that the real danger these new technologies represent is not inherently bad technology, but the possibility of ecosystem dama…

> The distribution / maintainer / package manager approach has proven to be an extremely reliable way to get trustworthy software. Many of us love it and want to see it stick around. I disagree, it's proven to be inadequate for modern software development and that's why these new languages/ecosystems are springing up. The least reliable way to package and distribute software is by relying on traditional package manag…

> The least reliable way to package and distribute software is by relying on traditional package managers.

Checks and balances produce reliability. Having a packaging process and people distinct from the code author validating and enforcing it, most certainly produces much more reliable, secure and stable packages and distributions.

Sure, it's slower. Slower is actually a feature in this use case.

Having anyone push out their code to the world without any constraints or care, breaking compatibility day to day, that is certainly faster and easier. But reliable, certainly not. This is the culture that produces leftpad debacle and assorted malicious packages regularly.

Re: The modern packager’s security nightmare

#193

Post by secabeen »

pdonis wrote: post #191
secabeen wrote: post #189

Earlier quoted context omitted.

> 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. If instead I have umpteen zillion different statically linked applications installed, each of which packages all of its own dependencies, then instead of just relying on my distro to push sec…

As a user, my response is simple: I don't use software that's built that way. Outside of code that I write myself, I simply refuse to use software that's not accompanied by a distribution and maintenance infrastructure that I trust. For most software, that means it's packaged by my distro. Some big players might be able to convince me to take their software from them directly, but they will be very few, because there…

> Outside of code that I write myself, I simply refuse to use software that's not accompanied by a distribution and maintenance infrastructure that I trust. For most software, that means it's packaged by my distro.

Okay, that's a reasonable approach, but with distros essentially saying for new software, they can't continue to maintain that standard, and they're just taking software as it comes, without securing it. I think you will find that there are lots of small utility programs and libraries that you won't have available to you in 10 years with this approach. YMMV.

Re: The modern packager’s security nightmare

#194

Post by pdonis »

secabeen wrote: post #193
pdonis wrote: post #191

Earlier quoted context omitted.

As a user, my response is simple: I don't use software that's built that way. Outside of code that I write myself, I simply refuse to use software that's not accompanied by a distribution and maintenance infrastructure that I trust. For most software, that means it's packaged by my distro. Some big players might be able to convince me to take their software from them directly, but they will be very few, because there…

> Outside of code that I write myself, I simply refuse to use software that's not accompanied by a distribution and maintenance infrastructure that I trust. For most software, that means it's packaged by my distro. Okay, that's a reasonable approach, but with distros essentially saying for new software, they can't continue to maintain that standard, and they're just taking software as it comes, without securing it. I…

> I think you will find that there are lots of small utility programs and libraries that you won't have available to you in 10 years with this approach.

Then I'll either find an alternate source that has enough reliability to satisfy me, or write them myself, or do without.

(Or I'll end up building what amounts to my own distro. Which is something I have indeed thought of doing, because my preferences are rather idiosyncratic.)

Re: The modern packager’s security nightmare

#195

Post by mands »

mwcampbell wrote: post #113
jauer wrote: post #58

Earlier quoted context omitted.

> Two different communities create two very different kinds of software, which run on the same systems, but are created and distributed in very different ways. This is where the disconnect is coming from. The distro maintainers are coming from a world of multi-user systems where backwards compatibility and updating deps without disturbing a user's workload / forcing them to recompile is paramount. Go (and a fair amou…

This makes me wonder if there's a Linux base system suitable for servers that embraces the newer approach. That is, a minimal base system that's built for immutable container images, providing just what's needed to bootstrap the current generation of language-specific build and package systems. The Alpine Linux Docker images might be a good choice for now, but IIUC, Alpine Linux itself still embraces the older distro…

Check out Fedora Silverblue for something along these lines.

Re: The modern packager’s security nightmare

#196

Post by mands »

1MachineElf wrote: post #180
orra wrote: post #77

Earlier quoted context omitted.

> I don't really buy that dynamic linking all the things is such a boon to security. Agreed. It's really not a panacea. When you upgrade a library, you probably want to restart the running applications that depend upon this. Dynamic linking won't save you. The solution is having a graph of your dependencies! IIRC, NixOS gets this right. I don't think Debian's apt did?

I would really like to know how NixOS solves this problem for things like yarn, webpack, parcel, esbuild, npm, pip, conda, cargo, stack, go modules, ruby gems, etc.

It's doesn't really, and that's the problem. There are automated tools and scripts to help, but there are always edge cases so that you end up going back to using pip for example.

Nix and language package managers just don't really play well together.

Re: The modern packager’s security nightmare

#197

Post by lmm »

ticviking wrote: post #85
hctaw wrote: post #74

Earlier quoted context omitted.

I'd disagree that the problem of large organizations are different from the problems of the FOSS ecosystem. Organizations just have a financial incentive to fix them, the FOSS ecosystem does not. If mutually incompatible dependencies and security updates breaking software weren't problems for both corporate and FOSS ecoystems, these new technologies wouldn't have needed to exist. They'd just use the existing platform…

> maintainers shouldn't place themselves in the development process. Then perhaps we as developers should spend more time thinking about and participating in the maintenance process?

Which is exactly what developers have done, and what this guy is complaining about: developers have figured out a different approach to maintenance that works better.

Re: The modern packager’s security nightmare

#198

Post by lmm »

bscphil wrote: post #86
hctaw wrote: post #74

Earlier quoted context omitted.

I'd disagree that the problem of large organizations are different from the problems of the FOSS ecosystem. Organizations just have a financial incentive to fix them, the FOSS ecosystem does not. If mutually incompatible dependencies and security updates breaking software weren't problems for both corporate and FOSS ecoystems, these new technologies wouldn't have needed to exist. They'd just use the existing platform…

> They should be cut out of the loop. I disagree. This is how you get the Google Play store or the "freeware" app marketplace. It sucks. As a user, I'm quite happy to continue using a traditional distribution even if it means I don't get to use a handful of flashy programs by developers that disagree with the concept of maintainers. So far that choice has been much more positive than negative for me, and I'm doing my…

> If you're creating open source software, they quite literally do! https://www.gnu.org/licenses/gpl-3.0.en.html

Clearly you missed the disclaimer of warranty in the licensing terms.

Packagers are welcome to maintain their own patches, or their own fork, if they like. But they don't have any right to tell upstream what to do or demand particular guarantees from upstream.

Re: The modern packager’s security nightmare

#199

Post by lmm »

pdonis wrote: post #175
hctaw wrote: post #42

Earlier quoted context omitted.

> The distribution / maintainer / package manager approach has proven to be an extremely reliable way to get trustworthy software. Many of us love it and want to see it stick around. I disagree, it's proven to be inadequate for modern software development and that's why these new languages/ecosystems are springing up. The least reliable way to package and distribute software is by relying on traditional package manag…

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

Re: The modern packager’s security nightmare

#200

Post by pjmlp »

jauer wrote: post #58
bscphil wrote: post #13

Over the last several weeks I was working on an essay about this exact problem, including the connection between static linking and bundling. This one is so well done that I probably won't even publish it. But I'll add this, for people who may not immediately see why this is important. I think that the real danger these new technologies represent is not inherently bad technology, but the possibility of ecosystem dama…

> Two different communities create two very different kinds of software, which run on the same systems, but are created and distributed in very different ways. This is where the disconnect is coming from. The distro maintainers are coming from a world of multi-user systems where backwards compatibility and updating deps without disturbing a user's workload / forcing them to recompile is paramount. Go (and a fair amou…

Additionally, when you have languages with rich library ecosystems, the OS kind of becomes irrelevant, the platform is the language ecosystem.

Just to pick Go as an example (not to be lost discussing VMs and such), it doesn't matter if I am targeting bare metal, Linux, Windows, IBM z/OS, AWS special cloud runtime, whatever.

As long as the Go code is the same, and someone has done the low level runtime support, it is a compile away and done.

Finally by pushing containers no matter what, the Linux community has made this even easier.

Post reply on HN