Weblogs for dkg
I always find that kind of task a little off-putting and difficult to tackle, but I was happy to see someone driving the project, since it does need to get done. Debian is potentially also in a position to help the upstream python community, because we have a pretty good view of what things are being used, at least within our own ecosystem.
I'm happy to say that i also missed one of the other great benefits of paultag's audacious proposal, which is how it has engaged people who already knew about debian but who aren't yet involved. Evidence of this engagement is already visible on the py3porters-devel mailing list. But if that wasn't enough, I ran into a friend recently who told me, "Hey, I found a way to contribute to debian finally!" and pointed me to the py3-porters project. People want to contribute to the project, and are looking for ways in.
So cheers to the people who propose audacious projects and make them inviting to everyone, newcomers included. And cheers to the people who step up to potentially daunting work, stake out a task, roll up their sleeves, and pitch in. Even if the py3porters project doesn't move all of debian's python infrastructure to pyt3 as fast as paultag wants it to, i think it's already a win for the project as a whole. I am looking forward to seeing what comes out of it (and it's reminding me i need to port some of my own python work, too!)
The next time you stumble over something big that needs doing in debian, even something that might seem impossible, please make it inviting, and dive in. The rest of the project will grow and improve from the attempt.
The basic gist is that i like to use git-buildpackage (gbp) with the upstream source included in the repo, both as tarballs (with pristine-tar branches) and including upstream's native VCS history (Joey's arguments about syncing with upstream git are worth reading if you're not already convinced this is a good idea).
I also started using gbp-pq recently -- the patch-queue feature is really useful for at least three things:
- rebasing your debian/patches/ files when a new version comes out upstream -- you can use all your normal git rebase habits! and
- facilitating sending patches upstream, hopefully reducing the divergence, and
- cherry-picking new as-yet-unreleased upstream bugfix patches into a debian release.
My preferred packaging practices document is a work in progress. I'd love to improve it. If you have suggestions, please let me know.
Also, if you've written up your own preferred packaging practices, send me a link! I'm hoping to share and learn tips and tricks around this kind of workflow at debconf 15 this year.
I'm using grub version 2.02~beta2-2.
I want to make a USB stick that's capable of booting Intel architecture EFI machines, both 64-bit (x86_64) and 32-bit (ia32). I'm starting from a USB stick which is attached to a running debian system as /dev/sdX. I have nothing that i care about on that USB stick, and all data on it will be destroyed by this process.
I'm also going to try to make it bootable for traditional Intel BIOS machines, since that seems handy.
I'm documenting what I did here, in case it's useful to other people.
Set up the USB stick's partition table:
parted /dev/sdX -- mktable gpt parted /dev/sdX -- mkpart biosgrub fat32 1MiB 4MiB parted /dev/sdX -- mkpart efi fat32 4MiB -1 parted /dev/sdX -- set 1 bios_grub on parted /dev/sdX -- set 2 esp onAfter this, my 1GiB USB stick looks like:
0 root@foo:~# parted /dev/sdX -- print Model: USB FLASH DRIVE (scsi) Disk /dev/sdX: 1032MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 4194kB 3146kB fat32 biosgrub bios_grub 2 4194kB 1031MB 1027MB efi boot, esp 0 root@foo:~#make a filesystem and mount it temporarily at /mnt:
mkfs -t vfat -n GRUB /dev/sdX2 mount /dev/sdX2 /mntensure we have the binaries needed, and add three grub targets for the different platforms:
apt install grub-efi-ia32-bin grub-efi-amd64-bin grub-pc-bin grub2-common grub-install --removable --no-nvram --no-uefi-secure-boot \ --efi-directory=/mnt --boot-directory=/mnt \ --target=i386-efi grub-install --removable --no-nvram --no-uefi-secure-boot \ --efi-directory=/mnt --boot-directory=/mnt \ --target=x86_64-efi grub-install --removable --boot-directory=/mnt \ --target=i386-pc /dev/sdXAt this point, you should add anything else you want to /mnt here! For example:
- a kernel and initramfs from your own computer
- debian-installer ISOs
- firmware blobs for that annoying proprietary device
- BIOS updates
- debirf images
umount /mnt sync
I wanted to say a word of thanks for the awesome work done by debian localization teams. I speak English, and my other language skills are weak. I'm lucky: most software I use is written by default in a language that I can already understand.
The debian localization teams do great work in making sure that packages in debian gets translated into many other languages, so that many more people around the world can take advantage of free software.
I was reminded of this work recently (again) with the great patches submitted to GnuPG and related packages. The changes were made by many different people, and coordinated with the debian GnuPG packaging team by David Prévot.
This work doesn't just help debian and its users. These localizations make their way back upstream to the original projects, which in turn are available to many other people.
If you use debian, and you speak a language other than english, and you want to give back to the community, please consider joining one of the localization teams. They are a great way to help out our project's top priorities: our users and free software.
Thank you to all the localizers!
(this post was inspired by gregoa's debian advent calendar. i won't be posting public words of thanks as frequently or as diligently as he does, any more than i'll be fixing the number of RC bugs that he fixes. This are just two of the ways that gregoa consistently leads the community by example. He's an inspiration, even if living up to his example is a daunting challenge.)
GnuPG 2.1 offers many new and interesting features, but one of the most important changes is the introduction of elliptic curve crypto (ECC). While GnuPG 2.1 discourages the creation of ECC keys by default, it's important that we have the ability to verify ECC signatures and to encrypt to ECC keys if other people are using this tech. It seems likely, for example, that Google's End-To-End Chrome OpenPGP extension will use ECC. GnuPG users who don't have this capability available won't be able to communicate with End-To-End users.
There are many other architectural changes, including a move to more daemonized interactions with the outside world, including using dirmngr to talk to the keyservers, and relying more heavily on gpg-agent for secret key access. The gpg-agent change is a welcome one -- the agent now holds the secret key material entirely and never releases it -- as of 2.1 gpg2 never has any asymmetric secret key material in its process space at all.
One other nice change for those of us with large keyrings is the new keybox format for public key material. This provides much faster indexed access to the public keyring.
I've been using GnuPG 2.1.0 betas regularly for the last month, and i think that for the most part, they're ready for regular use.
Timing for debian
The timing between the debian freeze and the GnuPG upstream is unfortunate, but i don't think i'm prepared to push for this as a jessie transition yet, without more backup. I'm talking to other members of the GnuPG packaging team to see if they think this is worth even bringing to the attention of the release team, but i'm not pursuing it at the moment.
If you really want to see this in debian jessie, please install the experimental package and let me know how it works for you.
Long term migration concerns
GnuPG upstream is now maintaining three branches concurrently: modern (2.1.x), stable (2.0.x), and classic (1.4.x). I think this is stretches the GnuPG upstream development team too thin, and we should do what we can to help them transition to supporting fewer releases concurrently.
In the long-term, I'd ultimately like to see gnupg 2.1.x to replace all use of gpg 1.4.x and gpg 2.0.x in debian, but unlikely to to happen right now.
In particular, the following two bugs make it impossible to use my current, common monkeysphere workflow:
- export-reset-subkey-passwd doesn't work, which breaks monkeysphere subkey-to-ssh-agent.
- pluggable keyserver transports no longer work, which means that i can't use hkpms:// access to keyservers.
Call for testing
Anyway, if you use debian testing or unstable, and you are interested in these features, i invite you to install `gnupg2` and its friends from experimental. If you want to be sensibly conservative, i recommend backing up `~/.gnupg` before trying to use it:
cp -aT .gnupg .gnupg.bak sudo apt install -t experimental gnupg2 gnupg-agent dirmngr gpgsm gpgv2 scdaemonIf you find issues, please file them via the debian BTS as usual. I (or other members of the pkg-gnupg team) will help you triage them to upstream as needed.
If the plain ASCII text below is mangled beyond verification, you can retrieve a copy of it from my web site that should be able to be verified.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OTR Key Replacement for XMPP email@example.com =========================================== Date: 2014-04-14 My main XMPP account is firstname.lastname@example.org. I prefer OTR  conversations when using XMPP for private discussions. I was using irssi to connect to XMPP servers, and irssi relies on OpenSSL for the TLS connections. I was using it with versions of OpenSSL that were vulnerable to the "Heartbleed" attack . It's possible that my OTR long-term secret key was leaked via this attack. As a result, I'm changing my OTR key for this account. The new, correct OTR fingerprint for the XMPP account at email@example.com is: F8953C5D 48ABABA2 F48EE99C D6550A78 A91EF63D Thanks for taking the time to verify your peers' fingerprints. Secure communication is important not only to protect yourself, but also to protect your friends, their friends and so on. Happy Hacking, --dkg (Daniel Kahn Gillmor) Notes:  OTR: https://otr.cypherpunks.ca/  Heartbleed: http://heartbleed.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTTBF+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcYwkQAKLzEnTV1lrK6YrhdvRnuYnh Bh9Ad2ZY44RQmN+STMEnCJ4OWbn5qx/NrziNVUZN6JddrEvYUOxME6K0mGHdY2KR yjLYudsBuSMZQ+5crZkE8rjBL8vDj8Dbn3mHyT8bAbB9cmASESeQMu96vni15ePd 2sB7iBofee9YAoiewI+xRvjo2aRX8nbFSykoIusgnYG2qwo2qPaBVOjmoBPB5YRI PkN0/hAh11Ky0qQ/GUROytp/BMJXZx2rea2xHs0mplZLqJrX400u1Bawllgz3gfV qQKKNc3st6iHf3F6p6Z0db9NRq+AJ24fTJNcQ+t07vMZHCWM+hTelofvDyBhqG/r l8e4gdSh/zWTR/7TR3ZYLCiZzU0uYNd0rE3CcxDbnGTUS1ZxooykWBNIPJMl1DUE zzcrQleLS5tna1b9la3rJWtFIATyO4dvUXXa9wU3c3+Wr60cSXbsK5OCct2KmiWY fJme0bpM5m1j7B8QwLzKqy/+YgOOJ05QDVbBZwJn1B7rvUYmb968yLQUqO5Q87L4 GvPB1yY+2bLLF2oFMJJzFmhKuAflslRXyKcAhTmtKZY+hUpxoWuVa1qLU3bQCUSE MlC4Hv6vaq14BEYLeopoSb7THsIcUdRjho+WEKPkryj6aVZM5WnIGIS/4QtYvWpk 3UsXFdVZGfE9rfCOLf0F =BGa1 -----END PGP SIGNATURE-----
After having several people poke me in different contexts about why inline cleartext PGP signatures are a bad idea, i got sufficiently tired of repeating myself, and finally documented some of the problems explicitly.
The report includes a demonstration of a content-tampering attack that changes the meaning of a signed inline-PGP message without breaking the signature, which i first worked out on the notmuch mailing list, but hadn't gotten around to demonstrating until recently.
The attack is demonstrated against clearsigned messages, but also works against inline encrypted messages (but is harder to demonstrate since a demonstration would require sharing secret key material for the decryption step).
Please don't generate Inline-PGP messages. And if you must parse and accept them, please consider carefully the risks you expose your users to and think about ways to mitigate the problems.
Here's the background:
The Internet Research Task Force (IRTF) is a body tasked with research into underlying concepts, themes, and technologies related to the Internet as a whole. They act as a research organization that cooperates and complements the engineering and standards-setting activities of the Internet Engineering Task Force (IETF).
The IRTF is divided into issue-specific research groups, each of which has a Chair or Co-Chairs who have "wide discretion in the conduct of Research Group business", and are tasked with organizing the research and discussion, ensuring that the group makes progress on the relevant issues, and communicating the general sense of the results back to the rest of the IRTF and the IETF.
One of the IRTF's research groups specializes in cryptography: the Crypto Forum Research Group (CFRG). There are two current chairs of the CFRG: David McGrew <firstname.lastname@example.org> and Kevin M. Igoe <email@example.com>. As you can see from his e-mail address, Kevin M. Igoe is affiliated with the National Security Agency (NSA). The NSA itself actively tries to weaken cryptography on the Internet so that they can improve their surveillance, and one of the ways they try to do so is to "influence policies, standards, and specifications".
On the CFRG list yesterday, Trevor Perrin requested the removal of Kevin M. Igoe from his position as Co-chair of the CFRG. Trevor's specific arguments rest heavily on the technical merits of a proposed cryptographic mechanism called Dragonfly key exchange, but I think the focus on Dragonfly itself is the least of the concerns for the IRTF.
I've seconded Trevor's proposal, and asked Kevin directly to step down and to provide us with information about any attempts by the NSA to interfere with or subvert recommendations coming from these standards bodies.
Below is my letter in full:
I'm aware that an abdication by Kevin (or his removal by the IETF chair) would probably not end the NSA's attempts to subvert standards bodies or weaken encryption. They could continue to do so by subterfuge, for example, or by private influence on other public members. We may not be able to stop them from doing this in secret, and the knowledge that they may do so seems likely to cast a pall of suspicion over any IETF and IRTF proceedings in the future. This social damage is serious and troubling, and it marks yet another cost to the NSA's reckless institutional disregard for civil liberties and free communication.From: Daniel Kahn Gillmor <firstname.lastname@example.org> To: email@example.com, Kevin M. Igoe <firstname.lastname@example.org> Date: Sat, 21 Dec 2013 16:29:13 -0500 Subject: Re: [Cfrg] Requesting removal of CFRG co-chair On 12/20/2013 11:01 AM, Trevor Perrin wrote: > I'd like to request the removal of Kevin Igoe from CFRG co-chair. Regardless of the conclusions that anyone comes to about Dragonfly itself, I agree with Trevor that Kevin M. Igoe, as an employee of the NSA, should not remain in the role of CFRG co-chair. While the NSA clearly has a wealth of cryptographic knowledge and experience that would be useful for the CFRG, the NSA is apparently engaged in a series of attempts to weaken cryptographic standards and tools in ways that would facilitate pervasive surveillance of communication on the Internet. The IETF's public position in favor of privacy and security rightly identifies pervasive surveillance on the Internet as a serious problem: https://www.ietf.org/media/2013-11-07-internet-privacy-and-security.html The documents Trevor points to (and others from similar stories) indicate that the NSA is an organization at odds with the goals of the IETF. While I want the IETF to continue welcoming technical insight and discussion from everyone, I do not think it is appropriate for anyone from the NSA to be in a position of coordination or leadership. ---- Kevin, the responsible action for anyone in your position is to acknowledge the conflict of interest, and step down promptly from the position of Co-Chair of the CFRG. If you happen to also subscribe to the broad consensus described in the IETF's recent announcement -- that is, if you care about privacy and security on the Internet -- then you should also reveal any NSA activity you know about that attempts to subvert or weaken the cryptographic underpinnings of IETF protocols. Regards, --dkg
But even if we cannot rule out private NSA influence over standards bodies and discussion, we can certainly explicitly reject any public influence over these critical communications standards by members of an institution so at odds with the core principles of a free society.
Kevin M. Igoe, please step down from the CFRG Co-chair position.
And to anyone (including Kevin) who knows about specific attempts by the NSA to undermine the communications standards we all rely on: please blow the whistle on this kind of activity. Alert a friend, a colleague, or a journalist. Pervasive surveillance is an attack on all of us, and those who resist it are heroes.
At the moment, most maintainers do the cryptographic check manually, or maybe even don't bother to do it at all. For the common case of detached OpenPGP signatures, though, uscan can now do it for you automatically (as of devscripts version 2.13.3). You just need to tell uscan what keys you expect upstream to be signing with, and how to find the detached signature.
So, for example, Damien Miller recently announced his new key that he will be using to sign OpenSSH releases (his new key has OpenPGP fingerprint 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30 -- you can verify it has been cross-signed by his older key, and his older key has been revoked with the indication that it was superceded by this one). Having done a reasonable verification of Damien's key, if i was the openssh package maintainer, i'd do the following:
cd ~/src/openssh/ mkdir -p debian/upstream gpg --export-options export-minimal --armor --export '59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30' >> debian/upstream/signing-key.ascAnd then upon noticing that the signature files are named with a simple
.ascsuffix on the upstream distribution site, we can use the following pgpsigurlmangle option in debian/watch:
version=3 opts=pgpsigurlmangle=s/$/.asc/ ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-(.*)\.tar\.gzI've filed this specific example as debian bug #732441. If you notice a package with upstream signatures that aren't currently being checked by uscan (or if you are upstream, you sign your packages, and you want your debian maintainer to verify them), you can file similar bugs. Or, if you maintain a package for debian, you can just fix up your package so that this check is there on the next upload.
If you maintain a package whose upstream doesn't sign their releases, ask them why not -- wouldn't upstream prefer that their downstream users can verify that each release wasn't tampered with?
Of course, none of these checks take the the place of the real work of a debian package maintainer: reviewing the code and the changelogs, thinking about what changes have happened, and how they fit into the broader distribution. But it helps to automate one of the basic safeguards we should all be using. Let's eliminate the possibility that the file was tampered with at the upstream distribution mirror or while in transit over the network. That way, the maintainer's time and energy can be spent where they're more needed.
UPDATED 2015-05-03: use the currently-preferred location for the signing key.
Fingerprints and Key IDsOpenPGPv4 fingerprints are made from an SHA-1 digest over the key's public key material, creation date, and some boilerplate. SHA-1 digests are 160 bits in length. The "long key ID" of a key is the last 64 bits of the key's fingerprint. The "short key ID" of a key is the last 32 bits of the key's fingerprint. You can see both of the key IDs as a hash in and of themselves, as "32-bit truncated SHA-1" is a sort of hash (albeit not a cryptographically secure one).
I'm arguing here that short Key IDs and long Key IDs are actually useless, and we should stop using them entirely where we can do so. We certainly should not be exposing normal human users to them.
(Note that I am not arguing that OpenPGP v4 fingerprints themselves are cryptographically insecure. I do not believe that there are any serious cryptographic risks currently associated with OpenPGP v4 fingerprints. This post is about Key IDs specifically, not fingerprints.)
Key IDs have serious problemsAsheesh pointed out two years ago that OpenPGP short key IDs are bad because they are trivial to replicate. This is called a preimage attack against the short key ID (which is just a truncated fingerprint).
Today, David Leon Gil demonstrated that a collision attack against the long key ID is also trivial. A collision attack differs from a preimage attack in that the attacker gets to generate two different things that both have the same digest. Collision attacks are easier than preimage attacks because of the birthday paradox. dlg's colliding keys are not a surprise, but hopefully the explicit demonstration can serve as a wakeup call to help us improve our infrastructure.
So this is not a way to spoof a specific target's long key ID on its own. But it indicates that it's more of a worry than most people tend to think about or plan for. And remember that for a search space as small as 64-bits (the long key ID), if you want to find a pre-image against any one of
2k keys, your search is actually only in a
(64-k)-bit space to find a single pre-image.
The particularly bad news: gpg doesn't cope well with the two keys that have the same long key ID:
0 dkg@alice:~$ gpg --import x gpg: key B8EBE1AF: public key "9E669861368BCA0BE42DAF7DDDA252EBB8EBE1AF" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) 0 dkg@alice:~$ gpg --import y gpg: key B8EBE1AF: doesn't match our copy gpg: Total number processed: 1 2 dkg@alice:~$This probably also means that caff (from the signing-party package) will also choke when trying to deal with these two keys.
I'm sure there are other OpenPGP-related tools that will fail in the face of two keys with matching 64-bit key IDs.
We should not use Key IDsI am more convinced than ever that key IDs (both short and long) are actively problematic to real-world use of OpenPGP. We want two things from a key management framework: unforgability, and human-intelligible handles. Key IDs fail at both.
- Fingerprints are unforgable (as much as SHA-1's preimage resistance, anyway -- that's a separate discussion), but they aren't human-intelligible.
- User IDs are human-intelligible, and they are unforgable if we can rely on a robust keysigning network.
- Key IDs (both short and long) are neither human-intelligible nor unforgable (regardless of existence of a keysigning network), so they are the worst of all possible worlds.
How to replace Key IDsIf we're not going to use Key IDs, what should we do instead?
For anything human-facing, we should be using human-intelligible things like user IDs and creation dates. These are trivial to forge, but people can relate to them. This is better than offering the user something that is also trivial to forge, but that people cannot relate to. The job of any key management UI should be to interpret the cryptographic assurances provided by the certifications and present that to the user in a comprehensible way.
For anything not human-facing (e.g. key management data storage, etc), we should be using the full key itself. We'll also want to store the full fingerprint as an index, since that is used for communication and key exchange (e.g. on calling cards).
There remain parts of the spec (e.g. PK-ESK, Issuer subpackets) that make some use of the long key ID in ways that provide some measure of convenience but no real cryptographic security. We should fix the spec to stop using those, and either remove them entirely, or replace them with the full fingerprints. These fixes are not as urgent as the user-facing changes or the critical internal indexing fixes, though.
Key IDs are not useful. We should stop using them.