3 ms·

A bash script can be signed too. See article. How many projects provide GPG signatures for their tarballs? How often do you check signatures on tarballs?

4ad 11y ago
> How often do you check signatures? Every time you run apt-get. So the answer is almost every time.
- FooBarWidget 11y ago
  The context of the comment is source tarballs. How often do you check the signatures on random tar.gz you download?
  - 4ad 11y ago
    tar.gz vs. curl|bash is a false dichotomy, there is no reason for either. We have better ways to install software these days. And yes, when I download tar.gz (e.g. when I am responsible of managing my own packages) I do check the signatures. You should, too.
    - tokenizerrr 11y ago
      Could you point me to the better way of installing software that will work on all Linux distros?
      - stephenr 11y ago
        District-appropriate packages. Use the right fucking tool for the job.
        tokenizerrr 11y ago
        That will not work on all Linux distros. That is writing a specific installer for each distro, which does not satisfy my requirements and as such is not the right tool for the job.
        stephenr 11y ago
        > That will not work on all Linux distros The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer. > That is writing a specific installer What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where.
        tokenizerrr 11y ago
        > The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer. Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere. > What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where. You will probably write a script to build your package, right? That's writing an installer. Or a builder for an installer, or however you want to call it. The point is that you now have to do work for every distro you want to support, and all users without a package manager that you support is SOL.
        stephenr 11y ago
        > Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere. Unless the user has existing files with the same names there. Or they edit a config file you placed in /etc/ and then they run the installer for a new version. Oh so now your "simple" installer has to handle version upgrades, and file conflicts? If your software is literally so simple as files in /usr/bin and /etc, building packages to install those files should be easier than writing a good install script, because the package manager will handle so many use-cases for you out of the box. > You will probably write a script to build your package, right? No? I have a makefile which can do the actual building and installing. dh_make will generate a debian directory, and debuild will call this makefile. An RPM specfile also will have calls to make build, make install, etc. None of this is writing an installer unless you consider a makefile having an "install" target "writing an installer". > The point is that you now have to do work for every distro you want to support If the installation is as simple as you claim, the packages will be simple wrappers around the results of a makefile. If its more complex, then packages are still easier to maintain, because you don't need to worry about "what distro am i on, and do i need to check what the apache binary is called, or what packages are installed by default". > and all users without a package manager that you support is SOL. If I haven't covered some Distro, it's hardly difficult to give them a .tar.gz containing the tree created by the aforementioned `make install`. This is still less work than your special installer script.
      - lmm 11y ago
        LSB-compliant RPMS, though there are a few aggressively antisocial distributions that don't support them as well as they should.
        ape4 11y ago
        I just want to add my agreement to this. If the LSB (Linux Standard Base) was better supported these hacks would not be necessary.
      - rkeene2 11y ago
        AppFS :-)
raesene4 11y ago
This is why signatures should be embedded into the packaging and distribution mechanism, to reduce manual steps. Looking at Dockers deployment of Content Trust as an example of this. You still have a trust decision on first use, but it's better protection than nothing.
- kentonv 11y ago
  > You still have a trust decision on first use, but it's better protection than nothing. That's what you're getting by curl|bashing sandstorm today (if you skip the PGP verification step). Once installed the updater verifies signatures automatically.

4ad 11y ago

> How often do you check signatures? Every time you run apt-get. So the answer is almost every time.

FooBarWidget 11y ago
The context of the comment is source tarballs. How often do you check the signatures on random tar.gz you download?
- 4ad 11y ago
  tar.gz vs. curl|bash is a false dichotomy, there is no reason for either. We have better ways to install software these days. And yes, when I download tar.gz (e.g. when I am responsible of managing my own packages) I do check the signatures. You should, too.
  - tokenizerrr 11y ago
    Could you point me to the better way of installing software that will work on all Linux distros?
    - stephenr 11y ago
      District-appropriate packages. Use the right fucking tool for the job.
      - tokenizerrr 11y ago
        That will not work on all Linux distros. That is writing a specific installer for each distro, which does not satisfy my requirements and as such is not the right tool for the job.
        stephenr 11y ago
        > That will not work on all Linux distros The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer. > That is writing a specific installer What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where.
        tokenizerrr 11y ago
        > The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer. Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere. > What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where. You will probably write a script to build your package, right? That's writing an installer. Or a builder for an installer, or however you want to call it. The point is that you now have to do work for every distro you want to support, and all users without a package manager that you support is SOL.
        stephenr 11y ago
        > Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere. Unless the user has existing files with the same names there. Or they edit a config file you placed in /etc/ and then they run the installer for a new version. Oh so now your "simple" installer has to handle version upgrades, and file conflicts? If your software is literally so simple as files in /usr/bin and /etc, building packages to install those files should be easier than writing a good install script, because the package manager will handle so many use-cases for you out of the box. > You will probably write a script to build your package, right? No? I have a makefile which can do the actual building and installing. dh_make will generate a debian directory, and debuild will call this makefile. An RPM specfile also will have calls to make build, make install, etc. None of this is writing an installer unless you consider a makefile having an "install" target "writing an installer". > The point is that you now have to do work for every distro you want to support If the installation is as simple as you claim, the packages will be simple wrappers around the results of a makefile. If its more complex, then packages are still easier to maintain, because you don't need to worry about "what distro am i on, and do i need to check what the apache binary is called, or what packages are installed by default". > and all users without a package manager that you support is SOL. If I haven't covered some Distro, it's hardly difficult to give them a .tar.gz containing the tree created by the aforementioned `make install`. This is still less work than your special installer script.
    - lmm 11y ago
      LSB-compliant RPMS, though there are a few aggressively antisocial distributions that don't support them as well as they should.
      - ape4 11y ago
        I just want to add my agreement to this. If the LSB (Linux Standard Base) was better supported these hacks would not be necessary.
    - rkeene2 11y ago
      AppFS :-)

raesene4 11y ago

This is why signatures should be embedded into the packaging and distribution mechanism, to reduce manual steps. Looking at Dockers deployment of Content Trust as an example of this. You still have a trust decision on first use, but it's better protection than nothing.

kentonv 11y ago
> You still have a trust decision on first use, but it's better protection than nothing. That's what you're getting by curl|bashing sandstorm today (if you skip the PGP verification step). Once installed the updater verifies signatures automatically.