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

271–280 of 282 posts

Re: The modern packager’s security nightmare

#271

Post by Foxboron »

microtonal wrote: post #270
Foxboron wrote: post #119

Earlier quoted context omitted.

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

That is nonsense and you seem to spread this misinformation in a lot of places. You should also add a disclaimer that you are part of the Arch team. AUR: Anyone can create an account and upload PKGBUILD s. There are no checks at all. AUR users should verify whether PKGBUILD s are not malicious. In practice, a lot of people use things like yaourt to install packages from the AUR without verifying the PKGBUILD s. nixpk…

>That is nonsense and you seem to spread this misinformation in a lot of places. You should also add a disclaimer that you are part of the Arch team.

The AUR comment is unfair, uncalled for and adds nothing to the conversation. I apologize and hope our previous conversations have been more productive. It was meant more tongue in cheek then some grand claim about the quality of nixpkgs and stems mostly from the frustration of the entire vendoring issue.

Re: The modern packager’s security nightmare

#272

Post by lmm »

pdonis wrote: post #256
lmm wrote: post #199

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

My release builds makes binary packages (including a .deb) and push them to my artifact repository; isn't that normal?

Re: The modern packager’s security nightmare

#273

Post by forrestthewoods »

nonameiguess wrote: post #266
forrestthewoods wrote: post #101

Earlier quoted context omitted.

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 don't think this is a fair characterization of why containers are a killer app. Full-OS virtualization was a killer app for hosting providers because it enabled multi-tenancy, allowing you to oversubscribe physical resources knowing that most applications you host aren't going to be experiencing anywhere near peak load 100% of the time. Containers allow you to take this a step further by allowing multiple applicati…

> Containers allow you to take this a step further by allowing multiple applications with different versions of the same dependencies to run together on the same physical or virtual server without needing to worry about symbol clashes and without having to install one application's dependencies into some different than expected location while manipulating LD_LIBRARY_PATH and PATH.

We agree 100% on the problem. I enthusiastically agree with all of your complaints.

My point is that Linux model of system-wide shared libraries and PATH/LD_LIBRARY_PATH bullshit is terrible. And the fact that containers are required to resolve that spiderweb nightmare is a damning indictment on the Linux library model.

Containers are one possible solution. An alternative is for those applications to bundle their dependencies. If all applications bundled their dependencies then everything would “just work”. No need to hack bullshit envvars. No need to containerize.

Yes that means it’s harder to deploy security fixes. But if everyone is using containers then also those images need to be updated. At which point what have you even gained?

Re: The modern packager’s security nightmare

#274

Post by lmm »

ticviking wrote: post #249
lmm wrote: post #197

Earlier quoted context omitted.

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.

I don't pretend to have an answer but I'm trying to listen to both sides so maybe I can formulate "the question" a little bit better and improve the discussion around this. It seems like have posts every few months where security professionals, maintainers and sysadmins explain that the "developer usability first" approach to maintenance and dependency management is having massive consequences to our ability to keep…

Knowing whether a vulnerable version is somewhere in your dependency tree, and making sure it gets fixed, is absolutely being done and being made part of CI etc. (I don't know about Rust/Go specifically, but the JVM ecosystem is the subject of similar complaints and we're absolutely doing vunerable dependency scanning and also things like "edge builds" where we bump every transitive dependency to the latest version and see if anything breaks). Nowadays Github itself will give you an alert without you even needing to do anything.

Frankly, most distribution maintainers seem to not know or care about how upstream software is built; they have an idea about what's "best practice" in the handful of languages they're using to build their distribution (which is mostly, like, C and Perl) and insist that they know best, without realising the rest of the world has passed them by.

Re: The modern packager’s security nightmare

#275

Post by lmm »

drran wrote: post #230
lmm wrote: post #202

Earlier quoted context omitted.

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

Debian in particular put a fair bit of effort into integrating apt deeply with CPAN so that you could install a package from there that depended on system libraries and vice versa, and then for subsequent languages they... didn't. You'd think these were well-known technologies, but as far as linux distribution maintaners are concerned they're new and scary.

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

I'd rather leave the distribution model behind entirely. And you know what? I do, and it works great. You just get the occasional complaint like this article, but it doesn't actually matter in the real world.

Re: The modern packager’s security nightmare

#276

Post by pvorb »

drran wrote: post #265
pvorb wrote: post #264

Earlier quoted context omitted.

I'm a software developer and a user of package managers. A package manager that allows me to only have one version of a software package installed will inevitably get in my way if I need two programs that need different, incompatible versions of that dependency. It happens quite a lot in my experience.

Basically, you want to put two versions of the same file(s) into one file. If you need two versions of almost same set of files, then chose different name for the package, e.g. package-2, chose different base directory for package files, e.g. /usr/share/package-2, and chose different names for binaries, e.g. /usr/bin/binary-2. It's not a magic. Just look at examples, e.g. python2 and python3.

But I'm not the author of those packages. How does the package manager allow me to rename existing packages?

Re: The modern packager’s security nightmare

#277

Post by account42 »

josephg wrote: post #236
drran wrote: post #207

Earlier quoted context omitted.

So, you deliberately chose distro intended for users, with low version churn, instead of distro intended for developers, e.g. Fedora, which ships even pre-release versions sometimes, and now you blame ... apt? Just curious, what you are using for coding? MS Word or Excel? For example, Linus uses Fedora/MATE/Emacs. It's relatively easy to convert between packages between different packagers/distros. Automatic converte…

If you want your software to work everywhere, you either need to take responsibility for making it build everywhere (yes, including old versions of Debian which don’t support the versions of your dependencies you need) or you punt that work to someone else - in which case your software simply won’t work on lots of computers. From the perspective of an upstream maintainer, the status quo is pretty awful. There’s a rea…

> weird incompatibilities between libc versions

Care to provide some examples?

Re: The modern packager’s security nightmare

#278

Post by posix_me_less »

tgbugs wrote: post #63
posix_me_less wrote: post #41

Earlier quoted context omitted.

Do you mean "robust for people using Gentoo" or "robust for everybody"? Isn't the latter responsibility of the Clojure developers rather than packagers?

Robust for everyone. In theory it is the responsibility of the Clojure devs, but if there isn't a packaging workflow that they are aware of, how can they be expected to integrate with it and make design and development decisions that it would reveal to them? The point is more that, the greater variety of different environments a piece of software runs in the more likely it is that systematic weaknesses will be reveal…

Yes packaging for different distributions can reveal unknown problems or enhancement possibilities in the project, however I would be surprised if the developers in general were interested at all in supporting that activity. Maybe Clojure is, I don't know.

Packaging is beneficial mainly to users, I expect developers to choose single platform and support that, if there is more, great. But most developers aren't interested in a massive distraction that accomodating 520+ distributions is.

Re: The modern packager’s security nightmare

#279

Post by posix_me_less »

sanxiyn wrote: post #65
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…

> basic desktop I actually wish this is feasible, but it isn't. GNOME is basic desktop, GNOME includes librsvg, librsvg build-depends on Rust. So you need to package Rust (hence LLVM) to have GNOME. Your proposal only works if "core OS" refuses to use Rust.

Yeah I get that. GNOME is a horrible big software. I would not count is as "basic desktop", because it is so big, buggy and dependencies are out of control. Basic desktop, I mean something like Xfce, with modular components and minimal dependencies so the desktop system is simple and unixy. You would still have the option to install GNOME on such a system, if only GNOME developers made a canonical version of GNOME that would be modular, and would install on any clean Linux system with Xorg or Wayland.

Re: The modern packager’s security nightmare

#280

Post by drran »

pvorb wrote: post #276
drran wrote: post #265

Earlier quoted context omitted.

Basically, you want to put two versions of the same file(s) into one file. If you need two versions of almost same set of files, then chose different name for the package, e.g. package-2, chose different base directory for package files, e.g. /usr/share/package-2, and chose different names for binaries, e.g. /usr/bin/binary-2. It's not a magic. Just look at examples, e.g. python2 and python3.

But I'm not the author of those packages. How does the package manager allow me to rename existing packages?

You can create your own repository, where you will be maintainer of your packages.

You can use it locally, as directory on disk, or you can put it on a server and share with others, or you can compile it using openSUSE Build Service, which supports OpenSuSE, SLE, Fedora, RedHat, CentOS, Debian, Arch, etc.: https://en.opensuse.org/openSUSE:Build_Service_supported_bui...

Post reply on HN