14:00:40 <Sparks> #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings
14:00:40 <zodbot> Meeting started Thu Nov  6 14:00:40 2014 UTC.  The chair is Sparks. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:43 <Sparks> #meetingname Fedora Security Team
14:00:43 <zodbot> The meeting name has been set to 'fedora_security_team'
14:00:45 <Sparks> #topic Roll Call
14:00:55 <mhayden> here!
14:00:57 <bvincent> .fas bvincent
14:00:58 <zodbot> bvincent: bvincent 'Brandon Vincent' <Brandon.Vincent@asu.edu>
14:01:34 <pjp> here!
14:02:35 <Sparks> jsmith: PING
14:03:37 <bvincent> Sparks: Time Exceeded: Time-to-live exceeded in transit.
14:03:46 <bvincent> Sparks: Couldn't resist.
14:03:48 <Sparks> hahaha
14:03:52 * mhayden sees what you did there
14:04:07 <sgallagh> So does that mean we have to have a funeral?
14:04:18 <pjp> :)
14:04:30 <bvincent> My ISP cut a fiber line yesterday, so I've been looking at my horrible connection a little closer.
14:05:35 <pjp> bvincent: cut a fibre, why?
14:06:07 <bvincent> pjp: I believe it was an accident, but it impacted the entire state. They had to change the BGP routing through another tier 1 provider.
14:06:32 <pjp> bvincent: Oh boy,
14:06:43 <D-Caf> Wow, impressive fiber cut
14:07:08 <Sparks> I love it when that kind of stuff happens.
14:07:14 <Sparks> Okay, lets get started.
14:07:26 * pjp is reminded of the under sea fibre cut couple years ago, near gulf which affected large parts of the interweb
14:07:33 <Sparks> #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better"
14:07:41 <Sparks> #topic Follow up on last week's action items
14:07:49 <Sparks> Sparks to follow up with fenrus02 (via the security list) on checksec and checksec2.
14:08:02 <Sparks> ^^^ I did not do this and cannot remember why this was important.
14:08:11 <Sparks> #action parks to follow up with fenrus02 (via the security list) on checksec and checksec2.
14:08:17 <Sparks> grrr
14:08:19 <Sparks> #undo
14:08:19 <zodbot> Removing item from minutes: ACTION by Sparks at 14:08:11 : parks to follow up with fenrus02 (via the security list) on checksec and checksec2.
14:08:33 <Sparks> #action Sparks to follow up with fenrus02 (via the security list) on checksec and checksec2.
14:08:39 <Sparks> #topic Outstanding BZ Tickets
14:08:45 <Sparks> #info Wednesday's numbers: Critical 1, Important 46, Moderate 346, Low 122, Total 507, Trend +8
14:08:49 <Sparks> #info Current tickets owned: 212 (~36%)
14:08:54 <Sparks> #info Tickets closed: 148
14:09:06 <Sparks> So, we closed four cases this week.
14:09:13 <pjp> Sparks: IIRC, it's not packaged for Fedora
14:09:38 <pjp> checksec2
14:09:48 <Sparks> #info EPEL will start retiring packages that are orphaned for more than six weeks (including dependencies).
14:10:09 <Sparks> fenrus02: Are you going to be around in ~30 minutes or so?
14:11:56 <Sparks> Does anyone have anything ticket-wise they'd like to discuss?
14:12:00 <bvincent> One issue.
14:12:11 <bvincent> CVE-2014-8517 came out a couple of days ago.
14:12:11 <Sparks> bvincent: Go
14:12:35 <Sparks> #link https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-8517
14:12:38 <bvincent> Thanks.
14:12:44 <bvincent> The packages are in the testing repository.
14:13:11 <bvincent> I feel like this issue is one of the cases where the packages should be pushed with a greater sense of importance.
14:13:29 <bvincent> What ever happened to the idea for the security repo?
14:13:37 <bvincent> This is probably another good case.
14:13:59 <pjp> bvincent: security repo?
14:14:06 <Sparks> Well, this hasn't made it to the repo phase yet so that's a non-issue at the moment.
14:14:26 <Sparks> bvincent: I suspect you're thinking about https://fedoraproject.org/wiki/Urgent_updates_policy
14:14:38 * pjp clicks
14:15:00 <bvincent> Sparks: +1 that was the previously discussed issue. Thanks.
14:15:02 <Sparks> bvincent: But it needs to be pushed through QA first before this policy applies.
14:15:51 <Sparks> #link https://fedorahosted.org/rel-eng/ticket/5886
14:17:21 <Sparks> bvincent: There appears to have been some movement on the repo side of the house.  Lots of discussion ~6 days ago.
14:17:40 <bvincent> Sparks: That looks interesting. Thanks for bringing it up.
14:19:56 <mhayden> i'd also like to bring up XSA-109/110 that affect Xen
14:20:01 <mhayden> #link http://xenbits.xen.org/xsa/
14:20:10 <Sparks> bvincent: It would be nice if we could move a higher-priority package through the system a bit quicker.
14:20:49 <mhayden> i'm looking to collaborate with someone on RHT's SRT about a possible mitigation for one of the new XSA's
14:20:50 <bvincent> Sparks: That is what I was pretty much getting at. This issue isn't that critical, but it is significant.
14:21:46 <Sparks> bvincent: I think the powers that be know about the issue.  I guess it's important to just keep the conversation going in their channels to keep this issue on top.
14:21:57 <Sparks> mhayden: Ummm... Give me a sec.
14:22:34 <mhayden> Sparks: could probably discuss this one offline afterwards... but there is a level of impact for fedora
14:23:21 <Sparks> mhayden: Is this something at affects RHEL and Fedora and EPEL?
14:23:29 <Sparks> s/and/and\/or
14:23:47 <mhayden> potentially -- still under embargo so we'd probably need to discuss details via private medium
14:23:59 <bvincent> I'm a little more surprised at NetBSD for letting this one slip by. OpenBSD has had protection against malicious filenames for a while.
14:24:07 <mhayden> bvincent: that was a surprise for me as well
14:24:35 <bvincent> Then again seeing FTP minus the TLS gives me shivers.
14:24:56 <bvincent> That probably won't change for another twenty years.
14:25:14 <Sparks> #topic Open floor discussion/questions/comments
14:25:47 <pjp> I'd like to to report about the FAD from last weekend
14:25:57 <pjp> -> https://fedoraproject.org/wiki/FAD_Pune_Security_1
14:26:07 <mhayden> pjp: saw your blog posts -- how did it go?
14:26:43 <pjp> It turned out to be quite good, we managed to touch about 30-35 issues,
14:27:01 <pjp> I specifically touched older ones from 2012,
14:27:37 <pjp> one issue that I want to bring to our notice here is, one of the bug in sSMTP has been open since 2012,
14:27:56 <Sparks> pjp: Links to blog posts would be good
14:27:57 <pjp> -> https://bugzilla.redhat.com/show_bug.cgi?id=864897
14:28:07 <D-Caf> pjp: nice
14:28:33 <bvincent> pjp: ssmtp is developed by Debian, no?
14:28:34 <pjp> Sparks: yes, I'm yet to write a detailed report, purposely delayed it for following up with the maintainers
14:32:45 <pjp> Hi, sorry xchat crashed!
14:32:57 <Sparks> pjp: heh
14:33:39 <pjp> Yeah, so the issue with the sSMTP one is, the fedora maintainer has quit programming since 15 yrs, and requires someone else to write a patch for it
14:34:02 <pjp> from the Debian repository it looks quite inactive too,
14:34:12 <bvincent> pjp: So upstream is gone?
14:34:27 <pjp> bvincent: no, not gone, it's there but does not look very active
14:34:42 <bvincent> pjp: If I recall, didn't the introduction of OpenSSL 1.0.1 make this very easy to implement?
14:34:48 <pjp> ->http://anonscm.debian.org/cgit/ssmtp/ssmtp.git
14:35:19 <pjp> bvincent: no the bugzilla comment says Openssl-1.1 makes it easy,
14:35:41 <bvincent> pjp: I think I looked at this issue before, hense the reason I somewhat remember it.
14:35:58 <pjp> I even filed an RFE against OpenSSL for back porting a required function to older versions, but it's immediately closed citing it's unlikely to happen
14:36:36 <pjp> of the 5-6 issues that I touched, only one of the maintainer has replied promptly,
14:36:52 <pjp> others have still no response,
14:37:35 <pjp> I'm trying to find someone who would like to write a patch for sSMTP to correctly do the server certificate validation,
14:38:22 <pjp> my question/concern is, if these bugs are inactive for more than 1.5-2 yrs, and still there is no progress, could we come up with some policy to deal with them?
14:38:52 <pjp> If they need contributors, maybe we need to actively look for such contributors and help/guide them towards writing patches
14:39:09 <Sparks> pjp: They still aren't dealt with.  I'd suggest leaving them open until the package is retired.
14:39:53 <bvincent> Makes sense. If nobody steps up on fedora-devel, I suppose that is the price you pay when no one wants to support a package.
14:40:15 <pjp> Sparks: what's the point of leaving them open? Secondly, it's possible that we won't know if the package is dead or not,
14:41:29 <pjp> looking at the debian sSMTP repo, it was last touched about 3 yrs ago,
14:41:40 <Sparks> pjp: It lets people know that there are still outstanding security issues pending.
14:42:17 <Sparks> pjp: Just because you close the ticket doesn't make the issue go away.  It would be better for a new maintainer to see exactly what is pending against a package if they decide to take it over.
14:42:21 <pjp> Sparks: true, but if the package is unmaintained or not active, maybe we could actively retire them
14:42:34 <pjp> Sparks: no, I'm not saying we close the ticket
14:42:37 <Sparks> pjp: We should if there are security vulnerabilities against them.
14:43:21 <pjp> Sparks: yes, the sSMTP issue is similar to this one -> https://github.com/google/nogotofail/blob/master/docs/getting_started.md#invalid-hostname-certificate
14:43:41 * Sparks feels as if he ran into this issue.
14:43:52 <pjp> yet, unpatched for > 2 yrs
14:44:32 <pjp> In fact, IIUC, the upstream source clearly states that it does not do server certificate validation at all, and hence it is _not_ a security issue for it
14:45:44 <bvincent> Sounds like this belongs in some Fedora Project policy or something. I would assume that any program that uses SSL/TLS should verify the certificate and chain.
14:45:52 <pjp> But in Fedora repository it is known to address this issue, but not neatly
14:46:40 <pjp> -> https://bugzilla.redhat.com/show_bug.cgi?id=864897#c9
14:47:38 * pjp feels there could be many more such instances of this kind
14:47:57 <Sparks> bvincent: It's a CVE if it doesn't.
14:48:06 <pjp> and who knows some of them could be major glitches too,
14:48:34 * Sparks notes that duplicity has a similar bug
14:48:43 <bvincent> Sparks: Well that answers the question. I'm not a programmer my any stretch, but could nss_compat_ossl assist in fixing this?
14:48:56 <bvincent> Maybe NSS is better suited at this point?
14:49:18 <Sparks> bvincent: Compared to...  OpenSSL?
14:49:35 <bvincent> Well the functionality that is only in OpenSSL 1.1 might be in NSS. I honestly don't know.
14:51:56 <pjp> Okay, a second maintainer responded just now saying maybe the package needs to be retired from EPEL, as it's already available in RHEL ->  https://bugzilla.redhat.com/show_bug.cgi?id=838162#c2
14:52:44 <pjp> And the security tracker against EPEL was open since July 2012
14:53:24 <Sparks> sSMTP?  It's in RHEL?
14:53:59 <pjp> Sparks: no-no, it's -> sblim-sfcb
14:54:06 <Sparks> Ahhh
14:54:33 <Sparks> Okay, we're getting close to the top of the hour.  Does anyone have anything else they'd like to discuss?
14:55:15 <pjp> I'll write a detailed report about FAD this weekend, maybe we could discuss about these issues on the list?
14:56:02 <Sparks> +1
14:56:40 <pjp> okay,
14:57:49 <Sparks> Anyone have anything else?
14:58:43 <Sparks> And with that...  I bid you all a good day!  Thanks for coming!
14:58:47 <Sparks> #endmeeting