XSA Tracker

[andrewdavidwong]

We could have a page on the website with a table that looks something like this ( in its simplest form):

XSA	Is Qubes affected?
997	Yes
998	No
999	Maybe

Whenever Xen releases a new XSA, we add a new row to the table for that XSA. Presumably, @rootkovska and/or @marmarek have to make this evaluation for each XSA anyway, so this should not result in any real extra work. (I could do all the footwork of emailing you to ask about each XSA, adding it to the table, adding relevant links and details, etc.)

What do you think?

[marmarek]

Generally this can be a good PR move. There is one category I'm not sure how to handle here: DoS-only issues. We don't consider them as security issues for Qubes OS (mostly because Qubes OS is single-user system, client system), but Xen project issue XSA for those too. What do you propose here? "DoS-only" in that column?

[marmarek]

Generally this can be a good PR move. There is one category I'm not sure how to handle here: DoS-only issues. We don't consider them as security issues for Qubes OS (mostly because Qubes OS is single-user system, client system), but Xen project issue XSA for those too. What do you propose here? "DoS-only" in that column?

[andrewdavidwong]

Generally this can be a good PR move.

Agreed. More importantly, though, I think it would give our users greater peace of mind to know whether each XSA affects them.

What do you propose here? "DoS-only" in that column?

Either that, or "No" with a clear explanation at the top that we don't consider DoS-only issues to be security issues.

[andrewdavidwong]

Generally this can be a good PR move.

Agreed. More importantly, though, I think it would give our users greater peace of mind to know whether each XSA affects them.

What do you propose here? "DoS-only" in that column?

Either that, or "No" with a clear explanation at the top that we don't consider DoS-only issues to be security issues.

[rootkovska]

I can see how this might be attractive PR-wise. But other than that I think this isn't such a good idea. This is because Qubes, might theoretically be affected by vulnerabilities in other components than just Xen. E.g. a hypothetical qubes.XYZ service, written in hypothetical language ABC, might be vulnerable to some bug resulting from ABC's compiler or some library being vulnerable. Or, perhaps, Qubes security might be compromised by a hypothetical bug in some PCI express/IOMMU hardware, which for other OSes would not be such an issue (since they are vulnerable to DMA attacks anyway ;). Etc. So, if we started such a formalized process for announcing non-vulnerability due to Xen bugs, we should then consequently extend it to cover also these other hypothetical components. This might be lots of work, possibly infinitely lots of ;)

[rootkovska]

I can see how this might be attractive PR-wise. But other than that I think this isn't such a good idea. This is because Qubes, might theoretically be affected by vulnerabilities in other components than just Xen. E.g. a hypothetical qubes.XYZ service, written in hypothetical language ABC, might be vulnerable to some bug resulting from ABC's compiler or some library being vulnerable. Or, perhaps, Qubes security might be compromised by a hypothetical bug in some PCI express/IOMMU hardware, which for other OSes would not be such an issue (since they are vulnerable to DMA attacks anyway ;). Etc. So, if we started such a formalized process for announcing non-vulnerability due to Xen bugs, we should then consequently extend it to cover also these other hypothetical components. This might be lots of work, possibly infinitely lots of ;)

[andrewdavidwong]

That sounds like allowing the perfect to be the enemy of the good. Your argument, if I understand it correctly, is basically this: "If we start indicating whether Qubes is affected by Xen vulns, then we'll have to start indicating whether Qubes is affected by all vulns, and that would be too much work." But that doesn't follow at all. In fact, it sounds like a slippery slope fallacy. The page could be limited to commenting only on XSAs, and it could be clearly labeled as such.

The goal is to communicate important information to users about one of the most (if not the most) security-critical components in Qubes. It could simply be a best-effort approach with as many disclaimers as you please clearly stated at the top of the page.

What's the alternative? It's to remain silent about the vast majority of XSAs -- as we have been -- and allow users and the general public to doubt the security of Qubes with each new XSA that's published.

Remember: Most of us aren't Xen experts. We understand that Qubes is based on Xen, but we don't have the expertise to evaluate whether Qubes is affected by each Xen vuln. When it comes to security, it's rational to assume to worst, which usually means assuming that Qubes is affected.

[andrewdavidwong]

That sounds like allowing the perfect to be the enemy of the good. Your argument, if I understand it correctly, is basically this: "If we start indicating whether Qubes is affected by Xen vulns, then we'll have to start indicating whether Qubes is affected by all vulns, and that would be too much work." But that doesn't follow at all. In fact, it sounds like a slippery slope fallacy. The page could be limited to commenting only on XSAs, and it could be clearly labeled as such.

The goal is to communicate important information to users about one of the most (if not the most) security-critical components in Qubes. It could simply be a best-effort approach with as many disclaimers as you please clearly stated at the top of the page.

What's the alternative? It's to remain silent about the vast majority of XSAs -- as we have been -- and allow users and the general public to doubt the security of Qubes with each new XSA that's published.

Remember: Most of us aren't Xen experts. We understand that Qubes is based on Xen, but we don't have the expertise to evaluate whether Qubes is affected by each Xen vuln. When it comes to security, it's rational to assume to worst, which usually means assuming that Qubes is affected.

[rtiangha]

I know I'm just a user here, but I see both sides. As a compromise, would it be possible just to post how Qubes is affected by vulnerabilities in the Security-Critical Code as listed here:

https://www.qubes-os.org/doc/security-critical-code/

As for 3rd-party stuff, according to that page, that would just cover the Xen bits and rpm itself, which should be manageable.

If the Qubes project is framing those packages on that webpage as Security-Critical, then (in my humble opinion) the project should be transparent and explicit on how it gets affected if upstream issues its own security bulletins. As of right now, it's hard for a user to know if an XSA or similar truly affects Qubes and something needs to be done on my end right away to mitigate it, or if it's something that can be waited on until a package gets pushed out (if at all).

But those are just my thoughts on this.

[rtiangha]

I know I'm just a user here, but I see both sides. As a compromise, would it be possible just to post how Qubes is affected by vulnerabilities in the Security-Critical Code as listed here:

https://www.qubes-os.org/doc/security-critical-code/

As for 3rd-party stuff, according to that page, that would just cover the Xen bits and rpm itself, which should be manageable.

If the Qubes project is framing those packages on that webpage as Security-Critical, then (in my humble opinion) the project should be transparent and explicit on how it gets affected if upstream issues its own security bulletins. As of right now, it's hard for a user to know if an XSA or similar truly affects Qubes and something needs to be done on my end right away to mitigate it, or if it's something that can be waited on until a package gets pushed out (if at all).

But those are just my thoughts on this.

[rootkovska]

What Andrew wrote above do sound convincing, of course, so I'm not terribly against the idea. However, what's wrong with the following rule:

If no QSB gets released, this means that the Qubes Security Team doesn't consider whatever-vulnerability-you-recently-read-about-on-tweeter-or-wherever to be applicable for Qubes OS.

[rootkovska]

What Andrew wrote above do sound convincing, of course, so I'm not terribly against the idea. However, what's wrong with the following rule:

If no QSB gets released, this means that the Qubes Security Team doesn't consider whatever-vulnerability-you-recently-read-about-on-tweeter-or-wherever to be applicable for Qubes OS.

[rtiangha]

The problem is for a user who's not plugged into the development happenings with Qubes, there's really no way for that person to know if nothing's being said because there really is no issue, or because people haven't gotten around to looking at it yet (or if it's silence due to a canary issue or something similar). On the other hand, I presume the devs monitor Xen developments constantly in which case, that statement could work.

[rtiangha]

The problem is for a user who's not plugged into the development happenings with Qubes, there's really no way for that person to know if nothing's being said because there really is no issue, or because people haven't gotten around to looking at it yet (or if it's silence due to a canary issue or something similar). On the other hand, I presume the devs monitor Xen developments constantly in which case, that statement could work.

[rustybird]

If no QSB gets released, this means that the Qubes Security Team doesn't consider whatever-vulnerability-you-recently-read-about-on-tweeter-or-wherever to be applicable for Qubes OS.

Stray thought: The raison d'être for canaries seems to be that it's easier to compel someone to silence than to compel them to false speech. Each XSA tracker item would have the benefit of acting as a kind of minor canary for Xen related issues, reducing the latency from (worst case) three months to probably a couple of days at most.

[rustybird]

If no QSB gets released, this means that the Qubes Security Team doesn't consider whatever-vulnerability-you-recently-read-about-on-tweeter-or-wherever to be applicable for Qubes OS.

Stray thought: The raison d'être for canaries seems to be that it's easier to compel someone to silence than to compel them to false speech. Each XSA tracker item would have the benefit of acting as a kind of minor canary for Xen related issues, reducing the latency from (worst case) three months to probably a couple of days at most.

[andrewdavidwong]

@rootkovska:

However, what's wrong with the following rule:

If no QSB gets released, this means that the Qubes Security Team doesn't consider whatever-vulnerability-you-recently-read-about-on-tweeter-or-wherever to be applicable for Qubes OS.

The problem is that this is a poor form of communication. Most people will not be aware that we have such a policy, since they are unlikely to learn of it unless they specifically seek it out. In the absence of positive communication from us, they will be left to their own assumptions, which will probably not be in our favor. This non-communication strategy is particularly ineffective at raising awareness about the fact that Qubes is not affected by the vast majority of XSAs (or any particular XSA). Besides, how are they supposed to know whether you've even seen the XSA yet or had a chance to evaluate it? What if you're sick or went on vacation or your internet is out? How many days should users wait before assuming things are safe? (And would that be a reasonable assumption, given the other possibilities I've just pointed out?)

Here's a real-world example of effective, positive communication. Whenever a new XSA is released, Amazon Web Services (AWS) makes an announcement, and it usually looks like this:

Xen Security Advisory 211 (XSA-211)
2017/03/14 05:00AM PDT

The Xen Security Team has released Xen Security Advisory 211 regarding the Xen hypervisor. AWS customers' data and instances are not affected by this issue, and no customer action is required.

Notice that this announcement is from today. You can view it here:
https://aws.amazon.com/security/security-bulletins/AWS-2017-003/

This kind of announcement accomplishes three main things:

1. It provides positive reassurance to users that they don't have to worry about this particular XSA.
2. Repeatedly seeing such an announcement whenever an XSA is published gradually builds confidence in AWS over time. (Even I have caught myself thinking: "Wow, AWS must be doing things right, since they never seem to be affected by XSAs." By contrast, since we only make an announcement when an XSA does affect Qubes, people have probably formed an unconscious association between XSAs and Qubes vulnerabilities.)
3. It deters would-be detractors from criticizing AWS on the grounds that it relies on Xen (which many people perceive as being full of security holes). Someone who wants to criticize AWS on these grounds will think twice about risking their own credibility, given the massive history of "AWS is not affected by $XSA" bulletins to which AWS supports can easily refer. By contrast, I have observed countless times over the years people casually dismiss Qubes because it's based on Xen. That's all they know about it, so the criticism is born of ignorance. However, there's no easily accessible, credible way to counter their dismissals, so public perception is slowly degraded through bad arguments.

Throughout the years, Qubes users have occasionally asked, "Is Qubes affected by $XSA?" (Most just wonder without asking.) The question usually goes unanswered, because the best answer any non-Qubes-dev can give is, "I guess maybe not, since we haven't heard anything from the Qubes devs, but I don't really know. Maybe it does, and a QSB is coming..." I'm not sure which is worse: an answer like that, or complete silence. Both tend to cultivate a sense of dread.

Here's an example of what this kind of casual uncertainty looks like: a message to qubes-users from ten hours ago. (This is not the best example, just the most recent one.)

Oh, would you look at that. Xen Security Advisory 211 (CVE-2017-9603)
came out just hours ago.

IMPACT 
====== 

A privileged user within the guest VM can cause a heap overflow in the 
device model process, potentially escalating their privileges to that 
of the device model process. 

Emphasis on "privileged user". Even if Qubes is not vulnerable, this
demonstrates how some fraction of all exploits are only available to
privileged users.

Notice how it's "even if Qubes is not vulnerable," with the (entirely reasonable) implication that Qubes might very well be vulnerable. No one can blame the author of that post for not knowing.

[andrewdavidwong]

@rootkovska:

However, what's wrong with the following rule:

If no QSB gets released, this means that the Qubes Security Team doesn't consider whatever-vulnerability-you-recently-read-about-on-tweeter-or-wherever to be applicable for Qubes OS.

The problem is that this is a poor form of communication. Most people will not be aware that we have such a policy, since they are unlikely to learn of it unless they specifically seek it out. In the absence of positive communication from us, they will be left to their own assumptions, which will probably not be in our favor. This non-communication strategy is particularly ineffective at raising awareness about the fact that Qubes is not affected by the vast majority of XSAs (or any particular XSA). Besides, how are they supposed to know whether you've even seen the XSA yet or had a chance to evaluate it? What if you're sick or went on vacation or your internet is out? How many days should users wait before assuming things are safe? (And would that be a reasonable assumption, given the other possibilities I've just pointed out?)

Here's a real-world example of effective, positive communication. Whenever a new XSA is released, Amazon Web Services (AWS) makes an announcement, and it usually looks like this:

Xen Security Advisory 211 (XSA-211)
2017/03/14 05:00AM PDT

The Xen Security Team has released Xen Security Advisory 211 regarding the Xen hypervisor. AWS customers' data and instances are not affected by this issue, and no customer action is required.

Notice that this announcement is from today. You can view it here:
https://aws.amazon.com/security/security-bulletins/AWS-2017-003/

This kind of announcement accomplishes three main things:

1. It provides positive reassurance to users that they don't have to worry about this particular XSA.
2. Repeatedly seeing such an announcement whenever an XSA is published gradually builds confidence in AWS over time. (Even I have caught myself thinking: "Wow, AWS must be doing things right, since they never seem to be affected by XSAs." By contrast, since we only make an announcement when an XSA does affect Qubes, people have probably formed an unconscious association between XSAs and Qubes vulnerabilities.)
3. It deters would-be detractors from criticizing AWS on the grounds that it relies on Xen (which many people perceive as being full of security holes). Someone who wants to criticize AWS on these grounds will think twice about risking their own credibility, given the massive history of "AWS is not affected by $XSA" bulletins to which AWS supports can easily refer. By contrast, I have observed countless times over the years people casually dismiss Qubes because it's based on Xen. That's all they know about it, so the criticism is born of ignorance. However, there's no easily accessible, credible way to counter their dismissals, so public perception is slowly degraded through bad arguments.

Throughout the years, Qubes users have occasionally asked, "Is Qubes affected by $XSA?" (Most just wonder without asking.) The question usually goes unanswered, because the best answer any non-Qubes-dev can give is, "I guess maybe not, since we haven't heard anything from the Qubes devs, but I don't really know. Maybe it does, and a QSB is coming..." I'm not sure which is worse: an answer like that, or complete silence. Both tend to cultivate a sense of dread.

Here's an example of what this kind of casual uncertainty looks like: a message to qubes-users from ten hours ago. (This is not the best example, just the most recent one.)

Oh, would you look at that. Xen Security Advisory 211 (CVE-2017-9603)
came out just hours ago.

IMPACT 
====== 

A privileged user within the guest VM can cause a heap overflow in the 
device model process, potentially escalating their privileges to that 
of the device model process. 

Emphasis on "privileged user". Even if Qubes is not vulnerable, this
demonstrates how some fraction of all exploits are only available to
privileged users.

Notice how it's "even if Qubes is not vulnerable," with the (entirely reasonable) implication that Qubes might very well be vulnerable. No one can blame the author of that post for not knowing.

[rootkovska]

Alright, all you're writing sounds convincing, Andrew :) Let's do it.

[rootkovska]

Alright, all you're writing sounds convincing, Andrew :) Let's do it.

[woju]

On Tue, Mar 14, 2017 at 10:54:49AM -0700, Andrew David Wong wrote: | XSA | Is Qubes affected? | | --- | ---| | 997 | Yes | | 998 | No | | 999 | Maybe |

(snip)

What do you think?

Could we add the QSB number (instead of just "yes")? That would make this easier to navigate and connect facts.

[woju]

On Tue, Mar 14, 2017 at 10:54:49AM -0700, Andrew David Wong wrote: | XSA | Is Qubes affected? | | --- | ---| | 997 | Yes | | 998 | No | | 999 | Maybe |

(snip)

What do you think?

Could we add the QSB number (instead of just "yes")? That would make this easier to navigate and connect facts.

[andrewdavidwong]

Could we add the QSB number (instead of just "yes")? That would make this
easier to navigate and connect facts.

Yes, that was my intention (and more, stay tuned). The initial example was just the simplest possible form.

[andrewdavidwong]

Could we add the QSB number (instead of just "yes")? That would make this
easier to navigate and connect facts.

Yes, that was my intention (and more, stay tuned). The initial example was just the simplest possible form.

[jpouellet]

Also, instead of just "No" when not vulnerable, I think it'd be nice to have explanations for why not e.g. "No, mitigated by qemu in stubdom" as link to paragraph below explaining the mitigation as implemented.

Some categories wouldn't need big explanations, such as "No, affects unused device model", "No, affects feature disabled at compile time", "No, only affects arm platform", etc.

I am willing to help populate this list as long as someone else double-checks it. Does someone already have a WIP list? If not I can start one

[jpouellet]

Also, instead of just "No" when not vulnerable, I think it'd be nice to have explanations for why not e.g. "No, mitigated by qemu in stubdom" as link to paragraph below explaining the mitigation as implemented.

Some categories wouldn't need big explanations, such as "No, affects unused device model", "No, affects feature disabled at compile time", "No, only affects arm platform", etc.

I am willing to help populate this list as long as someone else double-checks it. Does someone already have a WIP list? If not I can start one

[andrewdavidwong]

Also, instead of just "No" when not vulnerable, I think it'd be nice to have explanations for why not e.g. "No, mitigated by qemu in stubdom" as link to paragraph below explaining the mitigation as implemented.

Some categories wouldn't need big explanations, such as "No, affects unused device model", "No, affects feature disabled at compile time", "No, only affects arm platform", etc.

This would be nice to have, but I don't want this tracker to create additional work for @rootkovska or @marmarek. If we start providing this information, we should continue to consistently provide it for every XSA in the future. If they're OK with it, so am I.

I am willing to help populate this list as long as someone else double-checks it. Does someone already have a WIP list? If not I can start one

I haven't started a list yet.

[andrewdavidwong]

Also, instead of just "No" when not vulnerable, I think it'd be nice to have explanations for why not e.g. "No, mitigated by qemu in stubdom" as link to paragraph below explaining the mitigation as implemented.

Some categories wouldn't need big explanations, such as "No, affects unused device model", "No, affects feature disabled at compile time", "No, only affects arm platform", etc.

This would be nice to have, but I don't want this tracker to create additional work for @rootkovska or @marmarek. If we start providing this information, we should continue to consistently provide it for every XSA in the future. If they're OK with it, so am I.

I am willing to help populate this list as long as someone else double-checks it. Does someone already have a WIP list? If not I can start one

I haven't started a list yet.

[jpouellet]

This would be nice to have, but I don't want this tracker to create additional work for @rootkovska or @marmarek. If we start providing this information, we should continue to consistently provide it for every XSA in the future. If they're OK with it, so am I.

I definitely agree with you re: minimizing maintenance burden. However, there seems to be a small set of recurring reasons why XSAs do not apply to Qubes. I believe this would nearly always be just linking to an existing described reason. Sounds like that further classification is not much work considering one already needs to understand why it does not affect qubes in order to make the determination that we're not affected in the first place.

[jpouellet]

This would be nice to have, but I don't want this tracker to create additional work for @rootkovska or @marmarek. If we start providing this information, we should continue to consistently provide it for every XSA in the future. If they're OK with it, so am I.

I definitely agree with you re: minimizing maintenance burden. However, there seems to be a small set of recurring reasons why XSAs do not apply to Qubes. I believe this would nearly always be just linking to an existing described reason. Sounds like that further classification is not much work considering one already needs to understand why it does not affect qubes in order to make the determination that we're not affected in the first place.

[andrewdavidwong]

Very interesting analysis of XSAs (retweeted by Joanna):
http://ipads.se.sjtu.edu.cn/xsa/

[andrewdavidwong]

Very interesting analysis of XSAs (retweeted by Joanna):
http://ipads.se.sjtu.edu.cn/xsa/

[andrewdavidwong]

XSA Tracker is up:
https://www.qubes-os.org/security/xsa/

@jpouellet: Take a look at the architecture, and let me know how you'd like to integrate your explanations. Since they'll likely be reused, we should do implement them in a data-driven way.

[andrewdavidwong]

XSA Tracker is up:
https://www.qubes-os.org/security/xsa/

@jpouellet: Take a look at the architecture, and let me know how you'd like to integrate your explanations. Since they'll likely be reused, we should do implement them in a data-driven way.

[jpouellet]

See comments on commits for formatting & structure.

My WIP analysis of the Qubes impact for the most recent ~30 XSAs is here: https://github.com/jpouellet/qubesos.github.io/blob/xsa-data/_data/xen-vulns.yml

I have been intentionally not referencing QSBs while compiling that list to see if my analysis matches past analysis rather than complacently only focusing on those for which QSBs have been issued.

I'm also keeping track of the pre- and post-conditions of privilege under exploitation, as this data would let us re-evaluate the passwordless sudo argument (well really... the "should we care at all about guest vm privilege boundaries?" question) in a better-informed data-driven way. This is the intent of the priv_note field in my yaml.

[jpouellet]

See comments on commits for formatting & structure.

My WIP analysis of the Qubes impact for the most recent ~30 XSAs is here: https://github.com/jpouellet/qubesos.github.io/blob/xsa-data/_data/xen-vulns.yml

I have been intentionally not referencing QSBs while compiling that list to see if my analysis matches past analysis rather than complacently only focusing on those for which QSBs have been issued.

I'm also keeping track of the pre- and post-conditions of privilege under exploitation, as this data would let us re-evaluate the passwordless sudo argument (well really... the "should we care at all about guest vm privilege boundaries?" question) in a better-informed data-driven way. This is the intent of the priv_note field in my yaml.

[jpouellet]

One trend I've noticed is that Xen 4.7+ seems to restrict the contexts where the instruction emulator can be invoked, and as a result be less impacted by instruction emulation bugs (of which there seem to be plenty). I think this is a good reason to want to update Xen before 4.0.

@marmarek thoughts?

[jpouellet]

One trend I've noticed is that Xen 4.7+ seems to restrict the contexts where the instruction emulator can be invoked, and as a result be less impacted by instruction emulation bugs (of which there seem to be plenty). I think this is a good reason to want to update Xen before 4.0.

@marmarek thoughts?

[jpouellet]

Or maybe not further delay 4.0, but at least prefer to do sooner than later.

[jpouellet]

Or maybe not further delay 4.0, but at least prefer to do sooner than later.

[marmarek]

I think this is a good reason to want to update Xen before 4.0.

I already have Xen 4.8 on my early Qubes 4.0 installation (xen-4.8 branch).

[marmarek]

I think this is a good reason to want to update Xen before 4.0.

I already have Xen 4.8 on my early Qubes 4.0 installation (xen-4.8 branch).

[rootkovska]

Perhaps we could add a year column too the table, to make it clearer for a casual reader what (large) timespan is considered here?

[rootkovska]

Perhaps we could add a year column too the table, to make it clearer for a casual reader what (large) timespan is considered here?

[rootkovska]

Also, maybe a summary (above/below?) the table, e.g.:

Total timespan: X years
Total XSAa issued: 211
No affecting Qubes OS somehow: 16 (if I counted correctly:)

[rootkovska]

Also, maybe a summary (above/below?) the table, e.g.:

Total timespan: X years
Total XSAa issued: 211
No affecting Qubes OS somehow: 16 (if I counted correctly:)

[MarioGeckler]

Would it be better to change the table orientation to list the newest XSA at the top?

In its actual form, someone have to scroll down all to the bottom for each new XSA.

[MarioGeckler]

Would it be better to change the table orientation to list the newest XSA at the top?

In its actual form, someone have to scroll down all to the bottom for each new XSA.

[andrewdavidwong]

@rootkovska:

Perhaps we could add a year column too the table, to make it clearer for a casual reader what (large) timespan is considered here?

Also, maybe a summary (above/below?) the table, e.g.:

Total timespan: X years
Total XSAa issued: 211
No affecting Qubes OS somehow: 16 (if I counted correctly:)

Added all of the above.

@MarioGeckler:

Would it be better to change the table orientation to list the newest XSA at the top?

In its actual form, someone have to scroll down all to the bottom for each new XSA.

In practice, this shouldn't be a problem, since we'll use the anchor links to link directly to each new XSA when we add it to the tracker and announce it on the mailing lists. Anyone who clicks on such a link will be taken directly to that row of the tracker.

---

@rootkovska, @marmarek: Any objection to removing the "under construction" notice now? (Unless @jpouellet is planning on adding his mitigation data soon, in which case we can delay until that data has been added and reviewed.)

[andrewdavidwong]

@rootkovska:

Perhaps we could add a year column too the table, to make it clearer for a casual reader what (large) timespan is considered here?

Also, maybe a summary (above/below?) the table, e.g.:

Total timespan: X years
Total XSAa issued: 211
No affecting Qubes OS somehow: 16 (if I counted correctly:)

Added all of the above.

@MarioGeckler:

Would it be better to change the table orientation to list the newest XSA at the top?

In its actual form, someone have to scroll down all to the bottom for each new XSA.

In practice, this shouldn't be a problem, since we'll use the anchor links to link directly to each new XSA when we add it to the tracker and announce it on the mailing lists. Anyone who clicks on such a link will be taken directly to that row of the tracker.

---

@rootkovska, @marmarek: Any objection to removing the "under construction" notice now? (Unless @jpouellet is planning on adding his mitigation data soon, in which case we can delay until that data has been added and reviewed.)

[jpouellet]

Re newest-first: I also think it is desirable, and my data (not yet used) is intentionally listed in that order.

---

@rootkovska, @marmarek: Any objection to removing the "under construction" notice now? (Unless @jpouellet is planning on adding his mitigation data soon, in which case we can delay until that data has been added and reviewed.)

My free time is difficult to predict. If you feel the need to move forward, don't let my intended improvements stop you.

[jpouellet]

Re newest-first: I also think it is desirable, and my data (not yet used) is intentionally listed in that order.

---

@rootkovska, @marmarek: Any objection to removing the "under construction" notice now? (Unless @jpouellet is planning on adding his mitigation data soon, in which case we can delay until that data has been added and reviewed.)

My free time is difficult to predict. If you feel the need to move forward, don't let my intended improvements stop you.

[jpouellet]

@rootkovska I see you've thumbed-down the request to have newest data first. What is your logic? I'd like to note that the official XSA list is newest-first, and I think it makes sense from the perspective of someone frequently visiting that page to check on new vulns.

I'm happy to be persuaded otherwise though.

[jpouellet]

@rootkovska I see you've thumbed-down the request to have newest data first. What is your logic? I'd like to note that the official XSA list is newest-first, and I think it makes sense from the perspective of someone frequently visiting that page to check on new vulns.

I'm happy to be persuaded otherwise though.

[rootkovska]

@rootkovska I see you've thumbed-down the request to have newest data first. What is your logic?

This is very minor, so I wouldn't like this thread to turn into bikeshading ;) But generally: I consider top-down to be the natural way of reading things, instead of down-top. One reads books from top of the page to down of the page. Same with source code. Same with commands on the terminal. Even the very comments you're reading now are presented in this order. And we also explicitly advise against top-posting on the mailing-lists. Again, this is very minor and I don't plan to make any other comment regarding this anymore :)

[rootkovska]

@rootkovska I see you've thumbed-down the request to have newest data first. What is your logic?

This is very minor, so I wouldn't like this thread to turn into bikeshading ;) But generally: I consider top-down to be the natural way of reading things, instead of down-top. One reads books from top of the page to down of the page. Same with source code. Same with commands on the terminal. Even the very comments you're reading now are presented in this order. And we also explicitly advise against top-posting on the mailing-lists. Again, this is very minor and I don't plan to make any other comment regarding this anymore :)

[rootkovska]

And I think we're ready to go with announcing the page.

[rootkovska]

And I think we're ready to go with announcing the page.

[rootkovska]

Hm, actually XSA7 should be "YES" and linked to QSB#2.

[rootkovska]

Hm, actually XSA7 should be "YES" and linked to QSB#2.

[andrewdavidwong]

This is very minor, so I wouldn't like this thread to turn into bikeshading ;)

Agreed. It's a largely arbitrary choice. Order reversed.

And I think we're ready to go with announcing the page.

"Under construction" notice removed.

Hm, actually XSA7 should be "YES" and linked to QSB#2.

Fixed.

[andrewdavidwong]

This is very minor, so I wouldn't like this thread to turn into bikeshading ;)

Agreed. It's a largely arbitrary choice. Order reversed.

And I think we're ready to go with announcing the page.

"Under construction" notice removed.

Hm, actually XSA7 should be "YES" and linked to QSB#2.

Fixed.

[andrewdavidwong]

I've closed this issue since the tracker is now implemented, but I'd still very much like to see your mitigation data integrated (at your leisure), @jpouellet. Please feel free to create a separate issue to track that, if you like, or simply submit your PRs when you're ready.

[andrewdavidwong]

I've closed this issue since the tracker is now implemented, but I'd still very much like to see your mitigation data integrated (at your leisure), @jpouellet. Please feel free to create a separate issue to track that, if you like, or simply submit your PRs when you're ready.