Overall, I agree with a lot of the sentiment and the statements thus far. One key aspect I think we need to ensure is that we don't silo discussions to a specific topic or for example ssh keys. In other words, ultimately the *complete* scope of work remains undefined, and projects *should* identify potential areas of work that they can see, while the overall larger ecosystem moves forward and the overall exact needs are clarified further. The wider process should be to revise a vision and guidelines as time moves forward. For example, it could boil down to a very simple question for projects: Does your project do *anything* in relation to keys, encryption, or interaction of any encrypted data either at rest or while in transit.? If yes, are there actions to take? And then a dialog needs to occur, or at least a framework for understanding if there *really* needs to be an investment in time or resources in that specific instance of usage, or is it just permitting a longer value, or what. Ultimately that is a case by case assessment which needs to be performed. A good first step for any working group would be to create a chart which could be used as a reference for those individual discussions. -Julia On Mon, Oct 27, 2025 at 5:35 AM Sean Mooney <smooney@redhat.com> wrote:
my personal take on this is it may be a vaild future comunicaty goal but its probably premature.
in general most openstack project try to not be in the busyness of Cryptography if we can at all avoid it.
our dependicies may have cypto feature like ssh, ssl for our rest apis or similar both the openstack code base in general tries to not implement any cypto logic itself. i.e. we try to delegate to python-cryptography or similar well maintained modules.
for example just looking at the nova section you mentioned that nova can genreate ssh keys
https://wiki.openstack.org/wiki/Post_quantum_openstack#Nova_.28Compute.29
however we deprecatea and removed that capablity in zed relese in micoversion 2.92
https://docs.openstack.org/nova/latest/reference/api-microversion-history.ht...
we did that specificly because we did nto want to supprot ssh key generation in nova going forward and defiend that to be out of scope fo our project
so that is a non issue in a PQC world because we have decieed as a project not to extend or suprot that api going forward.
it has not been removed as we dont do that in nova if its reasonable to keep the code but it shoudl never be used anymore.
we only supprot uploading a pre generated public key now.
the there two case might be valide
```
Supports validation of Glance image signatures and certificate trust when booting signed images. (link)
Metadata path protection with Neutron uses HMAC over Instance-ID to prevent spoofing (shared secret). (link)
```
although for the metadata case that shared secretae is intened to be passed over a https connection so if the ssl encyption for the connection supprot post quantum encyption then the hamc does not really need too but we can likely change that algorhtypme when python cypgoraphy supprot somethign in the future that is a suitable replacement.
the glance image verficaiton woudl need glance to support somethign else instead but if they come ups with an updated approch nova coudl adapt.
none of the above seem particularly urgent and likely don't need to be addressed in 2026.1 or even 2027.1 but if someone wanted to write a spec for the nova/glance changes and wanted to work on it it could be reviewed via the normal upstream process without needing to make it a comunity goal or have it driven by the TC. you coudl for example create a popup team or sig kind of like the eventlet remvoal work to drive this instead.
speaking of which i think the eventlet removal work is gong to take precedence for most team as that is more urgent in terms of real world impact.
regards
sean.
On 27/10/2025 05:14, Goutham Pacha Ravi wrote:
On Fri, Oct 24, 2025 at 1:19 PM Jean-Philippe Jung <jjung@redhat.com> wrote:
Hi,
I am seeking help from the TC to raise the urgency of this work across all OpenStack projects and to help me lead an effort to reduce the number of cryptographic modules used in OpenStack (my personal opinion is that there should be no more than five).
Doing this may involve work in each OpenStack Project team; and I can help organize this effort. I'm seeking the following from the TC and/or project teams: Portions of this work will be isolated to specific repositories managed by a project team, while others will involve "cross-project" synchronization. What vehicles can we use to have a "call-to-action" for project teams to get someone to look into their specific projects? How can we go about community wide collaboration?
I've created a document [1] that I assembled from AI analysis of part of the OpenStack code. It gives an overall view of the problem we face.\
Thank you for starting this discussion, JP. I've added a topic to the TC's PTG for 1600 UTC on Friday, 31st Oct 2025. I hope you'll be able to share your findings there briefly and invite opinions in-sync. Our vehicle for driving cross project work has been via the Community Goals framework: https://governance.openstack.org/tc/goals/ If we have one or more objectives, this can be proposed as one, and will require a "goal champion" - someone that'll help us gather requirements, and coordinate efforts to complete the goal. Some goals in the past have spawned new groups - either as Pop Up Teams or SIGs (https://governance.openstack.org/tc/reference/comparison-of-official-group-s...).