[ https://issues.apache.org/jira/browse/DIRKRB-747 ]
Colm O hEigeartaigh deleted comment on DIRKRB-747: -------------------------------------------- was (Author: coheigea): Could you submit a pull request to fix this issue, or contribute a test-case that shows where the problem is? > 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 > Assignee: Colm O hEigeartaigh > Priority: Major > Fix For: 2.0.3 > > Time Spent: 10m > Remaining Estimate: 0h > > 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 affects {{v2.0.1}} as well. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org