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)