13:00:55 <redrobot> #startmeeting barbican
13:00:56 <openstack> Meeting started Tue Jan  8 13:00:55 2019 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:00 <openstack> The meeting name has been set to 'barbican'
13:01:04 <jaosorior> o/
13:01:12 <Luzi> o/
13:01:19 <graeb> o/
13:01:25 <redrobot> Courtesy ping for ade_lee hrybacki jamespage Luzi lxkong moguimar raildo rm_work xek
13:01:30 <moguimar> o/
13:02:15 <redrobot> Oh wow!  Lots of folks here today. 😄
13:02:30 <redrobot> As usual our agenda can be found here:
13:02:31 <raildo> o/
13:02:40 <redrobot> #link https://etherpad.openstack.org/p/barbican-weekly-meeting
13:03:04 <redrobot> and we actually have some topics on there today! 🎉
13:03:30 <redrobot> I hope everyone is having a great 2019 so far.
13:03:40 <redrobot> Let's get started:
13:03:48 <redrobot> #topic Action Items from last meeting:
13:04:47 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2018/barbican.2018-12-18-13.00.html
13:05:21 <redrobot> redrobot to update the Barbican Wiki page
13:05:28 <redrobot> I did not do that (boo!)
13:05:39 <redrobot> but I will get it done by next week.
13:05:44 <redrobot> #action redrobot to update the Barbican Wiki page
13:06:09 <redrobot> Next
13:06:13 <redrobot> > everyone think of topics for summit presentations
13:06:17 <redrobot> I hope y'all did.
13:06:23 <redrobot> #topic Summit CFP
13:06:40 <redrobot> Anyone think of Barbican or Barbican related presentations over the break?
13:08:05 <redrobot> Bueller?
13:10:28 <Luzi> will you or ade_lee give that workshop again?
13:10:53 <redrobot> Ok, I'm guessing y'all are still waiting for the coffee to kick in like I am. ☕
13:11:33 <redrobot> Luzi, great question.  I heard there was a lot of interest last summit, but things didn't go so well.  I think it would definitely be awesome to do it again sans hardware hiccups.
13:12:08 <redrobot> #action redrobot to ask alee about submitting the Barbican workshop to the next Summit
13:12:29 <redrobot> Anything else?
13:12:43 <redrobot> I was thinking maybe alee and I could talk about the HSM support we've been working on ...
13:12:54 <redrobot> I'll have to talk to him about it
13:12:59 <Luzi> that's a good idea redrobot
13:13:05 <redrobot> Does anyone know off the top of their head when the CFP deadline is?
13:13:42 * redrobot looks
13:13:45 <Luzi> 23rd i think
13:13:49 <Luzi> let mee look again
13:14:37 <Luzi> yep 23rd of anuary 11:59 pm PT
13:14:48 <Luzi> January
13:14:58 <redrobot> Thanks, Luzi
13:15:18 <redrobot> So we've still got a couple of weeks to think about and submit proposals.
13:15:42 <redrobot> Don't leave it to the last minute though! 😉
13:15:48 <redrobot> Ok, moving on ...
13:16:38 <redrobot> #topic Multiple regressions since Barbican 7.0.0
13:17:00 <redrobot> graeb, Luzi: your topic?
13:18:00 <Luzi> yeah, graeb made some more tests with our Safenet Luna HSM and noticed a few things, we would like to ask now
13:18:00 <graeb> Well. Barbican 7.0.0 and newer versions stoppt working with HSMs from SafeNet.
13:18:39 <graeb> Commit dba5ead from Alee introduced that problem. :-/
13:19:11 <graeb> Got an error CKR_ATTRIBUTE_VALUE_INVALID when trying to store a secret.
13:19:31 <Luzi> the same goes for utimaco soft hsm, but we heard some guys from utimaco are already working on it, right?
13:19:44 * redrobot looks for a link to the change
13:21:03 <redrobot> graeb, are you sure that's the correct change ID?  I'm finding this:
13:21:12 <redrobot> #link https://github.com/openstack/barbican/commit/dba5eade39a86b95a97369e7c0e5f79faf0ff385
13:22:02 <graeb> Sorry, wring commit. This is right: https://github.com/openstack/barbican/commit/df8c62aab357954000e8539ac17daea45f93ee7c
13:24:59 <redrobot> There were not many attribute changes on that patch
13:25:17 <redrobot> Do you know what function is throwing the error? e.g. unwrap, encrypt, decrypt, etc?
13:25:54 <graeb> generate_key
13:26:12 <graeb> in barbican/plugin/crypto/pkcs11.py
13:27:11 <redrobot> During normal operation or MKEK/PKEK generation?
13:27:28 * redrobot thinks it's going to be hard to debug this blind
13:28:18 <graeb> Then a new PKEK is generated, the error is thrown
13:29:11 <graeb> I not tried to generate a MKEK with Barbican 7.0.0 since it was already there.
13:30:31 <redrobot> I see .. I'll have to dig into the code to figure out what's going on.
13:30:36 <graeb> I couldn't find a difference in the way the PKEKs are generated in 7.0.0 and a working version of Barbican.
13:31:01 <graeb> With commit dba5ead it is still working.
13:31:10 <redrobot> Yeah, we tried to keep things the same when we introduced other mechanims.  Unfortunately we don't have access to a Safenet HSM for testing :(
13:32:21 <graeb> Shall I upload the StackTRace somethere?
13:32:39 <redrobot> graeb, yeah that would help.  And if you can get a PKCS#11 log from the HSM that might help debug too
13:32:43 <graeb> somewhere
13:32:57 <redrobot> paste.openstack.org?
13:33:17 <redrobot> I can't recall what Safenet logs look like
13:33:47 <redrobot> but the Thales HSMs we've been playing with have really good verbose logging options that would show what attributes are being sent on that generate_key call
13:33:48 <graeb> http://paste.openstack.org/show/740498/
13:34:06 <redrobot> graeb, sweet.  I'll take a look after the meeting.
13:34:52 <graeb> I must confess that I never have seen SafeNet HSM logs. Maybe I can past some information from such a log too.
13:35:14 <graeb> I juast pasted the TraceBack from Barbican.
13:35:54 <redrobot> I'll see what I can figure out from the Barbican logs
13:36:29 <graeb> Ok, thanks. So we can switch over to the next topic.
13:36:33 <redrobot> graeb, Luzi there was another concern on the agenda?
13:36:38 <redrobot> Yes, lets move on
13:37:32 <graeb> PKEK are generated with attribute CKA_SENSITIVE set to true. That means, that PKEK are extractable from the HSM. This also was introduced with commit df8c62a.
13:39:08 <graeb> Seems there is an compatibility issue with some HSMs, and so the workaround was to generate PKEKs like that. But this is less save.
13:39:36 <Luzi> there was a comment, that this was necessary for som HSM, right?
13:39:43 <graeb> Yes.
13:40:11 <graeb> So we have a security versus compatibility problem maybe?
13:40:52 <redrobot> Well, PKEKs do get extracted after being wrapped.
13:41:22 <redrobot> Though I can't recall off the top of my head whether CKA_SENSITIVE would survive the wrap/unwrap process.
13:42:21 <redrobot> Ah yes, CKA_SENSITIVE and CKA_EXTRACTABLE have to match
13:42:56 <redrobot> CKA_EXTRACTABLE has to be true for PKEKs so that we can retrieve them for storage in the DB
13:43:23 <redrobot> I wonder if that's the Attribute that's causing problems for the Safenet HSM?
13:44:35 <redrobot> I also can't remember if it was the ATOS or the Thales HSM that complained about the CKA_SENSITIVE and CKA_EXTRACTABLE mismatch. 🤔
13:44:37 <graeb> Ok, I will check that.
13:44:52 <graeb> With SafeNet HSM.
13:45:10 <redrobot> graeb, yeah, if you can change that attribute back to always true and have it work then we'll definitely need to make it configurable.
13:46:30 <redrobot> graeb, Luzi so I think we'll have to dig into this more after the meeting.  Is there anything else y'all want to talk about while we're here?
13:46:33 <graeb> To make that configurable is an brilliant idea I think.
13:47:19 <Luzi> redrobot, that's everything from our side
13:47:27 <redrobot> ok, thanks y'all
13:47:30 <redrobot> moving on ...
13:47:44 <redrobot> well, there's nothing else on there
13:47:51 <redrobot> but while we're on the topic of HSMs
13:47:58 <redrobot> #topic ATOS and Thales HSM integration
13:48:19 <redrobot> alee and I have been working on getting TripleO deployment support for Barbican with both ATOS and Thales HSMs
13:48:34 <redrobot> There's still some stuff under review
13:49:31 <redrobot> #link https://review.openstack.org/#/q/topic:add_hsm_parameters
13:49:59 <redrobot> We had two patches for tripleo-common but we were asked to put them elsewhere since they're not strictly tripleo related
13:50:34 <redrobot> The ansible roles are in my personal github for now:
13:50:35 <redrobot> #link https://github.com/dmend/ansible-role-atos-hsm
13:50:44 <redrobot> #link https://github.com/dmend/ansible-role-thales-hsm
13:51:02 <redrobot> I'm going to be working with the openstack-ansible folks to hopefully add those repos to the openstack-ansible org
13:51:25 <redrobot> I pitched the idea on their IRC channel the other day and they seemed receptive to the idea
13:52:21 <redrobot> Next steps is to submit a patch to infra, I think
13:52:29 <redrobot> so I'll post that to the channel once it happens
13:52:43 <redrobot> any questions about the TripleO+HSM work?
13:53:39 <redrobot> ok, moving on
13:53:45 <redrobot> #topic Reviews
13:54:02 <redrobot> #link https://tinyurl.com/yctfozgh
13:54:12 <redrobot> There's a milestone coming up this week.
13:54:23 <redrobot> are there any patches that need to be merged before then?
13:54:35 <redrobot> I'm going to be looking at the Vault AppRole patch today
13:54:39 <redrobot> for castellan
13:55:13 <redrobot> and I think we've gotten all the high priority patches reviewed for barbican server
13:55:24 <redrobot> we're going to have to punt on the OVO work
13:57:15 <redrobot> No patches on y'alls end?
13:57:20 <redrobot> alrighty then
13:57:25 <redrobot> I think we're done for the day
13:57:34 <redrobot> Thanks for coming everyone
13:57:39 <redrobot> #endmeeting