Thank you for taking this seriously and talking to devs.
Thanks to @unman to clarify second bulleted point from my previous post and consequently user (and now obviously wider) unawareness on the case is security risk per se. So - unawareness is risk per se
, not not-updated template. That is why I really think several words @adw will eventually add to the docs would definitely increase liability if nothing else.
Using outdated with the bugs yet to be discovered KeepassXC in my offline vault
is something not only me, but anyone would want to avoid at all costs, and if that’s not the risk, than we should actually completely turn off updates.
Thanks to @Insurgo for ellaborating my idea about testing @ludovic’s one per a given TemplateVM AppVM being online
.
Since there will be inexperienced users to blindly implement the idea of updating over qrexec, and considering that there are even experienced users that aren’t aware on the terms of offline and online:
Then, you say “offline Debian mini-pc” which is “cable tether”-ed
Whoops, terminology failure, my bad. By offline I meant “not directly connected to the internet”, after a short trip to an online dictionary I now realize that’s not exactly what offline means.
probably would be a good idea this to be emphasized somewhere in the docs, too.
Thanks to @Insurgo about pointing out about vault’s specifics. Although in my setup only 3 VMs have netVMs set: sys-fwall, sys-whonix and cacher, while using updates-proxy-setup
on all non-templates, except on vault and vault-alikes, that is why on the latter I have specifically added updates-proxy-setup
service to the Settings and deselected it, specifically disabling the service that way, thus preventing vault going online when future potential decision changes actual default state of the service.
But according to @Insurgo’s terrifying conclusion. even this isn’t enough, so I’m not clear if disabling update-check in vault would have implications on overall system in every possible way imagined,