## Lessening my Criticism of OpenShot

In this earlier posting, I criticized a non-linear video editor named “OpenShot”, stating that it was unstable. I think I need to both lessen, and pinpoint my criticism of this software.

At the time I was mainly having problems with the Windows version of OpenShot, which its developer worked long and hard to port to Windows. But the actual problem with OpenShot under Windows has to do with an environment variable named ‘QT_HOME’. When we install certain Linux-centric software under Windows, we are often instructed to set our ‘PATH’ variable to point to it. But with Qt-libraries, there is an additional variable named ‘QT_HOME’, which states what folders the Qt-libraries are to be found in. This is a global variable under Windows, even though we may have different examples of software installed, that use different versions of the Qt-libraries.

The way it is with me, I have ‘Kleopatra’ installed, which is also a Qt-based application which has been ported to Windows. Normally, a Windows executable will look in its own folder first, for an .DLL Files it needs, before looking in other directories.

But OpenShot is an application that comes with many Qt-library-files, located in its own directory or directories. And so to point the executable to these libraries, the OpenShot installer sets this environment variable.

The problem becomes, that when I next try to run Kleopatra, its Qt-executable respects this variable, and starts to try loading the Qt-libraries that shipped with OpenShot. Kleopatra does this, even though the developers of Qt have apparently forgotten that this variable exists because its observance is built-in to Qt.

The problem here is not strictly the fault of OpenShot developers. With Qt applications, the slightest mismatch between the Qt version the application was linked against, from the shared libraries it will ink to again, when it is run, will cause typical error messages. This problem has already happened to many users, who install Qt-based applications under Linux, that were not compiled and linked in-stream with the packaged version of Qt. In fact, when we install certain Qt-based applications that are out-of-tree in this way, we often need to do something like this:


rm -f libQt*.so*




In the folder of the software in question, to force that software to link to the Qt-libraries we have installed globally, instead of linking to its own version of these libraries, before the software will run.

So in my case, when the time came for Kleopatra to ask me for my passphrases, in order to unlock my private keys, this library-mismatch prevented the software from working. At first this might sound like some sort of malware-problem, but is really just a library-incompatibility-problem.

And so the only way I was able to clean up this problem on my Windows 7 machine ‘Mithral’, was to uninstall the Windows version of OpenShot, which its authors provided so carefully, and to delete this environment variable as well. Apparently, if this variable is set and the folder empty – or nonexistent – this is not enough to convince a Qt-application to link to its own Qt-libraries. In my case I needed to delete this variable as well, before Kleopatra became stable again.

Now, if a user only feels that he will be running software on his Windows computer, that uses one, global Qt-version, this could all look very different. But in my usage-scenario,

• The way I set up my Windows machine is different, and
• I have access to OpenShot on my Linux machines, for which reason I do not need this software under Windows.

I think that I had the additional problem on the machine I name ‘Phoenix’, that OpenShot once crashed my X-server, when instructed to play back a corrupted video file, in its preview window, but at full quality. Yet, I have already learned that ‘Phoenix’ has a weak, fragile instance of the X-server running… So this may also not strictly be the fault of OpenShot developers.

Dirk

## Interpreting various Kleopatra Errors

If we initially install “Kleopatra” under Windows, by way of ‘GPG4Win’, there could be many reasons fw the application may not work at first. But once it is installed, we usually expect it to continue working, especially if we also did not upgrade it.

But it has recently happened to me, that an attempt to launch the Kleopatra GUI failed, and gave me “Application Error 0xc0000005″. After that, uninstalling specific software, which did not insert any special libraries into the workings of Kleopatra, and then rebooting the Windows 7 machine, got rid of the error, and allowed Kleopatra to work again. In order to understand what this could mean, it is necessary to understand what Kleopatra normally does.

Kleopatra is a GUI, for the “GNU Privacy Guard” suite, which provides encryption, which manages public and private keys, and which manages the encryption of private keys as well. In order to do this, the application starts a process called ‘gpg-agent’, by means of which passwords can be entered securely, with which we are protecting our secret encryption keys. Securely means, in such a way that no other applications can read or log these passwords.

The error message above is somewhat vague. It can mean that a corrupted registry key has been digested by Windows, or it can also mean that some application is trying to access protected memory that does not belong to it. One possible meaning it could have in the case of Kleopatra, is that this application was unable to establish a secure way for key-strokes to be received by ‘gpg-agent’.

The fact that a reboot was required, after the other software was uninstalled, before Kleopatra would work again, could also mean several things:

1. The other application could have installed a library to our Windows System, which remained loaded, even though the DLL File was already deleted. Specifically, this could be a Linux application using the Qt GUI libraries, that was ported to Windows, but that also set its version of the Qt libraries as the system-wide default, which might not be compatible with the Qt libraries that Kleopatra uses, and which the latter defines properly, in a way staying local to it.
2. Windows could have digested a corrupted Registry entry during the previous reboot, in a way that would affect the entire session, even after this Registry entry was removed from the version stored on the HD.
3. The other application could have left some process running in the BG, which could have affected how key-strokes are entered, even though we weren’t using that other application.

There is a more specific term for Case 3 above: We call that a key-logger. And it comes in a fitting context, that a program we use to manage our secret encryption keys, would announce to us that something was wrong.

In this case I would ask myself, whether I have actually typed in any passwords since the preceding reboot, including the password that unlocks the session. I assume that the first time we start a Windows session, this key-logger would not get the password to the machine, because processes have not yet launched, which do so after we start the first session. But if the screensaver came on, and if we entered our password to unlock that, then the BG processes would presumably be running already, and would be able to log that password.

And so aside from getting rid of such a potential threat, we also need to ask ourselves whether some immediate effort needs to be made, to change sensitive passwords…

In my own case I also observed, that the simpler GUI named ‘GPA’, which does not use Qt as its GUI library, and which also installs with ‘GPG4Win’, was still working 100%, and that the ‘gpg-agent’ process was successfully launched and running. A more critical error would have stemmed from ‘gpg-agent’ instead of from attempting to launch the GUIs.

Another observation which applies to my scenario is, that After I Uninstalled the other application and rebooted, the Error Went Away. I did not use a System Restore Point. If somebody was to install a key-logger intentionally, then he would also configure his uninstall script in such a way, as to leave that key-logger installed, if we simply gave the command to uninstall the application, which would in this case be the Trojan.

Dirk

(Edit : ) It is worth pointing out, that Kleopatra is an application, where the EXE File is not installed in the same folder, as the DLL Files it will link to. But it is normal Windows behavior, first to look in the folder of the EXE to try finding the DLLs there. Only after those are not found there, does Windows ‘look for them elsewhere’.

This could explain why Kleopatra was one of the fewer programs on my machine, that were malfunctioning, which the majority of the programs were not.

It should also be pointed out, that the other application which was causing this malfunction in my scenario, had its libraries distributed in numerous folders local to it. Therefore, it would have made sense on some level, for its developer to enter those folders into the path, in which his EXE Files were supposed to search for them.

The result could easily have been, that the DLLs which belong to Kleopatra, and which Kleopatra would thus try to link to, matched the exact names of DLL Files in the other programmer’s folders by chance, to which Kleopatra could have linked falsely.

But this may not always be everybody’s scenario. Some people report getting this error message sporadically, and without the success of having gotten rid of. And then, what could it mean?

## How I typically Solve my Kleopatra Start-Up Delay Problem

Both under Linux and under Windows, I use “Kleopatra”, which is a GUI for the ‘GnuPG’ system – the “GNU Privacy Guard”. In case the reader does not know, GnuPG or ‘GPG’ is one software alternative for providing ‘Public Key Cryptography’, which can be used in practice to sign and/or encrypt emails, as well as to validate digital signatures made by other people’s computers.

Using GPG does not strictly require that we use Kleopatra, because there exists the capability which some power-users have, to use GPG from the command-line, and Kleopatra is a distinctly KDE-based front-end, even though there exist Windows ports of it.

One problem which I eventually run in to, and which has been reported elsewhere on the Internet, is that at first after installation, Kleopatra seems to run fine, but that after some point in time we encounter a strange delay, when we start up this program, which can last for several minutes or even longer, during which the program does not respond properly to user commands. Our GPG installation does not seem to be compromised.

In my case, this seems to take place entirely, because Kleopatra has been instructed to check the revocation status of some certificates, but no ‘OCSP Server’ has been specified in its settings. According to some other reports on the Web, this is a problem specific to “CACert” certificates, and in my case also, the problem seems to set in, after I’ve added a CACert certificate to my key-ring. Yet, AFAIK, this problem could just as easily occur after we’ve added other certificates.

The way I eventually solve this problem – on every computer I own – is to open Kleopatra somehow, and then to go into Settings -> Configure Kleopatra -> S/MIME Validation , and then to look at the field which says “OCSP responder URL”. By default, this field will be blank.

Since in my case the problem starts after I’ve added my CACert certificate, I actually add the OCSP Server which is provided by CACert there, which is currently “http://ocsp.cacert.org/”. After that, I find that when I open Kleopatra, a narrow and subtle progress-bar in the lower right of the application window, sweeps to completion within one second, and the program opens fine.

I need to explain why this solution works for me, so that anybody who may be having the same problem, but not with a CACert certificate, can also solve this problem.

Certificates which are not self-signed, are signed by a ‘Certificate Authority’, such as CACert. When Kleopatra starts, one of the functions which it automatically performs is to check its certificates against a ‘Revocation List’, in case the Certificate Authority has decided to revoke it.

The actual certificate which I received from CACert, has the detail encoded into its plain-text data, that its revocation status must always be checked. But what I’ve found happens with Kleopatra specifically, is that if no OCSP Server has been specified, instead of somehow recognizing the fact that it cannot check the revocation status, this program goes into some type of infinite loop, never actually connecting to any server, but also never seeming to exit this state.

I choose to put this OCSP, because in my case, I know that it is the CACert certificate which has this need set with a high priority. It should be possible to put some other OCSP Server into the same field, because ultimately they should all be synchronized. But finally, the OCSP Server provided by the same Certificate Authority, also provides the fastest response time, for validating its own certificates.

As I see it, there was a problem in priorities somewhere, in programming this application. There was the bureaucratic priority, which states that the status of this certificate must always be checked. but then there was also the programming priority, which states that an attempt to connect to a server, without any specification of which server, will lead to some sort of malfunction eventually. And between these two, the bureaucratic priority won out.

There are some people on the Web who choose to solve this problem, by simply deactivating the feature, of online revocation checking. This can be done within the same settings tab, by unchecking the first check-box in that tab. This check-box is located directly before the setting, to “Check certificate validity every Hour” (on my setup, with a drop-down window set to “hour”). I prefer to let my software do everything it’s supposed to do, including to check the revocation status of my certificates. And the way to do the latter is to specify an OCSP Server. The fact that this problem can apparently be solved both ways, affirms the quality of the programming.

Dirk