I've filed https://bugs.openjdk.java.net/browse/JDK-8225687.
> On Jun 11, 2019, at 7:56 AM, Nico Williams wrote:
>
> On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote:
>> Updated webrev at
>>
>> http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
>
> -
> src/java.security.jgss/s
Oops, I almost wanted to push my changeset yesterday and saw your mail.
Non of your comment are showstoppers. I'd like to push my current change and
file a follow on bug on them.
And DLLs have been in bin all the time.
Thanks,
Max
> On Jun 11, 2019, at 7:56 AM, Nico Williams wrote:
>
> On Mo
> On Jun 11, 2019, at 12:15 AM, Erik Joelsson wrote:
>
> Hello Max,
>
> I believe $(call FindSrcDirsForLib, $(MODULE), sspi_bridge) for SRC is the
> default so you shouldn't need to specify it explicitly, or did you experience
> some problems with the default that I'm missing?
I don't reme
On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote:
> Updated webrev at
>
>http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
-
src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java
Ugh, I never noticed GSSUtil.useMSInterop(). This really should no
Hi Max,
Thanks for the clarification on DecryptMessage. Updated webrev looks fine.
Regards,
Valerie
On 6/9/2019 7:30 PM, Weijun Wang wrote:
Updated webrev at
http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
@build-dev guys, I realize I've never included you in this code review. Plea
Hello Max,
I believe $(call FindSrcDirsForLib, $(MODULE), sspi_bridge) for SRC is
the default so you shouldn't need to specify it explicitly, or did you
experience some problems with the default that I'm missing?
/Erik
On 2019-06-09 19:30, Weijun Wang wrote:
Updated webrev at
http://cr
Updated webrev at
http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
@build-dev guys, I realize I've never included you in this code review. Please
take a look.
@Valerie, All comments accepted except for one (see below). In fact, I think I
found a bug in gss_release_context that it might
Hi, Max,
- line 424: the "(used to be const)" comment can now be removed.
- line 396-403: on line 338, there is no need to go to err as no memory
has been allocated. What happens when jumping to err but the variables,
i.e. value and name, have not been declared? Line 400-401 seems not used
I uploaded an updated webrev in place. The only changes are:
1. s/SSPI_TRACE/SSPI_BRIDGE_TRACE/ in sspi.cpp
2. Several copyright year updates.
3. Remove one unused import.
Thanks,
Max
> On May 30, 2019, at 11:18 AM, Weijun Wang wrote:
>
> Here is the latest webrev
>
> http://cr.openjdk.java
> On Jun 4, 2019, at 2:39 PM, Michael Osipov <1983-01...@gmx.net> wrote:
>
> Am 2019-06-04 um 04:09 schrieb Weijun Wang:
>> Rethinking about this. Although this sspi.cpp is included in OpenJDK, it was
>> meant to be a pure standalone DLL that has nothing to do with JNI or JVM.
>> Adding this
Am 2019-06-04 um 04:09 schrieb Weijun Wang:
Rethinking about this. Although this sspi.cpp is included in OpenJDK, it was meant to be
a pure standalone DLL that has nothing to do with JNI or JVM. Adding this
"JDK_" thing would be a tiny taint to the whole program. I'd rather make it
SSPI_BRIDGE
Rethinking about this. Although this sspi.cpp is included in OpenJDK, it was
meant to be a pure standalone DLL that has nothing to do with JNI or JVM.
Adding this "JDK_" thing would be a tiny taint to the whole program. I'd rather
make it SSPI_BRIDGE_TRACE. Is that better? Or still SSPI_TRACE?
On Sat, Jun 01, 2019 at 07:43:42AM +0800, Weijun Wang wrote:
> >> This is for export(), where they use
> >> "WELLKNOWN:ORG.H5L.REFERALS-REALM" but I hesitate to introduce it.
> >
> > Heimdal defines that, but doesn't use it. MIT doesn't even define
> > it.
>
> I thought I saw it with MIT but may
> On May 31, 2019, at 11:42 PM, Nico Williams
> wrote:
>
> On Fri, May 31, 2019 at 10:48:19PM +0800, Weijun Wang wrote:
>>> On May 31, 2019, at 3:09 AM, Nico Williams
>>> wrote:
>>> Can you
>>> just use the empty realm like Heimdal and MIT do?
>>
>> This is for export(), where they use "WE
On Fri, May 31, 2019 at 10:48:19PM +0800, Weijun Wang wrote:
> > On May 31, 2019, at 3:09 AM, Nico Williams
> > wrote:
> > Can you
> > just use the empty realm like Heimdal and MIT do?
>
> This is for export(), where they use "WELLKNOWN:ORG.H5L.REFERALS-REALM" but I
> hesitate to introduce it.
> On May 31, 2019, at 3:09 AM, Nico Williams wrote:
>
> On Thu, May 30, 2019 at 11:18:00AM +0800, Weijun Wang wrote:
>> Practically, if I always add the current realm to a name without a realm, and
>> then always remove the realm if it's the current realm when calling
>> InitiateSecurityContex
On Thu, May 30, 2019 at 11:18:00AM +0800, Weijun Wang wrote:
> Practically, if I always add the current realm to a name without a realm, and
> then always remove the realm if it's the current realm when calling
> InitiateSecurityContext, there should be no harm. If the realm was added by
> me, then
Practically, if I always add the current realm to a name without a realm, and
then always remove the realm if it's the current realm when calling
InitiateSecurityContext, there should be no harm. If the realm was added by me,
then removing it loses no info. If it was added by the user and it's t
On Tue, May 28, 2019 at 08:55:22AM +0800, Weijun Wang wrote:
> Do you have any new comments?
I should take one more look.
> My major concern now is the canonicalization of service/host.dev.example.com
> to service/host.example@dev.example.com now. As Michael pointed out, it
> could well be se
Thanks.
I tried a 2-realm environment and it seems even if I add the current realm to a
service in another realm, the service ticket can still be acquired
successfully. So it looks like I can always add the current realm to a
host-based service and there is no need to strip it later.
Precisely
I will have a look at the outstanding emails today.
Am 2019-05-28 um 02:55 schrieb Weijun Wang:
Hi Everyone,
Do you have any new comments?
My major concern now is the canonicalization of service/host.dev.example.com to
service/host.example@dev.example.com now. As Michael pointed out, it c
> On May 28, 2019, at 8:55 AM, Weijun Wang wrote:
>
> Hi Everyone,
>
> Do you have any new comments?
>
> My major concern now is the canonicalization of service/host.dev.example.com
> to service/host.example@dev.example.com now. As Michael pointed out, it
> could well be service/host.e
Hi Everyone,
Do you have any new comments?
My major concern now is the canonicalization of service/host.dev.example.com to
service/host.example@dev.example.com now. As Michael pointed out, it could
well be service/host.example@example.com.
My suggestion now is to strip the realm part w
Hi Michael and Nico,
>
> sspi.cpp:
> * KRB5_TRACE
If you think a different name is better I'll change it. And then I'd like to
revert to my old code that it always print to stderr. I don't have a need to
print it to any file.
> * showTime(): please use a readable format akin to %FT%T
What is
I'll reply to your other comment in a separate mail.
> On Apr 29, 2019, at 8:35 PM, Michael Osipov <1983-01...@gmx.net> wrote:
>
> I will try to setup a compile env after the next webrev and see how far
> I get. I have enough cross-realm stuff around here.
Please you can compile the current webr
On Mon, Apr 29, 2019 at 02:35:28PM +0200, Michael Osipov wrote:
> Am 2019-04-16 um 09:56 schrieb Weijun Wang:
> > There is been some time but I've uploaded a new webrev at
> >
> >https://cr.openjdk.java.net/~weijun/6722928/webrev.06
> >
> > Major changes:
> >
> > 1. No more get expiration ti
Am 2019-04-16 um 09:56 schrieb Weijun Wang:
There is been some time but I've uploaded a new webrev at
https://cr.openjdk.java.net/~weijun/6722928/webrev.06
Major changes:
1. No more get expiration time from TGT, accept the one from
AcquireCredentialsHandle, which makes GSS_C_INDEFINITE.
2
There is been some time but I've uploaded a new webrev at
https://cr.openjdk.java.net/~weijun/6722928/webrev.06
Major changes:
1. No more get expiration time from TGT, accept the one from
AcquireCredentialsHandle, which makes GSS_C_INDEFINITE.
2. KRB5_TRACE can be set to any file name. /dev/
Hi Michael,
Sorry about the late reply. I've just posted a new webrev at
https://cr.openjdk.java.net/~weijun/6722928/webrev.06
Below are my replies to some of your questions.
>
>>> * Why do you redefine SEC_SUCCESS macro from sspi.h?
>>
>> Oops, I didn't realized it's a redefinition. I'll
On Tue, Mar 26, 2019 at 07:12:21AM +0800, Weijun Wang wrote:
> > On Mar 25, 2019, at 11:37 PM, Nico Williams
> > wrote:
> >> But 1) Java GSS acceptor does not accept it and I don't want to break
> >> interop inside Java.
> >
> > That's not breaking interop. A Windows initiator and non-Windows
>
> On Mar 25, 2019, at 11:37 PM, Nico Williams
> wrote:
>
> On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote:
>>> On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01...@gmx.net> wrote:
> There's a few reasons:
>
> - NTLM doesn't have an OID, at least as I remember
On Mon, Mar 25, 2019 at 07:45:07PM +, Bernd Eckenfels wrote:
> Just to add another aspect to the discussion, there are at least 3 DLLs out
> there which implement this functionality (Microsoft’s JDBC driver, jTDS
> driver and Waffle) + commercial solutions as we have heared. All of them are
> u
://bernd.eckenfels.net
Von: security-dev im Auftrag von Nico
Williams
Gesendet: Montag, März 25, 2019 6:38 PM
An: Weijun Wang
Cc: security-dev@openjdk.java.net
Betreff: Re: RFR 6722928: Support SSPI as a native GSS-API provider
On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang
On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote:
> > On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01...@gmx.net> wrote:
> >>> There's a few reasons:
> >>>
> >>> - NTLM doesn't have an OID, at least as I remember
> >>>
> >>> - the JDK's JGSS stuff is very Kerberos-specific, especi
> On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01...@gmx.net> wrote:
>
> Am 2019-03-23 um 00:21 schrieb Weijun Wang:
>>
>>
>>> On Mar 22, 2019, at 11:28 PM, Nico Williams
>>> wrote:
>>>
>>> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
* header comment: Why do a
On Sat, Mar 23, 2019 at 10:45:34AM -0500, David Lloyd wrote:
> On Fri, Mar 22, 2019 at 10:29 AM Nico Williams
> wrote:
> >
> > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
> > > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work
> > > as
> > > it is inten
On Sat, Mar 23, 2019 at 01:03:17AM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 20:29 schrieb Nico Williams:
> > Our contributions add acquireCredWithPassword() methods.
> >
> > And we could add acquireCredFrom() to match gss_acquire_cred_from() /
> > gss_add_cred_from() (a Heimdal and MIT inno
On Sat, Mar 23, 2019 at 01:07:45AM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 20:43 schrieb Nico Williams:
> > All LoginModule functionality that is used to acquire credentials should
> > be made available outside JAAS. E.g., JGSS could use kinit-style
> > functionality (acquireCredWithPasswo
On Fri, Mar 22, 2019 at 10:29 AM Nico Williams
wrote:
>
> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
> > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
> > it is intended to work. Means less code you have to maintain
>
> There's a few reasons:
>
>
Am 2019-03-22 um 20:43 schrieb Nico Williams:
On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
Am 2019-03-22 um 16:28 schrieb Nico Williams:
- the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
to the ServicePermission stuff
Granted.
IMO JAAS (and w
Am 2019-03-23 um 00:21 schrieb Weijun Wang:
On Mar 22, 2019, at 11:28 PM, Nico Williams wrote:
On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
* header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
it is intended to work. Means less code you have to mai
> On Mar 22, 2019, at 11:28 PM, Nico Williams
> wrote:
>
> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
>> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
>> it is intended to work. Means less code you have to maintain
>
> There's a few reasons
On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 16:28 schrieb Nico Williams:
> > - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
> > to the ServicePermission stuff
>
> Granted.
>
> > IMO JAAS (and with it, *Permission) should be rem
On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 16:28 schrieb Nico Williams:
> > - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
> > to the ServicePermission stuff
>
> Granted.
:(
> > IMO JAAS (and with it, *Permission) should be r
On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 16:28 schrieb Nico Williams:
> > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
> > > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work
> > > as
> > > it is intended to work.
Am 2019-03-22 um 16:28 schrieb Nico Williams:
On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
* header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
it is intended to work. Means less code you have to maintain
There's a few reasons:
- NTLM doesn't have
On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
> it is intended to work. Means less code you have to maintain
There's a few reasons:
- NTLM doesn't have an OID, at least as I remember
- the JDK's JG
Hi Max,
Am 2019-03-22 um 02:10 schrieb Weijun Wang:
Hi Michael,
Many thanks to your review. Sorry I'm new to the C side of GSS-API and SSPI and
I write very little C code these days.
On Mar 22, 2019, at 5:17 AM, Michael Osipov <1983-01...@gmx.net> wrote:
Hi Max,
here is my review based on
Hi Michael,
Many thanks to your review. Sorry I'm new to the C side of GSS-API and SSPI and
I write very little C code these days.
> On Mar 22, 2019, at 5:17 AM, Michael Osipov <1983-01...@gmx.net> wrote:
>
> Hi Max,
>
> here is my review based on webrev.04. Some of the statements might not be
Hi Max,
here is my review based on webrev.04. Some of the statements might not
be correct due to my little C/C++ knowledge, just correct me if I am wrong.
I am really looking to test this, especially as a SASL provider for my
extended LDAP communication with Active Directory.
gssapi.h:
* Th
On Wed, Mar 20, 2019 at 10:20:28AM +0800, Weijun Wang wrote:
> New webrev at https://cr.openjdk.java.net/~weijun/6722928/webrev.05, and
> interdiff at
>
>https://cr.openjdk.java.net/~weijun/6722928/webrev.05/interdiff.patch.html
Thanks. I'll take a look.
> I'll think more about secondsUnti
New webrev at https://cr.openjdk.java.net/~weijun/6722928/webrev.05, and
interdiff at
https://cr.openjdk.java.net/~weijun/6722928/webrev.05/interdiff.patch.html
I'll think more about secondsUntil() and getTGTEndTime(). Other comments below.
> - sspi.cpp:61
>
> 61 #define SEC_SUCCESS(statu
On Tue, Jan 22, 2019 at 10:52:59AM +0800, Weijun Wang wrote:
> Webrev updated again at
>
> https://cr.openjdk.java.net/~weijun/6722928/webrev.04/
> This time I updated gssapi.h to make use of gss_const_xyz_t types. The types
> in NativeFunc.h and sspi.cpp are updated as well. (I wish there is a
Webrev updated again at
https://cr.openjdk.java.net/~weijun/6722928/webrev.04/
This time I updated gssapi.h to make use of gss_const_xyz_t types. The types in
NativeFunc.h and sspi.cpp are updated as well. (I wish there is an automatic
tool to check the consistence).
Several Windows API call
On Thu, Jan 17, 2019 at 11:19:14PM +0800, Weijun Wang wrote:
> Webrev updated at
>
>https://cr.openjdk.java.net/~weijun/6722928/webrev.03
>
> Changes since webrev.02:
>
> - gss_name_struct, gss_ctx_id_struct, and gss_cred_id_struct defined and
> gssapi.h is updated to use them to define po
Webrev updated at
https://cr.openjdk.java.net/~weijun/6722928/webrev.03
Changes since webrev.02:
- gss_name_struct, gss_ctx_id_struct, and gss_cred_id_struct defined and
gssapi.h is updated to use them to define pointer types gss_name_t,
gss_cred_id_t, and gss_ctx_id_t.
- small bug found i
On Thu, Jan 17, 2019 at 12:15:54AM +0800, Weijun Wang wrote:
> So I can just throw away the 'extern "c"' line?
No, no need.
> On Jan 17, 2019, at 12:13 AM, Nico Williams
> wrote:
>
> On Wed, Jan 16, 2019 at 11:12:00AM -0500, Christos Zoulas wrote:
>> On Jan 17, 12:04am, weijun.w...@oracle.com (Weijun Wang) wrote:
>> -- Subject: Re: RFR 6722928: Support SSPI as a native GSS-API p
On Wed, Jan 16, 2019 at 11:12:00AM -0500, Christos Zoulas wrote:
> On Jan 17, 12:04am, weijun.w...@oracle.com (Weijun Wang) wrote:
> -- Subject: Re: RFR 6722928: Support SSPI as a native GSS-API provider
>
> | Hi Nico,
> |
> | Can you provide more explanation on below? I have&#
On Jan 17, 12:04am, weijun.w...@oracle.com (Weijun Wang) wrote:
-- Subject: Re: RFR 6722928: Support SSPI as a native GSS-API provider
| Hi Nico,
|
| Can you provide more explanation on below? I have't touched C/C++ for quite=
| some time and I really forgot what extern "C" is
Hi Nico,
Can you provide more explanation on below? I have't touched C/C++ for quite
some time and I really forgot what extern "C" is for. I included it here only
because it's also in gssapi.h and I thought I should make the declaration and
implementation consistent.
The getenv line compiles f
Hi Valerie,
Thanks for the feedback. Most accepted. Some comments below inline. I'll read
Nico's feedback next and then upload a new webrev.
> On Dec 20, 2018, at 3:51 AM, Valerie Peng wrote:
>
> Hi Max,
>
> Here are more comments/questions on :
>
> I am a bit unclear on the handling of the
Heimdal goes a bit too far. The input_cred_handle argument to
gss_add_cred() should be gss_cred_id_t, not gss_const_cred_id_t, since
if you don't give it an output_cred_handle pointer then gss_add-cred()
mutates the input_cred_handle.
> On Jan 3, 2019, at 6:23 AM, Nico Williams wrote:
>
> On Wed, Jan 02, 2019 at 04:21:52PM +, Nico Williams wrote:
>> On Wed, Jan 02, 2019 at 10:59:26AM +0800, Weijun Wang wrote:
On Dec 31, 2018, at 2:36 PM, Nico Williams
wrote:
On Fri, Dec 28, 2018 at 09:07:04PM +0800, Wei
On Wed, Jan 02, 2019 at 04:21:52PM +, Nico Williams wrote:
> On Wed, Jan 02, 2019 at 10:59:26AM +0800, Weijun Wang wrote:
> > > On Dec 31, 2018, at 2:36 PM, Nico Williams
> > > wrote:
> > > On Fri, Dec 28, 2018 at 09:07:04PM +0800, Weijun Wang wrote:
> > >> If we are not going to use or imple
On Wed, Jan 02, 2019 at 10:59:26AM +0800, Weijun Wang wrote:
> > On Dec 31, 2018, at 2:36 PM, Nico Williams
> > wrote:
> > On Fri, Dec 28, 2018 at 09:07:04PM +0800, Weijun Wang wrote:
> >> If we are not going to use or implement new functions defined in RFC 5587,
> >> I
> >> doubt if this is use
> On Dec 31, 2018, at 2:36 PM, Nico Williams wrote:
>
> On Fri, Dec 28, 2018 at 09:07:04PM +0800, Weijun Wang wrote:
>> If we are not going to use or implement new functions defined in RFC 5587, I
>> doubt if this is useful.
>
> Using pointers to incomplete structs is much better than pointer
On Fri, Dec 28, 2018 at 09:07:04PM +0800, Weijun Wang wrote:
> If we are not going to use or implement new functions defined in RFC 5587, I
> doubt if this is useful.
Using pointers to incomplete structs is much better than pointers to
void: you get static type safety. When we made that change in
I redefine "new" to be "new (std::nothrow)" in the program.
Thanks,
Max
> On Dec 20, 2018, at 6:44 AM, Ivan Gerasimov wrote:
>
> Hi Max!
>
> In sspi.cpp native memory is allocated via `new` or `new []`, and sometimes
> the returned pointer is checked for NULL.
>
> If `new` fails, it will thr
If we are not going to use or implement new functions defined in RFC 5587, I
doubt if this is useful.
And I don't think we can rewrite existing declarations in gssapi.h to use these
const types. Or can we?
Thanks,
Max
> On Dec 20, 2018, at 6:53 AM, Valerie Peng wrote:
>
> Sure, those typedef
Sure, those typedefs makes sense.
Thanks,
Valerie
On 12/19/2018 12:31 PM, Nico Williams wrote:
On Wed, Dec 12, 2018 at 02:20:24PM -0800, Valerie Peng wrote:
- gss_unwrap: add "const" to the 2nd and 3rd arguments? Isn't variable
naming convention starts with lower case? the argument qop_state ma
Hi Max!
In sspi.cpp native memory is allocated via `new` or `new []`, and
sometimes the returned pointer is checked for NULL.
If `new` fails, it will throw the `std:: bad_alloc` exception, so I
believe you should use `new (std::nothrow)` and `new (std::nothrow) []`
instead.
With kind regar
On Wed, Dec 12, 2018 at 02:20:24PM -0800, Valerie Peng wrote:
> - gss_unwrap: add "const" to the 2nd and 3rd arguments? Isn't variable
> naming convention starts with lower case? the argument qop_state may be
> non-null but is not set?||
Nowadays we have gss_const_* types. You have to use those b
Hi Max,
Here are more comments/questions on :
I am a bit unclear on the handling of the gss qop and MS qop. There are
a few places where you seem to treat them as the same thing. But there
are also cases where they seem unrelated as you didn't set one using the
other and vice versa.
For all
Another way to avoid hand-coded SPNEGO here would be to use SSPI for SPNEGO.
That could negotiate Kerberos or NTLM, but I do believe there's a way to tell
it to only negotiate Kerberos -- I'm not terribly familiar with the details,
but I'm pretty sure that Martin Rex's GSS->SSPI shim handles this.
Hi Max,
- the DER related code is very hard to read... Would be nice to use
constants/enum for commonly used tag or use some method to construct them.
- line 449, I think you mean to use "c" instead of "cred_handle"
- gss_unwrap: add "const" to the 2nd and 3rd arguments? Isn't variable
nam
My review of the first 16% of
https://cr.openjdk.java.net/~weijun/6722928/webrev.02/ is below.
- First, I noticed this in the gssapi.h in the JDK:
typedef void * gss_name_t;
typedef void * gss_cred_id_t;
typedef void * gss_ctx_id_t;
This is not good! We long ago discovered th
On Fri, Dec 07, 2018 at 10:45:02AM +0800, Weijun Wang wrote:
> Your detailed analysis is very valuable and I've included the whole text into
> https://bugs.openjdk.java.net/browse/JDK-8214988. I knew GSSName was
> complicated at the beginning and I remember I've especially asked you to look
> at it
Hi Nico,
Your detailed analysis is very valuable and I've included the whole text into
https://bugs.openjdk.java.net/browse/JDK-8214988. I knew GSSName was
complicated at the beginning and I remember I've especially asked you to look
at it in my initial code review request. I think I have a bet
I filed https://bugs.openjdk.java.net/browse/JDK-8214988.
Thanks,
Max
> On Dec 7, 2018, at 5:33 AM, Nico Williams wrote:
>
> Looking at how to fix the incorrect isMN() implementation... The lowest cost
> route to fixing that would start with this sort of change:
>
>diff --git
> a/src/jav
Looking at how to fix the incorrect isMN() implementation... The lowest cost
route to fixing that would start with this sort of change:
diff --git
a/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.java
b/src/java.security.jgss/share/classes/sun/security/jgss/GSSNameImpl.j
On Wed, Dec 05, 2018 at 11:41:44AM +0800, Weijun Wang wrote:
> Java's GSSName::isMN always returns true, therefore to my observation, the
> GSS-API canonicalize_name() is not called if GSSName::canonicalize is called.
That *would* be a valid design choice (per RFCs 2743 and 2744), but it requires
I've thought about this over and have the following plan:
Since GSSName::isMN is always true, every gss_name_t must be a MN and I decide
the name to be always krb5 style and the type to be always NT_KRB5_NAME.
However, somewhere in the JGSS native bridge implementation the name and type
are cac
Java's GSSName::isMN always returns true, therefore to my observation, the
GSS-API canonicalize_name() is not called if GSSName::canonicalize is called.
It is only called in export(), where the first call to export_name() might
return "Name is not MN" (MIT krb5 behavior) and then the bridge auto
On Tue, Dec 04, 2018 at 10:55:49AM +0800, Weijun Wang wrote:
> > On Nov 29, 2018, at 10:00 AM, Weijun Wang wrote:
> >> - gss_canonicalize_name() is not fully implemented. This will be
> >> noticeable
> >> to callers of GSSNameElement's getKrbName(). In particular, permissions
> >> checks will
> On Nov 29, 2018, at 10:00 AM, Weijun Wang wrote:
>
>> - gss_canonicalize_name() is not fully implemented. This will be noticeable
>> to callers of GSSNameElement's getKrbName(). In particular, permissions
>> checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly
>>
On Sun, Dec 02, 2018 at 07:58:38PM +0800, Weijun Wang wrote:
> > On Dec 1, 2018, at 12:37 AM, Nico Williams
> > wrote:
> >
> > I don't see where that allows something like this property to be set via
> > some configuration file in /etc or via the registry on Windows.
>
> conf/security/java.secu
> On Dec 1, 2018, at 12:37 AM, Nico Williams wrote:
>
> I don't see where that allows something like this property to be set via
> some configuration file in /etc or via the registry on Windows.
conf/security/java.security is our supported place for these per-installation
settings. It's not
On Fri, Nov 30, 2018 at 10:12:12AM +0800, Weijun Wang wrote:
> Nowadays whenever we introduce a new security-related property, we are
> thinking about whether it can also be both a system property and a
> security property. If so, it can be set "permanently" in
> conf/security/java.security or "tem
Nowadays whenever we introduce a new security-related property, we are thinking
about whether it can also be both a system property and a security property. If
so, it can be set "permanently" in conf/security/java.security or "temporarily"
as a system property. See
https://hg.openjdk.java.net/j
On Thu, Nov 29, 2018 at 10:00:02AM +0800, Weijun Wang wrote:
> > - If you can get Legal approval for including / distributing a fork of
> > Martin Rex's bridge, you'll get all of the above functionality and
> > also acceptor functionality.
>
> Anyway, one can use his bridge with -Dsun.security
On Thu, Nov 29, 2018 at 10:00:02AM +0800, Weijun Wang wrote:
> > - You're constructing SPNEGO tokens yourself. I'll have to review that
> > very carefully.
>
> I wrapped the outgoing token into NetTokenInit and extracted in incoming
> NegTokenTarg. This might fail if there are multiple rounds,
Thanks a lot. Some comments inline.
> On Nov 29, 2018, at 1:55 AM, Nico Williams wrote:
>
> On Tue, Nov 20, 2018 at 09:56:36AM +0800, Weijun Wang wrote:
>> Please take a review at
>>
>> https://cr.openjdk.java.net/~weijun/6722928/webrev.01/
>>
>> We ported [1] the native GSS bridge to Window
On Tue, Nov 20, 2018 at 09:56:36AM +0800, Weijun Wang wrote:
> Please take a review at
>
>https://cr.openjdk.java.net/~weijun/6722928/webrev.01/
>
> We ported [1] the native GSS bridge to Windows in JDK 11, but user still have
> to download and install a native GSS-API library. This code chan
Thanks. I'll be very glad to hear your opinions are the handling of names. They
are complicated.
> On Nov 21, 2018, at 1:51 AM, Nico Williams wrote:
>
> On Tue, Nov 20, 2018 at 09:56:36AM +0800, Weijun Wang wrote:
>> Please take a review at
>>
>> https://cr.openjdk.java.net/~weijun/6722928/w
On Tue, Nov 20, 2018 at 09:56:36AM +0800, Weijun Wang wrote:
> Please take a review at
>
>https://cr.openjdk.java.net/~weijun/6722928/webrev.01/
>
> We ported [1] the native GSS bridge to Windows in JDK 11, but user still have
> to download and install a native GSS-API library. This code chan
Please take a review at
https://cr.openjdk.java.net/~weijun/6722928/webrev.01/
We ported [1] the native GSS bridge to Windows in JDK 11, but user still have
to download and install a native GSS-API library. This code change provides a
native GSS-API library inside JDK that can be used withou
97 matches
Mail list logo
