Re: [dev] file integrity github project

From: Hiltjo Posthuma <>
Date: Thu, 24 Aug 2017 13:45:35 +0200

On Thu, Aug 24, 2017 at 01:22:33PM +0200, Laslo Hunhold wrote:
> On Thu, 24 Aug 2017 11:02:46 +0200
> ilf <> wrote:
> Dear ilf,
> > HTTPS is good, and it's the new default:
> >
> > 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
> 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,
Received on Thu Aug 24 2017 - 13:45:35 CEST

This archive was generated by hypermail 2.3.0 : Thu Aug 24 2017 - 13:48:34 CEST