Home
release-team@conference.openafs.org
Wednesday, September 30, 2015< ^ >
Room Configuration
Room Occupants

GMT+0
[03:37:06] Jeffrey Altman joins the room
[13:33:30] shadow@gmail.com/barnowlABEE2063 leaves the room
[13:33:41] shadow@gmail.com/barnowlABEE2063 joins the room
[13:56:18] stephan.wiesand joins the room
[14:00:00] <stephan.wiesand> Hello
[14:01:27] <stephan.wiesand> I'm curious how we'll do releases in the future
[14:03:10] stephan.wiesand leaves the room
[14:03:38] stephan.wiesand joins the room
[14:04:34] meffie joins the room
[14:04:47] <meffie> hello
[14:04:54] <stephan.wiesand> Hello Mike
[14:05:50] <stephan.wiesand> Not much to discuss today. No progress on my part :-(
[14:06:08] <meffie> me too. just got back from vacation.
[14:06:36] <stephan.wiesand> This is my last day. Normal life restarts tomorrow.
[14:07:53] <meffie> ok. i did notice a bug on the current master in the cache manager. it's from commit "return an error from afs_readdir..."
[14:08:26] mvita joins the room
[14:08:30] <stephan.wiesand> Is the bug present in 1.6?
[14:08:33] <mvita> sorry I'm late
[14:08:33] <meffie> no
[14:08:46] <meffie> it hit master just recently
[14:09:28] <meffie> i'll look into it.
[14:09:34] kaduk joins the room
[14:09:41] <mvita> hello Ben
[14:10:00] <stephan.wiesand> Hell Mark & Ben
[14:10:04] <mvita> heh
[14:10:22] <stephan.wiesand> Mike: do you have a gerrit number?
[14:10:25] <mvita> I've been called a lot of things....
[14:10:52] <kaduk> 1001 is the afs_readdir thing
[14:10:56] <stephan.wiesand> oops sorry
[14:11:19] <meffie> i had to revert 9b0d5f274fe79ccc5dd0e4bba86b3f52b27d3586
[14:11:49] <meffie> which is yes, gerrit 1001
[14:12:07] <mvita> ?
[14:12:12] <mvita> numbers reset?
[14:12:43] <mvita> oh, nm
[14:13:50] <kaduk> It's just very old.
[14:14:14] <kaduk> What were the symptoms that caused you to need to revert it?
[14:14:29] <meffie> EIO returned for random dir entries
[14:15:00] <meffie> "random"
[14:15:15] <meffie> dont know why yet.
[14:15:47] <stephan.wiesand> And no randomly missing entries after reverting the cheange?
[14:15:53] <mvita> well
[14:16:07] <mvita> index into a dir needs to be unsigned
[14:16:20] <mvita> or maybe
[14:17:44] <kaduk> What platform is this on, linux-x86_64?
[14:18:03] <meffie> yes
[14:18:28] <mvita> I'm wrong, afs_int32 should suffice for all dirs
[14:18:55] <meffie> it prob the line that returns code instead of 0. i'll look.
[14:19:38] <kaduk> That was the only thing even remotely jumping out as I look at it now, yeah.
[14:22:15] Daria Phoebe Brashear joins the room
[14:22:31] <meffie> Daria Phoebe Brashear: hello!
[14:22:51] <Daria Phoebe Brashear> \o
[14:25:01] <stephan.wiesand> pleasant surprise...
[14:25:31] <Daria Phoebe Brashear> sorry i'm late. a minor snafu with the ark now that the rain stopped
[14:25:55] <meffie> heh
[14:26:59] <mvita> hello Daria
[14:27:50] <mvita> this line worries me too:
[14:27:53] <mvita> 918
»       AFS_UIO_SETOFFSET(auio, (us + afs_dir_NameBlobs(nde->name)) << 5);
[14:28:10] <meffie> all the lines worry me. :)
[14:28:12] <mvita> could easily get sign extension on the right
[14:28:40] <mvita> but the old code was no better... so it's probably a red herring
[14:29:14] <kaduk> meffie: if I pick a random log-rotation change in gerrit (later in the chain of commits) and follow the dependencies in gerrit towards earlier changes in the series, the behavior is odd -- sometimes I'll land on a commit with no forward-pointer to the one I came from, or a forward-pointer to a different commit than the one I came from.  Do you think it's worth the effort of someone (you?) going through and trying to re-linearize gerrit's idea of history, by pushing a single branch with all of the relevant changes and everything in the proper order?
[14:30:09] <meffie> yes, i think it is worth that effort to do that. and i'd be happy to do so.
[14:30:17] <kaduk> Thanks.
[14:31:02] <kaduk> There are many things early on that are sitting on +2 review, but things are confused enough that I'd want to go check before actually submitting them.
[14:31:03] <stephan.wiesand> These are not necessarily problems though
[14:31:39] <mvita> I have a few questions after we finish discussing this one.
[14:33:28] <stephan.wiesand> Ben, should Mark go ahead?
[14:33:30] <kaduk> I think you should go ahead and ask, Mark.
[14:33:48] <mvita> gerrit 11934
[14:33:56] <mvita> not sure how I should proceed
[14:34:09] <mvita> but some version of it needs to go into 1.8
[14:35:38] <mvita> as mentioned there, the windows code seems fine to me, so I only fixed the unix side I know is busted.
[14:35:46] <kaduk> You need to touch the windows code; the windows code is not fine.
[14:36:02] <mvita> I have no way to test it.
[14:36:11] <kaduk> "If it compiles, ship it"
[14:36:29] <mvita> okay.  it compiles now.
[14:36:55] <mvita> but seriously, I don't understand what's wrong with it
[14:36:58] <kaduk> Basically, before calling splitpath, the extra options need to be stripped.
[14:37:44] <kaduk> _splitpath("C:\path\to\fileserver.exe -L",...) will claim that there is no file extension
[14:37:57] <mvita> do you want me to come up with a more generic string implementation, sans splitpath?
[14:38:24] <kaduk> I think windows still needs the splitpath, just after a little bit of "by hand" string processing.
[14:38:33] <mvita> okay, will do, thanks.
[14:38:38] <mvita> next question.
[14:38:46] <mvita> 12005
[14:39:23] <mvita> does jeffrey mean submit the bozo change (just discussed) in a separate stack?
[14:39:25] <kaduk> ("by hand" string processing probably just being to search for whitespace and write a NUL over the first one, for now)
[14:39:36] <mvita> that is, alone on top of master?
[14:40:06] <mvita> and the rest of the unrelated fixes in a topic branch without the bozo fix, again, rebased on top of master?
[14:40:15] <mvita> just looking for clarification
[14:40:45] <kaduk> I think you leave the bozo change as is, but make a separate branch for the other stuff, rebase on top of current master and rebase -i to remove the bozo change from the new branch.
[14:40:51] <mvita> I don't think I've ever used a topic branch for gerrit before, so I'd also like guidelines on when that's called for and when it's not.
[14:41:03] <kaduk> You can't add a topic in gerrit to a change that already exists, but you can alter gerrit's ideas of the dependencies between commits.
[14:41:50] <meffie> yes, rebase -i or cherry-pick the commits you want.
[14:41:59] <kaduk> If you have more than one commit in a series that are building towards a common goal or working on the same code or actually dependent on each other, it's nice to use a named topic for the initial push to gerrit.  I don't think anyone will enforce a strict requirement for doing so.
[14:42:58] <mvita> okay - I did consider it before I pushed that stack - but didn't know if there was some etiquette protocol
[14:43:07] <mvita> thanks.
[14:43:10] <mvita> last question.
[14:43:11] <kaduk> (It looks like what happened with 12005 is that your working copy happened to be on the bozo commit, and then you started working on something else unrelated, so when you pushed the new stuff, gerrit thought it should go on top of the bozo commit, which is not really the case)
[14:43:30] <mvita> well, I did that deliberately because I need the bozo fix to test
[14:43:38] <mvita> but yes, it's unrelated
[14:45:00] <mvita> okay, last question is about security team.
[14:45:28] <mvita> simon has stepped down, and presumably Daria, you are stepping away from that as well.
[14:45:46] <mvita> is there anyone else remaining on the security team?
[14:46:17] <Daria Phoebe Brashear> i mean, i'll be a contributor, in the interim, just like any other
[14:46:22] <Daria Phoebe Brashear> but i am "nobody special"
[14:46:27] <mvita> ah, okay.
[14:46:28] <Daria Phoebe Brashear> hell. i never was.
[14:46:30] <kaduk> I'm not sure whether anyone is currently getting notifications when new traffic hits the security queue.
[14:46:35] <Daria Phoebe Brashear> not me
[14:46:42] <kaduk> But I look at it from time to time.
[14:47:08] <mvita> if no one is getting notfications, that needs to change immediately.
[14:48:18] <Daria Phoebe Brashear> i mean, i could get notifications and ignore them, if that'd help :|
[14:48:19] <mvita> who has access to the entire queue?  stephan?  ben?  daria?
[14:48:41] <mvita> heh.  no, not really helpful, but thanks for the offer ;-)
[14:48:49] <stephan.wiesand> I have access to the queue but not the key
[14:48:53] <kaduk> Oy, jhutz
[14:49:12] <mvita> jhutz has the key?
[14:49:21] <mvita> that would be perfect
[14:49:24] <kaduk> jhutz can look at the RT group membership
[14:49:29] <kaduk> and other permissions
[14:50:08] <stephan.wiesand> I guess Simon had the key...
[14:50:39] <mvita> sure.  so if he's out, we should retrieve it from him.
[14:51:00] <kaduk> Last I heard, the key was on a desktop machine of Simon's that was in storage in an annoying to access location.  Mind you, that was a couple years ago...
[14:55:32] <mvita> okay, so first order of action is to find out what we've got and what we still need.  Ben, could you ask Simon (or whoever) for the key?  And could someone ask jhutz who is subscribed to the queue and who gets notifications?
[14:55:42] <kaduk> Hmm, looks like a 1024-bit DSA key from 2009 with no expiration date?
[14:55:52] <mvita> gulp.
[14:56:04] <kaduk> It may be best to make a new key and try to get Simon to revoke the old one...
[14:56:07] <meffie> should we just regenerate a key?
[14:56:11] <mvita> agreed.
[14:56:35] <stephan.wiesand> The question is who would authorize that?
[14:56:42] <mvita> exactly.
[14:56:48] <kaduk> Authorize what?
[14:56:58] <kaduk> Anyone can make a key and claim it's the openafs security officer; that's how PGP works.
[14:57:12] <stephan.wiesand> Replacing the key, and distributing it.
[14:57:26] <kaduk> Getting signatures on it, getting its fingerprint on the website, getting RT to use it, those are the more interesting parts.
[14:57:27] <mvita> the people in this room are the stakeholders, for sure.
[14:57:33] <mvita> there may be others who aren't here
[14:57:36] <mvita> like jhutz
[14:58:00] <mvita> I don't think this is a foundation thing, though.
[14:58:08] <meffie> could be signed by openafsfoundation.org though.
[14:58:14] <mvita> hmm.
[14:58:22] <mvita> idk.
[14:58:25] <kaduk> Does openafsfoundation.org already have a key?  If not, that doesn't buy anything.
[14:58:48] <kaduk> Getting shadow and jaltman and myself to sign it and getting its fingerprint on the website probably goes as far as is needed.
[14:59:05] <mvita> that would be excellent
[14:59:22] <stephan.wiesand> Who decides who gets access to the private key?
[15:00:02] <kaduk> "Whomever creates the one that gets used."
[15:00:17] <stephan.wiesand> This was handled very strictly in the past.
[15:00:46] <mvita> by elders and gatekeepers
[15:00:51] <mvita> no more elders
[15:00:59] <mvita> no official gatekeepers
[15:01:09] <stephan.wiesand> Single gatekeeper?
[15:01:31] <mvita> fine by me until we figure out how to get more
[15:02:23] <Daria Phoebe Brashear> gatekeepers are people i am trying to get rid of in my life. i blame myself for stealing the term from CMU
[15:03:54] <mvita> well, someone needs to have final say on what gets merged.
[15:04:01] <Daria Phoebe Brashear> yeah but overloaded.
[15:04:02] <Daria Phoebe Brashear> http://www.pqmonthly.com/gatekeeping-the-dark-history-of-trans-health-care/22368
[15:04:45] <meffie> kaduk: silly question, can a pgp key be created from an purchased ssl cert? mabye the 503c can buy one?
[15:05:01] <Jeffrey Altman> hello
[15:05:10] <mvita> hi Jeffrey
[15:05:15] <Jeffrey Altman> I am looking for the security queue revocation key
[15:05:24] <stephan.wiesand> Hello lone gatekeeper ;-)
[15:06:44] <Jeffrey Altman> I am the last gatekeeper.   Ben is the first of the guardians and he has the ability to approve and merge changes
[15:06:53] <stephan.wiesand> Why revoke the old one? Was it used for signing anything?
[15:07:39] <stephan.wiesand> Why not make Ben a gatekeeper?
[15:07:46] <Daria Phoebe Brashear> the name should die
[15:07:48] <Jeffrey Altman> Because I do not have the private key of the old too short public key.   the gatekeepers were given a copy of the revocation key that could be used in the event of a security officer departure
[15:08:44] <meffie> Daria Phoebe Brashear: which term would your rather see adopted? maintainer?
[15:09:00] <stephan.wiesand> I still don't get why the old key should be revoked. All it was ever used for was to decrypt stuff sent to the security queue?
[15:09:01] <Jeffrey Altman> gatekeepers were designated as having a certain role with responsibilities that should not be passed on
[15:09:20] <Daria Phoebe Brashear> how about the term already applied: guardian
[15:10:15] <mvita> Jeffrey:  could you please elaborate on the responsibilities that should not be passed on?
[15:10:58] <mvita> and what you think the responsibilities of guardian/maintainer should be?
[15:11:24] <Daria Phoebe Brashear> i don't think maintainer should have any, because i don't think that's a thing. but it's not my project, so, dwyw
[15:12:18] <mvita> (also Jeffrey,  if you have any suggestions or thoughts about security team going forward, please share)
[15:15:48] <kaduk> The old key should be revoked so that people know to not encrypt new things to it.
[15:16:07] <kaduk> This is just part of how PGP was intended to be used.
[15:18:43] <stephan.wiesand> Fine, but that's not vital. Worst case you have to ask the reporter to resend using the new key.
[15:19:33] <stephan.wiesand> What's vital is to have someone who's able to decrypt the message.
[15:20:33] <stephan.wiesand> NB I think RT itself has no knowledge of the key at all. I also don't see why signatures on it would be needed.
[15:21:03] <Jeffrey Altman> RT has no knowledge.  The messages that go to RT are encrypted and the person with the key must decrypt them.
[15:21:38] <mvita> was simon the only one who could decrypt?
[15:21:51] <Jeffrey Altman> Communication to and from RT and its storage on disk is not encrypted so if you want privacy for a security issue you must use an out of band encryption mechanism
[15:22:04] <Jeffrey Altman> Each security officer in turn has their own key
[15:22:46] <stephan.wiesand> so all we need is a security officer...
[15:24:26] <mvita> Ben is a logical choice
[15:24:41] <mvita> if you are willing.  I don't want to ask too much.
[15:25:47] <meffie> i nominate mvita.
[15:26:20] <kaduk> It's unclear whether there is potential for conflict of interest if guardian and security officer are filled by the same person.
[15:26:26] <mvita> thanks, I don't decline outright, but I don't think I have enough experience or community visibility
[15:26:51] <Jeffrey Altman> and I think the security officer needs to directly report to the Foundation Board
[15:27:07] <Jeffrey Altman> and be paid by the Foundation Board
[15:27:07] <meffie> yes, but it requires someone with diligence, which i think you have in spades.
[15:28:08] <mvita> jhutz would also be a good choice
[15:28:14] <meffie> yes
[15:28:37] <Jeffrey Altman> You can ask but I doubt he would accept the role.  He hasn't in the past.
[15:29:19] <mvita> so we can make suggestions, but how do we go about choosing?
[15:29:46] <mvita> (first one that doesn't run screaming from the room)
[15:30:00] <mvita> no, not that.
[15:30:12] <Jeffrey Altman> I don't think *we* choose.   I think the Foundation Board if it is going to be a governing organization for OpenAFS needs to start to do that job
[15:30:32] <kaduk> "Do they know that?"
[15:31:00] <mvita> certainly they know about the gatekeeper thing
[15:31:05] <Jeffrey Altman> you were at the workshop.   do I think they understand what it means to govern?  no
[15:31:16] <mvita> probably security officer is under their radar
[15:33:54] <mvita> my take on foundation role is in the "soft" requirements for the project:   public face, funding, direction, user advocation - the technical side of things must clearly be delegated to something like a CTO
[15:34:02] <mvita> or gatekeeper or whatever
[15:34:28] <mvita> or to the ad-hoc "cabal" of people who work on it the most.
[15:34:42] <mvita> kaduk, I know, I know, there is no cabal
[15:35:22] <meffie> ok, so can we wrap up this discussion? need to fix some bugs today you know.
[15:36:19] <stephan.wiesand> Someone has to tell the foundation that we need a new security officer, a CTO, and IMO more gatekeepers...
[15:36:37] <stephan.wiesand> Or guardians...
[15:36:53] <mvita> I'll write to Dave B.
[15:37:02] <mvita> as soon as I figure out which one is which.
[15:37:09] <mvita> ;-)
[15:37:30] <meffie> (use their maillist, it will go to both.)
[15:37:40] <mvita> okay.
[15:37:44] <Jeffrey Altman> how about use the public mailing list and not the private one
[15:38:05] <meffie> yes, i meant the public one.
[15:38:22] <stephan.wiesand> Sounds good. Let's see what comes out.
[15:39:26] <meffie> ok thanks!
[15:39:56] <meffie> do you have any photos to share stephan.wiesand to wrap up the meeting?
[15:40:22] <stephan.wiesand> Not today. I'm home again :-(
[15:40:41] <stephan.wiesand> Really missing iceland.
[15:41:08] <stephan.wiesand> But let's call it a day.
[15:41:33] <meffie> ok, i'll post one :) http://www.meffie.org/gallery/sapelo/img_2441_med
[15:41:40] <stephan.wiesand> Thanks for what unexpectedly became a lively meeting!
[15:42:09] <stephan.wiesand> Nice
[15:42:53] <stephan.wiesand> Ok I have to go shopping. Thanks everyone!
[15:43:08] stephan.wiesand leaves the room
[15:50:43] meffie leaves the room
[16:05:20] kaduk leaves the room
[16:18:36] Daria Phoebe Brashear leaves the room
[17:05:19] Daria Phoebe Brashear joins the room
[17:22:50] Daria Phoebe Brashear leaves the room
[17:47:19] Daria Phoebe Brashear joins the room
[17:58:25] <jhutz@jis.mit.edu/owl> openafs-security is an RT queue.  Members of the openafs-sec group can see,
modify, and comment on tickets in that queue.  Currently that's me, cg2v,
jaltman, kaduk, and sxw.
Members of openafs-sec-view have read-only access, including the ability to
make themselves watchers.  Currently that's Ben, Stephan, and Marc Dionne.
There are currently three people who are watchers on the queue, and get
notification whenever there is a new ticket.  Those are cg2v, sxw, and
kaduk.  Any of the above people could be added; in fact, at least some of
them could add themselves.
[17:59:43] <jhutz@jis.mit.edu/owl> security-officer@openafs.org is a mail alias that goes directly to the
security officer (it does not create tickets in RT).  That currently
forwards to sxw, but can be updated as needed.
[20:56:51] Daria Phoebe Brashear leaves the room
[21:58:18] <mvita> just noticed this, thank you jhutz for the info
[22:37:24] Daria Phoebe Brashear joins the room
[22:57:02] Daria Phoebe Brashear leaves the room
[22:59:59] Daria Phoebe Brashear joins the room
[23:09:54] Daria Phoebe Brashear leaves the room
[23:42:52] Jeffrey Altman leaves the room
[23:42:52] Jeffrey Altman leaves the room
[23:42:52] Jeffrey Altman joins the room
[23:43:23] Jeffrey Altman joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!