15:01:23 <xek> #startmeeting barbican
15:01:23 <opendevmeet> Meeting started Mon Nov 18 15:01:23 2024 UTC and is due to finish in 60 minutes.  The chair is xek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:23 <opendevmeet> The meeting name has been set to 'barbican'
15:01:32 <xek> #topic Roll Call
15:01:33 <xek> o/
15:01:39 <xek> Courtesy ping for dmendiza[m] ade_lee d34dh0r53 Luzi tosky tobias-urdin jjung mharley lpiwowar
15:01:51 <xek> As usual our agenda can be found here:
15:01:58 <xek> #link https://etherpad.openstack.org/p/barbican-weekly-meeting
15:02:23 <dmendiza[m]> 🙋‍♂️
15:03:39 <rajiv> hey
15:05:26 <dmendiza[m]> Hi rajiv !
15:06:01 <rajiv> Hey dmendiza[m]
15:07:00 <xek> #topic Review Past Meeting Action Items
15:07:20 <xek> #link https://meetings.opendev.org/meetings/barbican/2024/barbican.2024-11-04-15.00.html
15:07:23 <xek> There were none
15:07:34 <xek> #topic Liaison Updates
15:08:10 <xek> We're after the Epoxy-1 milestone
15:08:19 <xek> #link https://releases.openstack.org/epoxy/schedule.html
15:08:33 <xek> #topic Open Discussion
15:09:27 <rajiv> regarding https://bugs.launchpad.net/barbican/+bug/2036506, i am pushing Thales to update their docu but they want logs to show the latest mechanisms are being picked
15:09:56 <rajiv> i enabled cklog or debugging on Thales but a barbican operation like secret create or delete isnt considered as a crypto operation
15:10:12 <rajiv> any suggestions how to share crypto log with mechanism ?
15:11:41 <rajiv> if the hmac or mkek are replaced or corrupt, barbican only reports Contact Administrator or errors but nothing related to mechanism or crypto mechanism
15:11:46 <rajiv> even if debug is enabled
15:11:56 <dmendiza[m]> rajiv: Try CKM_AES_KEY_WRAP_PAD with IV generation set to false
15:12:37 <dmendiza[m]> You could also query the API for supported mechanisms, but you'd have to do that manually since we don't have that code in Barbican
15:15:03 <rajiv> how can i set it to false ? https://github.com/openstack/barbican/blob/master/barbican/plugin/crypto/pkcs11.py#L144C1-L144C21
15:15:40 <rajiv> set key_wrap_generate_iv to false in the conf ?
15:17:11 <rajiv> would it take sometime for the backend bug notes to be updated here ? https://docs.openstack.org/barbican/latest/install/barbican-backend.html#thales-luna-network-hsm
15:17:44 <dmendiza[m]> yes, key_wrap_generate_iv = False
15:19:38 <xek> dmendizanote about https://bugs.launchpad.net/barbican/+bug/2084691
15:20:19 <xek> I didn't realise the patch deprecating kmip already went in, so we'll leave it at that
15:21:05 <rajiv> dmendiza[m]: i tested the patch without setting key_wrap_generate_iv = False, but the secret operations still worked, is this expected ?
15:21:50 <rajiv> lastly, i would like to create a blueprint for multi-vendor support, is there any reference or whats the procedure to propose a blueprint ?
15:22:18 <dmendiza[m]> Grzegorz Grasza: ack.  yeah, I'll reply to the thread on the ML.  Didn't realize we had already deprecated it.  I remember we talked about it, but wasn't sure about the current status.
15:23:32 <dmendiza[m]> rajiv: I don't know what your device expects for CKM_AES_KEY_WRAP_PAD.  Some devices allow for the IV to be generated and passed in as a parameter of the mechanism.  Other devices don't.  🤷  If it works with IV generation then that's great.
15:23:55 <dmendiza[m]> SoftHSM, for example, throws an error if you generate an IV
15:24:10 <rajiv> i see, i am using Thales A790
15:24:12 <xek> rajivyou can propose a spec to https://opendev.org/openstack/barbican-specs
15:24:22 <rajiv> thanks xek
15:24:38 <xek> (look at the other specs for pointers, as well as specs in other projects)
15:25:15 <xek> There is also a description of the process here: https://wiki.openstack.org/wiki/Barbican/Blueprints
15:25:46 <rajiv> cool
15:26:18 <dmendiza[m]> Oh!  I have a topic now that I think about it
15:26:37 <dmendiza[m]> we have a functional target for tox in the barbican repo
15:27:08 <dmendiza[m]> It's a whole test suite that tests integration with Keystone.  But that seems like something that should be done in Tempest
15:27:28 <dmendiza[m]> I was reminded of this again while trying to set up testing for the PKCS#11 backend using SoftHSM.
15:27:53 <dmendiza[m]> In my opinion we should move that testing to the tempest plugin
15:28:23 <xek> I think I was able to run at least part of the suite without keystone some time ago
15:29:07 <dmendiza[m]> We're basically maitaining two different integration suites now
15:29:20 <dmendiza[m]> the in-tree tox -e functional and the barbican-tempest-plugin
15:29:27 <xek> yeah, it would be better to have just one
15:29:57 <dmendiza[m]> There is some delta there since the PKCS#11 + SoftHSM test fails the functional suite but passes the tempest suite
15:30:05 <dmendiza[m]> so I'll work on enhancing the tempest plugin tests
15:30:14 <dmendiza[m]> and then we can begin to deprecate the in-tree suite
15:31:41 <xek> dmendiza++
15:33:12 <xek> #topic Bug Review
15:33:47 <xek> There are 2 new bugs already in progress:
15:33:56 <xek> #link https://bugs.launchpad.net/barbican/+bug/2087915
15:34:06 <xek> #link https://bugs.launchpad.net/barbican/+bug/2088355
15:34:50 <xek> For the last one, there is no review proposed for Barbican yet
15:35:45 <xek> Thats all for today
15:35:51 <xek> See y'all next week!
15:35:53 <xek> #endmeeting