17:00:31 <geppetto> #startmeeting fpc 17:00:31 <zodbot> Meeting started Thu Jan 5 17:00:31 2017 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:31 <zodbot> The meeting name has been set to 'fpc' 17:00:31 <geppetto> #meetingname fpc 17:00:32 <geppetto> #topic Roll Call 17:00:32 <zodbot> The meeting name has been set to 'fpc' 17:00:48 <mbooth> Merry new year 17:00:57 <geppetto> Hey :) 17:01:02 <geppetto> #chair mbooth 17:01:02 <zodbot> Current chairs: geppetto mbooth 17:01:35 * limburgher here 17:01:40 <geppetto> #chair limburgher 17:01:40 <zodbot> Current chairs: geppetto limburgher mbooth 17:01:41 <tibbs> Morning. 17:01:49 <geppetto> #chair tibbs 17:01:49 <zodbot> Current chairs: geppetto limburgher mbooth tibbs 17:06:44 <geppetto> huh 17:06:52 <geppetto> #chair orionp 17:06:52 <zodbot> Current chairs: geppetto limburgher mbooth orionp tibbs 17:07:04 <geppetto> 5 ftw 17:07:19 <orionp> Hello - snow day here, so connecting from home 17:07:34 <geppetto> ok 17:07:39 <geppetto> #topic Schedule 17:07:43 <geppetto> #link https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/X55Q6HWWQTRX67AYGGIL6O7ZMFRV26P2/ 17:08:16 <geppetto> So, all old tickets this week. Are there any that people want to talk about esp.? 17:08:22 <tibbs> Folks, I'm trying to be around but it's a crazy busy day today for some reason. 17:08:30 <tibbs> There was at least one new one recently, though. 17:09:32 <geppetto> There's 667 17:09:41 <geppetto> it wasn't on the agenda as there is no draft yet 17:09:49 <geppetto> but we can all take a look: 17:10:01 <geppetto> #topic #667 Add recommendations for systemd sandboxing directives to packaging guidelines 17:10:04 <Rathann> hi 17:10:06 <Rathann> sorry for being late 17:10:07 <geppetto> .fpc 667 17:10:10 <zodbot> geppetto: #667 (Add recommendations for systemd sandboxing directives to packaging guidelines) – fpc - https://fedorahosted.org/fpc/ticket/667 17:10:11 <geppetto> #chair Rathann 17:10:11 <zodbot> Current chairs: Rathann geppetto limburgher mbooth orionp tibbs 17:10:26 <tibbs> I don't think what I told mattdm is out of line with how anyone else would feel about this. 17:10:50 <tibbs> Basically, "please don't ask FPC to make up security policy". 17:11:20 <Rathann> yes, I think this is FESCo competence, too 17:11:27 * limburgher nods 17:11:35 <geppetto> Kind of … some of them look like best practice type things 17:11:41 <tibbs> I'm all for saying "must be enabled if supported", personally. 17:12:09 <Rathann> I agree 17:12:09 <geppetto> And if anyone with a security hat in Fedora was advocating for them I'd be happy to consider pass them on that alone. 17:12:15 <tibbs> But all we can say is "MAY", "SHOULD" or "MUST". 17:12:20 <geppetto> sure 17:13:13 <orionp> I'm supportive of promiting it, but would be good to be supported by FESCo 17:13:46 <tibbs> I think it's down on the level of pointlessness to list everything that it's merely OK for packagers to do. 17:14:01 <orionp> promoting 17:14:25 <tibbs> Right, but how does "promoting" fit into may/should/must? 17:14:43 <geppetto> should or may, I guess :) 17:14:58 <tibbs> Just saying "sure, you can use those options" (i.e. "may") is what I was saying is down to the level of pointlessness. 17:15:08 <tibbs> We could do that with everything supported by anything. 17:15:16 <geppetto> I dont disagree 17:15:58 <tibbs> But I guess that's pretty much all we can do at this point, really. 17:16:57 <orionp> I figure that having them in the guidelines and recommending usage is "promoting" 17:17:55 <tibbs> Sure, but the guidelines shouldn't really be a dumping ground for promoting random things. If we're going to say you should or must do something, that's a guideline. Or at least, we've been trying to tighten things up to be that way. 17:18:13 <geppetto> Yeh, but as tibbs said we can't list everything that anyone might want to use. 17:19:03 <geppetto> As I said in the ticket, I think a couple of them should have changed defaults and then have guidelines on when people will want to change them back. 17:19:10 <geppetto> Eg. PrivateTmp 17:19:53 <geppetto> Any more discussion on this, or move on? 17:20:29 <geppetto> ok 17:20:32 <geppetto> #topic #665 SSLCertificateHandling policy update 17:20:36 <geppetto> .fpc 665 17:20:37 <zodbot> geppetto: #665 (SSLCertificateHandling policy update) – fpc - https://fedorahosted.org/fpc/ticket/665 17:22:55 <geppetto> I guess I'm +1 17:25:06 <geppetto> Any other coments? Questions? Votes? 17:25:09 <Rathann> I don't like the duplication 17:25:25 <Rathann> between https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support (last two paragraphs) and https://fedoraproject.org/wiki/PackagingDrafts/SSLCertificateHandlingUpdate 17:26:30 <limburgher> Can they be merged? 17:26:44 <Rathann> I'd move the last two paragraphs from the former to the latter and merge 17:27:18 <geppetto> That seems reasonable 17:27:25 <limburgher> That seems reasonable 17:27:29 <limburgher> Whoa 17:27:33 <geppetto> :) 17:27:44 <Rathann> :D 17:29:20 <geppetto> Any other comments? Are we mostly happy with it otherwise? 17:29:37 <geppetto> s/happy/not unhappy/ :) 17:29:58 <tibbs> I still barely understand why it's called "SSLCertificateHandling" and why it doesn't tell me how to handle SSL certificates in my packages which need them. 17:30:44 <tibbs> That instead is in the "initial service setup" guideline. (Which I just implemented for a package and ran into issues, but that's another discussion entirely.) 17:32:08 <geppetto> ¯\_(ツ)_/¯ 17:32:27 <tibbs> But otherwise, I guess it's fine but I'm still not sure how it actually relates to packaging. 17:32:31 <geppetto> We could add a link back somehow? 17:33:06 <Rathann> because SSL certs can be stored in the HSMs and accessed using the PKCS#11 provider libraries 17:33:08 <tibbs> We could certainly say "if you're trying to figure out XXX then -> this is the guideline you're looking for." 17:33:23 * geppetto nods 17:33:40 <tibbs> OK, but if I'm packaging something, I have no idea what this guideline tells me to do. 17:33:43 <Rathann> and I believe (some) GPG keys can also be stored 17:34:22 <Rathann> tibbs: it's a guideline for packaging pkcs11 modules 17:34:25 <tibbs> Basically all I see is three SHOULDs (one of which is actually capitalized). 17:34:30 <Rathann> and the name should reflect that 17:34:37 <Rathann> https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support <- 17:34:42 <tibbs> I'm looking at SSLCertificateHandlingUpdate 17:35:13 <Rathann> ah, that one shouldn't be in the guidelines IMHO 17:35:25 <Rathann> it's just a regular HOWTO 17:35:39 <Rathann> hm wait 17:35:54 <Rathann> I guess I misunderstood a bit 17:36:00 <tibbs> Programs SHOULD support PKCS#11 URIs and SHOULD NOT use a separate configuration option to load keys and certs, and SHOULD use the tokens which are present in the p11-kit config. 17:36:32 <Rathann> https://fedoraproject.org/wiki/PackagingDrafts/SSLCertificateHandlingUpdate is a guideline how applications which do support loading keys/certs via pkcs11 should be configured 17:36:51 <Rathann> i.e. they should use system-wide config 17:37:10 <tibbs> So just the one sentence is the actual guideline and the rest is just... not guidelines? 17:37:31 <Rathann> there's another one 17:37:48 <Rathann> in the paragraph above 17:37:49 <Rathann> For non-interactive applications which get information on the command line or configuration file, there should not be a separate configuration option to load keys and certificates stored in smart cards, the same option accepting files, should additionally accept PKCS#11 URIs. 17:38:09 <tibbs> Right, that was the second SHOULD I listed above. 17:38:20 <Rathann> ah 17:38:25 <Rathann> you abbreviated it 17:38:27 <Rathann> cool 17:38:39 <Rathann> +1 from me ;) 17:38:39 <tibbs> Not capitalized in the draft. Also will need to fix grammar there. 17:39:19 * Rathann is an avid follower of the KISS principle 17:39:23 <limburgher> +1 if grammar is fixed. 17:39:33 <tibbs> The current https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling is just not what we should be trying to do for guidelines, I'll say that. 17:40:23 <tibbs> Most of that should live elsewhere. The guidelines should just have the two or three SHOULDs I listed above, maybe a link to exposition if that's really needed, and be done with it. 17:40:29 <Rathann> yup 17:40:38 <Rathann> verbosity is a killer here 17:41:06 <tibbs> I'm not entirely sure if the "*Update" document is intended to replace the entire SSLCertificateHandling page or just a portion of it. 17:42:47 <tibbs> Because if the former then that's great. 17:43:12 <tibbs> Anyway, with grammar fixed and SHOULDs capitalized, I'm +1 to https://fedoraproject.org/wiki/PackagingDrafts/SSLCertificateHandlingUpdate 17:43:49 <tibbs> Though due to the confusing name I'll add a link to the initial service setup document. 17:44:17 <tibbs> As for https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support.... let's see. 17:45:02 <tibbs> I don't understand why it recommends both pkg-config and just using the direct path. 17:45:42 <tibbs> One recommendation is completely sufficient, and if hardcoding the path is good then why not just do that? 17:46:42 <tibbs> And, then, why wouldn't the three relevant sentences from SSLCertificateHandlingUpdate just go into Pkcs11Support ? 17:47:49 <tibbs> And the SSLCertificateHandling page can hang around saying "if you want to generate self-signed certificates for a service when it starts, see -> here. If you want to know how to handle certificates via PKCS#11, see -> here." 17:48:13 <Rathann> +1 17:48:28 <tibbs> Especially since the third SHOULD of SSLCertificateHandlingUpdate is exactly the same as https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support#How_applications_take_advantage_of_registered_provider_modules 17:48:57 <tibbs> And the first is the same as the next section. 17:51:41 <tibbs> Is there some point to the duplication that I'm missing? 17:52:14 <geppetto> I think it's just the different audiences, and they thought one page each was better? 17:52:54 <Rathann> I think tibbs is referring to the last two paragraphs at the bottom of https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support 17:53:10 <tibbs> The last three, actually. 17:53:26 <Rathann> tibbs: the first one talks about HSMs and the second about keys/certificates stored on them 17:53:41 <tibbs> Sure, OK, but in the end it says the same thing. 17:53:55 <tibbs> Use p11-kit instead of specifing a provider explicitly. 17:54:08 <tibbs> Talks about PKCS#11 URI and saying to use those. 17:54:09 <Rathann> ah in that case the third from the end talks about modules to support the HSMs 17:54:42 <Rathann> but as you say it can be summarized in one sentence 17:54:55 <tibbs> The fact that it says "RFC7512 defines a 'PKCS#11 URI' as a standard way to identify tokens and objects." identically twice is just kind of weird. 17:57:08 <tibbs> I want to say I'll take a pass over both pages and try to make something which makes sense. 17:57:44 <geppetto> You want to say that? 17:57:49 <tibbs> I just don't want to make promises right now as it's going to be a busy time for me for the next three weeks. 17:58:04 <tibbs> I can say that I'll maybe try to find half an hour to do it. 17:59:18 * geppetto nods 18:01:19 <geppetto> #action tibbs Try to tidy up what we have, might be a couple of weeks though. 18:01:25 <geppetto> #topic #635 FC Automatic Provides for Python RPM Packages 18:01:30 <geppetto> .fpc 635 18:01:31 <zodbot> geppetto: #635 (FC Automatic Provides for Python RPM Packages: Accompanying change of Python packaging guidelines) – fpc - https://fedorahosted.org/fpc/ticket/635 18:01:46 <geppetto> So it looks like the person who opened it moved it from needinfo to meeting, which is nice. 18:02:59 <geppetto> I guess they answered the question though 18:04:45 <tibbs> The proposal in comment 16 looks reasonable to me. 18:04:51 <Rathann> I think this is the diff: https://fedoraproject.org/w/index.php?title=User%3ATorsava%2FPackagingDrafts%2FPython&diff=477448&oldid=466988 18:06:13 <tibbs> But if that's what they're presenting currently, the draft hasn't been updated to use it as far as I can tell. 18:07:45 <geppetto> Yeh, I'm happy with the small number of macros 18:08:05 <geppetto> And having problems on the build side seems like something that we could live with 18:08:23 <Rathann> I also like the 3-macro version better 18:08:26 <tibbs> It can get awfully verbose with multiple dependencies, though. 18:08:42 <tibbs> Unless they do %{py2_dist A B C} or something like that. 18:09:46 <geppetto> Eh, I'm fine with it either way … but I guess it'd be nice to support N args. 18:09:52 <Rathann> yeah that'd be shorter 18:10:05 <Rathann> but I personally like to have one dependency per line 18:10:17 <Rathann> makes it more readable and makes future diffs smaller 18:10:31 <tibbs> I don't know if they have. I group dependencies as they make sense, as a big block of dependencies is far from readable. 18:10:33 <geppetto> So are we good to say please update the draft to reflect comment 16 and we'll probably approve it? 18:10:46 <Rathann> geppetto: yes 18:10:49 <geppetto> Ok 18:11:10 <limburgher> I think so. 18:11:18 <geppetto> #action Proposal in comment 16 seems fine, please update draft so we can approve it. 18:11:25 <tibbs> I am there, yes, but it would be nice to be specific about what argument(s) the %py*dist* macros take. 18:12:12 <geppetto> #info It would be nice to be specific abut what arguments the py*dist macros can take (Eg. multiple names). 18:13:12 <geppetto> #topic Open Floor 18:13:21 <geppetto> tibbs: I assume nothing has happened with 661? 18:13:26 <tibbs> I am still well behind on everything. 18:13:31 * geppetto nods … no problem 18:13:57 <tibbs> I'm trying to get a pending redhat-rpm-config update out before I go trying to change anything else. 18:14:24 <tibbs> Since I unkindly obsoleted orionp's update and then somehow mine got invalidated. 18:14:28 <tibbs> Back to testing for another week. 18:17:40 * geppetto nods 18:17:57 <geppetto> Did orionp's change get lost or rolled into your new one? 18:18:43 <tibbs> No, but the update got superceded. 18:19:35 <tibbs> And then another package got attached to my update, and then a newer version of that one got submitted in its own separate update and got enough karma to go to stable. So my update couldn't be pushed because it contained a package older than what's currently in the distro. 18:19:46 <tibbs> So that package was then removed from my update, which sent it back to testing. 18:20:07 <geppetto> ok 18:20:32 <geppetto> I feel like it should just be pushed to stable now, as it's been tested a bunch 18:20:34 <tibbs> Bodhi doesn't warn when any of that happens, so you have to check closely before you mess someone else's update. 18:20:44 * geppetto nods 18:21:01 <geppetto> It's kind of optimised for one update one package/packager 18:22:43 <geppetto> Anything else? 18:24:42 <geppetto> Ok, thanks for coming everyone. See you next week. 18:24:58 <geppetto> #endmeeting