update wolfboot for option of using local wolfssl source and add wolfhsm recipe - #174
update wolfboot for option of using local wolfssl source and add wolfhsm recipe#174JacobBarthelmeh wants to merge 4 commits into
Conversation
The FIPS Ready recipe could only take its sources from a local directory or an already-extracted tree, so every build host had to stage the archive by hand. The GPLv3 FIPS Ready bundles are published openly, so there is no reason to require that. wolfssl-commercial.bbclass already builds a SRC_URI out of a remote URI for the GCS case, and nothing on that path is GCS specific. Generalize it as COMMERCIAL_BUNDLE_URL, taking precedence over COMMERCIAL_BUNDLE_GCS_URI, and expose it from wolfssl-fips-ready.bb as WOLFSSL_SRC_URL. Existing local directory and GCS setups are unaffected.
|
Retest this please Jenkins |
night1rider
left a comment
night1rider
left a comment
There was a problem hiding this comment.
Some things I found. Biggest issues are with the newer syntax/variables related to the wrynose lts.
| # A plain download URL and a gs:// path are handled identically here: both | ||
| # are just a URI bitbake's fetcher understands. COMMERCIAL_BUNDLE_URL takes | ||
| # precedence so a recipe can offer the public download as its default while | ||
| # still allowing a GCS override. |
There was a problem hiding this comment.
Comment says GCS can still override, but url or gcs_uri means a non-empty URL wins and gcs_uri is never read. Might be good to comment that if both are set GCS is ignored.
| SRC_URI = "git://github.com/wolfSSL/wolfHSM.git;protocol=https;branch=main" | ||
| SRCREV ?= "4aeecb2c35686bd4daeb40b3537500d15a93aff9" | ||
|
|
||
| S = "${WORKDIR}/git" |
There was a problem hiding this comment.
Older Yocto releases unpacked source straight into WORKDIR, which is why ${WORKDIR}/git used to be right. Newer ones unpack into a subfolder called UNPACKDIR and name the checkout after the recipe, so that path no longer exists. wrynose is listed in LAYERSERIES_COMPAT, so this layer promises to work there, and oe-core now rejects this exact line: bitbake wolfhsm stops at do_unpack with "Recipes that set S = "${WORKDIR}/git" ... should remove that assignment". Scarthgap will not show this, because it has no UNPACKDIR at all. wolfssl, wolftpm, wolfboot and others already test for UNPACKDIR and handle both layouts.
|
|
||
| # Guard against a half-copied tree: the pipeline above reports only the | ||
| # extract side's exit status under a plain POSIX shell. | ||
| if [ ! -f "${WOLFBOOT_WOLFSSL_STAGED_SRC}/wolfcrypt/src/asn.c" ]; then |
There was a problem hiding this comment.
This catches a copy that produced nothing at all. It will not catch one that started fine and died halfway, disk filling up, or a permissions problem part way down. In that case asn.c already exists, the check passes, and the build carries on with an incomplete tree.
Not sure if this is something we want to account for.
| # are just a URI bitbake's fetcher understands. COMMERCIAL_BUNDLE_URL takes | ||
| # precedence so a recipe can offer the public download as its default while | ||
| # still allowing a GCS override. | ||
| remote_uri = d.getVar('COMMERCIAL_BUNDLE_URL') or gcs_uri |
There was a problem hiding this comment.
When BitBake cannot find a variable, it does not blank it out. It leaves the raw text ${FOO} sitting in the value. That text is not empty, so this test passes it through and it ends up in SRC_URI as if it were a real web address. I tried it and parsing stopped across the whole build with MalformedUrl. The function above already guards for this with not X.startswith('${'), so the same check here would fix it.
| # ${WORKDIR}, not ${UNPACKDIR}: the layer still supports pre-styhead | ||
| # releases (LAYERSERIES_COMPAT reaches back to sumo) where file:// SRC_URI | ||
| # entries unpack straight into ${WORKDIR}. | ||
| install -m 0644 ${WORKDIR}/wolfhsm.mk ${D}${datadir}/wolfhsm/wolfhsm.mk |
There was a problem hiding this comment.
On newer releases a file:// entry lands in ${UNPACKDIR}, not directly in ${WORKDIR}, so this path points somewhere the file is not. I confirmed it separately by fixing only S, which left this failing on its own with install: cannot stat '.../wolfhsm.mk': No such file or directory.
| # order the class resolves them: | ||
| # | ||
| # 1. WOLFSSL_SRC_DIRECTORY - an already-extracted source tree. No fetch. | ||
| # 2. WOLFSSL_SRC_URL - a URL bitbake downloads the archive from. The |
There was a problem hiding this comment.
wolfssl-linuxkm-fips-ready.bb still only understands the GCS path, a local directory, and an already-extracted folder. It never sets COMMERCIAL_BUNDLE_URL, so when a user sets WOLFSSL_SRC_URL it builds a file path with no directory and fails on the checksum lookup.
| if remote_uri and bundle_archive: | ||
| unpack_flag = ';unpack=false' if bundle_archive.endswith('.7z') else '' | ||
| sha_flag = f';sha256sum={bundle_sha}' if bundle_sha else '' | ||
| filename_flag = f';downloadfilename={bundle_archive}' | ||
| return f'{gcs_uri}{filename_flag}{unpack_flag}{sha_flag}' | ||
| return f'{remote_uri}{filename_flag}{unpack_flag}{sha_flag}' | ||
|
|
||
| bundle_dir = d.getVar('COMMERCIAL_BUNDLE_DIR') |
There was a problem hiding this comment.
This task exists to unpack password-protected .7z bundles by hand, which is why it wants a folder to look in. A plain .zip from a URL needs none of that, because BitBake has already downloaded and unpacked it. The task knows this at line 198, where it says "not a .7z, let BitBake handle it" and returns, but line 186 demands the folder first and stops the build before getting there. I built it: do_fetch succeeds, then COMMERCIAL_BUNDLE_DIR not set. Moving :198 above :186 fixes it and leaves the .7z path unchanged.
No description provided.