I’ve released MKVToolNix v8.5.1 only four days after 8.5.0. The reason is that Cisco’s Talos Research Group has found several cases of invalid memory access and instances of freeing memory twice in libEBML (TALOS-CAN-0036, TALOS-CAN-0037). The consequences range from heap information disclosure to denial of service.
Those issues have been fixed along with some more cases of invalid memory access discovered while investigating the TALOS-CAN reports. New releases of libEBML (v1.3.3) and libMatroska (v1.4.4) were made yesterday. Today’s release of MKVToolNix incorporates both updated libraries, and its build system requires at least those versions if you want to use globally-installed copies.
As MKVToolNix and therefore both libEBML and libMatroska are often used to process content from arbitrary sources I highly recommend everyone to upgrade.
You can download the source code or one of the binaries.
Here’s the full ChangeLog since the previous release:
- 2015-10-21 Moritz Bunkus <moritz@bunkus.org>
- Released v8.5.1.
- 2015-10-20 Moritz Bunkus <moritz@bunkus.org>
- build system: libEBML v1.3.3 and libMatroska v1.4.4 are now required due to important fixes for invalid memory accesses in those two releases. The copies included in the MKVToolNix source code have been updated to those releases as well.
- 2015-10-19 Moritz Bunkus <moritz@bunkus.org>
- MKVToolNix GUI: bug fix: the "save file" dialogs did not have the currently entered file name pre-selected anymore. Fixes #1480.
- MKVToolNix GUI: header editor enhancement: several track properties like name or language are shown as columns in the tree for easier distinction between tracks. They’re also shown on the overview page on the right when that track’s entry is selected in the tree. The text in the labels on this overview page can be selected with the mouse for copying & pasting elsewhere.
- 2015-10-18 Moritz Bunkus <moritz@bunkus.org>
- MKVToolNix GUI: bug fix: fixed a crash when loading corrupted job settings.
- MKVToolNix GUI: header editor bug fix: the tree items weren’t re-translated when the GUI language was changed.
- mkvmerge: bug fix: updating the track headers wasn’t working in some rare cases (corresponding error message "Re-rendering track headers: data_size != 0 not implemented yet").
- 2015-10-17 Moritz Bunkus <moritz@bunkus.org>
- MKVToolNix GUI: bug fix (Linux): the function "open folder" was inserting a superfluous leading slash in the directory name. This causes some file managers (in this particular case Dolphin on Linux) to interpret a directory name like "//home/mosu/…" as a share called "mosu" on a Samba/Windows server called "home" and to prepend the whole name with the "smb://" protocol. Fixes #1479.
Have fun.
why MKVToolNix-GUI is still so biggg??
how re-size horizontally?
for 32bit: Properties > Compatibility > Disable visual themes (enabled), GUI is re-sizeable.
but for 64bit. Nope.
This seems to be a bug in the theme (engine) you’re using. See https://github.com/mbunkus/mkvtoolnix/issues/1349
MKVToolNix 8.5.0 and 8.5.1’s installers both delete the file gMKVToolnix.dll from the MKVToolNix directory, causing gMKVExtractGUI to stop working if it is installed in that directory.
Please fix it so the MKVToolNix installer no longer deletes any gMKVExtractGUI-related files (gMKVExtractGUI.exe, gMKVEstractGUI.ini, and gMKVToolnix.dll).
In fact it would be good if it didn’t delete files it can’t identify, period, as its current behavior could also cause compatibility problems with other software that integrates with MKVToolNix and is installed into the same directory by end users.
You’re correct. This is due to me simplifying the installer script a lot for release v8.4.0 (or v8.5.0? don’t remember exactly). I hadn’t thought of scenarios such as yours. I’ll look into it.
Note, though, that I don’t support installing other applications into the same directory. What if they contain the same files that the MKVToolNix does? E.g. one of the READMEs, or worse, data/magic.mgc (which is tightly coupled to the library version it is used with).