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

221–230 of 282 posts

Re: The modern packager’s security nightmare

#221

Post by drran »

hctaw wrote: post #50

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. Until then, I'll keep doing it, because it saves me time and money. I don't really buy that dynamic linking all the things is such a boon to security. But I'll link to this: https://drewdevault.com/dynlib > Not including libc, the only libraries which had "…

It's why we like to use LGPL for libraries: if you ship statically linked software, ship your source too, so we will be able to patch and recompile.

Re: The modern packager’s security nightmare

#222

Post by progval »

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 adapt to software distributions."

Re: The modern packager’s security nightmare

#223

Post by progval »

giantrobot wrote: post #29
ampdepolymerase wrote: post #25

Earlier quoted context omitted.

The way iOS and Fuchsia are dealing with the problem is to completely lockdown the operating system with a tight permissions system. An app can be compromised but the damage is limited. Perhaps it is time for servers to move to a similar model.

We should call this newly invented and wholly original concept a "container". The software gets "contained". It just might work. /s

For security by isolation, you don't even need containers. Just run each application as its own user.

This is already done by most (all?) daemons packaged in Debian that don't need to be root.

Re: The modern packager’s security nightmare

#224

Post by progval »

paultopia wrote: post #66

I feel like this confuses a lot of things by assuming an extremely sophisticated end user. Sure, if you're a double-threat dev/sysadmin using linux, then when some vulnerability gets discovered in some dynamically linked library on your system, you have the capacity to (a) receive information about that fact, and (b) update it. But now suppose you're an ordinary person. You use software. Maybe you even have a windows…

In addition to the other answers to your comment pointing out that the way you wrote (b) is very unfair; I'd like to point out that (a) assumes that the developer of the application is aware of the security update of their dependency and pushes a fix quickly.

Re: The modern packager’s security nightmare

#225

Post by orf »

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…

Why on earth would you ever add awscli as a dependency? That makes very little sense. It’s an application (that is no longer distributed via pypi).

You should use boto3

Re: The modern packager’s security nightmare

#226

Post by pjmlp »

rini17 wrote: post #220
pjmlp wrote: post #200

Earlier quoted context omitted.

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…

What if there's another software in another language you want to interoperate with? What if you want to avoid containers with their complexity and dubious security record?

Some form of IPC, usually OS agnostic ones.

That is what I have been doing the last 20 years, in the context of C++, Java and .NET.

Re: The modern packager’s security nightmare

#227

Post by ece »

noobermin wrote: post #157
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…

That's literally what windows does, for the most part, actually.

It's the pragmatic thing to do, and it's defacto what happens on Linux distros too. Distros offer pip/docker/cargo, but when some libraries/programs are popular enough, someone will inevitably package it and offer it in a 3rd party repo or the main distro repo. Examples of this would be numpy, ripgrep etc..

Re: The modern packager’s security nightmare

#228

Post by kasabali »

hctaw wrote: post #50

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. Until then, I'll keep doing it, because it saves me time and money. I don't really buy that dynamic linking all the things is such a boon to security. But I'll link to this: https://drewdevault.com/dynlib > Not including libc, the only libraries which had "…

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

That's completely missing point of the article.

You're free to ship your program binary however you want as the upstream.

It only becomes a problem if dynamic linking is a second class citizen in the language or build tool you use, you bundle dependencies and don't support un-bundling, or pin specific dependency versions.

Re: The modern packager’s security nightmare

#229

Post by 1337shadow »

> Why do people pin dependencies? The primary reason is that they don’t want dependency updates to suddenly break their packages for end users, or to have their CI results suddenly broken by third-party changes. However, all that has another underlying problem — the combination of not being concerned with API stability on upstream part, and not wishing to unnecessarily update working code (that uses deprecated API) on downstream part. Truth is, pinning makes this worse because it sweeps the problem under the carpet, and actively encourages people to develop their code against specific versions of their dependencies rather than against a stable public API. Hyrum’s Law in practice.

Exactly one of the problems with pinning your project dependencies, whatever language your project is in. It's better to unpin and continuously integrate upstream changes as early as possible: it's less work this way at the end of the year, and more secure.

Re: The modern packager’s security nightmare

#230

Post by drran »

lmm wrote: post #202
delroth wrote: post #59

Earlier quoted context omitted.

You're making a distinction between "packagers" and "users" which does not exist. Packagers are advanced users that take the initiative to improve their distro when they find software they want to use and that isn't integrated in their distro. > Let the new complicated juggernaut software be deployed and configured by the users, according to developers' instructions, using whatever modern mechanism they prefer I'm no…

> The existence of packagers is proof that some subset of users "prefer" that software "be deployed and configured" via distro package managers. Not necessarily. It might be inertia - back when linux distributions started being organised this way, those language dependency management mechanisms pretty much didn't exist.

CPAN exists since 1993, online since 1995. CPAN has the package manager, which is able to install perl software with their dependencies. It's not a new, unknown technology.

If you are sure that you can create functional, stable, bug free, hole free, up to date, full of useful software distro with 10 independent package managers instead of one, then just do it. We will enjoy it. You will spend about 10x more time than current maintainers, but your time is free, so it's not a problem. Of course, we will say huge THANK YOU for your incredible effort, with nine zeroes after initial zero, except for some hatters, which will blame your perfect distro at HN for no reason.

Post reply on HN