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.
You can find more information on what a QSB 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:
If youâre the type of person who doesnât want to be bothered with any announcements other than the most important ones, we made qubes-announce specifically for you.
Iâm genuinely surprised that you could be a Qubes user for over two years and not know what a QSB is!
Do you know what? After several days on-and-off with all this, going through the docs, I understand less now than before.
and also
Bottom line: what do I need to watch, to know when to do the things I need to do, to make my system safe and secure?
That is unfortunate. 
A Qubes Security Bulletin (QSB) is a security announcement issued by the Qubes OS Project, typically providing a summary and impact analysis of one or more recently discovered software vulnerabilities, including details about patching to address them. This is a very common thing in computing and is not at all unique to Qubes. Examples from other projects and companies include Xen Security Advisories (XSAs), Lenovo Product Security Advisories (LENs), and Debian Security Advisories (DSAs). Almost every similar project and company has their own version of this. There is also, of course, the Common Vulnerabilities and Exposures (CVE) system.
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:
qubes-announce you have made âspecifically for people like meâ is/were listed but buried ~1800 words of housekeeping down the Support page.(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:
âSecurity Updates > Qubes security updates are obtained by Updating Qubes OS.â
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.)
(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?? )
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?
Iâm done.
Touchy, and a bit snarky too.
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.
Had to move this discussion into its own topic (What are Qubes Security Bulletins (QSBs)? How to find them?) as it was getting way off topic from (Safety when forced NOT to use Updater)
Hopefully this moving of discussion finds itâs way well to your inbox @unman. Let me know if it doesnât.
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 thread in 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.