Yang Wang created DIRKRB-747:
--------------------------------
Summary: 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
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
