3 ms·

I'm with you! If you're serious about your software (read: you want users)... either make a Flatpak manifest, package spec, or something equivalent. Point is,

I'm with you! If you're serious about your software (read: you want users)... either make a Flatpak manifest, package spec, or something equivalent. Point is, somebody made something better than this little install shell script. I'll accept pip, I'm not picky. There is almost surely no reason for $thing to be writing to my system directories. Nobody should be coaching this, it can go wrong in every way. Binaries and libraries can come from my home directory. You won't find /home mounted with noexec outside of strict compliance environments. Build services like OBS and COPR make the actual equipment investment of building packages basically non-existent. Roaming repositories for any distribution you could want. Leaving the one-time cost of writing out the specs... and I suppose maintaining dependency creep. That maintenance isn't that expensive because you'd be maintaining them in the script anyway. You're just using common domain language Do these things and you cover 95% of the DSL: - PKGBUILD (basically the script, AUR means you'll get maintainers) - RPM - DEB Say a fourth significant option comes around, I'll guarantee you the concepts are similar enough. Macro creep is real, but this is the cost of maintenance work. Give us something to maintain. Signed, - A person maintaining several packages for projects with no upstream involvement

fiddlerwoaroof 4y ago
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.

fiddlerwoaroof 4y ago

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.