[Looks like some of the ideas in this post were anticipated while I was typing it.]
Let’s step back for a moment. Why don’t templates have unrestricted network access anymore? To prevent users from doing dangerous things in templates, right? But this assumes that all templates are at the same ultra-high-trust security level, which isn’t realistic. In practice, many users want to have templates of varying trust levels. Some are ultimately trusted, some aren’t trusted very much at all, and others are in-between. Sometimes, users need to use some untrusted piece of software in a couple qubes, but they don’t trust it at all. They want to be able to install it in an untrusted template for use with untrusted app qubes in order to keep all of that separate from their trusted templates and app qubes. The problem is that the current one-size-fits-all policy of “no templates are allowed to have direct network access” doesn’t support this common use case. That’s what’s driving you to find workarounds.
See, that’s the thing. I’m not convinced that is the actual problem. That sounds more like a symptom of the underlying problem, which is the one-size-fits-all nature of the way template networking works. Suppose we added a feature where you could toggle on “unsafe mode” for a template, and doing so grants that template normal network access just like an app qube (and just like templates used to work back in the day). Then users would be able to add new keys to templates and install software in them the normal ways, without any proxy hoops to jump through. Of course, there should be a big red warning when enabling “unsafe mode” that explains just what you’re getting yourself into. And, if you prefer, you can instead have this “unsafe mode” (or whatever you’d like to call it) implement the networked-but-firewalled system we had more recently in Qubes history, where the user had to choose to allow temporary network access for 10-15 mins or however long.
Either way, we have the UX challenge of having to explain to the user why their desire to install (or enable the installation of) non-default-repo software is a security risk.
My point here isn’t that one solution would be better than the other, but rather that we should understand the nature of the underlying problem.
I can see the appeal of this approach, since the “direct network access” approach allows for doing “stupid” things in templates, but the trade-off is that the workaround is less robust. It’s only a matter of time until users start asking how to install software that doesn’t work with wget-proxy or curl-proxy. (Actually, they already are.)
Of course, this is just a specific instance of the more general trade-off between security and convenience.
Realistically, many (not all) users will follow upstream instructions without understanding them. Since those commands could do anything, this is tantamount to doing “crazy stuff” in a template. In other words, executing commands you don’t understand in a template is effectively doing crazy stuff in that template. But look, I’m not here to argue about whether it’s “crazy” or not. That’s beside the point. The point is that users want untrusted templates, but the current no-networking safeguard applies to all templates, hindering that use case.
This is not necessarily a mistake. After all, Qubes OS should be secure by default, so defaulting to the most secure assumptions for templates makes some sense. But that doesn’t change the reality that many users will continue to want untrusted templates and be stymied.
I agree with the user-education philosophy, but realistically, many users’ understanding will only get as far as “replacing wget with wget-proxy makes it work for some reason, so I just do that to make it work.”
Also, many users are allergic to the command line, so this is still a stepping stone to a GUI solution.