Bpkg: package manager for bash | Hacker News Reader

Bpkg: package manager for bash

bpkg.io

68 pointsaserafini32 comments

Jesus! Another package manager, I don't even want to look at that website before I can think of a single reason of why would anyone want to have a package manager for Bash, once I think of a legitimate use case I will go to that website to see what is their offer. But seriously, do we need a package manager for everything [1]? Some time ago I was thinking to create a package manager for package managers, then realized that it was already proposed [2] and that it has no purpose so I desisted on the idea.

[1] https://en.wikipedia.org/wiki/List_of_software_package_manag...

[1] https://news.ycombinator.com/item?id=8387137

I'm sure there's a "single reason" the developer rationalizes in their own mind, but I'm fatigued as hell having to make sure I have yet another package manager installed just to get the %thing%.

Obligatory xkcd: xkcd.com/927

In fairness though, the "package manager for package managers" functionality is arguably included in your OS package manager.

Furthermore, as (e.g.) a node developer looking to share a package with the community, I'd much maintain one package in npm than one for each of Debian, Arch, Redhat, OSX, etc.

You are so right. Which exactly points at the problem:

Multiple OS package managers (choose one), and for each language/framework/... that you use, one extra. Which includes headaches for how to handle overlaps between the two. One ought to take into consideration how others are handling these issues, just to ensure you're not alone.

I do not have concrete answers, but I firmly believe that it is possible to reduce the mental and practical efforts required for package and dependency management by somehow abstracting and disciplining the current solutions.

In this context, Guile and NIX are often named. Their stated goals, however, are generally about reproducibility of builds. Could anyone point me to discussions/documentation that specifically addresses the wildfire of dependency- and package management?

Since creating OS packages for the target OS can be completely automated, the failure to do so is a failure to make the computer do the work and automate the process.

I genuinely don't understand the use case of this over the default OS pkg manager. Separation of concerns? Uniformity across *nixes?

Either way, it doesn't seem very compelling.

I use bpkg for one of the stated reasons on the project homepage:

   Besides installing shell scripts globally you can use them on a per-project basis.

Per-language package management seems to be the way to go lately. I think this is mostly because some operating systems don't have a package manager, or have one that is difficult to create and distribute packages for.

If I make a package using $LANGUAGE's package manager I get portability across the platforms that $LANGUAGE supports, and I do it I using tools that I already know and am already using to write in $LANGUAGE. Market share == $LANGUAGE's market share.

But If I want to make an $OS package for my $LANGUAGE module, I have to use a tool unrelated to my language and package that I probably don't know and target only $OS (or do that step for every one of them). Not to mention that the specific ones that we have, say RPM and DEB, have always been a right pain for me to generate personally. Market share == $LANGUAGE's market share / $OS's market share.

I don't like the state of affairs, but I do understand why people end up distributing with their language's package manager instead. It's way simpler and already baked into their process and assuming that they wrote the code in the first place to scratch their own itch and they already know how to use their language's package manager, it solves that problem for them nicely.

I think one solution is for language-specific package managers to target creating OS packages on some common platforms (`setup.py make-deb`, `cargo deb`, etc). These modules are probably so similar that it's much easier than the package case.

If an OS has no software management subsystem, it is not enterprise deployment material, and therefore has no business being used to power production; it really is that simple.

There are uses of software outside enterprise.

There certainly are uses outside of enterprise, but then it's not enterprise, is it?

If however such software is used for generating money, then suddenly, the exact same criteria as within enterprise applies, because as soon as the flow of money is jeopardized, that's production.

I'm not sure what point you're trying to make here. I'm saying that my original comment had nothing to do with enterprise. It may well be that operating systems without package management are unsuitable for enterprise. I personally think operating system without package management are unsuitable anywhere; my comment, however, was descriptive rather than prescriptive.

If you're writing a bash package it'd probably be preferable to package for this rather than per-distro. By making it easier for maintainers, you get more packages - so maybe this is a good thing?

As a user, I keep my dotfiles in git. Having something like bpkg could help my dotfiles "just-work" across more platforms, so maybe it's a good thing?

I'm not particularly compelled either, just pointing out how it might be useful.

ah, another curl|bash installation...

it amazes me that people still put them onto their sites. even vetting the code is futile if you pipe it afterwards[0].

[0] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

curl|bash is no less secure than any script you download and run as a regular user. When you add a third party apt repository and install a deb package do you always verify that the postinst script doesn't do anything malicious?

The only mistake I see in this case is doing this over plain HTTP. Let's Encrypt is free and there is no excuse for not enforcing HTTPS for this.

> When you add a third party apt repository and install a deb package do you always verify that the postinst script doesn't do anything malicious?

Package managers have decades of work put into them. Not just the installation and verification aspects, but all of the maintainence bureaucracy required so that there is accountability and verification. As much as developers might like to think that we know more about our users than anyone else, we don't. And there's essentially no verification or reason to believe that an upstream curl|sh will work on a given distribution. People who package software are usually part of the distro community they're packaging for, and are much better at knowing how software should be packaged for that community.

Your parent comment was referring to the third-party repositories, and they're not subject to strict packaging policies and may contain just anything. So, the comparison is mostly correct - it's like downloading a random .deb file off the web (only worse, because a trusted malicious repo can override any system package with an "upgrade" - AFAIK there's no package-level signatures in dpkg).

However, not sure about the the implied conclusions (or my perceptions of them). I believe, the correct answer is that adding untrusted repositories is also dangerous and should be done with caution.

And, yes, when I add external repos, I consider a quick background check on who runs it, how popular (=trusted by others) it is, and depending on my conclusions about the trustworthiness, do audit the package contents or perform a test run in a VM. Others' mileage may vary.

Security issues aside, there's also the concern of what happens if the piped-into `bash` receives an incomplete script (usually because `curl` was interrupted, often because of poor network connectivity). `bash` will attempt to execute whatever it already got from `curl`, which can cause all sorts of problems.

It's actually possible to detect the |bash part server side and send different content than if you were simply curling, wgeting or viewing in a browser.

Not only does this mean that you could end up with a compromised system, but it also means that there's no artefact of what caused it left on disk.

I agree with your point that running third party software is always a risk, the problem here being that you can think you've done your due diligence by reading the curl output first and then doing curl|bash, but in actuality this is not necessarily the case which is what makes curl|bash such an insidious bad habit.

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Does anyone read install scripts/formulas when installing something from system package managers?

No, but I trust my OS distribution. I don't trust random third-party developer. I wouldn't add their APT repository willy nilly either.

On Arch, installing from AUR people are told to (and generally will) inspect the install script(s) when installing something. It's part of the workflow for all AUR helpers.

Server: ... rm -fr /$variable

Network: ... rm -fr / <HUP>

Bye bye everything!

That doesn't happen if you put all the main code into a function. Which they do.

>it amazes me that people still put them onto their sites.

Why?

It's way more secure than any binary blob -- and people download and install billions of these every day... (And even a hash means nothing -- a hacker could easily change both the blob and the hash).

At least with "bash installations" you can check the code yourself before running it...

The people who would vet the code before execution are experienced enough to change it from curl | bash to curl > install.sh and then read it before executing. The only thing you can, and should, criticise here is the delivery over HTTP instead HTTPS. Delivering any kind of code over HTTP is completely inexcusable since the introduction of Let's Encrypt.

What is a bash package? A shell script?

The thing is at least about two years old (first posted here 650 days ago) and has no doc and merely about a dozen packages listed. There seems to be nothing to show here.

How many more private packaging formats bypassing the OS software management subsystem must people invent?

Bite the bullet and create native OS packages.

I've started ignoring .io domains, because they seem to be a convenient shorthand for "I care more about being trendy than being correct." I doubt this project is based in the British Indian Ocean Territory.

Was this comment necessary? No one cares what you think about the domain.

The comment is on point. The io TLD does seem to be used more for software which is trendy rather than which is useful, thus it makes a reasonable litmus test.

Reply on news.ycombinator.com