19:00:06 <Sparks> #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings
19:00:06 <zodbot> Meeting started Wed Jul 23 19:00:06 2014 UTC.  The chair is Sparks. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:09 <Sparks> #meetingname Fedora Security Team
19:00:09 <zodbot> The meeting name has been set to 'fedora_security_team'
19:00:13 <Sparks> #topic Roll Call
19:00:15 * Sparks 
19:00:28 * joat waves
19:00:56 <ignatenkobrain> heya
19:00:58 * ignatenkobrain here
19:01:06 <bojov> present
19:01:11 <jrusnack> hello
19:03:10 * Sparks gives everyone a few more minutes to make it in.
19:03:22 <revskills> hello!
19:03:42 <ignatenkobrain> revskills: ^^
19:04:01 <jrusnack> reading meetbot howto tbh ...
19:06:15 <Sparks> Okay, lets get started
19:06:19 <Sparks> #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better"
19:06:30 <Sparks> #topic Welcome
19:06:59 <Sparks> First, a big thank you to the beta team that is currently working some issues.
19:07:31 <Sparks> I've already received lots of feedback from team and non-team members on the actions that have already happened and so far it's all been positive.
19:08:19 <ignatenkobrain> :)
19:08:28 <Sparks> As someone pointed out in IRC, there are a lot of issues that need to be addressed.
19:08:46 <Sparks> As of last Friday there were:
19:08:53 <Sparks> Critical: 3
19:08:58 <Sparks> Important: 65
19:09:05 <Sparks> Moderate: 378
19:09:08 <Sparks> Low: 131
19:09:22 <Sparks> #info 577 open security bugs in Fedora
19:09:46 <ignatenkobrain> so much
19:10:20 <Sparks> I hope that number will decrease based on our work and also based on work I'm doing in my day job to hopefully help provide information to developers to keep some of these bugs from being written in the first place.
19:10:47 <Sparks> So, with all that said, does anyone have any questions, concerns, or comments?
19:12:15 <jrusnack> alright, regarding process - how do we split the pool of bugs so that we don`t double contact the package owners by mistake ?
19:12:28 <Sparks> jrusnack: That is an excellent question.
19:13:12 <Sparks> jrusnack: I'm honestly not sure of a great way of doing this.  It would be nice if BZ supported an entry where we could put our name on the ticket.
19:13:38 <Sparks> jrusnack: I might be able to talk with the BZ admins about this so that if the ticket is security related that the field shows up.
19:14:01 <Sparks> jrusnack: Another way, which is way less convenient, would be to have a list on a wiki page.
19:14:11 <Sparks> *But*, I'm open to suggestions.
19:14:18 <revskills> Sparks: what about to have own bz?
19:14:21 <jrusnack> Sparks: yeah, that would tend to get out of sync quickly
19:14:49 <Sparks> revskills: I would dislike splitting the information up more than it already is.
19:15:23 <jrusnack> could we misuse some of the existing fields like Whiteboard ?
19:15:28 <Sparks> revskills: It's good to keep all the information on the same bug.  We *could* utilize the "Doc" field as I'm not sure that is being used on security bugs.
19:16:12 <Sparks> jrusnack: Whiteboard can get overwritten by automated scripts run by Red Hat Product Security so I don't think we should touch Whiteboard.
19:17:23 <thoger_> Sparks: we assume Whiteboard on trackers is not under our full control, we do care more about flaw bugs whiteboards
19:18:00 <revskills> Sparks, eg: What happen if ignatenkobrain are looking into a vuln and found 2 embargo vuln, need to contact with us (redhat), we need to create the embargo, and he cannot advance without this, and finally fedora security team can be in a time loop
19:18:01 <Sparks> thoger_: So, would those fields get overwritten?
19:18:03 <thoger_> imo, whiteboard with some special tag may work well... e.g. fst_owner:name
19:18:26 <Sparks> thoger_: +1
19:18:33 <revskills> +1 thoger_
19:19:04 <thoger_> Sparks: iirc, we only touch tracker bug whiteboard when creating tracker, and only if affected component != bugzilla component, which should never happen in Fedora, only happens for other products
19:19:09 <Sparks> revskills: Yeah, embargoed stuff is going to be interesting although it's been said that we maybe able to get the FST onboard earlier.
19:19:40 <thoger_> we use component:component_name, and assume other things can be in the wb when reading
19:21:00 <Sparks> So, use fst_owner:name in the beginning of the Whiteboard.  I think we could even write something up to search for bugs that don't have this tag.
19:21:30 <jrusnack> Sparks: just name, or rather email contact ?
19:22:17 <Sparks> jrusnack: Email may be better so that people outside the circle can contact whomever.
19:22:50 <jrusnack> it may not matter in the end, but yeah, might be helpful for outsiders
19:23:05 <Sparks> +1
19:24:26 <thoger_> email that is bz login should probably be restriction
19:25:03 <Sparks> Does anyone want to write this up on the wiki?
19:25:10 <jrusnack> thoger_: I`d prefer not - my bz login is tied to redhat`s, for fst_owner I`d use fedoraproject one
19:25:31 <jrusnack> thoger_: what would be the purpose of that restriction ?
19:25:54 <revskills> nickname from fedora security team listed in wiki, link to fedoraproject email at wiki
19:26:40 <thoger_> jrusnack: makes it easy to CC owner on other bug if needed
19:27:22 <thoger_> FAS login name is alternative
19:27:57 <thoger_> that would not require anti-spam obfuscation
19:29:34 <Sparks> jrusnack: Any problems with that?
19:29:46 <jrusnack> Sparks: not at all.
19:30:04 <Sparks> Okay, cool.
19:30:07 <Sparks> Does anyone want to write this up on the wiki?
19:30:24 <jrusnack> I can do that
19:31:27 <Sparks> jrusnack: Awesome.  I'm still working on moving data from the general security pages to the more specific security-team pages.  Feel free to squeeze that in.
19:32:02 <Sparks> #action jrusnack to document the use of fst_owner: in the whitepages of the bugs
19:32:09 <Sparks> Okay, anyone else have anything?
19:33:17 <joat> Does anyone mind if I borrow wording from already sent emails?
19:33:48 <Sparks> I believe someone will be talking about our work at Flock.  Are we okay with opening the doors of the team up to everyone?  I have about twenty people on a list right now.
19:34:13 <Sparks> My initial concern was that it would be a much rockier start...  fortunately it has gone quite well.
19:34:33 <joat> I liked that the team was CC:'d and would like to "borrow" that.
19:34:56 <ignatenkobrain> sorry, was frozen
19:34:58 <joat> Apologies for the slow typing
19:35:08 <Sparks> joat: Sounds good to me.
19:35:41 <jrusnack> Sparks: taking the number of outstanding issues into account ... I`d say everyone is welcome. Keeping everyone in sync would be bigger challenge then though
19:36:03 <jrusnack> and related question: do we have a current team roster somewhere ? :)
19:36:20 <ignatenkobrain> I think no
19:36:30 <Sparks> jrusnack: We don't.  We should.
19:36:32 <Sparks> ignatenkobrain: No?
19:37:05 <ignatenkobrain> Sparks: I mean we don't have team roster now
19:37:15 <Sparks> ahh
19:37:32 <Sparks> Yes, so I'll put that together and post that.
19:37:35 <ignatenkobrain> I think we can create wiki pacge
19:37:46 <ignatenkobrain> and link to fas accounts/wiki pages
19:37:51 <Sparks> ignatenkobrain: +1
19:37:53 <ignatenkobrain> as SIGs
19:37:55 <revskills> +1
19:38:17 <Sparks> #action Sparks to create a team roster with links to people's User: wiki pages.
19:38:40 <ignatenkobrain> ack
19:38:48 <Sparks> Anything else from anyone?
19:39:36 <jrusnack> yup
19:39:52 <Sparks> jrusnack: Go
19:40:11 <jrusnack> there are 3 CVEs for pwgen - sent mail to author, who basically rejects them as vulnerabilities
19:40:26 <jrusnack> how do we close such issues ?
19:40:31 <ignatenkobrain> jrusnack: links to bugs ?
19:40:50 <Sparks> jrusnack: We don't until the CVEs are fixed.
19:41:06 <jrusnack> ignatenkobrain: bz#1020222 bz#1020249 bz#1020259
19:41:07 <Sparks> jrusnack: Which is a very sucky answer.
19:41:14 <ignatenkobrain> .bug 1020222
19:41:16 <zodbot> ignatenkobrain: Bug 1020222 CVE-2013-4440 pwgen: non-tty passwords are trivially weak by default [fedora-all] - https://bugzilla.redhat.com/1020222
19:41:19 <jrusnack> Sparks: they wont be by upstream
19:41:24 <ignatenkobrain> .bug 1020249
19:41:26 <zodbot> ignatenkobrain: Bug 1020249 CVE-2013-4441 pwgen: Phonemes mode has heavy bias and is enabled by default [fedora-all] - https://bugzilla.redhat.com/1020249
19:41:28 <ignatenkobrain> .bug 1020259
19:41:31 <zodbot> ignatenkobrain: Bug 1020259 CVE-2013-4442 pwgen: silent fallback to insecure entropy [fedora-all] - https://bugzilla.redhat.com/1020259
19:41:37 <revskills> jrusnack: propose patches help
19:41:47 <Sparks> jrusnack: Speaking as a non-developer, is it possible to fix these issues with a patch from within Fedora?
19:42:12 <Sparks> jrusnack: I mean, if upstream doesn't want them then we can include them in our packages I guess.
19:42:22 <jrusnack> revskills: well, one of them was rejected as fix would break legacy apps, so I`d say upstream would reject any fix for that
19:42:43 <jrusnack> Sparks: sure we could. Do we want to ?
19:42:53 <ignatenkobrain> I think yes
19:43:03 <ignatenkobrain> we want to apply sec fix here
19:43:25 <Sparks> jrusnack: Do *I* want to?  :)
19:43:37 <Sparks> jrusnack: These CVEs also affect EPEL.
19:43:55 <Sparks> #topic pwgen CVEs
19:43:55 <jrusnack> ignatenkobrain: so the problem here is, that version of the same package in say fedora and ubuntu would ahve different behaviour
19:44:08 <Sparks> #link https://bugzilla.redhat.com/1020222
19:44:15 <Sparks> #link https://bugzilla.redhat.com/1020249
19:44:20 <Sparks> https://bugzilla.redhat.com/1020259
19:44:24 <ignatenkobrain> jrusnack: for example ?
19:44:24 <Sparks> #link https://bugzilla.redhat.com/1020259
19:44:34 <ignatenkobrain> I know nothing about pwgen
19:44:48 <ignatenkobrain> password generator which creates passwords which can be easily memorized by a human.
19:44:49 <ignatenkobrain> okay
19:44:49 <jrusnack> say someone depends on the legacy behaviour and lists specific version of pwgen as dependency. In fedora that version could be patched and behave differently
19:44:51 <Sparks> jrusnack: Ubuntu might want our patches.  :)
19:45:06 <ignatenkobrain> Sparks: +1
19:45:34 <Sparks> jrusnack: That's true.  When we fix things outside of upstream we'd want to know exactly what else we're touching and work with those packagers too.
19:45:35 <ignatenkobrain> I'd say so
19:45:51 <ignatenkobrain> openssl in Fedora doesn't support md5 since f21
19:46:02 <ignatenkobrain> disabled by our maints
19:46:04 <Sparks> jrusnack: It's unfortunate that this is the reaction from upstream.
19:46:15 <ignatenkobrain> so I think we can break legacy things
19:46:57 <jrusnack> Sparks: the reason for that is: guy who reported this wanted his patch to be merged into pwgen, and when author refused, he tried to force him by requesting CVEs for the issues :)
19:47:13 <Sparks> Oh good
19:47:21 <Sparks> I'm glad we're keeping everything civil.  :)
19:47:38 <jrusnack> the patch contained many other belss and whistles, and of course author was only annoyed and didn`t play along
19:47:44 <Sparks> So, we can probably break legacy things if those legacy things aren't in the current release
19:48:04 <jrusnack> I think so
19:48:21 <Sparks> jrusnack: Yeah, I'd only be interested in shipping a fix for the vulnerability, not features.  If the person wants features added then he can fork.
19:49:36 <joat> Gotta go
19:49:45 <Sparks> joat: Thanks for coming!
19:50:06 <Sparks> jrusnack: Any chance in getting upstream to consider fixes for the vulnerabilities only?
19:50:06 <ignatenkobrain> I looked at this patch
19:50:08 <jrusnack> joat: bye !
19:50:17 <ignatenkobrain> joat: bye
19:50:26 <bojov> joat: bye
19:50:27 <ignatenkobrain> seems we will not break critical things
19:50:53 <jrusnack> Sparks: sure, the package is small and if the patch is minimal, it won`t hurt to try
19:51:29 <jrusnack> although, phonemes bias one might not be fixable
19:51:34 <Sparks> Okay, I'd say we should try to work with upstream again.  In the end, though, we should try to get the fix into Fedora.
19:51:47 <Sparks> sure
19:51:53 <ignatenkobrain> well. someone should contact upstream
19:52:02 <ignatenkobrain> I think I can try
19:52:18 <bojov> if break legacy patch must include changes in man pages? or at least documented in README?
19:52:25 <jrusnack> ignatenkobrain: I did write to tytso.
19:52:42 <ignatenkobrain> jrusnack: tytso... softworks?
19:52:44 <Sparks> bojov: And perhaps put something in the release notes.
19:52:55 <ignatenkobrain> ooops
19:53:00 <ignatenkobrain> I'm wrong
19:53:17 <jrusnack> ignatenkobrain: http://sourceforge.net/u/tytso/profile/
19:53:34 <ignatenkobrain> yes, I know this guy ;)
19:53:46 <jrusnack> bojov: Sparks: funny you mention it. The insecure behaviour is well documented in manpage
19:54:34 <Sparks> jrusnack: Is it an optional insecure behaviour?
19:54:41 <jrusnack> Sparks: yes.
19:55:17 <jrusnack> Sparks: you can, and should, force secure passwords explicitly
19:55:23 <Sparks> jrusnack: If it's documented then it likely isn't a CVE
19:55:44 <jrusnack> Sparks: right ? makes me wonder why it was assigned
19:56:21 <Sparks> jrusnack: Me too.  I'm pretty sure you can allow some really stupid things as long as it is documented.
19:57:42 <jrusnack> anyway, that is almost philosophical debate. I`ll try to figure out what can be patched and follow up with upstream
19:57:44 <Sparks> jrusnack: Let me follow up on these with Red Hat Product Security and see if we can get a ruling on this.
19:57:54 <Sparks> jrusnack: +1
19:58:02 <Sparks> #action jrusnack to follow up with upstream
19:58:17 <Sparks> #action Sparks to follow up with Product Security regarding the validity of the CVEs.
19:58:26 <Sparks> #topic Open Floor
19:58:45 <Sparks> Okay, with less than two minutes left, does anyone have anything else they'd like to say?
19:59:13 <ignatenkobrain> ack
19:59:16 <ignatenkobrain> nothing from me
19:59:38 <bojov> nothing for now
19:59:39 <ignatenkobrain> only - let's go fixing vulnerabilities !
19:59:51 <Sparks> Okay, well then I'm going to close the meeting.  I really appreciate everyone joining us today.  See you guys on IRC and the mailing list.
19:59:52 <ignatenkobrain> 500+ is so much
19:59:59 <ignatenkobrain> yea
20:00:04 <jrusnack> Sparks: thank you !
20:00:05 <Sparks> #endmeeting