- Wednesday, September 24, 2014

release-team@conference.openafs.org

Wednesday, September 24, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[12:13:40] stephan.wiesand joins the room
[12:14:26] <stephan.wiesand> test
[13:43:26] meffie joins the room
[14:00:16] deason joins the room
[14:00:43] Marc Dionne joins the room
[14:01:01] <stephan.wiesand> Hello
[14:01:13] <Marc Dionne> hi Stephan
[14:01:27] <stephan.wiesand> Hi Marc. Any Linux news?
[14:01:55] <Marc Dionne> looks like the 3.17 release may happen this weekend, or probably next weekend at the latest
[14:02:29] <stephan.wiesand> And we still lack one change to cope?
[14:02:35] <Marc Dionne> currently testing a fix for the problem I knew about, but running into another issue which may or may not be related
[14:03:29] <stephan.wiesand> Since I didn't get around to doing much lately, this gets us back to the question whether to delay 1.6.10 for that issue?
[14:03:36] <stephan.wiesand> Thoughts?
[14:04:35] <stephan.wiesand> If we don't delay it, 11486 should be the last commit.
[14:05:08] <Marc Dionne> not sure
[14:05:28] <stephan.wiesand> How invasive is the change you have in mind?
[14:05:46] <stephan.wiesand> (maybe it's really better to have a 1.6.10.1 with just that?)
[14:05:50] <Marc Dionne> some questions are when actual releases may use the new kernel, and how long it may take to have  stable fix
[14:06:03] <shadow@gmail.com/barnowlE5B64A04> the other question is how dangerous it is
[14:06:09] <Jeffrey Altman> I do not believe you should delay 1.6.10
[14:07:01] <Marc Dionne> it's only a few lines of code, but in a touchy area
[14:08:21] <stephan.wiesand> Ok. Unless someone strongly in favour of delaying it speaks up now, let's get it out now as it is and have a .1 when needed and ready. Objections?
[14:08:38] kaduk joins the room
[14:09:01] <Marc Dionne> i'm getting oopses under load with the fix, but its possible that it's a race thats not related to the other fix (need to re-test without the fix to see if the oops can still be triggered)
[14:09:07] <kaduk> Debian had to take patches on top of 1.6.9 for the 3.16 kernel just recently
[14:09:27] <stephan.wiesand> Huh?
[14:09:40] <kaduk> So, I guess that's a vote for 1.6.10 soon, and not delaying for patches.
[14:09:41] <Marc Dionne> i assume he's talking about debian/ubuntu
[14:10:33] <stephan.wiesand> Ah, ok.
[14:10:36] <kaduk> Marc is right, I'm talking about debian/ubuntu.
[14:11:03] <kaduk> (Sorry, I know I'm jumping in in the middle like that.)
[14:11:28] <stephan.wiesand> No, that's fine. Right, we have fixes for 3.16 in 1.6.10. Let's get it out.
[14:11:54] <stephan.wiesand> Could someone look at 11486 then?
[14:13:40] <stephan.wiesand> Unless there's something wrong with it, we should then do the usual drill:
[14:14:15] <stephan.wiesand> I upload tarballs, and after some smoke testing we tag. Then announce, with some binaries available if possible.
[14:14:30] <kaduk> Sounds like a plan.
[14:16:32] <stephan.wiesand> Ok. I'll merge 11486 and work on he tarballs then, while you discuss the 1.8 branch ;-)
[14:17:17] <kaduk> Who all do I have to discuss with, though? ;)
[14:17:20] <Jeffrey Altman> Ben, thanks for doing so much leg work.   Unfortunately, my travel schedule hasn't permitted me to look at any of it.
[14:18:06] <kaduk> I suspected something like that when you missed last week's meeting, Jeff.  Besides, getting patches submitted right before a deadline is a great way to have them not be merged before the deadline -- review takes time.
[14:18:38] <Jeffrey Altman> Last Wednesday I was attending a conference at the British Museum and suffering from extreme jet lag
[14:18:48] <kaduk> (Something of an aside: maybe Andrew wants to look at converting the ukernel.so perl/swig build to using libtool?  I think it shouldn't be very complicated, but I don't have a setup to test it.)
[14:19:03] <Jeffrey Altman> I don't understand how some folks regularly make the SFO to LHR round trip in a weke
[14:19:31] <kaduk> Even BOS/LHR is pretty jarring, for me.
[14:19:52] <Jeffrey Altman> that at least is 5 hours.  one hour adjustment per day is about my limit.
[14:20:26] <kaduk> I guess I can come up with general-ish things we can talk about that are not tied to the details of patches:
[14:20:37] <kaduk> (1) we should not install .la files as part of our final installation
[14:21:50] <kaduk> (I am largely defaulting to this because it's Debian's preference, but even while working on these patches I ran into cases where libtool got confused by the presence of a .la file.)
[14:23:26] <Jeffrey Altman> not my area of expertise unfortunately
[14:23:39] <kaduk> (2) Should we bump the SONAME for shared libraries that have been converted to libtool?  I did so in my patches as a general precaution -- there are a lot of variables and I wouldn't be confident that I checked all cases.
[14:24:24] <Jeffrey Altman> Did Simon bump the SONAME for the libraries he converted?
[14:24:29] <kaduk> (libtool's scheme for tracking library version state is a little strange when one is used to just tracking major+minor pairs, but it should work just fine if we stick to it.)
[14:25:09] <kaduk> I don't think we have any versioning information on the ones he converted.
[14:25:36] <Jeffrey Altman> Since OpenAFS doesn't have a stable abi let alone a stable api I cannot think of any reason it would be a problem to bump the SONAME.  At least not for those libraries that are only used internally.
[14:26:10] <Jeffrey Altman> that is probably a question for openafs-devel
[14:27:14] <kaduk> Getting a broader audience seems reasonable.
Maye I should make a list of things to ask on -devel ... (a) SONAME bumps for libtool conversions
[14:27:52] <kaduk> (3) 11466 makes the installation of pam modules conditional on --enable-kauth
[14:28:28] <Jeffrey Altman> I don't believe the openafs shipped pam module is useful to the majority of users.
[14:28:33] <meffie> those are the old k4 pam modules, right?
[14:28:39] <Jeffrey Altman> kauth modules
[14:28:40] <kaduk> We already have an --enable-pam configure knob (which I had forgotten about when writing that patch), so the documentation of things does not document their interaction.  The openafs pam module is for kauth-style things, right.
[14:29:16] <kaduk> So, as of that change, --enable-pam controls whether they get built, and --enable-kauth controls whether they get installed.
[14:29:21] <stephan.wiesand> 1.6.10 tarballs and srpm were uploaded to /afs/.grand.central.org/software/openafs/1.6.10
[14:29:32] <kaduk> I think I'm okay with that being the situation, but maybe the documentation should be updated about it.
[14:29:40] <Jeffrey Altman> perhaps --enable-pam and --enable-pam-install
[14:30:12] <kaduk> (4) netscape plugin
If you go to libuafs and 'make webinstall', we will try to build this thing.  It seems highly likely that it has bitrotted
[14:30:13] <Jeffrey Altman> perhaps just get rid of --enable-pam and only build if --enable-kauth
[14:30:30] <Jeffrey Altman> JPL uses the web stuff
[14:30:48] <kaduk> I would be okay with --enable-kauth controlling whether the pam modules get built.
[14:30:49] <Jeffrey Altman> or used the web stuff as of 2005
[14:31:10] <kaduk> I hear netscape stopped being a thing in 2008.
[14:32:15] <Jeffrey Altman> this is a server plugin or a client plugin?   the firefox plugin api is backward compatible to netscape.   that being said I do not believe that browser or web server extensions should be part of the openafs tree.
[14:32:36] <Jeffrey Altman> they should be external projects
[14:34:21] <kaduk> For (4), I'm talking about the AFSWEBOBJ bits in libuafs.
There's also src/afsweb which is probably the other one of server/client, but I haven't touched that yet.
[14:35:12] <kaduk> src/afsweb/README talks about apache and web servers and "web security pack", so I think that's the server part, which would probably make libuafs client side stuff, but it's not entirely clear to me.
[14:35:18] <kaduk> (5) JUAFS
I managed to convince myself that libuafs.a and libjuafs.a provide the same functionality, since 80943970 when the web enhancements were enabled universally.  11471 drops the separate juafs build and just also installs libuafs.a as libjuafs.a
[14:36:17] <shadow@gmail.com/barnowlE5B64A04> juafs was in fact the same damn thing. really the java bindings should
just be updated ot use libuafs drectly
[14:36:45] <kaduk> On the other hand, some of the removed code from (4) had conditionals on NETSCAPE_NSAPI, which is a server thing.  So maybe they're both part of the server-side stuff.
[14:36:53] <Jeffrey Altman> The way the web server bits work is that it loads a module built against libuafs to provide the web server its own cache manager so you do not need to install a kernel cache manager and the web server can live in its own world and manage its own tokens
[14:37:12] <kaduk> Okay, so they probably are both server-side, then?
[14:37:37] <kaduk> Maybe that should be (b) move web stuff out of our tree (if someone wants them to stay alive, they can be a separate project)
[14:40:13] <kaduk> (6) libuafs/lwptool
Once web and java were gone, there was just UAFS and UAFS.pic, and our lwptool script can be convinced to build both of those.  It's not clear that this is strictly necessary for 1.8, but I had started down it while looking at some ideas that involved more prevalent libtool usage.
I asked Andrew to look at it at some point, though I guess he just got back from vacation or similar.
I'm not sure how much there is to talk about now, especially if Simon isn't here.
[14:41:46] <kaduk> (7) MIT krb5 plus out-of-tree roken+hcrypto
Mike looked at this one a little (11474); it is mostly just shuffling around the per-file and per-module CFLAGS/CPPFLAGS/LDFLAGS and such, so that we can ensure that the more localized flags take precedence both for compiler options and library/header search paths.
[14:42:36] <kaduk> I cheated a little bit and used the variable named MODULE_CFLAGS as if it were CPPFLAGS, since we seem to just be using it for preprocessor defines and search path statements.
[14:43:05] <kaduk> In order to get that setup working with Debian we also need to have separate configure options for the header and library locations for roken and hcrypto, as we already do for krb5 through rra-c-util.
[14:43:44] <kaduk> I don't think there is anything particularly controversial in spirit, it just needs some review to ensure that there aren't any edge cases that are now going the wrong way.
[14:44:17] <meffie> it looks sane, but still reading
[14:45:40] <kaduk> (8) librokenafs
First off, we couldn't usefully build it with libtool until LT_LDLIB_shlib_missing got fixed (11475) since it would include in its export list symbols it did not provide.
It's also unclear if we should be using a nonzero SONAME for this at all, as I mentioned in one of the gerrit comments -- it's possible for OS updates to cause symbols to disappear from roken behind our back, and we couldn't do the versioning properly and keep it right for all systems, in principle.
[14:47:43] <kaduk> I guess back in (7) I should note that we still need to build the in-tree hcrypto for the LWP version.  I had configure output a value which the all target depends on, which is either all-internal or all-lwp.  (I'll probably make rxgk use a similar thing to decide whether to build the "real thing" or just stubs that return failure, so that we can still export symbols like rxgk_GetServerInfo from other libraries.)
[14:48:33] <kaduk> (9) the configure defaults
I actually didn't see much to change; just pthreaded-ubik and pam.  And maybe pam will not be a separate thing anymore anyway.
[14:49:02] <kaduk> That said, we have a lot of configure options.  I sort of wonder if we can make some of them go away somehow.
[14:50:00] <kaduk> I thought a little bit about supergroups, but I don't think we should enable the code by default until we have a way for its use at runtime to be administratively prohibited.   (We had talked about such a scheme when considering prdb format changes.)
[14:51:05] <kaduk> We have --disable-gtx, --disable-uss, --enable-bitmap-later, and --disable-unix-sockets that I don't know much about; are they candidates for removal?
[14:52:04] <stephan.wiesand> I think bitmap-later is considered safe?
[14:53:04] <kaduk> (10) the old shared-library build system
Kind of a minor point, really, but I got things to a point where Makefile.shared can be removed.  The shlib-build script is still used for the perl ukernel.so build which I mentioned earlier.  I guess shlib-install could be removed, but it seems to go hand-in-hand with shlib-build so I didn't touch it yet.
[14:53:27] <meffie> distable-gtx could be replaced with --without-ncurses ?
[14:53:44] <kaduk> Are any of those things to ask about on -devel?
[14:55:13] <stephan.wiesand> Do all of those have to be sorted out before branching?
[14:56:30] <kaduk> I wouldn't consider those configure tweaks to be blockers to the branch.
(I assume that's what "those" maps to.)
[14:56:35] <kaduk> (11) The liboafs_foo libraries
I mentioned this a little on the list, but I don't think it's worth installing them and switching the utilities to shared linkage until we have removed more of LWP from the tree (i.e., after branching).
[14:58:04] <stephan.wiesand> "Those" := {1..n, n >= 11}
[14:58:20] Jeffrey Altman leaves the room
[14:58:49] <kaduk> Uh-oh...
[14:58:58] <meffie> thank you for enumerating, kaduk.
[14:59:18] <kaduk> Having numbers to refer to is usually helpful :)
[14:59:45] <meffie> i didnt understand point 8, re OS updates.
[15:01:36] <kaduk> I would say that some of them are blockers, in particular: 1, 2, and part of 9 (pthreaded-ubik should be decided; the other ones are less important to me).  We would also care about 8 and some related stuff if we acceed to Jeff's desire to use libtool to build/install the shared libraries that we ship.
[15:02:37] Jeffrey Altman joins the room
[15:03:07] <kaduk> Mike: so, the point of roken is to provide functionality that the OS doesn't ship; what roken decides to implement is dependent on what the configure-time checks say is and isn't there.  That means if we take version 1.8.0 of our software and build it on (say) Debian etch, roken will have to provide some set of symbols, call it A.  If we then take the same version 1.8.0 of our software and build it on Debian jessie, the OS has started to provide more of those symbols, so roken will include fewer symbols than it did on etch.  But it's still version 1.8.0 of our software.
[15:04:07] <kaduk> This means that the "version 1.8.0" provided by jessie would break some application which was compiled against "version 1.8.0" on the etch system and the binary kept around, since the binary expects a symbol which is not there.
[15:04:15] <meffie> ah, got it.
[15:04:26] Jeffrey Altman leaves the room
[15:05:10] Jeffrey Altman joins the room
[15:06:16] <kaduk> The other items from email would be (12) install/run testing of the current master, and (13) documentation.
Does anyone have anything new to report re (12)?
I guess I can say that I ran my debian packaging of master on a test machine and smoke-tested it.
[15:06:46] <kaduk> Does Jeff want to say anything about which items he considers blockers for branching?
[15:06:54] <kaduk> (If his client can stay connected, of course.)
[15:08:32] <kaduk> I would also like to double-check the list of things to ask on -devel; right now I only have:
(a) SONAME bumps for libtool conversions
(b) Dropping the libuafs/web and/or src/afsweb bits
[15:09:39] <Jeffrey Altman> my apologies but I only have scrollback to (8)
[15:10:00] <kaduk> http://conference.openafs.org/release-team@conference.openafs.org/2014-09-24.html
[15:10:26] <Jeffrey Altman> thanks
[15:10:39] <kaduk> I think it would also be useful if we can reasonably estimate how long it will take to get these patches reviewed and merged.
Gatekeepers, would it be helpful if I went through the patch series and self-reviewed the changes pretending to not be the implementor?
[15:11:02] <Jeffrey Altman> you don't do that anyway?
[15:12:08] <kaduk> Well, usually I don't give a review value for my own commits at all, in gerrit.
[15:12:15] <Jeffrey Altman> as far a removing stuff goes.   I don't think doing so is a blocker for branching unless doing so is a pre-requisite for something that is a blocker
[15:12:32] <kaduk> I generally go through and look over the commits prior to pushing, but sometimes it's not as thorough as I would do for reviewing someone else's work.
[15:13:15] <Jeffrey Altman> my pattern is a develop, test, push to gerrit, see buildbot, and review.  I might not +1 but I will certainly -1
[15:13:34] <kaduk> > usually I don't [review my own commits in gerrit]
since it's unclear how much value is given to such self-review
[15:13:53] <Jeffrey Altman> I give a lot of value to a -1 from the author
[15:13:59] <kaduk> Sure :)
[15:14:30] <Jeffrey Altman> I will give value to +1 verified from the author if the author indicates what they did to verify the change
[15:15:36] <Jeffrey Altman> A +1 review from the author really depends on the author
[15:19:54] <Jeffrey Altman> I think 1, 2, 5ish (renaming references to libjuafs.* to libuafs.*), 7, possibly 8, possibly 9 should be addressed before branching.
[15:24:26] <stephan.wiesand> Ok, we have another list. What's next?
[15:26:28] <kaduk> Code review, I think.
[15:28:06] <stephan.wiesand> Ok.
[15:28:17] <stephan.wiesand> Do we want to set a new deadline?
[15:28:36] <kaduk> That probably depends on how quickly we think we can get patches reviewed and merged.
[15:28:52] <stephan.wiesand> Proposals?
[15:29:01] <kaduk> (I don't think I'm in a good position to make such an estimate.)
[15:29:45] <stephan.wiesand> Who is? But I think the last one did help, even though we're slipping.
[15:30:28] <kaduk> "Jeff is" :)
Given that I suspect the ability to get this merged is highly dependent on, e.g., his travel schedule, etc..
[15:32:07] <Jeffrey Altman> Most of these items are things that are outside my area of review expertise.   The community needs to review.   The role of Daria and I will be to merge when sufficient review has been obtained.
[15:32:34] <Jeffrey Altman> I don't think I can provide estimates for the voluntary actions of others.
[15:32:48] <kaduk> Sure.
[15:33:37] <kaduk> In the absence of other data, I would probably say "two weeks", but it's unclear how realistic that is.
[15:34:06] <stephan.wiesand> Let's discuss the changes in next week's meeting, one by one, with the goal of at least identifying what's required to get them adequately reviewed.
[15:34:19] <Jeffrey Altman> I think that requesting reviews with a goal of two weeks for merging is reasonable
[15:35:57] <stephan.wiesand> Ben, will you ask for review on -devel?
[15:37:01] <kaduk> Sure,
(c) please review the pending gerrit changes, with priority to [ones relating to branch-blocking topics, to be enumerated for email but not here]
[15:37:58] <stephan.wiesand> Ok, let's aim for two weeks then.
[15:38:20] <stephan.wiesand> I'll try to send minutes too, but can't promise...
[15:38:28] <stephan.wiesand> Anything else to discuss today?
[15:38:38] <kaduk> Will it spoil your minutes thunder if I mention the "two weeks" in my email?
[15:39:15] <stephan.wiesand> If you make the minutes reduntant altogether, that's best :-)
[15:39:34] <kaduk> Well, the 1.6.10 tarballs are not part of my item :)
[15:40:05] <stephan.wiesand> They were announced to release-team already ;-)
[15:40:41] <stephan.wiesand> Please smoke test and/or provide binaries if you can.
[15:41:11] <kaduk> Oh, hmm.
[15:41:38] <kaduk> I think that part of (1) should probably turn into (d) should we install .la files
[15:42:02] <Jeffrey Altman> makes sense
[15:43:10] <kaduk> and maybe (e) should --enable-kauth replace --enable-pam
[15:44:00] <kaduk> I guess, "I'll come up with some topics for the email to -devel".
Y'all should yell at me if I pick bad ones :)
[15:44:11] <kaduk> So, probably that's all for today.
[15:44:11] <meffie> not likely.
[15:44:21] <Jeffrey Altman> I have to go.  Thanks Ben
[15:44:27] <kaduk> Thanks.
[15:44:28] <meffie> thank you ben.
[15:45:28] <stephan.wiesand> I'm afraid CVE-2014-6271 will tie me up for at least the rest of the day...
[15:46:18] <kaduk> It seems hard to find good information on what exactly the scope of it is...I think I'm unaffected.  "But maybe not."
[15:48:05] <stephan.wiesand> I'm afraid most of us are. http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html
[15:50:35] <stephan.wiesand> Ok. Thanks a lot everyone for participating today!
[15:50:47] <kaduk> Thanks for running it, as always.
[15:51:09] <stephan.wiesand> Well, you ran the better part again.
[15:52:18] <stephan.wiesand> I'm off to get rid of AcceptEnv in our sshd_configs now. Bye.
[15:56:15] kaduk leaves the room
[15:58:55] kaduk joins the room
[16:01:37] <meffie> here's a good description: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
[16:13:32] Marc Dionne leaves the room
[16:30:24] meffie leaves the room
[19:39:51] stephan.wiesand leaves the room
[21:22:12] kaduk leaves the room
[21:58:40] deason leaves the room