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 isD919 9745 B054 5F2E 8197 062B 0F92 290A 445B 9007. Note that its sub-keyF2E32C85is 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 isEB24 BCA1 4BA6 A24F 1427 6FEE 16D2 F5DC 10C0 52A6.
Fantastic! Just updated.
Thank you for detailed instructions.
:)
I made a Debian package that will automatically add the repository to the sources lists and add the GPG key: https://github.com/darealshinji/bunkus-org-repo-debian
Got the idea from the CentOS rpm. Maybe you can make some use of it.
Interestingly it’s not customary to install packages for enabling repositories on Debian/Ubuntu – unlike in the Fedora/CentOS/RHEL ecosphere. One reason is that in Debian/Ubuntu you would need to offer a distinct package for each distribution. yum (the tool used on Fedora/CentOS/RHEL) understands certain placeholders inside the repository definition ($releasever for the release version and $basearch for its architecture) which allows me to offer a single package for all of my supported Fedora versions.
Another thing I really like about how Fedora et al. handle things is that the repository’s GPG key isn’t added to the trusted keys automatically. Instead the first time the user installs a package from that repository yum asks if that key should be added and presents a lot of information about the key. On Debian/Ubuntu there’s no comparable mechanism. Either the package adds the key automatically or the user has to do it himself – including the task of verification.
I will therefore not offer such a package for Debian/Ubuntu at this time.
You could get the distribution codename with “grep DISTRIB_CODENAME /etc/lsb-release” and use that to enable the right repository. But I can see why this is better for rpm distribution then for debian-based systems.
There’s something wrong with the new Fedora/CentOS repo rpm. It contains a key
/etc/pki/rpm-gpg/RPM-GPG-KEY-BUNKUS-ORG-20150211
but the bunkus-org.repo mentions another key:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-BUNKUS-ORG-20150210
Looks like a typo to me. It seems to be the correct key.
Meh… it is a typo, but I thought I had built a new RPM with the correct key and uploaded that. Looks like I didn’t. Thanks for the heads-up.
Here’s a new RPM with updated repo files referencing the correct key: https://www.bunkus.org/videotools/mkvtoolnix/fedora/bunkus-org-repo-2-2.noarch.rpm
Hi Mosu!
I’m sorry that I’m asking you here, but today, when I reduced HD audio track to DTS core, mkvmerge informed me about strange error that was found in Matroska file structure. I’m not a specialist so I don’t know how to interpret that message. I’ve uploaded a log in .txt for you here: http://www.datafilehost.com/d/1cde9b97
Could you take a look at this, please? I’ll be grateful for an explanation.
If it is something serious, I can create a new issue for that, but I don’t know if this is a bug or not. If you want, I can upload a source file (.mkv) and a new file (.mka: DTS core). Thank you.
Such errors mean that your source is damaged at one or more positions. This has nothing to do with reducing audio to its core; it would happen without that option, too.
mkvmerge recovered as much data as it could be skipping ahead at the point of the damage to the next cluster element it could fine. In your case it looks like ~4 seconds of data were irrevocably lost.
The most common reasons for such failures: bad hardware. Usually USB drives, sometimes bad memory, overtaxed CPU; crashes (e.g. due to power loss) and following file system corruptions are a possibility as well.
BTW: I’d prefer such questions via email or at least in a blog post that actually talks about Matroska. Here it’s completely unrelated to the topic.
Thank you very much for an explanation Mosu. I think you’re right because my PC isn’t modern and sometimes there are problems with hardware. Ah, something else: I’ve just noticed that my source file (.mkv) isn’t recognized correctly by Bitrate Viewer: scanning has stopped at 00:24:19:500 so it definitely means that the file is damaged because all other .mkv files are recognized correctly.
I apologize you again for my question here: I will remember next time to ask you via e-mail or in a blog.
Regards!