13303 2019-04-21 16:47:59 +0000 git fetcher should verify tags for releases 2025-02-27 16:00:47 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 2.7 All Multiple NEW Medium enhancement Future 1 bunk unassigned JPEWhacker p.lobacz poky.bs.watcher poky.watcher randy.macleod richard.purdie --- --- Yes (doc changes required) oldest_to_newest 83626 0 bunk 2019-04-21 16:47:59 +0000 Especially due to the instability of github tarball releases it has become common to use the git fetcher also for releases. This leads to the following problem: --- a/meta/recipes-kernel/cryptodev/cryptodev.inc +++ b/meta/recipes-kernel/cryptodev/cryptodev.inc @@ -4,7 +4,7 @@ LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263" SRC_URI = "git://github.com/cryptodev-linux/cryptodev-linux" -SRCREV = "fd8b15ef1c8398a69a37932ee48c74ab40329a29" +SRCREV = "f971e0cd4a0ebe59fb2e8e17240399bf6901b09b" This change does move the package from a release to a git snapshot, but both look the same and it is impossible to see or review what is going on. It should be assumed that every upstream release is tagged, and then the tag made mandatory for SRCREV that match a release. Then could be checked automatically with (pseudo-code): if(TAG) (commit(TAG) == SRCREV) TAG xor (PV contains "+git") 90437 1 richard.purdie 2021-05-20 15:32:11 +0000 We already have the option of adding a tag to the SRC_URI which the SRCREV would be verified against. We could then make it a general policy that the URL should have a tag specified in it for OE-Core recipes? 94963 2 p.lobacz 2023-02-17 17:53:27 +0000 (In reply to comment #1) > We already have the option of adding a tag to the SRC_URI which the SRCREV > would be verified against. We could then make it a general policy that the > URL should have a tag specified in it for OE-Core recipes? I am trying to use tag with git fetcher and it causes me a problem like that https://www.openembedded.org/pipermail/openembedded-core/2017-November/144422.html and my SRCREV is pointing me to the correct hash. My bitbake is 2.2 94981 3 p.lobacz 2023-02-22 09:25:01 +0000 OK,I have found a solution for that issue. I need to set nobranch=1 and tag=hash_value of tag release. By hash_value for a tag release I mean the hash of the that e.g. which can be returned by `git ls-remote --tags <remote_branch> refs/tags/<tag_id>` 101246 4 JPEWhacker 2025-02-27 16:00:18 +0000 We don't want to move away from SRCREV specifying SHA-1, but it would also be useful to be able to mark a way for the fetcher to check if a specified tag matches that SHA-1, perhaps something sort of like: SRCREV = "f971e0cd4a0ebe59fb2e8e17240399bf6901b09b" SRCREF_TAG = "v1.0.0" (although another mechanism might be preferred). This would give the best of both worlds where we are fixed to a SHA-1, but it would be clearly indicated what tag that tag is supposed to be, and we would be notified if upstream did something silly like move a tag 101247 5 JPEWhacker 2025-02-27 16:00:47 +0000 That should be SRCREV_TAG for reference