On Wed, Mar 06, 2019 at 10:24:50AM +0800, Weijun Wang wrote:
> Tell me the title and description of the bug/RFE, and I'll create one like
> https://bugs.openjdk.java.net/browse/JDK-8212217.
Thanks. All the commit subject lines work as bug synopses (when they
differ, the commit subject is in parenthesis below proposed synopsis):
- (bug) Add missing dbgsysGetLastErrorString()
dbgsys*() are wrappers around dlopen() (Unix) / LoadLibrary()
(Windows). A binding for dlerror() was missing.
- (bug) cut/paste error in NativeUtil.c
(Fix cut/paste error in NativeUtil.c)
- (RFE) Cleanup error handling in GSSLibStub
(Fix error handling in GSSLibStub)
- (RFE) Need a String to gss_buffer_t conversion utility
(Implement String to gss_buffer_t import)
- (bug) GSS_S_FAILURE major status lost in importContext
(Fix loss of GSS_S_FAILURE major status in importContext)
- (bug) GSSNameElement constructor needs actual mechanism input
(Add actual mechanism to native GSSNameElement state)
- (RFE) Add getLocalName() GSSName method
- (RFE) Add createCredential() with password
- JDK-8212217 (exists)
- (bug) SpNego multi-round-trip bug
(Fix SpNego multi-round-trip bug)
- (RFE) ServicePermission empty realm support
- (bug) GSSCredentialSpineeds isDefaultCredential() method
(Add isDefaultCredential() method to GSSCredentialSpi)
- (bug) Prefer default cred handles if possible
(JGSS: Prefer default cred handles if possible)
- (bug) GSSName should extend Principal
(Make GSSName implement Principal (add getName()))
This is the key bug. Without this a GSSName backed by the native C
GSS-API library cannot be used with JAAS.
Note that GSS name objects conceptually *are* principals. The base
RFCs, 2743 and 2744, both refer to them as such.
A GSSName is notionally no different that a Krb5Principal, except as
to implementation details.
- (bug/RFE) Add GssLoginModule
Naturally, Krb5LoginModule is not appropriate when using the native C
GSS-API library. That makes the non-existence of GssLoginModule a
bug when using the native C GSS-API library.
Arguably, JAAS's continued existence in a world without applets is a
bug! I would prefer JAAS be removed, but there is a great deal of
cargo-culted JAAS-using application code out there that will not go
away anytime soon, so at the very least stub classes and methods
would have to stay behind.
This commit adds a GssLoginModule that is almost a complete
replacement for Krb5LoginModule.
Missing functionality to make it a complete replacement of
Krb5LoginModule:
- kinit with key (maps to gss_acquire_cred_from())
- kinit with keytab (maps to gss_acquire_cred_from())
- (RFE) Krb5LoginModule cleanup
- (bug) Output actual mechanism
(fixup SEAM bug uncomments)
- (bug) Memory leak in exception cases in getJavaOID()
(Fix leak in exception cases in getJavaOID())
- (RFE) Simplify Krb5 context permissions checks
(JGSS: Simplify context permissions checks)
- (bug) Dispose of delegated cred handles early
Like JDK-8212217.
When a Java object has an associated C object, it's important to
dispose() of the C object as soon as possible. The GC does not know
there there is more memory pressure due to that C object. Java
objects with unknown-to-the-GC C objects are icebergs.
> You're an author now, right? You can post one yourself, webrev is at
> https://hg.openjdk.java.net/code-tools/webrev.
OK, I'll figure that out.
> > So Peter, for example, doesn't need to be a contributor?
>
> Anyone can reply, but to push the change, a formal openjdk reviewer is needed.
OK, thanks.
> If Peter rewrite the patch in total then he might need to sign the OCA.
That will not be the case.
> > Right, GitHub is sure a lot more convenient than webrevs.
>
> Hope so, but I do switch between the udiff, sdiff, frames and new
> views of webrev a lot. It's not very friendly to comment of course.
This could be fixed though. I'm surprised that webrev still doesn't
have a comment facility all these years later. I left Sun (Oracle) in
2011 -- that webrev has hardly changed since it was created (when was
that? I want to say it was around 2003) is a testament to its utility,
but it is also surprising because writing code review comments in e-mail
takes a lot more time than on a web page.
Nico
--
