BLAKE2 not checked when building add-on?

Add-Ons
1

Hello,

I just finished a build for my add-on and realized that I had not updated the lfs file with the b2sum information for the new source file. But the build completed successfully and the package worked when I installed it on my firewall.

Is this expected behavior of make.sh for building an add-on? How is the b2sum used by make.sh?

Regards,
Stephen

Checking for missing rootfiles...
Checking for rootfile consistency...
Packages have created new files                                         [ WARN ]
  coreutils-9.5                                                         [ WARN ]
*** Build Finished                                          [    10:51 ][ DONE ]
~/git/ipfire-2.x$ grep BLAKE2 lfs/speedtest-webgui 
$(DL_FILE)_BLAKE2 = 6fd40803846aba68ab98e2ded69482a65570610754274e3d4be5e5bee9d4004bc45d7cea2073f2d8197f8684f6586ddaf76abdc7a1e8ab9adde12063b7af4c80
b2 : $(subst %,%_BLAKE2,$(objects))
$(subst %,%_BLAKE2,$(objects)) :
~/git/ipfire-2.x$ b2sum cache/speedtest-webgui-0.8.0.tar.gz 
3d26a342e02cac7d0a877b3632cf44b5ed8cba4c6ddb311fa52a2fd977b4d15823bac577fc7de542f13816e2ba17394f9f8d0ac08dbc9562b8256982b45070f8  cache/speedtest-webgui-0.8.0.tar.gz
2

Run ./make.sh downloadsrc and it checks the b2sum values and that the source file with the correct version number is available in the cache directory, or it tries to download it from the IPFire source location.

The standard way to run the build, which I do every time I am doing a build (core or addon) is

./make.sh gettoolchain
./make.sh downloadsrc
./make.sh clean
clear
./make.sh build
3 Likes
3

Hello,

I reran the build with the steps above and the ./make.sh downloadsrc did indeed pick up the mismatched b2sum values and throw an error.

Thanks for explanation and assistance.

Regards,
Stephen

1 Like
4

This would be a concern if things are not being picked up correctly.

I did make a change recently to get some better performance out of this when doing a rebuild. This is as follows:

Formerly, the checksums were checked first, whenever we walked past a package. That means that when the build aborted and was re-run, all checksums would be checked against which was somewhat slow.

It should now only check the checksums when a package is actually built. In a usual clean build that is all of the time, but in case of a partial rebuild, only the packages that have not been built will be checked again.

I deemed this is good enough because we would never allow packages that don’t match their checksum being extracted into the build environment.

I might have broken the code and this might actually not work as intended, but this is what I intend. Can you confirm that your case is breaking this?

Also ./make.sh downloadsrc will check all checksums all of the time. On the automatic builders we always run this first, so we should not have any compromised builds here at all.

1 Like
5

If the intent was that running the build command would also check the b2sum and flag up that it is not matching, then that is not happening.

I tested it out by changing a b2sum in the linux lfs and then ran the downloadsrc command and it flagged up the b2sum not matching.

I then ran the build command and it built the linux package without any message.

6

Not sure if this is relevant to the issue at hand, but my build process was doing iterative builds without doing a ./make clean or anything else in between them.

After a previous ./make build, I would drop the new addon source into cache, edit the lfs with the new b2sum (until I forgot that time) and then run ./make build again. I was doing this because with a ./make clean, the rebuild would take about 2 hours, without the ./make clean the rebuild would take about 10 minutes.

The point being that just changing the source in the cache without any other changes was enough for it to get picked up and built. So make.sh is detecting that the source changed and building it, but not checking the b2sum when doing so.

Regards,
Stephen

1 Like
7

Hello Stephen,

you are right. This is indeed a problem when the source has already been downloaded. I have submitted a patch to the development mailing list:

https://patchwork.ipfire.org/project/ipfire/patch/20241221105442.2607315-1-michael.tremer@ipfire.org/

Thanks for reporting this.

2 Likes