On Thu, Aug 24, 2017 at 01:22:33PM +0200, Laslo Hunhold wrote: > On Thu, 24 Aug 2017 11:02:46 +0200 > ilf <i...@zeromail.org> wrote: > > Dear ilf, > > > HTTPS is good, and it's the new default: > > https://www.eff.org/deeplinks/2017/02/were-halfway-encrypting-entire-web > > The hierarchical trust model of X.509 make it suitable for many > > things, but for signing code that we build and run on our machines, I > > would like to use the strongest available trust model. > > given we don't PGP-sign our commits and suckless-projects are hosted on > the suckless server, going full overboard with PGP on the release-area > is overkill. > I won't support the PGP snake-oil movement just so you can sleep well > at night. If you want to go with maximum trust, you can compare the > tarball-contents with the status of the git-repo at a certain tag. >
This only checks if the data is the same, not if it is signed/approved by the releaser. You probably know this, but there is a difference between normal git tags (reference) and a git annotated tag (used for PGP signs). git references can be easily modified. > > The OpenPGP "web of trust" might be a little clumsy to use for some > > people and others might not have a trust path to the signing key(s). > > But when you have verified the signing key, it's the strongest > > cryptographically verified trust method out there. I'm sure many > > people here can use it correctly, and surely it's now suckless' > > fault, if people use it wrong. > > As nice as PGP sounds, I think it has seen its best days already for > general usage. I know no package manager that implements this model > (tell if there is one). The ones I know use hashes. > This sounds outrageous, almost any serious distro implements this model in some way. For example OpenBSD signify(1). A list of hashes can be used for example if the ports are fetched in a trusted way (for example a ports.tgz in an OpenBSD release). > If you trust us suckless developers, you trust our server as well. > There is chance your connection is MITM'd, but we will counteract with > HTTPS. There's simply no reason to go further, given the entire > development model is not based on this kind of authentification model. > I disagree, it assumes as if we're the only part in the trust chain. Releases can/must be signed locally. > > Providing an OpenPGP signature does not hurt anyone and does not > > force anyone to use it. > > But it means more work with questionable benefit. It's already > difficult enough to keep the patches on the site up-to-date and even > (as Hiltjo discovered) to provide checksums for all packages on > dl.suckless.org. It's easy to delegate such things on the mailing > list, proposing them (like in your position), but not actually doing > anything. > Those doing the work are the ones that should be asked. > We must have scripts for this. Generating the SHA256 checksums was easy. There were 2 checksums missing for surf which were fixed. If we automate this then there is less chance to forget anything. We should remove MD5 and SHA1 checksum support. > > If people trust code from git, http or https - nice for them. > > If people trust checksums - nice for them. > > If people want to verify code authenticity and integrity via OpenPGP > > - please let them! > > How many people even do that? I guess the number is so low, it would > take less time to hand-pack a tarball for each after a personal request > per mail, provided of course they trust me. > But will you PGP sign the mail? :P I think it's a good idea if we start to (optionally) sign (git) releases. This can be discussed further. -- Kind regards, Hiltjo
