#10 Trivial locale bug breaks decryption in Turkish locale

[Tim Allison]

This is a bot generated description, but the issue is real.

Opening an agile-encrypted (Access 2010+ .accdb) database fails when the JVM's
default locale is Turkish (tr/tr-TR), with or without the correct password.

Cause: XmlEncryptionDescriptor.parseEnum(String, Class) normalizes the XML
attribute value with

  value.trim().toUpperCase().replaceAll("[-_]", "")

and then calls Enum.valueOf. toUpperCase() uses the default locale; in Turkish,
'i' uppercases to dotted 'İ' (U+0130), so the cipherChaining value
"ChainingModeCBC" becomes "CHAİNİNGMODECBC" and no constant of
XmlEncryptionDescriptor.CipherChaining matches:

  "ChainingModeCBC".toUpperCase(Locale.forLanguageTag("tr"))  -> "CHAİNİNGMODECBC"
  "ChainingModeCBC".toUpperCase(Locale.ROOT)                   -> "CHAININGMODECBC"

Any enum value containing a lowercase 'i' is affected the same way.

Fix: use toUpperCase(Locale.ROOT) in parseEnum.

The same default-locale pattern appears in two other places in 5.0.0, which may
be worth changing at the same time:

• MSISAMCryptCodecHandler uppercases the password with String.toUpperCase()
  before encoding it for key derivation, so under Turkish a password containing
  'i' would derive a different key (not verified with a test file).
• EncryptionHeader.parseKeySize lowercases the CSP name with toLowerCase() before
  checking for " base"; harmless for that substring, but Locale.ROOT would make
  it independent of the default locale.

[James Ahlborn]

fixed in 5.0.1