I’ve just redone my code signatures today.

One of the habits which I have in my life is, first to undertake a programming project, then to make sure it works, and finally to post some of it on my blog, where I can tell people ‘what I did, to make the project work’. As a result, some of my postings point to a ‘binaries page’, which has the following URL:

https://dirkmittler.homeip.net/binaries/

What gets shown is a table of contents, from which it’s virtually impossible to intuit what each compressed file is actually about. However, individual posts which link there, usually state, which compressed file resulted from the exercise.

Later, I got the idea to compile some of those projects, on behalf of readers who may not know how to do so, AND, to compile a subset again, to run under Windows.

What makes this tricky is the fact that, under Windows, people like me are obliged to put code signatures onto executables. My code signature only identifies me positively, as the author of the program. It doesn’t, by itself, guarantee, that the user won’t get the scary Windows defender message, when he or she double-clicks on the file-icon.

What makes this even tricker with the type of certificate I chose (to use, to sign the .EXE Files), is, that each certificate expires after one year. Even if readers did download the bundles before yesterday (May 12, 2021), the code would absolutely refuse to work, after May 25 this year. Thus, I need to buy a new certificate, and anybody who might want to keep using my programs, also needs to re-download them.

As of today, I have re-signed all the .EXE Files, with a newer certificate, which will ‘only’ expire after May 13, 2022. So, my readers may proceed, if they have used my program(s), and wish to continue doing so.


 

(Update 5/14/2021, 14h30: )

Just to be exact, the certificate which I actually used, has the Serial Number ‘154a757a67e7fd31188adce1474afadc‘.

 

Dirk

 

Opus En Ligne

( Last edited on 11/25/2016. )

On the Island Of Montreal, bus and subway fares have been handled for many years via a contact-less smart-card, called our “Opus Card”. Most residents “recharge” their fares at designated commercial establishments, but those so inclined may instead buy a USB-connected reader for this card, which also has contacts, which the privately-used readers use to recharge them.

I am one passenger, who chooses to pay their fares this way at home, by plugging the USB-cable of the card-reader into my remaining Windows 7 computer named ‘Mithral’, and by going to a Web-site, where we can provide payment information.

Until last month, the way in which this system worked was:

  • We install a device-driver for the actual card reader – which is chosen for us by the designated site.
  • We kept our Java installation up-to-date.
  • The site charges our payment method, validated on their side.
  • The Web-site deployed and launched a Java application with each use, that connected to the card reader and wrote changes to the data on the card.

At least in theory it was possible to say, that this system was based on an open standard, that being Java.

But as of this month, the transit authority has switched to a different system. We still need the actual USB driver for the card reader. But now we must also download what they call their ‘SmartCardPlugin’, which is given to us from the site as an .MSI File in the case of Windows users. This plug-in actually forms the bridge, between their Web-application and the recognized card reader.

While this system seems to work quite well, based on my first use today, I would say it represents bad programming aesthetics. Even though the actual software-components were provided by Xerox, this system does not install a PKCS#11 security device, nor anything approaching a CAC card reader, with PKI. Instead, this service is based on an .EXE File, and leaves its hook in our browser, which in the case of Firefox, we can find under Tools -> Options -> Applications.

What this means is that the site will display an Web-object, that needs to be ‘opened’ by a specific application, associated by the Web-browser.

The most positive aspect to how this works seems to be, that indeed, it provides compatibility with Firefox, Chrome, IE etc..

But instead of providing strong security, this method is only as secure as the SSL connection to the site.

It may be interesting to note, that even when this system was based on Java, none of the officials ever promised that it would work under Linux, so I see no loss there.

Some users have complained, in that this system fails to meet their expectations, in one day combining the payment service as a smart-phone, NFC service. I have to concur with this hope. I also find it a bit clumsy right now, to have to plug in my Opus Card into a USB port, and to open a site which asks me for my payment credentials – ‘the old-fashioned way’.

But OTOH, I do not see much of a practical loss, compared with how it used to work. And one reason the officials may be doing it this way, could be a negative prognosis for the future of Java itself.

It just so happens that I prefer proven standards.

Dirk

Continue reading Opus En Ligne