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

111–120 of 282 posts

Re: The modern packager’s security nightmare

#111

Post by ccday »

forrestthewoods wrote: post #101
sigjuice wrote: post #73

Earlier quoted context omitted.

The day I stop static linking is the day I can compile on one distro and ship to many without worrying about users reporting loader errors. That day is not today. Maybe do the trendy thing and link your whole distro together with your app (a.k.a containers)?

The fact that containers exist and are prevalent is a damning indictment on the Linux model imho. Producing software that can simply launch is so wildly complex that the solution is... to snapshot an entire operating system install to run the application. That’s INSANE. But it’s unfortunately required. https://xkcd.com/1987/ > Now, for the worst of all — one that combines all the aforementioned issues, and adds even…

I'm not sure it's fair to characterize a container as a snapshot of an entire OS install - you can have containers that are very lightweight, e.g. just a static Go binary copied into a "scratch" container - but often the required effort is not put in to reduce size.

Re: The modern packager’s security nightmare

#112

Post by Foxboron »

alfiedotwtf wrote: post #81
bscphil wrote: post #47

Earlier quoted context omitted.

> I disagree, it's proven to be inadequate for modern software development Well, that's exactly why the OP (and my essay) are "anti" modern software development in many ways. The view is that we're moving away from the traditional open source ecosystem and methods of software development with these new technologies, which (to be clear) are good technologies, but were created mostly to solve problems that some large c…

I’ve been on Debian since Potato, so I totally see what you’re saying. But... > that's cutting maintainers out of the loop Is this necessarily a bad thing? The market has seen the need to fill a hole, and it seems to be working. I first started with Slackware, and dependency nightmares is what got me into Debian in the first place. Although Debian is nice because of its slow and stable base (which makes me happy for…

>With systems like Arch that get us closer and closer to upstream, are maintainers the unnecessary middlemen? Of course they’re not entirely redundant, but maybe a new model of distros like Arch will be more commonplace in the future

Arch is an old distribution, very much in the same class as Fedora, Debian, Gentoo and all the traditional ones.

What makes you think Arch makes maintainers even slightly redundant?

We still deal with security issues. We still need to figure out which Go software utilizes a library with a CVE with no tooling (go list and grep comes a long way). And we still need to deal with pinned dependencies in upstream projects.

Re: The modern packager’s security nightmare

#113

Post by mwcampbell »

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…

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

Re: The modern packager’s security nightmare

#114

Post by sagichmal »

acidbaseextract wrote: post #62
anderskaseorg wrote: post #53

Earlier quoted context omitted.

If you publish a Python library with pinned dependencies, your code is broken as soon as someone tries to use it with another Python library with pinned dependencies, unless you happened to pin exactly the same version of the dependencies you have in common. Python libraries should not pin dependencies. _Applications_ can pin dependencies, including all recursive dependencies of their libraries. There are tools like…

The most frustrating thing is that pip doesn't make it easy to use more loose declared dependencies while freezing to actual concrete dependencies for deployment. Everybody rolls their own. > Python libraries should not pin dependencies. _Applications_ can pin dependencies, including all recursive dependencies of their libraries. Is the pypi package awscli an application or a library? poetry is frustrating in that it…

> Is the pypi package awscli an application or a library?

Hopefully a library! As hopefully the AWS command-line interface is maintained and distributed separately from any SDK that powers it...

Re: The modern packager’s security nightmare

#115

Post by baybal2 »

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…

> it's easier to reason about code that is running if you can look at the commit that a bin was built from and know exactly what's inside (including all deps).

Believe me, it's usually the opposite.

Lack of proper releases, testing, and versioning results in unending checkout-fu to figure out what commits for each of 20 libraries will work for each other.

The idea is plainly stupid, without any redeeming qualities.

The entirety of this cargo cult hinges on the point of "If people calling it a genius invention for last 8-10 years admit it not being it, some major reputation, and cred loss will be incurred"

Re: The modern packager’s security nightmare

#116

Post by dralley »

Foxboron wrote: post #112
alfiedotwtf wrote: post #81

Earlier quoted context omitted.

I’ve been on Debian since Potato, so I totally see what you’re saying. But... > that's cutting maintainers out of the loop Is this necessarily a bad thing? The market has seen the need to fill a hole, and it seems to be working. I first started with Slackware, and dependency nightmares is what got me into Debian in the first place. Although Debian is nice because of its slow and stable base (which makes me happy for…

>With systems like Arch that get us closer and closer to upstream, are maintainers the unnecessary middlemen? Of course they’re not entirely redundant, but maybe a new model of distros like Arch will be more commonplace in the future Arch is an old distribution, very much in the same class as Fedora, Debian, Gentoo and all the traditional ones. What makes you think Arch makes maintainers even slightly redundant? We s…

Maybe they have heard of the AUR and think it's how the rest of Arch works?

Re: The modern packager’s security nightmare

#117

Post by sagichmal »

AshamedCaptain wrote: post #98
gpm wrote: post #91

Earlier quoted context omitted.

> your compiler Compilers of languages like C, C++, Rust, Go etc go above and beyond to maintain backwards compatibility. It is extremely likely that you will still be able to compile old code with a modern compiler. > your processor Hardware is common enough that people go out of their way to make backwards compatibility shims. Things like rosetta, qemu, all the various emulators for various old gaming systems, etc.…

> Dependencies are far more likely to rot because they change in incompatible ways than the underlying hardware does Yes, that is true. It is also very likely that you can more easily go back to a previous version of a dependency than you can go back to a previous hardware. The argument is that, therefore, pinning can only speed up your rotting. If you don't statically link your dependencies, and due to an upgrade so…

Honest question: have you ever worked as an application developer? Responsible for getting working artifacts to users as a means to an end?

Pinning dependencies absolutely and unquestionably works better, and for longer, than dynamic linking, for this use case.

Re: The modern packager’s security nightmare

#118

Post by cuillevel3 »

> Static linking, dependency pinning and bundling are three bad practices that have serious impact on the time and effort needed to eliminate vulnerabilities from production systems.

I'm astonished how different this perspective is. As a developer I see that software is developed faster nowadays. size, library reuse and functionality are increasing.

And distributions are just not able to keep up. I feel like they never did, they just made exceptions for packages that were too important to ignore, like browsers or office suites.

Really, it's not the software. It's the distros.

Not using libraries is not an option, you don't want devs to write their own crypto. Not pinning dependencies is bad, incompatibilities and security issues could make their way into the code. The test surface also gets bigger and it raises the question which combinations are supported.

Update: I think what I want to say is, distributions should accept that they can only provide that level of "stability" for a limited set of applications. The new and shiny stuff will always happen elsewhere.

Re: The modern packager’s security nightmare

#119

Post by Foxboron »

dralley wrote: post #116
Foxboron wrote: post #112

Earlier quoted context omitted.

>With systems like Arch that get us closer and closer to upstream, are maintainers the unnecessary middlemen? Of course they’re not entirely redundant, but maybe a new model of distros like Arch will be more commonplace in the future Arch is an old distribution, very much in the same class as Fedora, Debian, Gentoo and all the traditional ones. What makes you think Arch makes maintainers even slightly redundant? We s…

Maybe they have heard of the AUR and think it's how the rest of Arch works?

I'd be terrified, but that is how NixOS works.

Re: The modern packager’s security nightmare

#120

Post by bfrog »

ticviking wrote: post #79
oblio wrote: post #56

Earlier quoted context omitted.

The open source solutions are primarily for C/C++. A bit for Perl, a bit for Python. But they haven't really moved on. Java has been tacked on since forever. Same for .NET, JavaScript, whatever. And if you wanted your program propagated to all major distros you'd have to wait a decade. Nobody has time for that. Not corporations, not mom and pop stores, and I doubt many hobbyists.

Then you always have the option to package your software for the ones you use and not worry about the rest. If you want to make your program popular then packaging is part of the process needed.

Not anymore
Post reply on HN