search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
536 stars 47 forks source link

Mechanism to notify users when critical action is required #3430

Open andrewdavidwong opened 6 years ago

andrewdavidwong commented 6 years ago

We need a mechanism to notify users when critical action is required. For example, Fedora 25 recently reached EOL (#3429), and we failed to notify users in time. However, even if we had made an announcement through our usual channels (website, mailing lists, social media) as soon as the F26 template was available in mid-November, it's likely that at least some users would not have gotten the message in time to upgrade safely. (We shouldn't expect everyone to subscribe to our RSS feed, subscribe to the lists, or use social media.) Users who diligently check for Fedora template upgrades would simply see "No updates available." After a while, they may wonder why there haven't been any new updates for weeks or months, but by then it could be too late. We need a more reliable mechanism for notifying users when they need to take a critical action like upgrading their templates.

adrelanos commented 6 years ago

I agree this is important and useful to have. Spent a lot thought (and code) previously on that subject.

In many cases however, fixing things automatically (or after confirmation) for the user (implemented using salt or so) seems to me would fix the issue for a greater number of users since many will ignore the notification anyhow. (Confused; forgotten; or underestimate importance. - So automatic updates are good to have in principle but also hard to implement.)

andrewdavidwong commented 6 years ago

I agree that, when possible, automatically fixing something for users is superior to instructing users to fix it themselves. However, there are cases in which it is not possible to do things for users, e.g., when the action requires knowledge or decisions regarding how users partition their lives into security domains, or when the action is something like reinstalling of the whole OS. Therefore, it is still important to have a more general mechanism to notify users when critical action is required.

ninavizz commented 3 years ago

Created #6905 to specifically address EOL concerns. Are there other scenarios that qualify as requiring critical action? To handle this issue separately, it would help a great deal to have further comments itemize those "Critical Action" needs.

DemiMarie commented 3 years ago

Created #6905 to specifically address EOL concerns. Are there other scenarios that qualify as requiring critical action? To handle this issue separately, it would help a great deal to have further comments itemize those "Critical Action" needs.

New QSB is one other scenario.

andrewdavidwong commented 3 years ago

Created #6905 to specifically address EOL concerns. Are there other scenarios that qualify as requiring critical action? To handle this issue separately, it would help a great deal to have further comments itemize those "Critical Action" needs.

New QSB is one other scenario.

Yes, but it depends on the QSB. Some require special action beyond updating normally, but many do not. For many QSBs, the only "special user action required" is to reboot after doing a normal update, hence #6692.

3hhh commented 3 years ago

I'd suggest to create a qubes-news signed RPM for dom0 which is installed & updated by default and then use the RPM capabilities of displaying messages to users.

Only disadvantage I see here is that users who never update their system won't get news. However they'll still see the "There are dom0 updates available." icon and I guess those users have different issues anyway...

iacore commented 2 years ago

I can write a tool to fetch from https://github.com/QubesOS/qubes-secpack/ and auto update if possible.

We can include machine-readable code (for upgrade) and text in QSB for the tool to use.

andrewdavidwong commented 7 months ago

https://github.com/QubesOS/qubes-issues/issues/9025 is another case where this would have helped. See here for discussion.

ben-grande commented 3 months ago

@3hhh wrote on 2021-09-17:

I'd suggest to create a qubes-news signed RPM for dom0 which is installed & updated by default and then use the RPM capabilities of displaying messages to users.

What 3hh proposed is the foundation for solving this issue. I am more interested in being able to read the Qubes Secpack from Dom0 or a dispvm to open user favorite editor than a mechanism to parse the QSBs and notify users, but both goals requires the qubes-secpack repository to be packaged.

Is there any position of the Qubes Core Team on this matter? If accepted, I can do the packaging.

What is needed:

  1. Package qubes-secpack
  2. Dom0 GUI tool to notify of new QSBs to be read (interactive) with qubes.OpenInVM RPC to open the QSB in the user's favorite editor
  3. Dom0 tool to parse QSBs
    1. Requires new QSB section to be machine readable
    2. Most QSBs require waiting the threshold to pass from testing to stable, I don't see how this can be done non-interactively though. Also a lot of the times is just continue to update normally and reseal the TPM when needed.

For this issue to be a single actionable thing, I propose to do 1. Package qubes-secpack or use this issue as a meta issue and still do the 1 but in another issue that will reference this one.

The item 2, I will leave for others to do with more GUI experience than me, but I imagine a 2 tabs GUI, one listing Read QSBs, one listing Unread QSBs and each tab has a list of QSBs with a button to read.

The item 3, I don't plan to do.

Only disadvantage I see here is that users who never update their system won't get news. However they'll still see the "There are dom0 updates available." icon and I guess those users have different issues anyway...

Well, user's that don't update won't get news is a user policy problem, they can setup automatic updates if they want. It is also not an excluding option, user's still can get notified via forum and mailing list without having to upgrade their system.