| 17 Apr 2024 |
 Jacmet | ejoerns: yes, the cut off point between check and install could be varied, E.G. all "safe" or "non-intrusive" installation steps can be done as part of the check | 12:46:47 |
| Jacmet | ejoerns: is there anything built into rauc for such a split? | 12:47:12 |
| Jacmet | E.G. the activation logic could differ between versions, so ideally part of the bundle. Is the solution just to install an activation script from the bundle and then run it some time later? | 12:47:55 |
 ejoerns | Jacmet: No. There is only support for splitting up image writing and bootloader activation. Thus if you update microcontroller or bootloader softwarwe directry from RAUC, this is not an option. | 12:48:27 |
| ejoerns | If you have the firmware in the rootfs and let the components sync/update on system startup, this would be possible | 12:49:26 |
| Jacmet | ejoerns: yes, we do that for some setups, but sometimes their update is a bit intrusive (or just slow) so if possible we like to "pre-update" them as part of the installation step | 12:50:34 |
| Jacmet | with the knowledge that the installation may fail and we have to recover at next boot | 12:51:01 |
|  Marcus Hoffmann set a profile picture. | 13:55:26 |
 shoragan | ejoerns, Jacmet: my main issue with a --dry-run mode is that it opens the door for time-of-check/time-of-use issues | 14:30:24 |
| shoragan | with streaming or mounting from untrusted storage, you can't be sure that the bundle you're checking is actually the one you will be installing | 14:31:09 |
| shoragan | which then leads to the confirmation callback approach. there, the bundle stays mounted and cannot be replaced | 14:31:46 |
| shoragan | you could pass the manifest hash from a --dry-run to the real installation, but that feels too much like a hack | 14:33:29 |
| Jacmet | shoragan: true, but you have that with rauc info as well | 15:00:20 |
 shoragan | Yes, and that's why I'd avoid using it on the target | 15:01:26 |
| shoragan | Hmm, perhaps the manifest hash check during the second run would actually make sense... | 15:06:09 |
| shoragan | Not sure yet. | 15:06:15 |
| Jacmet | shoragan: well, that is always the issue when you do something non-atomic. I don't really think it is a problem as long as the install does the same checks again | 15:07:51 |
|  @libera_leon-anavi:stratum0.org left the room. | 15:27:03 |
| 18 Apr 2024 |
|  iokill left the room. | 04:42:52 |
| iokill joined the room. | 04:44:40 |
| @libera_leon-anavi:stratum0.org joined the room. | 05:44:22 |
| ejoerns | In reply to @libera_shoragan:stratum0.org
ejoerns, Jacmet: my main issue with a --dry-run mode is that it opens the door for time-of-check/time-of-use issues I am not sure in how much this is an issue. It can't bypass any security-related verification. And the suggested check is more like a sanity check. It can only be the case that you assumed something is installable which turns then out to be not (because it was replaced). | 11:47:17 |
| ejoerns | Anyway, the callback is something we should focus on first of all. | 11:47:55 |
| Jacmet | ejoerns: agree about the check/install | 13:32:21 |
| @libera_leon-anavi:stratum0.org left the room. | 15:01:18 |
| 19 Apr 2024 |
|  @libera_ladis:stratum0.org joined the room. | 06:10:17 |
| @libera_ladis:stratum0.org left the room. | 11:02:20 |
|  @libera_mriesch:stratum0.org left the room. | 15:40:40 |
|  gsc left the room. | 18:52:06 |
| gsc joined the room. | 19:22:03 |
