On Thu, Aug 24, 2017 at 01:22:33PM +0200, Laslo Hunhold wrote:
> On Thu, 24 Aug 2017 11:02:46 +0200
> ilf <ilf_AT_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
Received on Thu Aug 24 2017 - 13:45:35 CEST