"any OQS repo" -- No. Suggest to agree on a subset. Ideally only those with a diverse, active contributor base which can play ball, err, handle problems (to stay in the picture, there should be more linebackers for that project than quarterbacks)

We haven't enabled vulnerability reporting on all OQS repositories. So really this can be turned into a point about only turning on security vulnerability reporting on repositories that we have a sufficient base to support.

What I meant (and probably should have clarified) was that we should make sure we're aware of all vulnerability reports, whichever repo they're filed on. For instance, if we have security advisories enabled for oqs-demos, it's possible we'll receive a report there that is pertinent to liboqs, even though (I imagine) we won't offer any sort of security policy for the demos.

Ah, now I get it. Honestly I wasn't aware that security advisories are enabled for all, even ancillary, sub projects... Out of curiosity: When was that decided and how does this fit to this statement

we won't offer any sort of security policy for the demos.

? I would agree to this statement, but then I don't understand this statement now:

it's possible we'll receive a report there that is pertinent to liboqs

AFAIK we didn't enable reporting security issues for demos, right? Just the publication of advisories (which is a weird combination, honestly).

I think this ties to #2 (comment): What is it that @dstebila labels "fully supported" ? Having a security policy and everything as per this conversation that goes with it?

Honestly I wasn't aware that security advisories are enabled for all, even ancillary, sub projects... Out of curiosity: When was that decided and how does this fit to this statement

Looking in the Settings tab on Github for oqs-demos, I don't see any option to enable/disable security advisories -- perhaps it's always enabled?

I think this ties to #2 (comment): What is it that @dstebila labels "fully supported" ? Having a security policy and everything as per this conversation that goes with it?

The criteria you stated at the top of #2 defined "Fully supported (at least 2 fully committed maintainers)" which is what I applied. If you want to add having a security policy to that, or other things, I'm open to that, but that probably belongs in the discussion on #2.

Yes. But with the proposed "up next" approach, this cannot be guaranteed, depending on priorities, travel plans or other shenanigans.. I'd thus propose that the rotation changes by time (as and when a person is certain to be responsive) not by event ("up next").

I see your point Michael. I think it would be important to make sure the quarterback knows that they're on duty. This could be done by a schedule (say, monthly; with an email coming from me at the start of each month letting them know they're on duty) or it could be that the one of the tasks of the quarterback is to pass the baton to the next quarterback by emailing them once the current quarterback is activated for an issue.

If we go for a time-based rotation, we could do a 5-week cadence and "pass the baton" at TSC meetings (all of the current VMT regularly attends those).

I proposed the "up next" approach mostly to distribute work in the event that we receive two or three reports in a short time span.

I also think it should just be a scheduled rotation. While the up-next approach seems nice from a load balancing perspective, I think what would realistically happen is long stretches of time go by with one person designated as the up-next person, and then per this line:

Members of the VMT should inform the team when they will be unresponsive

They would just end up doing more out-of-office bookkeeping to keep the team informed of their availability than actual QBing. Eventually human nature will take over and the person forgets they are up-next entirely.

If we go for a time-based rotation, we could do a 5-week cadence and "pass the baton" at TSC meetings (all of the current VMT regularly attends those).

This sounds like a good solution to me, it also provides the flexibility to skip a candidate if they are unavailable during the specified time period.

Doesn't that make matters even more complicated? Instead of focusing on the issue, the Quarterback is to be exchanged? To stay in the picture, why shouldn't the QB be allowed to run towards the end zone? Admitted, if there's a strong defense, not advisable -- but for OQS there's hardly anyone on the playing field.

My intention was to potentially speed up the response process by separating management and technical responsibilities, so that the QB doesn't get swamped (especially if we go with a time-based rotation and the same person is handling multiple reports concurrently). Note that it's an optional swap and the original QB would still be involved: they would just be focusing solely on remediation development as opposed to managing the response process.

Same thought as just voiced elsewhere: Are we overdoing things here? We have received how many security reports, exactly? We have how many players on the field? My gut feeling is that the work on "security issues" is going to go down from here as more and more serious(ly supported) software packages include PQC and current OQS users with a need for reliable (read: paid-for) software maintenance will accordingly switch over to such packages.

I'd thus suggest to no over-engineer things here: What about adding simple wording like "members of the VMT agree to be available to support each other on short notice if the need arises" for any "unforeseen issue" (like overload or whatever else)?

On the OQS website we have some text saying that people can email me to request to be added to a security notification list. Is this something we should continue?

I think it's a good idea—not everybody uses GitHub.

we have some text saying that people can email me to request to be added to a security notification list.

No, the text says that an email should be sent to the same "security@" email address: This warrants two questions: 1) Did you create such list (and do you want to keep maintaining it), @dstebila and 2) should this wording be retained (or a split done into a reporting email address (that all of VMT receives) and a "interested party registration" email list (that only people subscribing to things like GDPR receive)?

not everybody uses GitHub

Agreed. So having such mechanism is "nice and kind" -- but comes at a cost (e.g., documenting it here, on the website and then "living" it)... I'm afraid we're overdoing things here: A company taking money for its software of course does this, but this is a completely non-committal project entirely without funding for people doing actual work or chores like this.

we have some text saying that people can email me to request to be added to a security notification list.

No, the text says that an email should be sent to the same "security@" email address: This warrants two questions: 1) Did you create such list (and do you want to keep maintaining it), @dstebila and 2) should this wording be retained (or a split done into a reporting email address (that all of VMT receives) and a "interested party registration" email list (that only people subscribing to things like GDPR receive)?

You're right, not me personally but to security@. Yes, I have been keeping track of such requests and have a textfile on my computer containing about half a dozen addresses. Possibly we could move this over to a mailing list on @lists.pqca.org so that that system manages the subscription and privacy concerns.

Shall I ask Ry to set up an [email protected] mailing list? And then I can contact all the people who have asked to be added to our list and point them to the new mailing list.

Are there other scenarios that would be considered out of scope? For instance, could a vulnerability outside the OQS threat model be classified as such?

I know this report is closed and dealt with, but re-reading it makes me wonder: If liboqs is affected, wouldn't that imply that at least the language wrappers are also affected automatically? Also oqsprovider makes available HQC code if I'm not mistaken. So in case of a more severe problem with liboqs what would such problem mean for dependent OQS sub projects? Should that be spelled out somewhere?

Where do we spell out which algorithms fall into which category?

I've created open-quantum-safe/liboqs#2045 to track this.

As a follow-up to my previous comment: Are all sub projects to be checked or are there some we don't consider (oqs-demos? ci-containers? profiling?). I'd guess that should also be spelled out ahead of time so the responsible committers and maintainers can agree on their involvement (level). And if indeed a vulnerability should be fixed "througout the OQS suite", all steps to do so should be clear -- either in writing for manual execution or as an automation/script.

Good point. This calls for a script to do that, e.g., executing all CI commands locally (and for all sub projects deemed affected): TBD.