You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Colm O hEigeartaigh (Jira)" <ji...@apache.org> on 2023/02/20 07:34:00 UTC

[jira] [Closed] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

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

Colm O hEigeartaigh closed DIRKRB-747.
--------------------------------------

> 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: 20m
>  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-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org