Welcome to release v18.0.0 of MKVToolNix. This is just a smallish bug fix release which also contains a couple of performance improvements.
There were no changes for package maintainers.
You can download the source code or one of the binaries. The Windows and macOS binaries are available already. The Linux binaries are stil being built and will be available of the course of the next couple of hours.
Here are the NEWS since the previous release:
New features and enhancements
- build system: when building with clang v3.8.0 or newer,
configure will no longer restrict optimization flags to
-O1 and use
-O3 again (older versions of clang suffered from excessive memory usage with higher optimization levels).
- build system: when building with mingw 7.2.0 or newer,
configure will no longer restrict optimization flags to
-O2 and use
-O3 again (older versions of mingw suffered from bugs such as segmentation faults with higher optimization levels).
- build system: stack protection is enabled when building with clang 3.5.0 or newer on all platforms.
- mkvmerge: AVC & HEVC ES parsers: performance improvements by copying much less memory around.
- mkvmerge: tags: reintroduced a workaround for non-compliant files with tags that do not contain the mandatory
SimpleTag element. This workaround was removed during code refactoring in release v15.0.0.
- GUI: multiplexer: the "AAC is SBR/HE-AAC/AAC+" checkbox in the "audio properties" section will be disabled if the functionality is not implemented for the selected track’s codec & container.
- GUI: multiplexer: the "reduce to core" checkbox in the "audio properties" section will be disabled if the functionality is not implemented for the selected track’s codec. See #2134.
- mkvmerge: AAC ADTS parser: fixed interpretation of the
channel_configuration header element for ADTS files that do not contain a program configuration element: value 7 means 7.1 channels. Fixes #2151.
- mkvmerge: Matroska identification: the
date_utc attributes will only be output if the identified Matroska file actually contains the "date" header field.
- mkvmerge: WebVTT: mkvmerge did not recognize timestamp lines if the hours components were absent. Fixes #2139.
- mkvpropedit, GUI’s header editor: the
date header field won’t be added automatically anymore whenever the segment info section is edited and the
date element is either deleted or not present in the first place. Fixes #2143.
Have fun :)
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.
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.
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 <firstname.lastname@example.org>"; it can be used with both my private and work email addresses: email@example.com, firstname.lastname@example.org). 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 <email@example.com>"; it cannot be used for email communication). Its fingerprint is
EB24 BCA1 4BA6 A24F 1427 6FEE 16D2 F5DC 10C0 52A6.