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

81–90 of 282 posts

Re: The modern packager’s security nightmare

#81

Post by alfiedotwtf »

bscphil wrote: post #47
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 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 production), I’ve recently moved to Arch and have been so happy as it’s brought back Slackware’s idea of getting as close to upstream as possible and it handles dependencies! And to be honest, I’m loving it. And as an even added bonus, I’m getting more and more surprised how a tonne of packages that I’ve installed are Rust apps.

So, coming back to your comment:

> that's cutting maintainers out of the loop

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

Re: The modern packager’s security nightmare

#82

Post by [deleted] »

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…

[deleted]

Re: The modern packager’s security nightmare

#84

Post by young_unixer »

Centralized repositories are not a good, general solution to the software distribution problem.

First: They don't have all the packages and versions the user could ever need, which means that you'll always have a mixture of software installed through the packagr manager and software installed through tarballs or curl | bash

Second: They distort the relationship between application developer and application user.

Third: they neglect offline use cases.

The only sane, generalizable solution is for the OS to be a platform upon which bundles can be installed. The OS should just define a sane format for said bundles and the user gets their applications directly from the application developer.

Re: The modern packager’s security nightmare

#85

Post by ticviking »

hctaw wrote: post #74
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'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?

Re: The modern packager’s security nightmare

#86

Post by bscphil »

hctaw wrote: post #74
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'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 best (by promoting the open source ecosystem) to keep it that way.

> Maintainers don't have a right

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

If you put in a bunch of crap that doesn't belong in an application (ads, for example), I'm glad I have a maintainer that can either strip this out thanks to the GPL (or BSD / MIT etc), or else choose not to include your app in the distribution at all.

Re: The modern packager’s security nightmare

#87

Post by edoceo »

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…

Based on this writing, I'm keen to read your full essay

Re: The modern packager’s security nightmare

#88

Post by regularfry »

nomercy400 wrote: post #31

It's a risk calculation: do I want to risk being vulnerable to 0days, or do I want to risk my application not running for any user because a dependency changed its headers/api? As software engineers we want to be in control of as much as possible when running our application, to make it as deterministic as possible. For that we select versions of our dependencies, build it, and then test it, and if our tests pass, we…

Keeping the application working in the face of dependency updates is the distro's job, if they're supported in doing it. They won't be pushing dependency updates at random except to channels explicitly marked as unstable (at least, assuming a minimally sane distro).

I'm less familiar with Gentoo, but Debian-based distros ought to be safe from that threat (and if anything, you ought to be worries about the reverse problem). So your question becomes: do I want to risk being vulnerable to zero-days?

Re: The modern packager’s security nightmare

#89

Post by archi42 »

steveklabnik wrote: post #24

There is a lot I could say about this article, but I've kinda been in this whole Texas natural disaster situation. But I do think it's worth pointing out one thing: > Rust bundles a huge fork of LLVM It is not super huge, and we try to upstream patches regularly to minimize the fork. We also regularly re-base all current patches on each release of LLVM, so it's less 'fork' and more 'maintain some extra commits to fix…

What's the problem with focusing on upstreaming the patches and getting rid of rust's "staging fork"? Especially if they fix something as serious as miscompilations, wouldn't those patches be VERY much needed upstream? I'm asking out of genuine interest.

Re: The modern packager’s security nightmare

#90

Post by bscphil »

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…

Thoughtful comment, thanks. I'm an Arch user as well and agree broadly with its approach to a desktop operating system. (I.e. stick as closely to upstream as possible.)

That said, I disagree that this means maintainers are unnecessary middlemen, even though their role on a distribution like Debian is obviously more prominent. The essay I linked to in my top level comment is actually by an Arch maintainer, explaining why they still see maintainers as playing an important role. http://kmkeen.com/maintainers-matter/

Post reply on HN