Ricky's Hodgepodge

Another simple post this time. I updated my phone again with LineageOS (I was waiting if any release other than nightly was to be available, but the blueborne exploit convinced me to move now) and, again, I spent some time trying to install a custom certificate in the phone. The procedure is explained in this article in detail and it works like a charm for me.

1. To install your CA certificate you need to obtain a hash of the certificate because android expects the file to be called using this hash (this point was crucial and I had no idea about it before). So first you obtain your PEM and get the hash with the following command:

   openssl x509 -inform PEM -subject_hash_old -in calocal.crt | head -1
   xxxxxxxx
   

2. Once you have the certificate and the hash you just need to install it with the following name /system/etc/security/cacerts/xxxxxxxx.0 and the same permissions than the other CAs. Remember that the /system file system is read-only by default and you need su to do the complete process. So you have to go to Settings → Developer Options → Root Access and include ADB to it.

   $ adb shell
    daemon not running. starting it now on port 5037 
    daemon started successfully 
   $ su
   # mount -o remount,rw /system
   # cp /sdcard/Downloads/calocal.crt /system/etc/security/cacerts/xxxxxxxx.0
   # chmod 644 /system/etc/security/cacerts/xxxxxxxx.0
   # mount -o remount,ro /system
   

3. And reboot your phone. You can check that your local CA now should be listed in Settings → Security → Trusted Credentials in the System tab.

Following the procedure all my synchronizations started to work again against my personal nextcloud and runalyze servers. It's incredible that such an old phone is still maintained by lineage and now running android 7.1.2 with the September security patches from google. I have to say that my requirements for the phone are very slight.

Good job lineage team!

Because of my new work now I only use debian testing in my desktop box. I have a little gigabyte next to my TV and, if you remember, my nasty samsung model is always boycotting me (using an HDMI connector the TV uses a mode in which a little zone at the four edges is missing, other samsung models have a screen fit option that avoids this issue, but in mine that option is missing; if common VGA connection is used then the TV does not send the EDIDs to the computer). I am not going to buy another samsung TV in my whole life, that is for sure. But after upgrading the box I discovered that (again) the resolution was 1024x768 and not to the correct 1360x768 that is supported in VGA, that mode line was configured in the xorg.conf file and now, something had changed, and it did not work. To my surprise debian testing has moved to wayland and now the X11 configuration is not used (if I logged in using X11 it worked again with the proper resolution).

I do not know if I am going to use wayland or X11 but at least I wanted to know how to configure a custom mode line in wayland to have both options available, and I finally discovered it in this post answer. Now you have to add the mode line in EDID format and configure the kernel to boot using that EDID. The steps are quite easy:

1. Akatrevorjay has created an easy project to change any X11 mode line in an EDID file. So first clone the project.

   
   git clone https://github.com/akatrevorjay/edid-generator.git
   cd edid-generator
   

2. Install some required packages.

   
   sudo apt-get install zsh edid-decode automake dos2unix
   

3. The project has some standard mode lines already present but I had to add my custom one. This creates a 1360x768.S definition file for the mode line.

   
   ./modeline2edid - <<< 'Modeline     "1360x768" 84.75  1360 1432 1568 1776  768 771 781 798 -hsync +vsync'
   

4. Compile and create the binary EDID files.

   
   make
   

5. Copy the ones you are interested in to the /lib/firmware/edid directory.

   
   sudo cp 1024x768.bin 1360x768.bin /lib/firmware/edid/
   

6. Finally add the EDID you want to configure in the kernel at grub level. The option drm_kms_helper.edid_firmware=edid/<resolution>.bin should be added to the GRUB_CMDLINE_LINUX variable in the /etc/default/grub file (In debian this option is empty by default).

   
   GRUB_CMDLINE_LINUX="drm_kms_helper.edid_firmware=edid/1360x768.bin"
   

   You can first try adding manually the option editing the boot line in grub (in the grub menu you can click e to edit the line and start with the option manually added, you also need to do this if you make any mistake and the kernel does not boot).

7. Update the grub.

   sudo update-grub
   

And that is all. When you restart the box, it uses the new resolution in the complete boot process. I do not know if I will continue with wayland or I switch back to X11 (think that this box is mainly used to browse internet, watch youtube videos, series and films, listen to music and so on and so forth), for the moment I have not seen any issue but you never know. As always, the entry is mainly for me, next time I will have the information here, easy access.

Regards!

A quick entry this time. This week the version 0.17.0 of OpenSC has been released which supports DNIe 3.0 by default. Hopefully all the main linux distributions will update the package and the version 3.0 will be finally integrated out of the box in any linux desktop or laptop. My personal impression is that only a few are testing so let's see if no bugs are still present. As always, if somebody finds an issue, please file it in the github project and I will try to work on it when I have time.

I am going to take this opportunity to explain in more detail the difference between DNIe in OpenSC and the official driver provided by the Spanish government. I see that there are a lot of confusion about what is what, and a lot of people even do not know that there are two different implementations.

The FNMT (Fabrica Nacional de la Moneda y Timbre) gives a full PKCS#11 library called MultiPKCS11. This library provides a PKCS#11 compatible API to connect to several crypto-devices (among them DNIe v2.0 and v3.0). This is the current implementation you have to use in linux if you want to follow the official path (the old versions of OpenSC provided before are very old and almost incompatible with any modern linux distribution). The FNMT also provides the source for that library (which I use a lot to understand the internals of the card), but it is not clear under what license those sources are distributed. Now I realize that there is documentation to compile it in a rhel 7 box, but I have to say that I have never been able to compile it. This official PKCS#11 can be downloaded from the FNMT download page, the MultiPKCS11 links are at the end of it.

The second implementation is the one that comes with the OpenSC project. The OpenDNIe driver is a complete and new implementation started long ago because of the mess done with the source code given by the Spanish government (license). I wrote a detailed entry about this same subject long ago. So the OpenDNIe driver integrated in OpenSC is done by unselfish people who come and go (because we have a life too!), mainly it was started by Juan Antonio Martinez (he implemented the first fully functional driver for v2.0), then Germán Blanco (who integrated it in OpenSC and maintained it for some years) and now me (I added v3.0 support and some minor modifications). There are and have been another nice people who collaborate in testing too (special mention to miguel-cv). But that is all. None of the people I have mentioned (included me) has any relation with the official driver or works for the FNMT. We are/were doing this only for free and because we like it. So please understand the situation.

For the moment I will try to maintain the driver in OpenSC but you never know what will happen in the future. You can always test things with both implementations before reporting bugs or issues, that usually helps. And also remember that PKCS#11 and web are right now quite incompatible about digital signature, there is no standard way of signing with crypto-devices in the web and all the techniques (applets, addons,...) are problematic (there are several articles about the topic in this blog). So, OpenSC/OpenDNIe is not always the culprit, the situation is much more complex than anyone would usually expect.

Enjoy the new release!