This is a discussion that stemmed from one where a user who had been on Qubes for two years are not yet come across a QSB. The original question had to do with the user not know how to proceed to safely update qubes when the qubes updater failed. Find that discussion here.
I’m genuinely surprised that you could be a Qubes user for over two years and not know what a QSB is! We do blanket every Qubes venue with announcements every time we publish a new one, so they should be hard to miss. Specifically, you only have to watch or subscribe to one of these not to miss any QSBs:
Occasionally, QSBs may require or recommend (depending on the user’s circumstances) action that is not already handled by the updater. When that is the case, we state the actions explicitly, with step-by-step instructions, if appropriate. In most cases, however, everything is handled by the updater, and the important update information provided by the QSB is: (1) the fact that an important security update is available (currently in security-testing, soon in stable), and (2) the exact package version numbers containing the fixes. If you already check for and install updates daily or more frequently, then most QSBs will not require any unusual action from you, but many users do not have the best habits in this regard, so QSBs help keep users safe and informed.
In the past, more user action was required, but we’ve improved the updater so that it can now automatically (via Salt) perform more actions for the user. This improves security because it removes user error from the equation in these cases.
We’re also working on making further improvements in this area, such as having all security updates installed automatically by default (#6299) and having a notification system built in to the OS that informs users when action is required on their part (#3430).
If by “dom0 updates by cli” you mean the command qubes-dom0-update (as opposed to qubesctl), then nothing. It’s only the opposite that holds: the Qubes Update tool (which uses qubesctl, which uses Salt), can do more than just qubes-dom0-update, dnf, and apt can by themselves, since it can use Salt for additional automated actions. (This was the topic of conversion in the thread to which you linked above.)
I believe I just answered this in the post above:
I’ll also add this information to the installation guide so that new users will be better informed.
And if you’re looking for a complete list, including non-QSB things, it’s documented here:
On a more general note, I think it’s worth stepping back to gain some perspective on all this. To give you a few examples:
My recent iPhone has automatic updates turned on, but they never actually install automatically. I have to find out about updates from random web surfing, then check my device to see that there are, indeed, updates available. Apple never notifies me, and their automatic update system is broken. If you search online, you’ll see that this is a widespread problem.
Most laptops never notify the user when a BIOS update (or similar) is available. I literally had to use a tool that watches a web page for changes to see when BIOS updates were available for my Lenovo laptop, until I finally found an obscure email notification system on their website.
It took me a lot of trial and error to figure out which Fedora mailing list contains EOL announcements, and that list contains a lot of stuff I don’t want. There doesn’t seem to be a list of just the important stuff that includes EOL announcements (which are pretty darn important).
Needless to say, most routers are terrible about notifying you when a firmware update is available, much less installing them automatically.
The point of these examples is this: A lot of stuff in the consumer electronics and software world is pretty awful when it comes to updates and keeping users informed about things in, and Qubes is already miles ahead in many ways.
For example, our XSA Tracker and general XSA announcements (recent example) are the result of many years of experience learning what kinds of information users care about and how they consume it. For example, some users see when a new XSA is released, and they wonder whether it affects Qubes. Before, there was no system in place, so the Qubes OS Project was just silent on these. There were QSBs, so you knew when an XSA did affect Qubes, but for the others, you didn’t know what the silence meant. Did it mean that the Qubes team had analyzed the XSA and decided Qubes was safe? Did it mean that Qubes team hadn’t gotten around to looking at it yet? Had they somehow completely missed it? It’s much better to have positive assurance that says, “We’ve looked at this, and it does not affect the security of Qubes OS” rather than just leaving the user to wonder.
We also take special effort to disseminate the critical announcements (such as QSBs) widely (see the list above) and to make sure that important project security documentation is easy to find (there’s a link on literally every page of the documentation).
For these reasons, most users currently have no trouble finding out about QSBs (though this won’t stop us from making it even easier and more foolproof, as explained above). But we can only do so much. The user also has a responsibility to consume what we create. Our carefully-written documentation and announcements do no good if no one reads them.
But we can only do so much. The user also has a responsibility to consume what we create. Our carefully-written documentation and announcements do no good if no one reads them.
These carefully-written documents really are being continually updated, aren’t they, Andrew? For example, your addition of a Security paragraph on the Getting Started > Next Steps section. Just 16 hours ago, according to Github. Social media information added too.
Please don’t admonish me for not reading material that wasn’t there when I asked for it.
Yes. Increasingly, it seems to be.
For the record, as of this morning, after a weekend and more searching the Documentation, I observed the following:
Details of the qubes-announce you have made “specifically for people like me” is/were listed but buried ~1800 words of housekeeping down the Support page.
(And why, of all the technical things about Qubes that *could* use more explanation, did you choose to provide a link to define "mailing lists" via Wikipedia?)
(BTW on all Qubes Doc pages, the sidebar menu disappears as you scroll down. That is not user friendly on long, technical pages.)
On Get Started, there was no mention of QSBs, qubes-announce, and the very last line says If you encounter any problems, please visit the Help, Support, and Mailing Lists page. That’s it. I’m not going to ask about QSBs if I don’t know about them, yes?
This is essentially the same story on 4.0.3 Release Notes, Installation Guide and in fact any documentation I can find via the Downloads page.
I acknowledge that this may have been subject to timely updates by now. I’m not going to bother to check.
But moving on, when searching around the site carefully-written site:
If I go to the Qubes Project Security Center, I see [or at least, would have seen yesterday] a bunch of hyperlinked bullet points that don’t seem immediately relevant. It then talks about Reporting, (probably not at my skill level), in which it mentions QSB, but gives no indication that I need to get into that, because The Very Next Section clearly says:
“Security Updates > Qubes security updates are obtained by Updating Qubes OS.”
Even if I click on that rather self-explanatory statement, the Updating Qubes page doesn’t tell me anything about QSBs, secpacks, etc. None of the links do either, AFAICT. There is one hyperlinked word, “security”, which goes back the page I just came from.
I don't think I even saw a statement that explained `qubes-dom0-update`, `qubesctl` - hey, you know what? The Updating Qubes page doesn't *once* mention Qubes Updater. Can't help but feel you missed something there.
Around about here, I’d say any reasonable reader would be thinking, why the I need to do anything else for security than Update? And if I already know about the Updater, (somehow, maybe by the little orange flower of joy in systray), why would I even bother investigating that link further?
Other than curiosity or precognition, there is no reason given why I should click on “Security Pack” or “Security Bulletin”, (which, as written, breaks with the naming convention of “Qubes [Thing]” btw. Don’t do that. It confuses things for people not familiar with the jargon. Documentation shouldn’t do that.)
The secpack documentation pretty much leads off with an 2015 e-mail from Joanna that is more than 500 words long. It only really talks ( or talked, as of yesterday?) about PGP keys and canaries and - very understatedly, quite without detail - some announcements and “info”.
It assumes knowledge. It also means I need to go digging through 500 words and I still haven’t found anything that says, “this QSB thing is important, not optional and requires action”.
(While we’re on the subject, nothing there explains why I need an updated copy of the PGP keys all the time – Updater handles all that, no? No?? )
Less than 24 hours ago, when I was getting confused, the QSB page did not explain QSBs, indicate their importance, nor give any instructions to the noob.
The writing is not so careful, Andew. There are flaws. True, you have made some improvements, but only after being defensive, shaming me (“genuine surprise”), talking down to me, and - by editing pages to include information that you then admonish me for not having read beforehand - you gaslight me.
You’re the official Qubes Community Manager, right?
Of course, the information was there, on the support page, with a
link to the QSB page that explained exactly what they were.
And that has been there for a long time.
So yes, the information was there when you asked for it, and you hadn’t
found it because you hadn’t read the support page.
But if you had followed any of the various methods that Qubes
interacts with its users you would have received notification of QSBs.
In any case, the documentation (and Qubes itself) is a collaborative
effort, and you can make a contribution to improve it at any time. If you
think that the issue is still not explained please do this, to make it
better for everyone else.
I second what @unman said. This is a community effort and constructive feedback is welcome! However, there are ways of going about it and ways of how not to do it.
Curating documentation is a challenging task: balancing discoverability with technical accuracy and security disclaimers. All of this while looking at it from the outside perspective and bring up some feedback like the one you did. (and probably much more that I’m forgetting).
I’m surprised as well that you didn’t find the QSB before. But the good part is that now you have and can follow them. Furthermore, because of your feedback changes were made that will likely make it even easier for others find.
So, please try to be constructive in your criticism and avoid being dismissive of others’ efforts.
When using Windows, one just runs Windows Update. I don’t think many people ever click the advisories linked to or even know what Patch Tuesday is. I would also guess that not many people read docs on Microsoft’s site that explains what Windows Update is. So there is little expectation that a user has to read documentation or be familiar with terminology - just run Windows Update. The average user does not need to know what a Security Bulletin, Security Advisory, Vulnerability Research Advisory, etc are.
If Windows is a bad example, if there’s a security update in Ubuntu - you just update; average users probably don’t read online USNs from Ubuntu when they are released - because they are integrated into the updater.
When using Qubes, the same model doesn’t always work. Granted, if the Updater itself did not experience issues, that model could work, but Qubes OS is not run by a large organization like Microsoft with many resources (as far as I know). There’s a good recent GitHub issue talking about improvements with the Updater already previously mentioned. But in the event the Updater doesn’t, users will seek support. There is a heavy burden for users to read a lot of documentation; there is also a heavy burden for the Qubes team/community to continually improve the documentation. Both are hard problems to solve given the nature of Qubes OS: the size of the core team, its open source nature, and the simple fact that it is essentially 3 operating systems all in one with a goal to be reasonably secure - that’s a lot to support.
However, Qubes OS pushes you to cross the boundary of being an ‘average user’ since one reason for its existence is to be reasonably secure. The inherent nature of that goal forces more decision making onto the user - which may give the impression that all users are reading all QSBs, have memorized all documentation available, are following GitHub, etc. It is a balance.
@ToastedCoral I would say keep that in mind as you do things. Understand the documentation (and OS itself) is a continual improvement - your perspective helps to improve it.
Wow. I clearly added that section based on your feedback, and I even linked to this very threadin the commit message. Did you miss the part where I told you I’d be adding this new part? If you’re going to accuse me of “gaslighting” you, you should really do your homework first to make sure that I’m not actually trying to improve things based on your feedback. Clearly, all the other information in that section was already there and has been for some time. Everyone can see all of this in the git history. It’s all transparent. That’s the entire point of open source. If I were trying to “gaslight” you, do you honestly think I would take extra steps to document my own actions while doing so? When I provided you a link that section, it was in answer to your question, an attempt to be helpful. I was simply pointing out to the complete list (recently updated with the new addition we had just been discussing, which I told you I’d be adding). I think you need to ask yourself why you’re inaccurately assuming the worst at every turn.
I never said there weren’t. If you had taken any effort to learn anything about this project, you’d know that the documentation is a collaborative, mostly volunteer effort that was written by many different people over many years. Rather than taking any steps to contribute or help with that, or even just to first understand it, you instead devote your energy to criticizing, complaining, and defaming. Worst of all, your initial complaints weren’t even justified. They were just the result of not RTFMing.
I tried to be nice and understanding at first. I generally try to assume the best and avoid blaming the user, but when a user makes zero effort to learn anything about the software he’s using, then proceeds to lash out and blame everyone else for his ignorance, I can’t abide it. It really takes effort to bury one’s head in the sand so deeply that one has never heard of a QSB after using Qubes for two years. If you thought that Qubes would be “install and forget” software, your expectations were misplaced. That’s fine, but the reasonable thing to do would have been to acknowledge that reality, update your expectations accordingly, and move on. Instead, you’ve gone out of your way to embarrass yourself in a public forum for no reason and to no one’s benefit.