Category Archives: Uncategorized

MKVToolNix not affected by FossHub breach

Last week FossHub was breached by attackers from the group PeggleCrew. As I’m using FossHub as the primary mean of distributing Windows and MacOS binaries for MKVToolNix, users have asked me whether MKVToolNix or my other servers have been compromised, too.

To the best of my knowledge the answer is: no.

I base this on several facts:

Last week the FossHub administrators sent an quick announcement to the developers hosting their software on FossHub on the day the breach was discovered. In it the admins were very open and honest about how they’d been breached, what the attackers had had access to, and what had been modified. While they did have access to the MKVToolNix binaries, those binaries were not modified.
Several reports about the incident that have been release since by various media do not list MKVToolNix either.
The group’s Twitter account didn’t list MKVToolNix as a modified program.
To date I haven’t received a single report by a user about a MKVToolNix binary that was acting suspiciously or that was detected by anti virus tools as dangerous.

Another thing the attackers did have access to was the account database used for the developer section of the site. That database includes the passwords, and they’ve allegedly not been salted. This, however, doesn’t pose a problem for me either:

I’m using random, long passwords for such sites. Therefore it’s irrelevant whether or not the passwords have been salted as rainbow attacks (the use of pre-computed tables containing the cleartext passwords and their hashed checksums) aren’t effective against randomly generated passwords.
Even more important is that I don’t re-use passwords on other sites. So even if someone was able to determine the cleartext version of my FossHub password, it wouldn’t do them any good as it cannot be used to gain entry to any other service I’m using.

There are two things Windows users can do to verify that the binaries they’ve downloaded from FossHub are clean. The first is to verify its SHA-1 and SHA-512 checksums. I provide both checksums on my own server, and they’re always linked to from the download page: SHA1 checksums for 9.3.1, SHA512 checksums. Checksums for other versions can be queried by replacing the version number 9.3.1 in the URL with the one you’re interested in.

The second thing is to check that the executables (both the installer’s executable as well as the ones for the actual tools) are signed by the right certificate. I’m using a certificate signed by StartSSL (StartCom) (“CN = StartCom Class 2 Object CA, OU = StartCom Certification Authority, O = StartCom Ltd., C = IL”). My current certificate’s serial number is ‎5a:d8:f8:75:9a:c3:46:ae:8b:ec:99:15:eb:b5:5d:04 and its SHA1 fingerprint is 48:13:1B:5D:41:63:12:07:D2:86:20:6C:28:F3:78:C8:06:6F:34:AA, though those two values are subject to change when the certificate will be renewed in 2018.

MKVToolNix home page moved

This is just a short heads-up that MKVToolNix’ new URL is https://mkvtoolnix.download/. The old URLs all redirect to the new home page automatically.

New OpenPGP/GPG keys for emails and repository signatures

Yesterday I’ve created new OpenPGP/GPG keys: one for use in emails and for signing my Debian and Ubuntu package repositories, and another one for signing my RPM packages for CentOS/Fedora Core. All existing repositories and packages have been re-signed with the new keys.

Here are instructions for retrieving those keys (fingerprints are at the bottom).

For sending me encrypted emails and checking my signature you can retrieve the key with the ID 445B9007 from public key servers or download it from the bunkus.org webserver and import it from there.

If you use my apt repositories for Debian or Ubuntu you will have to add the new key to your apt key ring with the following command:

wget -q -O - https://www.bunkus.org/gpg-pub-moritzbunkus.txt | sudo apt-key add -

If you use my yum repositories for Fedora Core or CentOS you will have to update the repository definition. This is done by updating the RPM I offer that contains both the repository spec and the key. Run this command:

sudo rpm -Uhv https://www.bunkus.org/videotools/mkvtoolnix/centos/bunkus-org-repo-2-1.noarch.rpm

Alternatively you can download the key from public key servers or from my web server and add it to rpm with the following commands:

wget -q https://www.bunkus.org/gpg-pub-bunkusorg-rpm-signing.txt sudo rpm --import gpg-pub-bunkusorg-rpm-signing.txt

Fingerprints for manual verification:

The key used for emails and Debian/Ubuntu repositories has the ID 445B9007 ("Moritz Bunkus <moritz@bunkus.org>"; it can be used with both my private and work email addresses: moritz@bunkus.org, m.bunkus@linet-services.de). Its fingerprint is D919 9745 B054 5F2E 8197 062B 0F92 290A 445B 9007. Note that its sub-key F2E32C85 is used for the actual signature.
The key used for the RPMs for Fedora Core and CentOS has the ID 10C052A6 ("bunkus.org RPM signing key <rpm-signing@bunkus.org>"; it cannot be used for email communication). Its fingerprint is EB24 BCA1 4BA6 A24F 1427 6FEE 16D2 F5DC 10C0 52A6.

Laptop keys not working on Ubuntu 11.04 Natty Narwhal

A couple of days ago I upgraded my laptop, an Asus UL30A, from Ubuntu 10.10 Maverick to 11.04 Natty. Everything went fine. Unfortunately pretty much all of my special keys (backlight, volume, suspend, WIFI) stopped working after the obligatory reboot.

Investigation showed the following lines in syslog:

May 5 11:26:56 kirana kernel: [ 30.900537] ACPI Exception: AE_AML_BUFFER_LIMIT, Index (0x0000000000000064) is beyond end of object (20110112/exoparg2-418)
May 5 11:26:56 kirana kernel: [ 30.900551] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.STBR] (Node ffff88013763f118), AE_AML_BUFFER_LIMIT (20110112/psparse-536)
May 5 11:26:56 kirana kernel: [ 30.900565] ACPI Error: Method parse/execution failed [\_SB_.PCI0.VGA_.LCDD._BCM] (Node ffff8801376382f8), AE_AML_BUFFER_LIMIT (20110112/psparse-536)
May 5 11:26:56 kirana kernel: [ 30.900580] ACPI Error: Evaluating _BCM failed (20110112/video-365)

Typical ACPI errors you encounter way too often on laptops. Ubuntu 11.04 comes with kernel 2.6.38. Instead of wasting countless hours tracking the actual issue down I decided to check with the latest and greatest vanilla kernel first. That was 2.6.38.5 at the time of writing. I compiled using Ubuntu’s configuration as a template. The required commands where the usual (more or less the following):

cd /usr/src/linux-2.6.38.5 cp /boot/config-2.6.38-generic .config yes '' | make oldconfig make prepare make bzImage modules make INSTALL_MOD_STRIP=1 modules_install install update-initramfs -k 2.6.38.5 -c update-grub

After a reboot everything was working fine again.

Of course you can use the Debian/Ubuntu way for building and installing the kernel. The point is: 2.6.38.5 just works.