Ok. Point made @Sven 
I would continue to advocate that the wrapper was pausing WHILE TELLING THE USER what was going to happen next, but now get that it would not serve the expected outcome… While reminding everyone that scripts calling the proxy directly today would work, without that non-existing safeguard. And that people not blocking that feature (which is used by dnf/apt to update Templates) as of today could have scripts download stuff if no wrappers are made available to pause, failsafe those downloads. So what to do with that?
Having 3 seconds pausing will open more widely, I get the point.
Following others considerations, it would be better to have the wrappers failsafe, explaining why, or have MOTD explaining security properties/differences implemented in the TemplateVM.
Solutions are:
- Deploy GPG keys + Repos from packages.
- MOTD/wrappers educate/telling users what is going on/what to do.
- Have users pass explicitely wget/curl/other arguments to be able to use those commands.
- Have cloned TemplateVMs have internet access momentarily.
Well, now more then even, I would love to have tinyproxy logs to at least match hostnames/timestamps for dnf/apt update attempts. Otherwise, this proxy is more security by obscurity (not knowing where the proxy was, which is not randomized per install but static per installation) and once known, can be used by scripts.
Again, the idea was to permit installation per upstream software installation guides. Did not want to address malware download scripts, evolved in such way to pause user before doing so, where now people want more protection from the proxy once knowing that it is there to be used if known per such script.