[LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH

Baptiste Jonglez baptiste at bitsofnetworks.org
Fri Oct 27 01:27:19 PDT 2017

On 27-10-17, Yousong Zhou wrote:
> On 26 October 2017 at 17:50, Baptiste Jonglez <git at bitsofnetworks.org> wrote:
> > When calling a download target, hash verification is now completely
> > skipped if the SKIPHASH variable is set.
> >
> > This allows to easily bump package version:
> >
> >     # Update PKG_VERSION in the package Makefile
> >     $ make package/<mypackage>/download SKIPHASH=1 V=s
> >     $ make package/<mypackage>/check FIXUP=1 V=s
> >
> > This will download the new version of the package, and then automatically
> > update PKG_HASH with the hash of the new version.  Of course, it is still
> > the responsibility of the packager to ensure that the new tarball is
> > legitimate, because it is downloaded from a possibly untrusted source.
> Introducing another knob to the build system seems cubersome.  I
> remembered that hash checking would be skipped if PKG_MD5SUM var was
> empty and the behaviour is very likely the same with PKG_HASH.  The
> workflow can be simply emptying PKG_HASH var while bumping the
> versions, then do the download and hash fixup on the second command.
> This should eliminate the need for SKIPHASH var.

In my opinion, it's bad practice to implicitly skip hash verification in
some special cases.  Before my first patch [1], any typo in the hash would
result in verification being silently skipped.  You can also imagine a
typo in the variable name (e.g. "PKGHASH" instead of "PKG_HASH") and this
would inadvertently result in an empty hash.

When we're talking about bypassing security features, it's much better to
have an explicit knob to avoid mistakes.

[1] http://patchwork.ozlabs.org/patch/809259/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20171027/6e6c9275/attachment.sig>

More information about the Lede-dev mailing list