I’ve already said why I think this is a bad idea.
That marker makes sense where the updateVM is guaranteed to go through
Tor, as is supposedly the case with sys-whonix.
It doesn’t make sense in a case where it’s trivial for the user to change
things so that the updateVM does not go through Tor. For the cacher,
the only setting is that the netvm or netvm of some upstream qube is set
to a Tor proxy. But that is quite fragile, and easily changed in error.
If such a change were made then Whonix would allow updates that dont go
through Tor, and I assume that that wood be unwelcome in Whonix.
(Actually it’s this sort of check that is one reason why I dont use
Whonix, but that’s a separate issue.)
This is a major intervention, and I am not clear it is the right think
to do.
The solution I have promoted so far is to use a proxy setting in the
qube and set netvm to cacher; no one has had any problem with that.
I think that I prefer that option - not least because it requires users
to think about whether they should be installing software in the qube
(doesn’t work without user action), or the template (works).
We still see posts about this - “I installed foo and it disappeared
when I restarted the qube”.
When I comment in the Forum or in the mailing lists I speak for myself.