There seems to be a weak spot in Qubes. And that is when you install apps into a Template. If the adversary attacks at that time he can do setup whatever he wants into the template. And you would have to do threat hunting to root out his hack-ware/malware. The enabler to this is due to Qubes not having a sudo password.
Please bundle LibreOffice into the Fedora Template so I don’t have to ever expose myself.
How would an adversary “enter” that template? They have no network. Btw. fedora uses package signing:
The Template must have networking, how else can you install packages ?
Also package signing has nothing to do with the matter. The advesary can install the packages he wants, which are Not what I want.
Qubes GlobalConfig sets sys-net as default proxy for updates. The (simplified) procedure is as follows:
sys-net and signature checkedFor dom0 and whonix-vms it’s not sys-net, but sys-whonix or sys-firewall that gets used as update proxy.
Thanks for explaining the proxy mechanism. Never knew that. Now I feel safer !
Would you mind changing the topic title? It might unnecessarily frighten others.
It is good to wonder and pose questions about security. Never assume that you are totally safe. The curious will read the thread and find out more. Leave the title be.
Adding a question mark would suffice. Thank you.
For those who come later, there is a description of the reasons here, and the mechanism is explained here.
There is also a page about the even more careful methods for update of Dom0.
Reading pages like these gave me a lot of respect for the architects of Qubes.
I revised the title.
This would be true only under the assumption that your template is already at least partially compromised such that your adversary already has user-level access to your template.
If your template is not already compromised, then even full network access would not be sufficient to allow your adversary to execute arbitrary code in your template. If that were the case, then every Linux computer on the planet would be instantly compromised the moment it connected to the Internet, never mind Qubes.
Qubes is designed not to rely on the user/root distinction as a security boundary, but you can use minimal templates if you don’t want passwordless root.
The main purpose of the updates proxy is just to protect users from their own mistakes (e.g., to prevent accidentally browsing the web inside a template). It doesn’t magically make installing packages more secure; it just makes it a bit harder to accidentally engage in network activities other than installing packages. It’s probably not the sort of security mechanism that you seem to think it is, but that’s okay, because the original security problem you described doesn’t actually exist. 
If set to sys-whonix as update proxy everywhere it’s probably also hiding Qubes presence on the computer for adversary like ISP. Of course if all qubes don’t have network access except through sys-whonix.
The updates proxy role is technically distinct from the NetVM role. It’s not the updates proxy that Torifies your traffic but rather the NetVM (when a qube like sys-whonix is the one providing network access). While it’s true that these two roles are commonly provided by a single qube, they need not be. For example, you could have a separate qube, e.g., sys-update, to play the updates proxy role, and sys-update could have either sys-whonix or sys-firewall as its NetVM, depending on whether you want the traffic to be Torified.
Don’t quite understand why this clarification was. The reason of my words was idea that you need fully torify your traffic to hide Qubes usage. It was said right in next sentence. I said about update proxy because by default sys-firewall is set as it so even when people set sys-whonix as update proxy in installer, in fact (as I remember) it becomes set only as dom0 update proxy and sys-whonix update proxy. So it makes unwanted clear traffic leaks possible.