On 6/10/19 8:59 AM, Michael Osipov wrote:
> Do I have still have some time to test this in our multi-forest
> environment? I have a large setup to "play" with.
>
This would be great. Thanks.
> On Jun 10, 2019, at 7:59 PM, Michael Osipov <[email protected]> wrote:
>
> Am 2019-04-23 um 06:53 schrieb Weijun Wang:
>> Hi Martin,
>>
>> Sorry for the delay. I went through the changes and they are all in the
>> correct place. Next, I'll read the RFC carefully and make sure all behaviors
Am 2019-04-23 um 06:53 schrieb Weijun Wang:
Hi Martin,
Sorry for the delay. I went through the changes and they are all in the correct
place. Next, I'll read the RFC carefully and make sure all behaviors are
correct. In the mean time, you can start preparing the CSR.
BTW, what kinds of real w
I made some tiny changes: s/(in advanced)/(in advance)/, change the property
names to fixed width, and remove the full URL for JDK-8223172.
One thing not sure. I am not a native English speaker, but "security or system
properties" looks a little strange to me. I would use "property".
You can cl
> On Jun 6, 2019, at 11:38 PM, Martin Balao wrote:
>
> Hi Max,
>
> On 6/5/19 10:20 PM, Weijun Wang wrote:
>> For the server referral part, I think we can clone some existing cross-realm
>> authentication test and remove the [domain_realm] part in the client's
>> krb5.conf and see if the aut
Hi Max,
On 6/5/19 10:20 PM, Weijun Wang wrote:
> For the server referral part, I think we can clone some existing cross-realm
> authentication test and remove the [domain_realm] part in the client's
> krb5.conf and see if the authentication still succeeds.
I'm not sure why you would remove the
Hi Max,
On 6/5/19 9:55 PM, Weijun Wang wrote:
>
>> If there are no further comments and jdk-submit tests succeed, I'll push
>> tomorrow (2019-06-06) at around 11 am EST.
>
> None from me.
>
> Such a new feature would need a release note. I've created a skeleton at
> https://bugs.openjdk.java.n
Hi Martin,
The new test in the changeset uses a simple homemade KDC and we might want to
develop some internal tests that access real KDCs. For the server referral
part, I think we can clone some existing cross-realm authentication test and
remove the [domain_realm] part in the client's krb5.co
> On Jun 6, 2019, at 3:22 AM, Martin Balao wrote:
>
> If there are no further comments and jdk-submit tests succeed, I'll push
> tomorrow (2019-06-06) at around 11 am EST.
None from me.
Such a new feature would need a release note. I've created a skeleton at
https://bugs.openjdk.java.net/br
Hi Max,
Thanks for your feedback.
On 6/4/19 12:28 AM, Weijun Wang wrote:
> - java.security typos:
>
>492,497: ovewritten
>496: infite
>
Fixed.
> - CredentialsUtils.java:
>
>36: unused import
>
Fixed.
> - KDCRep.java:
>
>no need to move the position
>
Fixed.
> - Referra
Tiny comments:
- java.security typos:
492,497: ovewritten
496: infite
- CredentialsUtils.java:
36: unused import
- KDCRep.java:
no need to move the position
- ReferralsCache.java:
Red Hat has different copyright lines. For example, in java.base. Maybe any
one is OK. IANAL. S
Hi Max,
Thanks for your feedback.
Here it's Webrev.03:
* http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.03/
Changes:
* msgType is now private
* Check in CredentialsUtil.java removed (always true)
* "PrincipalName cSname = (PrincipalName) sname.clone();" not necessary
> On May 25, 2019, at 4:43 AM, Martin Balao wrote:
>
> Hi Max,
>
> Thanks for your review.
>
> 1)
> src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReqBuilder.java:
>
> * When NT-ENTERPRISE names are used, a "@" char can be part of the name
> and we should not interpret it as a
Hi Max,
Thanks for your review.
1)
src/java.security.jgss/share/classes/sun/security/krb5/KrbAsReqBuilder.java:
* When NT-ENTERPRISE names are used, a "@" char can be part of the name
and we should not interpret it as a realm separator. If we don't escape,
we may be missing part of the name whe
Sorry for the late reply. Comments below:
1. ReferralsState::handleError
cname = new PrincipalName(cname.getNameString().replaceAll(
PrincipalName.NAME_REALM_SEPARATOR + "", "" +
PrincipalName.NAME_REALM_SEPARATOR), cname.getNameType(),
referredRealm.toString());
Why is the escap
Hi,
I'd like to propose Webrev.02:
* http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.02/
Security properties were introduced mirroring System properties. See CSR
[1].
Thanks,
Martin.-
--
[1] - https://bugs.openjdk.java.net/browse/JDK-8223172
Hi Max,
Thanks for your feedback.
Here it's Webrev.01:
* http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.webrev.01/
Webrev.01 includes:
* rep.encKDCRepPart.pAData may be null in KrbKdcRep.java (found by Max)
* When requesting a TGS, the sname principal name is of type
KRB_NT_SRV
Hi Martin,
Sorry for the delay. I went through the changes and they are all in the correct
place. Next, I'll read the RFC carefully and make sure all behaviors are
correct. In the mean time, you can start preparing the CSR.
BTW, what kinds of real world KDC have you tested against?
Thanks,
Max
Hi Martin,
This is really a big contribution. I'll look at it once I have free time.
Currently busy with last minute changes before JDK 12 RDP.
Thanks,
Max
> On Dec 10, 2018, at 11:39 PM, Martin Balao wrote:
>
> Hi,
>
> I'd like to propose an implementation of Kerberos cross-realm referrals
19 matches
Mail list logo
