- Wednesday, July 8, 2015

release-team@conference.openafs.org

Wednesday, July 8, 2015< ^ >

Room Configuration

Room Occupants

GMT+0
[12:11:16] meffie joins the room
[12:20:03] wiesand joins the room
[14:01:38] <wiesand> Hello
[14:01:45] <wiesand> Anyone actually here?
[14:01:59] hi
[14:02:02] <meffie> hello
[14:02:09] oh, sigh. i am the room again
[14:02:16] <wiesand> Ah :)
[14:03:57] <Jeffrey Altman> morning
[14:03:59] <Jeffrey Altman> afternoon
[14:04:07] <wiesand> Whatever. Hello.
[14:04:21] <wiesand> Linux 4.2 news anyone?
[14:04:32] <Jeffrey Altman> There are at least four changes required
[14:05:02] <wiesand> getting worse...
[14:05:41] <Jeffrey Altman> we have been told that a major refactoring of the linux vfs is underway so the pace of change is going to increase not decrease
[14:06:02] <wiesand> Sounds bad.
[14:06:21] <Jeffrey Altman> since Linus pulls directly from Al's private repo there is no way for us to see what is coming before it lands
[14:07:39] <wiesand> Sounds like there might be times without a working client for the current mainline kernel.
[14:07:56] <wiesand> That wouldn’t worry me much.
[14:08:32] <wiesand> But Ubuntu LTS “backporting” changes braking the opeanfs client very quickly  does.
[14:09:09] <Jeffrey Altman> one of the changes is to the processing of link operations which removes our ability to alter the total link count to avoid hitting the symlink loop detection
[14:09:56] <Jeffrey Altman> not having a working client is the downside of being out of tree
[14:09:58] <wiesand> (This could be the end of AFS home dirs on our Linux desktops)
[14:10:48] <wiesand> Would this link count issue be avoided by presenting mountpoints as mounts?
[14:11:26] <Jeffrey Altman> I don't think so.  Each mount is a link
[14:12:23] <Jeffrey Altman> what the existing afs automount code does is decrement the total link count and that we can no longer do
[14:13:01] <Jeffrey Altman> in other words the vfs sees a mount and increases the link count and openafs resets the link count to ignore the mount point
[14:13:44] <Jeffrey Altman> orgs that have very deep trees of mount points could start seeing failures due to symlink loop detection as a result
[14:14:23] <wiesand> Bad.
[14:14:50] <wiesand> Any hope for a workaround from Marc?
[14:15:50] <Jeffrey Altman> We can make the tree work with the new changes.  We cannot alter the link count.
[14:16:55] <Jeffrey Altman> Marc has changes in AuriStor.  We will backport them to openafs as time permits.  Likely after the next round of changes is pulled in by Linus.
[14:17:52] <wiesand> Ok, thanks.
[14:18:05] <Jeffrey Altman> YFS has a lot of deadlines this month and I am focusing all of my available energy on the Win10 release on July 29
[14:18:18] <Jeffrey Altman> because that is likely to be the last release from openafs
[14:18:48] <wiesand> The last windows openafs will ever support?
[14:19:46] <Jeffrey Altman> once the certification checks kick in new releases of openafs cannot be signed and installed.
[14:20:27] <Jeffrey Altman> openafs cannot pass certification as-is
[14:22:22] <Jeffrey Altman> The AuriStor client is compatible with OpenAFS servers and sites can deploy that if they need newer certified clients for Windows
[14:22:53] <Jeffrey Altman> (when AuriStor is certified which is currently is not)
[14:24:37] <wiesand> Ok, end of the road.
[14:24:49] mvita joins the room
[14:25:41] <wiesand> Talking about a tentative schedule for the next release seems moot without having the substantial changes at hand. So maybe next week.
[14:26:17] <wiesand> Is there anything else in the pipeline that would warrant a next 1.6.x release anytime soon?
[14:26:35] <wiesand> I guess not.
[14:26:38] <mvita> <sorry I'm late - unavoidably detained>
[14:26:47] <wiesand> Hello Mark.
[14:27:12] <mvita> hello
[14:27:27] <wiesand> Regarding 1.8, I haven’t seen much going on in gerrit.
[14:27:53] <Jeffrey Altman> now that Ben no longer works for MIT I do not expect to see much happening on a full time basis
[14:27:53] <wiesand> We can probably forget that for the time being?
[14:29:04] <Jeffrey Altman> I have been told that MIT plans to include openafs development experience as one of the criteria for Ben's replacement.
[14:29:10] <wiesand> So, “yes we can”.
[14:29:20] <mvita> :-)
[14:29:31] <Jeffrey Altman> I've suggested a few candidates but the job has not been posted yet
[14:29:54] <wiesand> Thanks for the info.
[14:30:15] <wiesand> The next item I put on the agenda is the handling of security related changes.
[14:30:30] ok. how do you want to handle them? ;)
[14:30:31] <Jeffrey Altman> Simon is on vacation so he cannot join this discussion.
[14:30:52] i have a page up in front of me which russ tells me explains how he
got CVEs. i plan to get one shortly
[14:31:10] <wiesand> Which shows one of the problems we have in this area...
[14:31:38] <mvita> single point of failure
[14:31:41] <Jeffrey Altman> The core issue is getting the CVEs which were not obtained by Simon but by Russ
[14:31:56] <wiesand> I’m seriously unhappy about the situation.
[14:32:06] who's the single point of failure?
[14:32:21] <Jeffrey Altman> My understanding is that he was able to obtain them easily because of his relationship within Debian which is a CVE Numbering Authority
[14:32:22] <mvita> well, maybe that's putting it too harshly
[14:32:43] <mvita> but that we have a small project, and so understandably there will be one person who does certain things
[14:33:01] <Jeffrey Altman> prior to Russ joining we had a hell of a time obtaining CVEs.
[14:33:05] <mvita> when that person moves on, we're temporarily stalled
[14:33:10] <Jeffrey Altman> now that he is gone Simon has had a hard time getting them
[14:33:11] <wiesand> One core issue IMO is clinging to pre-issued embargoed CVEs even in cases where they aren’t needed.
[14:34:42] <mvita> it looked to me like Russ got them through Debian - is that accurate?
[14:34:54] <mvita> at least the few I looked at
[14:35:16] <Jeffrey Altman> Russ got them through Debian because he is a security person within Debian
[14:35:25] <Jeffrey Altman> Debian does not process CVEs for outsiders
[14:35:53] <mvita> ahh
[14:36:04] <wiesand> Who is maintaining the debian openafs packages today?
[14:36:11] <mvita> so what did you think of my idea of working through Oracle for this one?
[14:36:11] <wiesand> Or are they orphaned?
[14:36:43] <Jeffrey Altman> Oracle is a CNA for Solaris only and we are not Solaris
[14:37:07] <Jeffrey Altman> We are supposed to work directly with MITRE but that has been difficult
[14:37:11] <mvita> well - Solaris kernel module may count
[14:37:12] <Jeffrey Altman> or with CERT
[14:37:24] <Jeffrey Altman> Oracle doesn't ship it
[14:37:59] <mvita> I understand about working directly w/ MITRE being a tedious process - they are swamped
[14:38:32] <mvita> so we have to stick w/ that for now unless we can identify an appropriate CNA to help us out
[14:38:44] <wiesand> Obtaining a CVE through oss-security should be fairly painless. No embargo though.
[14:38:46] <Jeffrey Altman> pretty much the way that CNAs work is they have an agreement that permits them to issue CVEs for their own products.   Debian is supposed to be "linux only" but because of the relationships the lines were bent
[14:39:09] <mvita> okay
[14:40:12] https://github.com/RedHatProductSecurity/CVE-HOWTO
and russ suggested secalert@redhat.com
[14:40:19] <mvita> well, I _think_ we have consensus that this is indeed an exploitable security issue, but of a relatively low order - not a widespread or severe exposure
[14:40:37] <Jeffrey Altman> the one you know about
[14:40:38] <mvita> so maybe going w/out embargo would be okay?
[14:40:45] <Jeffrey Altman> there are other issues
[14:41:37] <mvita> I'm vaguely aware that there are others in the backlog, but don't know details.
[14:41:52] <mvita> so the case for embargo is stronger for them?
[14:43:33] <Jeffrey Altman> The gatekeepers have been beaten up time and again for shipping security related bug fixes mixed with non-security related fixes.   Not everyone cares but those that do care a lot.
[14:44:40] <mvita> makes perfect sense
[14:44:58] <Jeffrey Altman> So we don't mix them.  The purpose of the embargo is so we can document the CVE in the commit messages, and fix all of the relevant branches that need to be fixed.   Give those that trusted to build binaries for platforms that need them the ability to do so before the announcement.
[14:45:18] <mvita> nod
[14:46:20] <Jeffrey Altman> there is coordination required for that and since we do not have paid staff for these roles and rely on volunteers (some of whom have more than one job and small children) the coordination becomes even more difficult.
[14:46:58] <mvita> I know our community resources are spread thin - how can I help?
[14:47:16] <Jeffrey Altman> Russ didn't write a lot of code but he was a big help for things like security releases because of his placement in various orgs and because doing this was part of his job description for Stanford
[14:48:51] meffie leaves the room
[14:48:52] meffie joins the room
[14:49:24] <wiesand> Under the bottom line the current procedure isn’t working.
[14:50:14] at some point today, probably when i get lunch, i will compile the
list of needed CVEs and submit them. we need patches for master and
1.6, at least. those can be staged and wait for the CVEs to come back.
[14:51:03] <wiesand> IMO the “CVE dance” should be limited to critical cases.
[14:51:31] <Jeffrey Altman> What do you define as "critical"?
[14:51:57] <Jeffrey Altman> In Mark's case we asked for review from former Solaris developers and they told us it was clearly exploitable
[14:52:10] <wiesand> There’s an “official” definition of it.
[14:52:25] <wiesand> All the worse...
[14:52:55] <mvita> yeah, Mitre's CVE review and classification process is the official definition
[14:52:58] <Jeffrey Altman> I'm sorry you disagree about the criticality of exploitable kernel vulnerabilities
[14:53:20] <mvita> who's disagreeing?
[14:53:28] <Jeffrey Altman> Stephan
[14:53:54] <wiesand> As an example, if it requires a nonstandard configuration that nobody has ever seen in the wild, it’s probably not critical.
[14:54:31] <Jeffrey Altman> if that non-standard configuration can be created by the attacker it doesn't matter
[14:54:36] <mvita> clearly we have to solve the general case, but it would be helpful to just focus on this specific case for now - unless.... it seems you consider mine and the others to be equally critical, Jeff?  Am I reading that correctly?
[14:55:10] <Jeffrey Altman> they are all worthy of CVEs
[14:55:32] <mvita> sure.  but are they all worthy of embargo?
[14:56:12] <Jeffrey Altman> We embargo because of our process
[14:56:59] <mvita> that didn't answer my question
[14:57:04] <mvita> process can change
[14:57:20] <mvita> if the situation calls for it
[14:57:38] <Jeffrey Altman> If we want to give up the embargo we stop hiding the patches from gerrit, and doing updates behind the scenes, and providing the ability to get binaries out
[14:57:49] <wiesand> “worthy of a CVE” is very different from “absolutely requires an embargoed CVE”
[14:58:57] <mvita> I'm new to the table here, but I'm quite sympathetic to what Stephan just said - unless someone can give me a convincing argument otherwise
[14:59:45] <Jeffrey Altman> I don't know what I can tell you to convince you since obviously what I have already explained is insufficient
[15:00:09] <Jeffrey Altman> we don't trust you with the keys to the world so there are large classes of things you can't know and can't do
[15:00:23] <mvita> to CVE or not and to embargo or not are related questions, but not completely independent
[15:01:10] <mvita> I'm not trying to be difficult, honestly - I really want to understand why the two questions must have the same answer?
[15:01:37] <Jeffrey Altman> If something is in the security queue and is not pushed to gerrit, it gets an embargoed CVE.   If it is moved out of the security queue or the change is pushed to gerrit publicly, we do not get an embargoed CVE
[15:02:18] <Jeffrey Altman> We do not get CVEs for minor security issues.  If we did openafs would be publishing a hundred a year
[15:02:33] <wiesand> Your explanation is sufficient, and everything makes sense. And the conclusion is that OpenAFS is unable to deliver security fixes.
[15:03:04] <mvita> okay, now i understand your answer better.  openafs policy and process is to only obtain CVEs for issues worthy of embargo
[15:03:15] <Jeffrey Altman> that is not the conclusion.  The conclusion is that doing so is hard
[15:03:51] <wiesand> And the next conclusion is that it doesn’t happen because the resources aren’t available.
[15:04:03] <Jeffrey Altman> and the fact is that until such time as people get some breathing room or new individuals work up the trust chain it will continue to be hard.
[15:04:42] <mvita> Are you willing to help others - take me as an example - work up that trust chain so we can solve this issue?
[15:04:55] <Jeffrey Altman> I'm very sad that Ben left MIT and that he chose not to take a job with one of the orgs that fund openafs work.
[15:07:40] <Jeffrey Altman> working up the trust chain requires a focus on the work of others not just your own or that of your employer.  It also requires a demonstration of expertise across platforms and of good security practices.
[15:08:01] <mvita> of course.
[15:08:19] <Jeffrey Altman> its not my trust that needs to be earned but that of the broader community.
[15:09:05] <wiesand> Not getting security fixes out at all is not earning anyone’s trst.
[15:09:06] <mvita> I can't begin to do that until this fix goes out with my name on it.
[15:09:33] <mvita> so you can understand my frustration with the chicken-and-egg problem here
[15:10:08] <mvita> I think I've conducted myself well so far on this, and will continue to do so.
[15:10:17] from the other side, there is the temptation to just toss back my
keys, walk away, and yinz can figure out who you want to deal with
what.
[15:10:48] (and it feels wrong that the room name, not mine, is on that comment.
as i will absolutely own what i said)
[15:12:49] <wiesand> The last item I put on the agenda, and quite related IMO, is that of the release manager.
[15:14:20] <wiesand> Things have changed since I accepted this role. To the point that I’m wondering wether the role still makes sense at all and/or I’m the right person for it.
[15:14:39] <Jeffrey Altman> mvita: I'm not saying that you haven't conducted yourself well on this particular issue.   Ben took personal ownership for a platform (FreeBSD), he personally made sure that new releases of the OS were covered and added missing functionality.   He then began other projects.  He reviewed just about every submission to gerrit.  Over time he earned the ability to do more and more.   Your own work contributes to some of the trust level but a large degree of it has to do with what you do for others.
[15:14:44] <wiesand> Thoughts welcome.
[15:15:03] hey, we can all walk away together and have a drink, and let other
people deal. sounds good to me
[15:15:48] <Jeffrey Altman> Stephan, when you started the role there were two release managers for the branch.   Paul resigned and you carried on by yourself.
[15:15:57] <meffie> i think the role makes sense, and i think you continue to be a very good release manager.
[15:16:10] <mvita> jeffrey:  yes, I'm new to openafs and unix in general so I'm not qualified to do that yet - but I've been working hard to get to that point on Linux and Solaris kernel code
[15:17:16] <wiesand> I never objected to adding back a second release manager, and that’s not the change that actually concerns me most.
[15:17:17] <mvita> and for that matter, Windows as well
[15:17:24] <mvita> I'm farthest along w/ Solaris.
[15:17:33] <Jeffrey Altman> Stephan, my preference would be for you to work with someone, perhaps Mark, before you decide to walk away.
[15:18:53] meffie leaves the room
[15:18:56] <mvita> stephan I agree w meffie and jeffrey - you are doing a good job and no one wants to see you walk away - that's why we're discussing this
[15:19:39] <mvita> would it help if you had a helper again?
[15:19:53] <Jeffrey Altman> You might not remember but when Paul came back you indicated that you wanted to do the role on your own and you have done a wonderful job
[15:19:54] meffie joins the room
[15:20:16] <wiesand> Jeffrey: I’d be fine with that. It just wouldn’t change the situation.
[15:20:27] <wiesand> Contributors and contributions are dwindling.
[15:20:56] that is true. and i'm not sure what we can do to fix it, but it does
need to be fixed
[15:20:57] <Jeffrey Altman> that is true.
[15:21:26] <wiesand> Half the time one’s gagged and handcuffed. The other half one doesn’t have anything near the complete picture.
[15:21:42] <mvita> ah.
[15:21:44] <mvita> okay.
[15:22:07] <mvita> may I propose that Stephan (well, "release managers") be automatically included in the security loop.
[15:22:15] <Jeffrey Altman> Stephan is
[15:22:25] <wiesand> I do have elevated access to security stuff.
[15:22:40] <mvita> ah, so what do you mean about not having the complete picture?
[15:22:41] <wiesand> That’s still limited though.
[15:23:00] <Jeffrey Altman> None of us have the complete picture
[15:23:17] <mvita> well
[15:23:22] <mvita> certainly Simon does?
[15:23:31] <Jeffrey Altman> why do you say that?
[15:23:32] <mvita> isn't he the security officer?
[15:23:40] <Jeffrey Altman> that isn't the complete picture
[15:23:50] <mvita> please explain
[15:24:17] <Jeffrey Altman> Security is not the reason that contributions are dropping.
[15:24:18] <mvita> I apologize for my noob-ness here
[15:24:47] stephan is on a group that has permission to view the security queue,
already. so i guess the question is what else
[15:25:06] <Jeffrey Altman> why are contributions dropping?
[15:25:28] i'd venture it's not because of 3 things stuck in the security queue
[15:25:36] <Jeffrey Altman> absolutely not
[15:26:11] <wiesand> These are two different issues, yes. Both place a big question mark behind the current state though.
[15:27:28] <mvita> as a rank noob, my opinion is the #1 reason is high barrier of entry due to complexity of code and less-than-encouraging project culture
[15:28:54] i'd argue that's 2 reasons
[15:28:58] <mvita> #2 is low incentive due to small install base and obscurity of the project
[15:29:01] <wiesand> I’m not going to walk away without prior notice. But let me say that I’ll have no hard feelings if the outcome of the Pittsburgh workshop is that I’m expendable.
[15:29:21] <wiesand> Marc: what’s so bad about the project culture?
[15:29:22] <Jeffrey Altman> I doubt that is the outcome.
[15:29:32] <Jeffrey Altman> I don't know what the Foundation is going to decide to do
[15:30:36] <mvita> perhaps culture is the wrong word
[15:32:15] i'm not sure it is. in a project where no one seems to be excitedly
working on anything at the moment, culture might be exactly the right
word
[15:32:16] <mvita> getting fixes through gerrit is often very discouraging, even sisyphean -
[15:32:50] <Jeffrey Altman> it is because there are so few reviewers that are trusted.
[15:33:03] <mvita> and I'm NOT complaining about justified −1
[15:33:11] <Jeffrey Altman> and those that are trusted do not have time to do reviews because they are busy doing other things to earn a living
[15:33:40] <mvita> well, I _am_ sometimes paid to do reviews, and not just of my own stuff or my company's stuff
[15:33:47] this was easier when 3 of us made everything fly by the seat of our
pants, but the process was definitely lacking
[15:33:51] <Jeffrey Altman> great
[15:34:15] <Jeffrey Altman> I'm glad to hear that you are being paid
[15:34:26] <Jeffrey Altman> but that isn't true for many of the rest of us
[15:34:42] <Jeffrey Altman> and hasn't been for the better part of a decade
[15:34:42] <mvita> nod
[15:36:33] <mvita> I have not been doing many for a number of months because I'm focused on some very difficult tickets.  But I consider reviewing to be part of my job, so I certainly intend that the current lull in my contributions of both code and reviews is temporary.
[15:36:36] <Jeffrey Altman> I am very late to a meeting.   I'm sorry that some many people are feeling down
[15:37:16] <mvita> thanks.  so let's continue to focus on solutions.
[15:37:24] <Jeffrey Altman> I'm really hoping that the in person discussions in Pittsburgh will move things forward.  That is the primary reason the bpw is being organized
[15:37:29] <wiesand> I’m not trying to be difficult either, sorry. Just felt this had to be said.
[15:38:05] <wiesand> And to say it clearly once more: Having Mark as a partner would be fine!
[15:38:22] <mvita> I'll talk to evan about the possibility of my deeper involvement - e.g. helping Stephan.
[15:38:24] <Jeffrey Altman> welcome aboard
[15:38:30] <meffie> cool!
[15:38:53] <meffie> on that note, adjourn?
[15:39:04] <wiesand> I’ll just assert that it would reduce my workload, but not remove the hurdles to actually managing openafs releases.
[15:39:22] <mvita> one last question about the security issue, I'll raise it in the ticket
[15:40:40] <wiesand> Fine. Thanks a lot for this discussion!
[15:41:08] <mvita> thank you, all
[15:43:34] <wiesand> cu
[15:43:37] wiesand leaves the room
[15:45:56] meffie leaves the room
[17:07:24] mvita leaves the room
[17:07:25] mvita joins the room
[17:09:16] meffie joins the room
[17:27:08] mvita leaves the room
[17:27:09] mvita joins the room
[17:28:47] mvita leaves the room
[17:36:03] mvita joins the room
[18:55:46] meffie leaves the room
[19:07:14] meffie joins the room
[19:07:36] meffie leaves the room