- Wednesday, October 5, 2016

release-team@conference.openafs.org

Wednesday, October 5, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[14:00:09] wiesand joins the room
[14:00:19] <wiesand> Hi
[14:00:54] <Jeffrey Altman> hi
[14:02:05] <kadukoafs@gmail.com/barnowl9C09F4AA> Greetings
[14:02:22] <kadukoafs@gmail.com/barnowl9C09F4AA> Thanks for pushing 12409, Jeffrey.
[14:02:43] meffie joins the room
[14:02:48] <wiesand> yes, that looks interesting... what’s the impact?
[14:02:54] <meffie> hello.
[14:04:34] <wiesand> Is 12409 a must-have for 1.6.19?
[14:05:02] <Jeffrey Altman> yes
[14:05:11] <kadukoafs@gmail.com/barnowl9C09F4AA> We probably want it, yes
[14:05:31] <wiesand> ok, thanks
[14:06:40] <mvita> hi
[14:09:24] <meffie> > yes, that looks interesting... what’s the impact?
my understanding; users were seeing corrupted files.
[14:09:25] <wiesand> 12409 has a path conflict with 12328 - I guess there are no news on the latter one?
[14:09:59] <wiesand> eek
[14:10:42] <wiesand> pullup is 12413
[14:11:53] <meffie> 12328 should not induce a git merge conflict. it's a different function.
[14:12:03] <kadukoafs@gmail.com/barnowl9C09F4AA> It seems like there is no news on 12328, yes.
[14:12:43] <wiesand> ok, we have lived without it for a while - I guess 12409 is a bit more important
[14:12:57] <wiesand> mike: not in git, but in gerrit
[14:13:26] <wiesand> but I may be wrong about that once again
[14:13:56] <wiesand> are there other must-haves before we can issue 1.6.19pre1?
[14:14:11] <meffie> well, it's the same file, so gerrit will warn.
[14:14:13] <wiesand> are we still good on Linux 4.8 now that it’s released?
[14:15:26] <meffie> i hear it builds.
[14:15:55] <wiesand> good enough for pre1 ;-)
[14:16:23] <kadukoafs@gmail.com/barnowl9C09F4AA> I guess the time is coming near for my promise to do something about
that other thing to come due.
[14:16:44] <wiesand> the unmentionable?
[14:17:37] <wiesand> Is 12409 so serious that we should consider a 1.6.18.4 ?
[14:18:18] <kadukoafs@gmail.com/barnowl9C09F4AA> yeah
[14:18:25] <kadukoafs@gmail.com/barnowl9C09F4AA> Er, to the first one.
[14:18:32] <Jeffrey Altman> its serious but I dont think a couple of weeks matter
[14:18:32] <wiesand> ok
[14:18:47] <kadukoafs@gmail.com/barnowl9C09F4AA> what Jeffrey said
[14:18:51] <wiesand> ok
[14:19:08] <meffie> that was my impression as well.
[14:19:12] <wiesand> this bug has existed for a long time?
[14:19:41] <Jeffrey Altman> it is a particular problem for systems in which the page size is greater than 4kb
[14:20:15] <kadukoafs@gmail.com/barnowl9C09F4AA> Since 2009, it looks like.
[14:20:53] <wiesand> so not a particular problem on the vast majority of Linux systems
[14:20:58] <mvita> sorry, had to step away unexpectedly for a service tech
[14:23:20] <wiesand> 12365 and 12366 are still on my list of 1.6.19 candidates - they have been in my test builds for a while (EL5/6/7)
[14:23:36] <wiesand> I’m inclined to merge those... any objections?
[14:24:22] <mvita> no objections
[14:24:32] <mvita> I can +1 now if you like
[14:24:43] <meffie> thanks wiesand
[14:24:49] <wiesand> i do
[14:25:16] <kadukoafs@gmail.com/barnowl9C09F4AA> No objections here, either
[14:26:07] <wiesand> so, those two, 12409, another NEWS change, 12368 - that would be 1.6.19pre1
[14:26:45] <wiesand> and of course maybe that other thing
[14:27:53] <kadukoafs@gmail.com/barnowl9C09F4AA> It's almost time for my other meeting, so maybe I will have to drop a
comment and leave :-(
[14:27:57] <kadukoafs@gmail.com/barnowl9C09F4AA> mvita: any news on 12363?
[14:28:28] <mvita> I spent a number of hours on it last week but got pulled off before I could finish
[14:28:54] <mvita> Clearly the other d_invalidate needs to change as well
[14:28:58] <wiesand> Ben, I think we’re done with 1.6, sorry.
[14:28:59] <kadukoafs@gmail.com/barnowl9C09F4AA> Okay.  Thanks for putting the time in!
[14:29:12] <wiesand> If you want to bring up anything else re 1.8, go ahead
[14:29:15] <kadukoafs@gmail.com/barnowl9C09F4AA> I didn't really do much on 1.8 this week, myself, so maybe that
section of the meeting will be short.
[14:29:20] <mvita> once I code it, should I put it in a separate patch, or include in 12363?
[14:29:35] <kadukoafs@gmail.com/barnowl9C09F4AA> It could likely go into 12363 as well.
[14:29:39] <mvita> I've also made the other requested changes to 12363 and rebased it
[14:29:42] <mvita> so it's close....
[14:29:49] <kadukoafs@gmail.com/barnowl9C09F4AA> Yay!
[14:30:05] <kadukoafs@gmail.com/barnowl9C09F4AA> Since it sounds like that is pretty well in hand, I think the other
big 1.8 thing is the NEWS.
[14:31:47] <meffie> would you like a draft?
[14:32:11] <kadukoafs@gmail.com/barnowl9C09F4AA> Feel free to push new revisions of 12395
[14:33:26] <kadukoafs@gmail.com/barnowl9C09F4AA> In fact, please do so.
[14:33:34] <meffie> ok
[14:33:59] <kadukoafs@gmail.com/barnowl9C09F4AA> But I guess we should be careful to check before pushing whether
someone else has pushed a new version, so we don't stomp on each
other.  But that seems fairly unlikely to be a real issue.
[14:35:47] <mvita> where is 1.8 NEWS?
[14:36:01] <kadukoafs@gmail.com/barnowl9C09F4AA> 12395
[14:36:01] <mvita> 12395 is 1.6x
[14:36:10] <kadukoafs@gmail.com/barnowl9C09F4AA> Whoops
[14:36:21] <wiesand> 12393
[14:36:24] <kadukoafs@gmail.com/barnowl9C09F4AA> 12393, typo
[14:36:40] <meffie> ah
[14:36:43] <mvita> dats better
[14:37:48] <kadukoafs@gmail.com/barnowl9C09F4AA> w.r.t the heimdal import, what did you have in mind for the evp_pkcs11
import to be used for?
[14:38:25] <meffie> thank you for asking. i dont think we need it, right? but it seems it is required to build?
[14:38:49] <kadukoafs@gmail.com/barnowl9C09F4AA> Ah.
[14:39:51] <Jeffrey Altman> pkcs11 is required for solaris
[14:39:56] <kadukoafs@gmail.com/barnowl9C09F4AA> I don't think it is problematic to have it around per se.
But, historically heimdal has had a lot of macros we could define to
get it to not reference various features, and also it may be exciting
if we needed to pull that file into the kernel build.
[14:40:23] <kadukoafs@gmail.com/barnowl9C09F4AA> Ah, I raced with Jeffrey's comment.
[14:40:51] <meffie> there are a few things it needs from heimbase.c and it needs dlopen, etc.
[14:41:53] <meffie> is pkcs11 required from the solaris kernel builds too?
[14:41:58] <meffie> s/from/for/
[14:42:34] <kadukoafs@gmail.com/barnowl9C09F4AA> I mean, we only need the kernel hcrypto for, like, AIX and HPUX, IIRC.
I just put it in the build everywhere so we would actually notice if
the build broke.
[14:43:25] <kadukoafs@gmail.com/barnowl9C09F4AA> So, no, it is not "required" in that sense.
But I did not try building the kernel module with the new heimdal
code.
[14:44:26] <Jeffrey Altman> the in-tree hcrypto implementations are very slow.   the purpose behind all of the hcrypto refactoring is to permit use of the OS vendor's supported crypto engine including any hardware support it provides.  It also permits hcrypto to work with the latest OpenSSLcrypto api which broke backward compatibility
[14:45:04] <Jeffrey Altman> pkcs11 is the interface used by Solaris for userland and kernel
[14:45:16] <Jeffrey Altman> pkcs11 is also available on other platforms
[14:45:29] <kadukoafs@gmail.com/barnowl9C09F4AA> "I thought pkcs11 was slow, too" ;)
[14:46:04] <meffie> thanks for the background Jeffrey.
[14:46:32] <kadukoafs@gmail.com/barnowl9C09F4AA> Hmm, maybe my other meeting is not actually happening.
It's 15 minutes past start time and I'm the only one there...
[14:46:43] <Jeffrey Altman> all of that being said.   Heimdal is effectively dead at this point.  Its being removed from Samba and Debian/Ubuntu
[14:47:02] <wiesand> :-(
[14:47:06] <Jeffrey Altman> OpenAFS may want to look at an alternative
[14:47:36] <meffie> very sad.
[14:47:55] <kadukoafs@gmail.com/barnowl9C09F4AA> FreeBSD 11 will still have a Heimdal, but they may mark it as
deprecated in 11.1 and axe it for 12.
[14:48:20] <kadukoafs@gmail.com/barnowl9C09F4AA> But then again, FreeBSD 12 is probably going to have the base system
broken out into a package structure, so that may not be as meaningful
a statement as it seems.
[14:49:11] <meffie> kadukoafs, i have some other minor questions about the pullup as it is so far. i'll just put those in gerrit, ok?
[14:49:35] <kadukoafs@gmail.com/barnowl9C09F4AA> meffie: sounds good
[14:49:48] <Jeffrey Altman> if folks have time I would like to discuss kafs
[14:50:22] <Jeffrey Altman> more to the point AF_RXRPC
[14:51:03] <meffie> ok
[14:51:18] <wiesand> ok
[14:51:35] <kadukoafs@gmail.com/barnowl9C09F4AA> Please go ahead
[14:52:31] <Jeffrey Altman> for those of you that track kafs development you will have noticed that David has pushed hundreds of patches to AF_RXRPC over the past two months.
[14:52:37] <meffie> yes
[14:52:58] <Jeffrey Altman> You might also be aware that David's implementation of Rx is a clean room implementation.
[14:53:22] <Jeffrey Altman> As a result it does many things differently from how Rx has been used in the past.
[14:57:50] <Jeffrey Altman> David has already filed at least one Rx bug report regarding protecting against ddos attacks.  He also filed 133446 about the behavior when the DATA packet of a single packet reply is lost.  David has identified another bug which has yet to be reported to RT whereby the OpenAFS client fails to ack the DATA reply preventing the server from terminating the call and freeing the call channel.
[14:59:07] <wiesand> Well that’s good, isn’t it?
[14:59:35] <Jeffrey Altman> no, not good.
[15:00:26] <wiesand> Not the issues of course, but that someone is finding them
[15:01:03] <Jeffrey Altman> well, that part is good only if there is someone to fix them
[15:01:08] <kadukoafs@gmail.com/barnowl9C09F4AA> "It would be better if someone was fixing them"
[15:01:17] <wiesand> Even better, agreed
[15:04:45] <Jeffrey Altman> I've worked with David to modify the behavior of AF_RXRPC to avoid triggering these misbehaviors because AF_RXRPC has to co-exist with the OpenAFS Rx that is already in the wild.   My concern is that as David documents these issues that they will provide someone a roadmap of how to attack an OpenAFS cell.
[15:05:33] <wiesand> Is there more than DOS one could achieve?
[15:06:38] meffie leaves the room
[15:06:39] meffie joins the room
[15:07:01] <Jeffrey Altman> OpenAFS rx can be used to perform an amplification attack
[15:07:57] <wiesand> That’s ugly, but no reason to keep these issues secret IMHO
[15:08:18] <Jeffrey Altman> it is also susceptible to local denial of service attacks due to resource exhaustion
[15:08:30] <Jeffrey Altman> they aren't secret
[15:10:55] <kadukoafs@gmail.com/barnowl9C09F4AA> People who run old software and don't update are always going to be at
increased risk.
[15:11:16] <kadukoafs@gmail.com/barnowl9C09F4AA> We have never found an effective mechanism to induce people to
upgrade.
[15:13:57] <wiesand> Does Auristor have these fixed yet?
[15:14:33] <Jeffrey Altman> yes
[15:17:46] <wiesand> Anyway, thanks for the info!
[15:18:01] <meffie> yes, thanks for the update.
[15:18:45] <wiesand> I’m unsure what the conclusion would be though...
[15:18:52] <Jeffrey Altman> several of the issues that David identified  were fixed prior to David's discovery as part of the generic rewrite.   David came to me with packet traces because he could understand why OpenAFS was misbehaving with the AF_RXRPC client or srever when AuriStorFS suceeded
[15:20:31] <Jeffrey Altman> AF_RXRPC is not GPL only.  It can be used by other kernel modules and by userland services.
[15:21:40] <kadukoafs@gmail.com/barnowl9C09F4AA> That doesn't really help the Solaris OpenAFS servers, though.
[15:21:48] <Jeffrey Altman> No it doesn't
[15:22:15] <Jeffrey Altman> There are very few sites that use Solaris servers and those that do have money to spend to fix the issues
[15:22:32] <wiesand> Why Solaris in particular?
[15:23:20] <kadukoafs@gmail.com/barnowl9C09F4AA> I hear about people running them, moreso than the other non-linux
platforms.  I guess I hear about FreeBSD, too.
[15:25:00] <meffie> i didnt realize AF_RXRPC was not GPL only.
[15:26:43] <Jeffrey Altman> The conclusion is that OpenAFS has a vulnerability.  Both from a technical and a brand perspective (if a ddos attack is deployed in the wild.)  Those with a financial interest in its future should take this seriously.
[15:28:01] <mvita> will you as gatekeeper be willing to provide patches?
[15:28:14] <mvita> or at least provide more details so others can fix it?
[15:28:24] <Jeffrey Altman> details are in RT
[15:28:29] <mvita> thank you.
[15:28:44] <Jeffrey Altman> when someone pays me to do work I am willing to do work
[15:29:04] <mvita> understood.  but information is free.
[15:29:11] <Jeffrey Altman> information is time
[15:29:16] <Jeffrey Altman> time -- money
[15:32:20] <meffie> thanks for pointing out the RT ticket.
[15:33:10] <wiesand> Anything else to discuss today?
[15:33:43] <meffie> no thanks.
[15:34:05] <mvita> nothing from me.  I plan to do some builds against the new linux 4.9 merge window stuff later this week
[15:34:21] <wiesand> Great, thanks.
[15:34:38] <mvita> I know of at least one issue for which there's not yet a patch on gerrit
[15:34:39] <wiesand> Shall we aim for 1.6.19pre1 this time next week?
[15:34:52] <wiesand> Mark: Serious?
[15:35:08] <mvita> no, I don't think so.
[15:35:16] <mvita> just a build fix
[15:35:24] <mvita> an api got effectively renamed
[15:35:42] <mvita> but the semantics changed a bit and I need to research the implications of that
[15:35:46] <wiesand> Linux-next?
[15:35:49] <mvita> yes
[15:36:22] <meffie> off to the next meeting. have a good day.
[15:36:24] meffie leaves the room
[15:36:36] <wiesand> Let’s strive for getting out 1.6.19 soon, and keep things like this in mind for a .1
[15:36:56] <wiesand> Let’s adjourn. hanks a lot everyone!
[15:37:02] <Jeffrey Altman> bye
[15:37:09] wiesand leaves the room
[15:37:33] <kadukoafs@gmail.com/barnowl9C09F4AA> Thanks everyone.
<oblig>Review review review!</oblig>
[22:35:32] mvita leaves the room
[22:35:33] mvita joins the room
[22:35:37] mvita leaves the room