5 ms·

Pip/npm/gems are just as bad as are debs/rpms from an untrusted source. Piping curl to sh is no worse than any other way of installing unvetted software from a

Pip/npm/gems are just as bad as are debs/rpms from an untrusted source. Piping curl to sh is no worse than any other way of installing unvetted software from an untrusted source and the only better alternative is either verifying the software installation instructions yourself or relying on a trusted third party to do this for you (e.g. the Debian maintainers)

bravetraveler 4y ago
Those services I mentioned -- COPR/OBS, they can be the trusted sources by your users. They're signed the same way as your first party packages. If you trust the developer/maintainer, you can trust these services. It's literally the same infrastructure as OpenSUSE/Fedora/Red Hat. As a developer you don't have to provide the infrastructure or equipment, simply whatever is to be built. I'm not suggesting people provide their software by pure RPM or DEB files. The repositories do the important part of actually distributing the software. If you're on either OBS or COPR you're on the fast path to having the OS maintainers do the work for you
- fiddlerwoaroof 4y ago
  > I'll accept pip, I'm not picky This was the main thing I’m reacting to: installing from something like pip is usually running a ton of unvetted code downloaded from the internet. If you trust such package managers, you might as well curl to a shell.
  - bravetraveler 4y ago
    Apologies, that's fair -- there are levels to my rant. That's a very important part. I'll take package managers over shell scripts in concept for one main reason: they reduce reinvention. The supply chain is always of concern, of course. A shell script benefits from coreutils -- cp, mv, things like that. You're on your own for everything else, I don't trust that. They themselves are untrusted code -- for all we know there's no VCS behind it at all. A package manager at least offers some guardrails! With packages on OBS/COPR, you can at least know/verify the sources you're installing were built in a clean (offline) environment from the upstream sources. It's a small, but notable, improvement. Also consider you need to rebuild your system and you'd like it to look the same after. Will you find it easier to run 'pip freeze' / 'dnf history userinstalled'... or crawl your shell history for curl | bash and resolve any drift?
- masklinn 4y ago
  > Those services I mentioned -- COPR/OBS, they can be the trusted sources by your users. But there's nothing trusted about them is the point, you can ship a deb or rpm with all sorts of scripts running at installation, this is no safer than curl | sh. If anything it's worse, when you "curl | sh" and it requests sudo you can go "mmm no we're not doing this I will happily risk compromising all my user data but it stops at my system integrity". rpm or deb you're already running as root. > If you trust the developer/maintainer, you can trust these services. And you can also trust their site which you're curl-ing from.
  - bravetraveler 4y ago
    If we assume the worst of the maintainer/packager, of course it's no better. I'm assuming some adherence to these guidelines, otherwise they should be removed from the service: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_no_files_or_directories_under_srv_usrlocal_or_homeuser https://docs.fedoraproject.org/en-US/packaging-guidelines/#_... A package adhering to this guideline modifying system files, as designed, is not a problem. They are explicitly prohibited from modifying user data. My point with managers vs scripts is that managers provide some sanity. Not perfection. I trust: - a versioned package - built to the linked standards - from upstream sources in an offline environment Far more than I do curl | bash. There is far less ambiguity and I can actually reproduce this exact environment at some point.

bravetraveler 4y ago

Those services I mentioned -- COPR/OBS, they can be the trusted sources by your users. They're signed the same way as your first party packages. If you trust the developer/maintainer, you can trust these services. It's literally the same infrastructure as OpenSUSE/Fedora/Red Hat. As a developer you don't have to provide the infrastructure or equipment, simply whatever is to be built. I'm not suggesting people provide their software by pure RPM or DEB files. The repositories do the important part of actually distributing the software. If you're on either OBS or COPR you're on the fast path to having the OS maintainers do the work for you

fiddlerwoaroof 4y ago
> I'll accept pip, I'm not picky This was the main thing I’m reacting to: installing from something like pip is usually running a ton of unvetted code downloaded from the internet. If you trust such package managers, you might as well curl to a shell.
- bravetraveler 4y ago
  Apologies, that's fair -- there are levels to my rant. That's a very important part. I'll take package managers over shell scripts in concept for one main reason: they reduce reinvention. The supply chain is always of concern, of course. A shell script benefits from coreutils -- cp, mv, things like that. You're on your own for everything else, I don't trust that. They themselves are untrusted code -- for all we know there's no VCS behind it at all. A package manager at least offers some guardrails! With packages on OBS/COPR, you can at least know/verify the sources you're installing were built in a clean (offline) environment from the upstream sources. It's a small, but notable, improvement. Also consider you need to rebuild your system and you'd like it to look the same after. Will you find it easier to run 'pip freeze' / 'dnf history userinstalled'... or crawl your shell history for curl | bash and resolve any drift?
masklinn 4y ago
> Those services I mentioned -- COPR/OBS, they can be the trusted sources by your users. But there's nothing trusted about them is the point, you can ship a deb or rpm with all sorts of scripts running at installation, this is no safer than curl | sh. If anything it's worse, when you "curl | sh" and it requests sudo you can go "mmm no we're not doing this I will happily risk compromising all my user data but it stops at my system integrity". rpm or deb you're already running as root. > If you trust the developer/maintainer, you can trust these services. And you can also trust their site which you're curl-ing from.
- bravetraveler 4y ago
  If we assume the worst of the maintainer/packager, of course it's no better. I'm assuming some adherence to these guidelines, otherwise they should be removed from the service: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_no_files_or_directories_under_srv_usrlocal_or_homeuser https://docs.fedoraproject.org/en-US/packaging-guidelines/#_... A package adhering to this guideline modifying system files, as designed, is not a problem. They are explicitly prohibited from modifying user data. My point with managers vs scripts is that managers provide some sanity. Not perfection. I trust: - a versioned package - built to the linked standards - from upstream sources in an offline environment Far more than I do curl | bash. There is far less ambiguity and I can actually reproduce this exact environment at some point.