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