6 ms·

Bpkg: package manager for bash

68 points by aserafini 10y ago

gkya 10y ago
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.
y4mi 10y ago
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-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
- lbn 10y ago
  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.
  - cyphar 10y ago
    > 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.
    - drdaeman 10y ago
      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.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - yellowapple 10y ago
    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.
  - oholiab 10y ago
    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-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
    - ricardobeat 10y ago
      Does anyone read install scripts/formulas when installing something from system package managers?
      - bluecmd 10y ago
        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.
      - bluecmd 10y ago
        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.
      - semi-extrinsic 10y ago
        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.
  - ChoHag 10y ago
    Server: ... rm -fr /$variable Network: ... rm -fr / <HUP> Bye bye everything!
    - heinrich5991 10y ago
      That doesn't happen if you put all the main code into a function. Which they do.
- coldtea 10y ago
  >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...
- K0nserv 10y ago
  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.
guessmyname 10y ago
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_management_systems https://en.wikipedia.org/wiki/List_of_software_package_manag... [1] https://news.ycombinator.com/item?id=8387137 https://news.ycombinator.com/item?id=8387137
- iamdave 10y ago
  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
- whichfawkes 10y ago
  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.
  - joepvd 10y ago
    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?
eximius 10y ago
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.
- AndrewUnmuted 10y ago
  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.
- stirner 10y ago
  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.
  - ketralnis 10y ago
    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.
  - Annatar 10y ago
stirner 10y ago
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.
- Matachines 10y ago
  Was this comment necessary? No one cares what you think about the domain.
  - ChoHag 10y ago
    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.
Annatar 10y ago
How many more private packaging formats bypassing the OS software management subsystem must people invent? Bite the bullet and create native OS packages.

68 points by aserafini 10y ago

gkya 10y ago

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.

y4mi 10y ago

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-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

lbn 10y ago
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.
- cyphar 10y ago
  > 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.
  - drdaeman 10y ago
    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.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- yellowapple 10y ago
  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.
- oholiab 10y ago
  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-bash-server-side/ https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
  - ricardobeat 10y ago
    Does anyone read install scripts/formulas when installing something from system package managers?
    - bluecmd 10y ago
      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.
    - bluecmd 10y ago
      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.
    - semi-extrinsic 10y ago
      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.
- ChoHag 10y ago
  Server: ... rm -fr /$variable Network: ... rm -fr / <HUP> Bye bye everything!
  - heinrich5991 10y ago
    That doesn't happen if you put all the main code into a function. Which they do.
coldtea 10y ago
>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...
K0nserv 10y ago
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.

guessmyname 10y ago

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_management_systems https://en.wikipedia.org/wiki/List_of_software_package_manag... [1] https://news.ycombinator.com/item?id=8387137 https://news.ycombinator.com/item?id=8387137

iamdave 10y ago
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
whichfawkes 10y ago
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.
- joepvd 10y ago
  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?

eximius 10y ago

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.

AndrewUnmuted 10y ago
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.
stirner 10y ago
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.
- ketralnis 10y ago
  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.
- Annatar 10y ago

stirner 10y ago

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.

Matachines 10y ago
Was this comment necessary? No one cares what you think about the domain.
- ChoHag 10y ago
  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.

Annatar 10y ago

How many more private packaging formats bypassing the OS software management subsystem must people invent? Bite the bullet and create native OS packages.