07:12 <sjg1> marex: If you see p34 in those slides, the properties in the configuration node itself are protected. The properties in the signature subnodes are not

07:13 <sjg1> marex: Changes to properties in the signature node may still cause a verification failure, e.g. changing the algorithm

07:17 <sjg1> marex: There is also quite a bit of info about changing a FIT at https://docs.u-boot.org/en/latest/usage/fit/beaglebone_vboot.html (starting hawlfway down)

11:37 <marex> sjg1: I am not talking about signed fitImage

11:37 <marex> sjg1: I am talking about plain and simple fitImage with hash nodes

12:13 <sjg1> Oh. Well, you could do that

14:06 <marex> sjg1: you wrote "it makes no sense to add a hash node to a configuration" ... but clearly with signed fitImage, the configuration node properties have to be somehow protected, presumably by calculating hash of those and signing the hash ? So why can we not add that same hash to configuration node ?

14:21 <sjg1> marex: You can certainly implement that

14:40 <marex> sjg1: wait ... I am completely confused by your recent answers, they even contradict each other ... you wrote I can add a hash to config node, but it makes no sense, but it is not implemented, even if signed fitImages do just that ... ?

14:45 <sjg1> marex: I am also very, very confused

14:53 <sjg1> marex: Are you asking why, since signature-creation hashes the configuration node (and other things) we could not use that same code for the non-signature case, and add a hash?

14:56 <marex> sjg1: no

14:57 <marex> sjg1: I just want to add a hash to the configuration node and that hash is currently not calculated and inserted even if I add the hash@ node into configuration node, and I want to know why, as that is necessary to detect bitrot on the configuration node

14:59 <sjg1> marex: Well, it isn't implemented

15:09 <marex> sjg1: so it is not "you cannot hash a configuration" but "it isn't implemented" then ?

15:18 <sjg1> marex: Yes. By 'cannot' I mean it is not implemented

15:20 <sjg1> marex: as in 'cannot today'. But it is just software, so...

17:07 <Tartarus> sjg1: Looking at https://source.denx.de/u-boot/u-boot/-/jobs/932621 it's because the test is wrong I think and needs to be fixed with https://patchwork.ozlabs.org/project/uboot/patch/20241008094646.4052174-1-jerome.forissier@linaro.org/ can you perhaps fix the test, or do I need to ask Jerome?

17:20 <sjg1> Tartarus: Oh that's odd, I just sent an email about it

17:26 <sjg1> Tartarus: I don't know, you could perhaps make the test return -EGAIN ?

17:26 <sjg1> -EAGAIN

17:26 <sjg1> But lwip needs some work on sandbox and I believe Jerome is looking at it

17:28 <Tartarus> This isn't about lwip

17:28 <Tartarus> And no, I'm not wanting to touch the test myself atm

17:40 <sjg1> Tartarus: Oh, I assumed that is why is broke, but I suppose not. I just took a quick look, but I don't know why it fails within CI...seems to work OK in isolation, at least for me

18:28 <Tartarus> sjg1: Hmm, digging a little harder now, sorry, I'll poke Jerome about it since it's a problem outside of sandbox too