3 ms·

> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea h

> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.

IgorPartola 5y ago
That sounds like a personal problem. .deb and .rpm packages are nothing more than tar archives with a specific file structure. dpkg and rpm both have options to extract the package locally. dpkg -L NAME will show you all the files the installed package has placed on your file system (not generated ones by the code obviously but ones that came with the archive). pip has similar options. More broadly, and I am sorry if I am wrong here, but what do you expect to glean from reading that code if you don’t bother reading the man page for your package manager?
- newaccount74 5y ago
  The point is, if you want people to review the code before they deploy it, it's better to just give them a source file. Package managers just make it so convenient to use code without ever looking at it.
  - IgorPartola 5y ago
    That is a truly absurd argument.
heurisko 5y ago
In the context of PHP, the package source is put under vendor/ and in my IDE is automatically indexed. It's very easy to view the source code. You can even experiment with the packages directly, by editing the files in vendor/.
- Sander_Marechal 5y ago
  It would be nice if Composer can give me a `diff` of before/after an update though.
  - withinboredom 5y ago
    Git submodule with vendor packages checked in? Delete the module after the upgrade and you’ve inspected it.
- ryanbrunner 5y ago
  With node_modules, the amount of required code becomes unmanageable to review very, very quickly (sometimes with the installation of a single package).
pvorb 5y ago
Yes, somehow people seem to confuse a link to the Github repo with the same tags with a verifyable build and a hash of the result.
slingnow 5y ago
This just seems like willful ignorance and has very little to do with package managers. If you were interested in looking at the code, a quick google search or running `--help` would go pretty far.

IgorPartola 5y ago

That sounds like a personal problem. .deb and .rpm packages are nothing more than tar archives with a specific file structure. dpkg and rpm both have options to extract the package locally. dpkg -L NAME will show you all the files the installed package has placed on your file system (not generated ones by the code obviously but ones that came with the archive). pip has similar options. More broadly, and I am sorry if I am wrong here, but what do you expect to glean from reading that code if you don’t bother reading the man page for your package manager?

newaccount74 5y ago
The point is, if you want people to review the code before they deploy it, it's better to just give them a source file. Package managers just make it so convenient to use code without ever looking at it.
- IgorPartola 5y ago
  That is a truly absurd argument.

heurisko 5y ago

In the context of PHP, the package source is put under vendor/ and in my IDE is automatically indexed. It's very easy to view the source code. You can even experiment with the packages directly, by editing the files in vendor/.

Sander_Marechal 5y ago
It would be nice if Composer can give me a `diff` of before/after an update though.
- withinboredom 5y ago
  Git submodule with vendor packages checked in? Delete the module after the upgrade and you’ve inspected it.
ryanbrunner 5y ago
With node_modules, the amount of required code becomes unmanageable to review very, very quickly (sometimes with the installation of a single package).

pvorb 5y ago

Yes, somehow people seem to confuse a link to the Github repo with the same tags with a verifyable build and a hash of the result.

slingnow 5y ago

This just seems like willful ignorance and has very little to do with package managers. If you were interested in looking at the code, a quick google search or running `--help` would go pretty far.