Adar Dembo 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 think that does qualify as high, actually. I was hoping for a very low number, perhaps even 0. > 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). Why? I would expect that credential passing between the embedder and the client will be done explicitly (via client API calls) and abstractly enough that the fact that the client uses MIT krb5 is just an implementation detail. Is that not going to be the case? I'm not a fan of dependencies dictating our client APIs, to the point where we've even discussed a C API to elide STL dependencies. Anyway, if this interface is abstract, the client's use of symbol hiding should prevent the embedder from caring about the krb5/sasl usage of the client, regardless of its linkage. -- 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
