Re: Add SHA512 digests to package metadata

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Thu, Oct 22, 2015 at 05:27:50PM -0700, Alistair Crooks wrote:
> On 19 October 2015 at 13:39, Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> > On Mon, Oct 19, 2015 at 01:27:58PM -0700, Alistair Crooks wrote:
> >> My way of working is to make a number of small changes, and lots of
> >> them. This usually prevents big bang scenarios. You obviously prefer
> >> to make fewer, but more far-reaching changes.
> >>
> >> I'm not saying that one approach is better than the other, but I also
> >> think that trying to make your approach work for me is going to be
> >> counter-productive, much as if I were to try to encourage my way of
> >> working onto you.
> >
> > I don't think that introducing @digest for this purpose is any more
> > complicated in nature that hacking in an additional magic comment
> > string. It uses more common parser infrastructure and trades it for a
> > minor complication of making sure that pkg_install itself does not get
> > the SHA512 digest for bootstrap purposes.
> 
> This is missing the point - introducing a new @digest "keyword" to the
> +CONTENT files will take a while (I, for one have no desire to watch screenfulls
> of useless
> 
> pkg_admin: Unrecognised PLIST command `@digest
> SHA512:b98b9bd31f640a6f71249ea7be36d32396971664854b8aadb8022733ca595a2aff9f78f92a5b7e0f0298f86902de2226bf4b4788294888d6cfb71c7f5742f962'
> 
> fly past for every entry in every package where I'm using a downlevel set of
> pkg_install tools to install a binary package that someone has built with new
> pkg_install tools). There is much more of an emphasis on binary packages these
> days, especially with the advent of pkgin and binary package signing.
> Now I'm not ruling out a flagday, just saying that what you're painting as
> "not much work" entails a whole amount of work, actually, but mostly time.

While it is arguable a bit suboptimal that we check the tools version
after parsing the PLIST, it will stop on the first package and tell you
to update pkg_install. As such, you will get the noise for a single
package. I don't think *this* part was much a problem with the last new
PLIST keyword introduced.

The "not much work" is specifically about the amount of code changes.
Heck, I'm even willing to sit down this weekend and get it down
myself...

> > But let's go back to your patch first. The existing @comment handling is
> > quite fragile and subtile. Reording of the MD5 and SHA512 line would
> > mean that old pkg_install will accept the package, but silently skip the
> > content validation. That sounds to me like a good reason for not going
> > down this road.
> 
> This has always been the case, the MD5 lines currently refer to the "current"
> entry in the PLIST/+CONTENTS file, i.e. the one for which you've just had a
> file system path. How would it ever get out of order? There are no human
> users of pkg_create, only what is called from bsd.pkg.mk when making
> the binary package itself. Your example is purely hypothetical, and will not
> happen.

The Debian OpenSSL fiasco should have thought us a good lesson. Inverting
the order of MD5 and SHA512 line seems like a pretty innocent change and
it makes sense to have the stronger check first, right? In fact, your
description pretty much perfectly reflects the issue I have. The MD5
lines currently do not to refer to the "current" entry, but the
immediate last PLIST entry. That's a subtile difference: you can't have
a MD5 entry for a symlink for example.

Joerg