Add updated information regarding algorithm support

[RodriM11]

Update algorithm support information received from submission teams.

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged. Also, make sure to update the list of algorithms in the continuous benchmarking files: .github/workflows/kem-bench.yml and sig-bench.yml)

[baentsch]

Much better: Thanks for collecting this information @RodriM11 ! Regarding the "actively maintained" algs: Do we have in all cases a specific email address to contact, particularly in case of security issues, too?

Will approve when CI passes.

[RodriM11]

Regarding the "actively maintained" algs: Do we have in all cases a specific email address to contact, particularly in case of security issues, too?

We do have, beyond the general contact email to which we contacted initially, the email from the point of contact who assumed the "Actively maintained" status on behalf of their team, so I think is safe to assume they will be the PoC for issues going forward.

[RodriM11]

@dstebila would you mind helping me with the build failure? It seems that the copy_from_upstream.py script is changing the SLH-DSA maintenance status back to TBD, and therefore it outputs a build failure. I assume the problem comes from the copy_from_slh_dsa_c.py, which re-generates the .md and .yml files and puts the maintenance status values back to default.

[baentsch]

I think is safe to assume they will be the PoC for issues going forward.

Can I suggest to validate that for sure? And then enter those contacts into the list of whom to contact in case a security report comes in (for that algorithm)? It would be good to have/agree a place where to store (and regularly update) this information, too such as for the security handling process to actually work.

I assume the problem comes from the copy_from_slh_dsa_c.py, which re-generates the .md and .yml files and puts the maintenance status values back to default.

If this is the case (which at first glance seems to be the case also from my perspective), wouldn't @h2parson as the apparent main author of this file be the best person to help?

IMO the addition of an algorithm via a "bespoke" mechanism is a problem for long-term maintenance and should be avoided (echoing @xuganyu96 very true comments at the end of that file: Worthwhile creating an explicit issue about this?).

[RodriM11]

Can I suggest to validate that for sure? And then enter those contacts into the list of whom to contact in case a security report comes in (for that algorithm)?

Yes, I will double check with them. Maybe a way to add those contacts would be to include them as codeowners, following the standard practice that we have been following. Or did you have other way in mind?

If this is the case (which at first glance seems to be the case also from my perspective), wouldn't @h2parson as the apparent main author of this file be the best person to help?

@h2parson would you mind taking a look at the problem?

IMO the addition of an algorithm via a "bespoke" mechanism is a problem for long-term maintenance and should be avoided (echoing @xuganyu96 very true comments at the end of that file: Worthwhile creating an explicit issue about this?).

I agree, and the issue of how we handle inclusion of algorithms is something that we ought to discuss to try to facilitate the process to new submissions (specially in a time when we hope to have multiple new inclusions and collaborations). This topic will appear on the next TSC meeting.