Thanks @Insurgo for taking care. At the beginning I said I’d like to test some things but many of you were so quick sparing me from what you did (testing and explaining).
So, for me it is left from an user’s perspective to strongly suggest to develop additional dialog box on launching updater tool to rise with something like this:
Beside other regularly updated templates automatically marked for updating, templates listed below were last updated at least ______ ago. We strongly suggest you to select them here so they could be updated too. For more details please see https ://www.qubes-os.org/doc/how-to-update/
So, it would be possible to select those template for updating in that additional window.
I just think offline, airgapped qubes shouldn’t be allowed to go online in order to check for updates. They’re simply more important than their templates. What I’d agree it would be they could check only if there are updates in cacher’s cache, not to ask cacher to check repositories. And above procedure proposed would be life-saver for vault-alikes.
I guess you mean “trying to download,” right? If it’s an offline qube, it can’t download anything from the internet. I don’t see why that’s a security problem, as long as it isn’t trying to exfiltrate your data via a covert channel or anything. I suppose it would be slightly inefficient to have an offline qube vainly trying to check for updates when it has no network access, but it’s probably just a very minor waste of CPU activity at most, right?
(Also, regarding the portion of my post that you quoted, keep in mind that if you have a template, and you’re using a vault qube that’s based on that template, then you do have an actively-used qube based on that template.)
I am confused, as I already added the words before you posted this. Did you miss that, or is this a way of saying that what I added did not cover it?
I could be missing something, but I’m not sure why that would be a significant security risk by itself. If KeePassXC itself were compromised (e.g., package or source code), then it wouldn’t matter whether it’s up-to-date or not. (Updating to newer malicious code would probably just help the attacker.) And if Qubes VM separation as a security boundary were violated, then KeePassXC being patched would provide only minimal protection if KeePassXC were still being unlocked and used for stuff. You certainly wouldn’t want to rely on that, so this definitely doesn’t seem like something that’s important to “avoid at all costs.”
I don’t understand the suggestion, and this is too vague to be actionable for me. If something is unclear in the docs, please provide, at minimum:
An exact quotation of the unclear passage currently in the docs
Why you think it’s unclear
If you think something is missing, please provide, at minimum:
Example text of what you think should be added (or at least the start of it)
Why you think it should be added (e.g., the motivation for adding it, who it would help, or what problem it solves)
Also, casual asides in forum posts are easily missed, so if there is actually something important that needs to be updated or fixed in the docs, the best way is to either open a doc PR or open an issue.
I will explain again. That was in my draft, and you were too quick for me. The draft was created during your doc PR, which is obvious since in my last post I already referred to it
I strongly disagree. Theoretically, it could be compromised in a way to silently trigger setting netVM for vault and sending clipboard (at best, or whatever) to a specified IP address. That theoretical bug could be fixed in the new version, but update wouldn’t be possible. I’m sure there are better examples and more realistic than this one. But, whatever. I have my routine of regularly updating all qubes and it’s not about me, but of users unaware of the issue.
If a qube does not have a net qube (i.e., its netvm is set to None ), then that qube is offline. It is disconnected from all networking.
This is simply not true and dangerous. It should be:
If an update fixes whatever was compromised, then KeePassXC itself is no longer compromised, in which case my conditional statement is still true.
Thank you for the clear and specific example. I think we should actually just remove that sentence, as it’s now outdated and is not essential to the definition of the term “net qube” anyway:
I think the important part here is for users to understand that templates still have network access even though their netvms are set to None (or n/a). Thankfully, this is already documented, specifically here and here. I have also just added pointers to these sections from the “How to update” and “Templates” doc pages in order to make it easier for users to find this information:
You can search for any term in quotation marks to find exact hits:
This is a tricky question, asking to answer from a belief standpoint more then a factual, empiric standpoint. That is, until proof given to infirm such claim that there is nothing malicious there through extensive reverse engineering, its either there or not there until it can be verified its not there. That is, the whole definition of a backdoor injection through either intentional wrong doing or negligence or both.
There is awesome reversing work that has been done in the past on older CPUs, showing some proof that hidden instruction sets were added into x86 in the past:
Remember the names on those papers and dig down that rabbit hole if the subject interests you.
But keep in mind that you cannot highly modify what is on die; you can only patch it, so introducing new instruction sets is not thought as being possible. But what one day was thought impossible is years later dismantled and proven untruth.
So here again, in the absence of open source code, readable and understandable by many, we rely on the reverse analysis of the few and decide to place our trust (belief) into either of the possibilities (trustworthy/untrustworthy) waiting for the evidence.