Create new liboqs-cupqc-meta repo and delete old liboqs-cupqs team/repo

[praveksharma]

The integration of cuPQC's ML-KEM into liboqs is now complete. This PR does two things:

• Create a new public repo liboqs-cupqc-meta to store the metadata needed by liboqs' copy_from_upstream mechanism; this repo has the same access rights as the liboqs repo. This data is presently stored in a private repo: https://github.com/praveksharma/cupqc-mlkem. The possibility of storing this data in a Nvidia repo was discussed but this solution is more feasible and straightforward to implement.
• Deletes the private repo liboqs-cupqc (and associated maintainers team) since the repo is no longer needed.

Unconditionally, changes to config.yaml must

• be approved by 2 members of the OQS TSC
• not violate permissions documented in GOVERNANCE.md files for sub projects where such files exist

The following goals apply to changes to the file config.yaml with exceptions possible, as long as the rationale for the exception is documented by comments in the file:

• all sub projects should be treated identically wrt roles & responsibilities as per the detailed list below
• teams/team designations are to be used wherever possible; using personal GH handles should only be used in team definitions
• Admin changes to the file must be documented by comments as to the rationale of the change

All the following conditions hold for permissions set in config.yaml:

• sub project maintainers have admin rights on the sub projects
• OQS and sub project release managers have maintainer rights on the sub projects but can themselves set/reset branch protection rules limiting write access to sensitive branches
• sub project committers have write rights on all branches of the sub projects but can request branch protection rules limiting this
• sub project contributors (incl. code owners) have write rights on all branches except main on those sub projects
• OQS and sub project triage actors have triage rights on all branches of the sub projects
• OQS maintainers and LF admins have admin rights on the organization (e.g., org-wide secret management) as well as maintenance rights on the team configurations

[clowarden]

Validation succeeded

✅ The proposed configuration changes are valid!

Configuration changes

Directory

• team liboqs-cupqc-maintainers has been removed

Github

• repository liboqs-cupqc-meta has been added (visibility: public)
  • Teams
    • bots: write
    • liboqs-codeowners: write
    • liboqs-committers: write
    • liboqs-maintainers: admin
    • oqs-admins: admin
    • oqs-contributors: triage
    • oqs-release-managers: maintain
    • security-managers: read
    • tsc: read

---

🔸 Please review the changes detected as they will be applied immediately once this PR is merged 🔸

[baentsch]

This data is presently stored in a private repo: https://github.com/praveksharma/cupqc-mlkem. The possibility of storing this data in a Nvidia repo was discussed but this solution is more feasible and straightforward to implement.

Where and when was this discussed? What are the arguments speaking against NVIDIA taking continued responsibility for the adaptation layer to their proprietary HW library? What speaks for people sorely missed to move forward OQS in general (@praveksharma ) to assume (maintenance) responsibilities of a commercial entity?

Net-net: I think merging this PR would do a severe disservice to OQS: It removes NVIDIA technical folks that could help OQS move forward and instead puts all maintenance obligations onto the liboqs-committers team (with no-one from NVIDIA present in).

Reviewing all activities, I have to ask the question whether it was NVIDIA's sole interest to push support for their proprietary API into OQS for marketing reasons alone and when done, withdraw immediately and "let the community" deal with any issues incl. maintenance? @ydoroz, can you comment?

I acknowledge that NVIDIA funds PQCA and wants their money worth of marketing exposure for that -- but for as long as nothing of this money flows into the active support of OQS development I do not think it is warranted to spend community effort and resources on code benefiting primarily the entity selling the hardware.

To make this actionable, what about selecting either of these two alternatives to resolve this:

1. NVIDIA declares its willingness to support this proprietary API integration by maintaining it long-term with active participation in the OQS project, i.e., NVIDIA technical people "earn their stripes" to become "oqs-committers" and hence, support the community along with the code thus added. Advantages: More helping hands to move OQS forward & cuPQC is maintained throughout the full software stack.
2. OQS removes cuPQC support from liboqs: Advantages: No need for this PR & no need for maintenance of this by the OQS core team & much cleaner (and in consequence, more secure) code & more time to resolve problems beleaguering the whole project and not just a single vendor's single algorithm feature.