Can we talk about package signing?
Hi Crux, In my (humble) opinion, package signing for Crux's ports system should be seriously considered. It's a modern feature and is not too complex to implement. The advantages are twofold. First, a "web of trust" can be developed between core (and opt, contrib, whatever) ports maintainers so that there is some degree of accountability for the origin of any given port. Second, there is more assurance that a Pkgfile, footprint, or md5sum wasn't modified without the port maintainer's knowledge. The disadvantages include ports tree bloat (less than 1kB per port) and a dependency on crypto software (gnupg probably). Assuming we use something like gnupg's detached signatures, the process could be entirely optional. Perhaps there could be a configuration directive that controls whether the signatures are downloaded, and/or whether they are actually verified. The ports system would work just fine (and just as it does now) if the user chooses to do neither. As a quick example, to create a detached signature, the port maintainer would do this: gpg --output portname.asc --detach-sig --armor Pkgfile .footprint .md5sum And to verify, a user would do this: gpg --verify portname.asc Pkgfile .footprint .md5sum They would first need to import the public keys of the port maintainers, done like this: gpg --recv-keys $KEYID The $KEYID is given if a verification is attempted on a signature for which a public key does not exist. The --recv-keys option downloads the public key from a keysesrver and imports it automatically. Alternatively, Crux could ship the public keys of port maintainers so that this step could be omitted. One little caveat is that the list of files for signature creation and verification must always appear in the same order. Anyway, I think some discussion is called for. Regards, Ryan (rmull on IRC)
Hi Ryan. On Wed, May 30, 2012 at 5:07 PM, Ryan Mullen <rmmullen@gmail.com> wrote:
In my (humble) opinion, package signing for Crux's ports system should be seriously considered. It's a modern feature and is not too complex to implement.
A *package* and *ports* system are IMO two different things: the first is a binary blob prepared for the end user by a responsible packager. The latter is nothing but a bash script that you may use as-is to compile the code yourself (and any Pkgfile you should IMO examine before using it). Therefore, in the first case there's someone standing between you and the source code, while in the other it's only the code and you. In both cases the same code is used, but only in the first one someone other than you is responsible for producing the binary. That's why the thing is called *package signing*, because in the other case -- if I understand it correctly -- there's actually nothing to sign. ;) (A different thing is code signing, but that's the upstream's pain, not port maintainer's.)
Second, there is more assurance that a Pkgfile, footprint, or md5sum wasn't modified without the port maintainer's knowledge.
Well... .md5sum has very little to do with maintainer's job: basically it proves that the source tarball you pull to build the package on your system is the same the port maintainer used to create the Pkgfile. Other files included in the port should be nothing but text files, and the checksum should be enough to prove they are valid. Any other signing here, even if possible, seems a bit superfluous because with a distro like CRUX you should be able to verify if the script you run contains malicious code or not.
The disadvantages include ports tree bloat (less than 1kB per port) and a dependency on crypto software (gnupg probably).
The main disadvantage IMO is that the whole idea of *package* signing doesn't improve the security of the *ports* system because it wasn't meant to be used there. You can argue if the entire port can be signed somehow, though this would require high level of correctness as far as the content of .footprint files is concerned (among other things), and those not always appear to follow the changes in the package content. Besides, I decided to use CRUX because it allows for even further package customization than other distros, and because I wanted to compile the packages I use so that they fit my machine's specs (avoiding at the same time 'universal' binaries: a binary is a convenient way to go, but not always the best one). The simplicity of ports system improves security by the way it works: making a package myself I know who should be blamed if something doesn't work the way I wanted. :) And if the security flow comes from the upstream, well, that's where package signing can't help a lot really... Anyway, the bottom line: let's verify the scripts we run before we press Enter. For distros like CRUX it should be the default user action. ;) Best regards, bohoomil
participants (2)
-
bohoomil -
Ryan Mullen