Todd Lipcon has posted comments on this change. Change subject: Workaround test failures running with MIT krb5 1.10 ......................................................................
Patch Set 5: > But now we're stretching ourselves to accommodate el6's libkrb5. Does libkrb5 > also receive a high number of updates? If not, I'd argue we should ship it > ourselves and use a known good version. I don't know what classifies as a high number, but looking at the Debian changelog for Ubuntu 14.04, I see 18 CVEs in there (12 from 2014, 6 from 2015). Looking at a RHEL 6.6 system, I see 4 releases in 2015 and a bunch from 2014 as well. So, empirically, this library does get updated fairly frequently by distro vendors, and I can imagine that a security-conscious admin would be nervous about taking an embedded version. >I asked Dan about this and he said that due to how libsasl uses dlopen() to >get to libkrb5, it's really hard (or maybe impossible) to get it to prefer a >different version. Is that something you've looked into? Is there some way to >customize it? If it's impossible, we'd have to ship libsasl too, and patch it to load libkrb5 differently. I don't think that'd be the worst thing in the world (provided libsasl, like libkrb5 and unlike openssl, does not receive updates), but it'd be a lot more work than what you're doing here. Yea, this stuff gets nasty, too, because once we're shipping libsasl, we also need to make sure that libsasl loads our own sasl modules, and not the ones from the system SASL path. We went down this route before but reversed it in 152ff259de7ea44c81e17c59fd4a7c5f41ba712e a couple years ago, and I recall it was a big pain in the butt. Also keep in mind that this stuff is used by the client library, and having our client try to static-link in its own krb5 and sasl seems like a dangerous proposition since it is very likely to be running embedded in another process which is also using krb5/sasl (and where we actively want to be picking up credentials kinitted by the embedder, etc). -- To view, visit http://gerrit.cloudera.org:8080/4990 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I708334cbbee35d2629a38a369e63c1dc309ed91b Gerrit-PatchSet: 5 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Todd Lipcon <t...@apache.org> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Dan Burkert <danburk...@apache.org> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Tidy Bot Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-HasComments: No
