Came across this and thought to report as a bug but the guidance suggested discussing it first if unsure.
My team at work has to move our system into our GovCloud. Part of the requirement is enabling FIPS (140-3) mode for Java and OpenSSL. MD5 is not allowed in FIPS mode. Scala 2.13 scala.reflect.internal.StdNames makes use of MD5 and this doesn’t seem like an easy module to work around.
Should I report this as a bug? The fix would be to make use of SHA256 instead of MD5.
Sure, you can file an issue. Although, let’s look at the context of MD5 usage. Its only usage for scala-reflect is obtaining a hash for filenames that are longer than 240 characters to workaround these limits in a mostly stable way. Because of that SHA-256 would not be a good replacement, as it would not allow to apply the mentioned workaround.
However, the scala-reflect is probably used only at compile time when compiling/executing macros. I have no idea about the FIPS 140-3 details, but if it applies only to the program’s runtime (in our case final jar with application) and not the compiler itself then maybe it’s no problem right now. After all, MD5 is not used to encrypt any data in final executable.
why not? the code is converting the hash to hex string, so the string has 4x fewer characters than bits in hash, so for sha-256 the hex string length would be 64 bytes, i.e. fewer than 240 characters limit.
or do you mean that the hashes should be identical across compilations, compiler versions, etc?
Our use case is for reflection at runtime. It seems security is trying to “prevent accidents” by not allowing the Java MD5 library to be brought in at all. We’ve bumped into other use cases that should be non-offending (E.g., Liquibase uses it as a hash key as well to track ddl changesets.). The paperwork and process must be followed though so I need to open a bug on this.
Appreciate the feedback.
If they hadn’t removed -Xmax-classfile-length and if compactify were lazier, it might have been an easier workaround, depending on the application.