On Wed, Oct 03, 2018 at 07:54:15AM +0100, Alan Bateman wrote: > The "How to contribute" [1] is the best place to start. I see you > are listed on the OCA signatories so that gets you through step 0.
Indeed. Figuring out how to deal with the OCA is a large reason we took so long to begin this contribution, as our legal department had some objections for some time which were eventually resolved by having our open source entity sign the OCA and our contributions done under that entity. > For the patches then I think you'll need to start a discussion here > on the specific issues and changes that are you looking to > contribute. This project requires all contributions to be sent on Yes, I'm hoping that my post begins that discussion. > the mailing list or hosted on locations such as cr.openjdk.java.net. I'll attempt to attach all 25 commits now. I hope the list will accept them. I will post them (and webrev) to cr.openjdk.java.net. > From your mail then it sounds like you have a lot of changes so it's > probably best to start small, say with small fixes, until you've > gain some experience with the process of contributing and Our changes are broken up reasonably well -- they are not squashed into one big commit. Thus it is already possible to review small ones first. A lot of these changes are interrelated. Reviewing them in order of size might require rebasing our stack of commits, and may not be entirely possible. We're extremely familiar with this code as we have been patching the JGSS stack this way for years (we have developed these patches for JDKs 7, 8, 9, 10, 11, and the current 12 master), and we have been running this in production (with JDKs 7, 8, and 9, and soon 11) on Linux and Windows (our patches for earlier versions add native GSS support on Windows much as Weijun did for JDK 11, which we then use with the SAP GSS->SSPI bridge, our fork of which is here: https://github.com/twosigma/gsskrb5). FWIW, regarding credentials, Viktor and I are part of the Heimdal team, and we contribute to MIT Kerberos, and I have authored Internet RFCs in the GSS-API space, thus we're extremely familiar with the GSS-API in general and several implementation in particular. Also, I am familiar with the JGSS team as I used to work in Solaris security engineering 2002-2008 (and continued in Solaris engineering, just not security, for another two years), and I know the engineers working on JGSS well enough from back then (e.g., Weijun Wang, Valerie Peng), and I've stayed in touch with Weijun Wang since leaving Oracle. We're also maintainers or contributors to a number of GSS-API applications, including the SSHv2 GSS keyex implementation in PuTTY, similar patches for OpenSSH, and so on. Lastly, Viktor is a member of the OpenSSL core team, contributed DANE support, and is a co-maintainer of Postfix among other things. > sponsors/reviewers build up confidence in the changes. I suspect you We're hoping Weijun or Valerie can sponsor this. > will have the experience of doing significantly better than showing > up with large patch that add features and changes large areas of > JGSS. Starting small is really important for sponsors and reviewers > as the review and testing effort for many contributions can be > significant. There was no way to avoid showing up with a large set of patches. The problems we're fixing run deep and are interrelated, and indeed, we're not entirely done fixing problems that run deep, but we are done fixing all the problems that we care about, thus our commentary-only commits. In particular, we're not addressing the lack of generality in ServicePermission. See, GSS-API is supposed to be a pluggable security mechanism abstraction, and each security mechanism can have different ways of naming entities, but ServicePermission is entirely Kerberos-specific, and there are a number of places where ServicePermissions are checked if and only if Kerberos was used but not if something else was used. It is clearly not correct to skip these permission checks just because ServicePermission does not support non-Kerberos mechanisms, but ServicePermission could have been designed to -and could be updated to- to support them. Now, we could have shown up quite a while back, but for a variety of reasons that are not germane here, we ended up not being able to do so until now. I'd like to start by reviewing the important changes at an abstract level: - making GSSName extend Principal I don't think this should be controversial in the least, but probably will require discussion. This is one way in which JGSS problems run deep: by not making GSSName extend Principal, it is not possible to use native GSS with JAAS. - adding GssLoginModule This is the other way in which the problems we're fixing run deep: GSS-API is supposed to be pluggable as to security mechanisms, but the JGSS / Krb5 stack is very Kerberos-specific. It should always have been GssLoginModule, not Krb5lOginModule, not least because the Krb5 non-GSS interfaces are mostly not exposed. Similar lack of generality exists in ServicePermission, about which more below. Nico --
