Java has finally got strong crypto

For a long time now America has treated strong crypto as akin to munitions; a deadly weapon that must not be allowed to fall into the wrong hands. For the background to this, see the wikipedia page at https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States

The wikipedia page indicates that this attitude was significantly lessened in 1992 but the sad fact is that is persisted well beyond that for java. The Oracle release notes for JDK8 at https://www.oracle.com/java/technologies/javase/8all-relnotes.html say that the restricton was removed in January 2018, in update 161. The change was also backported to JDK7 in update 171.

This means that java projects using JDK8 had better move to at least this update version if they have not already. Of course, users of OpenJDK probably never had a problem and certainly don't now.

The way I ran into this problem was during work on a trade feed that uses the FIX protocol. The FIX session was secured with TLS1.2. everything was fine until one day the remote side changed from a weak crypto algorithm to a strong one. Our side failed with a mysterious SSL handshake error. This came from the mina package, as used by quickfixj. Mina which doesn't seem to handle this situation well at all. We had to turn on packet level logging via the JVM option -Djavax.net.debug=all to see what was happening. The log showed that the remote side wanted to use a strong algorithm but that many algorithms on our side were disabled. At the time the latest JDK8 update from Oracle was update 251. I switched to that and then all those messages about unknown algorithms disappeared and the algorithm preferred by the remote side was accepted. Everything started working again.

Windows password change through different levels of RDP

There is conflicting and incomplete information on how to change your Windows password where RDP is involved. It turns out that the thing to do changes depending on how many levels of RDP are involved. Here's what I found:

• No levels of RDP. This is the simple case. Just Ctrl-Alt-Del then click on change password.
• One level of RDP. Just Ctrl-Alt-END (that's END, not Del) then click on change password.
• Two levels of RDP. You need to send Ctrl-Alt-Del to the machine at the end of the RDP chain but typing that will do it on the top level machine. Ctrl-Alt-END will do it to the machine at the second level of RDP. So you have to use the OSK command on the target machine to get an On Screen Keyboard. Then type Ctrl-Alt and click on the Del button on the OSK display.

If you google to find out how to solve this problem the most common reply is Ctrl-Alt-END. Here people are assuming there is only one level of RDP. It is very annoying that what you have to do depends on how many levels of RDP there are.

Case-insensitive ext4: just say no!

I am dismayed to learn that ext4 was changed in linux kernel 5.2 to be case insensitive (strictly speaking, to allow it as an option). This is truly terrible and will come back to bite us all. See this kernel.org posting for details. But here are just a few thoughts: Is it really going to be case insensitive? I doubt it. There are some environments in which there is a requirement for filenames to contain both uppercase and lowercase characters. Java springs to mind where the filename maps directly to the class name. Of course one could start to code entirely in lowercase but what about those classes that have already been written? What happens when the source is moved to an ext4 partition that has this feature? I strongly suspect that when they say case-insensitive what they actually mean is case-preserving, like MS-Windows. The fact that this has not been called out shows that the functionality has not been considered very deeply. People have two confused two unrelated issues: the issue of filenames supporting case and the issue of applications making the case of filenames irrelevant or not. If the filesystem is case-preserving then applications will still need to cope with this by being case-blind where they think this is what the user wants. Putting this into the file system itself is completely wrong. IMAO. There are several changes being made to linux which I don't like and this is another in a growing list:

• systemd. I notice now that more and more linux software that is available through a distro's package management system is dependent (transitively) on systemd. I anticipate a day where practically every package has this dependency.
• The Out Of Memory (OOM) Killer. I've already blogged about this.
• btfs not supporting datetime last accessed.