directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Wang (Jira)" <j...@apache.org>
Subject [jira] [Updated] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
Date Thu, 30 Jul 2020 12:24:00 GMT

     [ https://issues.apache.org/jira/browse/DIRKRB-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Yang Wang updated DIRKRB-747:
-----------------------------
    Description: 
Since JDK 9, [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
has been the default Locale data. JDK 15 b23 [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245]
`DateTimeFormatter` so that non-Arabic (Western) numerals are now correctly honored for date
digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale {{mni-Beng-IN}} (Manipuri
India Bangla) when CLDR provider is used (which is default).

In method [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
a Date object is converted to string using {{SimpleDateFormat}} with system Locale, then converted
to bytes with {{StandardCharsets.US_ASCII}}. This leads to erroneous byte representation if
the system Locale has non-Arabic (western) numerals and CLDR is in use. For example, {{২০২০}}
is converted to something like {{byte[]\{63, 63, 63, 63}}}. 

These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. The JDK's Kerberos
implementation [expects only ASCII chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
for date strings and hence throws an {{IOException}} when decoding the message.

The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so that it does not
use the CLDR provider. This is non-ideal and also COMPAT is [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269].
Therefore it would great if this can be fixed within Kerby to ensure ASCII representation
is alwauys used when converting a Date to String. This is plausible since the Kerberos spec
also [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues for full
i18n support.

I can confirm this issue exists for {{v1.1.1}}. I have not tested with {{v2.0.1}}. But looking
at the source code, it is very likely that the same issue affect {{v2.0.1}} as well.

  was:
Since JDK 9, [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
has been the default Locale data. JDK 15 b23 [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245]
`DateTimeFormatter` so that non-Arabic (Western) numerals are now correctly honored for date
digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale {{mni-Beng-IN}} (Manipuri
India Bangla) when CLDR provider is used (which is default).

In method [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
a Date object is converted to string using {{SimpleDateFormat}} with system Locale, then converted
to bytes with {{StandardCharsets.US_ASCII}}. This leads to erroneous byte representation if
the system Locale has non-Arabic (western) numerals and CLDR is in use. For example, {{২০২০}}
is converted to something like {{byte[]\{63, 63, 63, 63}}}. 

These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. The JDK's Kerberos
implementation [expects only ASCII chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
for date strings and hence throws an {{IOException}} when decoding the message.

The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so that it does not
use the CLDR provider. This is non-ideal and also COMPAT is [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269].
Therefore it would great if this can be fixed within Kerby to ensure ASCII representation
is alwauys used when converting a Date to String. This is plausible since the Kerberos spec
also [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues for full
i18n support.


> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> --------------------------------------------------------------------
>
>                 Key: DIRKRB-747
>                 URL: https://issues.apache.org/jira/browse/DIRKRB-747
>             Project: Directory Kerberos
>          Issue Type: Bug
>    Affects Versions: 1.1.1
>            Reporter: Yang Wang
>            Priority: Major
>
> Since JDK 9, [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
has been the default Locale data. JDK 15 b23 [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245]
`DateTimeFormatter` so that non-Arabic (Western) numerals are now correctly honored for date
digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale {{mni-Beng-IN}} (Manipuri
India Bangla) when CLDR provider is used (which is default).
> In method [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
a Date object is converted to string using {{SimpleDateFormat}} with system Locale, then converted
to bytes with {{StandardCharsets.US_ASCII}}. This leads to erroneous byte representation if
the system Locale has non-Arabic (western) numerals and CLDR is in use. For example, {{২০২০}}
is converted to something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. The JDK's
Kerberos implementation [expects only ASCII chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
for date strings and hence throws an {{IOException}} when decoding the message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so that it does
not use the CLDR provider. This is non-ideal and also COMPAT is [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269].
Therefore it would great if this can be fixed within Kerby to ensure ASCII representation
is alwauys used when converting a Date to String. This is plausible since the Kerberos spec
also [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues for full
i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with {{v2.0.1}}. But
looking at the source code, it is very likely that the same issue affect {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org


Mime
View raw message