[yocto] git fetcher - AUTOREV and best practices

[Maciej Pijanowski]

Hello,

As explained in the mega manual [1], when using the git:// fetcher,
setting the
SRCREV to ${AUTOREV} will result in building the latest commit from
given git
branch (master, if not specified otherwise).

Using AUTOREV feature in recipe has following implications as far as I
can see:

- the same recipe might get built using different git commit, depending
on when
  the build was run, which breaks the reproducibility,
- it imposes some potential security risk - by specifying the exact
commit in
  the recipe, we can at least say that this revision of this package is fine
  and we want to build it; with AUTOREV we might not be aware of the
code we're
  fetching

I'm wondering whether there are any best practices or strict rules
written down
for recipes getting upstream to follow in this area. When inspecting some of
the layers from the git.yoctoprojects.org, it appears that the AUTOREV
feature
is almost not used, besides a few exceptions.

I'm wondering whether it would make sense to raise a warning when git
fetcher
with AUTOREV is used, so it would be easier to build on top OE / Yocto with
reproducibility / security in mind.

I understand that this feature is mostly meant for development purposes. I'm
just looking for a tools how one could easily make sure that each
fetched source code
is verified prior compilation.

I've already looked at the https:// fetcher (which is mostly used for
fetching tarballs).
It requires the recipe to contain valid md5 and sha256 sums. Even if we
suppress the
error in case checksum mismatch in the recipe by setting the
BB_STRICT_CHECKSUM
to 0, we are still getting the warning, which is the desired behavior I
believe.


[1]:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-AUTOREV
[2]:
https://www.yoctoproject.org/docs/2.0.1/bitbake-user-manual/bitbake-user-manual.html#var-BB_STRICT_CHECKSUM

-- 
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190605/95a66ef8/attachment.pgp>