The GNU Privacy Guard (GnuPG) upstream team maintains three branches of development: 1.4 ("classic"), 2.0 ("stable"), and 2.1 ("modern").
They differ in various ways: software architecture, supported algorithms, network transport mechanisms, protocol versions, development activity, co-installability, etc.
Debian currently ships two versions of GnuPG in every maintained suite -- in particular,
/usr/bin/gpg has historically always been provided by the "classic" branch.
That's going to change!
Debian unstable will soon be moving to the "modern" branch for providing
/usr/bin/gpg. This will give several advantages for Debian and its users in the future, but it will require a transition. Hopefully we can make it a smooth one.
Compared to "classic", The "modern" branch has:
If you want to try this out, the changes are already made in experimental. Please experiment!
If you're an end user and you don't use GnuPG directly, you shouldn't notice much of a change once the packages start to move through the rest of the archive.
Even if you do use GnuPG regularly, you shouldn't notice too much of a difference. One of the main differences is that all access to your secret key will be handled through gpg-agent, which should be automatically launched as needed. This means that operations like signing and decryption will cause gpg-agent to prompt the the user to unlock any locked keys directly, rather than gpg itself prompting the user.
If you have an existing keyring, you may also notice a difference based on a change of how your public keys are managed, though again this transition should ideally be smooth enough that you won't notice unless you care to investigate more deeply.
If you use GnuPG regularly, you might want to read the NEWS file that ships with GnuPG and related packages for updates that should help you through the transition.
If you use GnuPG in a language other than English, please install the
gnupg-l10n package, which contains the localization/translation files. For versions where those files are split out of the main package,
Recommends: gnupg-l10n already, so it should be brought in for new installations by default.
If you have an archive of old data that depends on known-broken algorithms, PGP3 keys, or other deprecated material, you'll need to have "classic" GnuPG around to access it. That will be provided in the
If you maintain a package that depends on
gnupg: be aware that the
gnupg package in debian is going through this transition.
A few general thoughts:
If your package
Depends: gnupg for signature verification only, you might prefer to have it
Depends: gpgv instead.
gpgv is a much simpler tool that the full-blown GnuPG suite, and should be easier to manage. I'm happy to help with such a transition (we've made it recently with
If your package
Depends: gnupg and expects
~/.gnupg/ to be laid out in a certain way, that's almost certainly going to break at some point.
~/.gnupg/ is GnuPG's internal storage, and it's not recommended to rely on any specific data structures there, as they may change.
gpg offers commands like
--delete for manipulating its persistent storage. please use them instead!
If your package depends on parsing or displaying
gpg's output for the user, please make sure you use its special machine-readable form (
--with-colons). Parsing the human-readable text is not advised and may change from version to version.
If you maintain a package that depends on
gnupg2 and tries to use
gpg2 instead of
gpg, that should stay ok. However, at some point it'd be nice to get rid of
/usr/bin/gpg2 and just have one expected binary (
gpg). So you can help with that:
Look for places where your package expects
gpg2 and make it try
gpg instead. If you can make your code fall back cleanly
Change your dependencies to indicate
gnupg (>= 2)
lintian to encourage other people to make this switch ;)
The last major step for this transition was renaming the source package for "classic" GnuPG to be
gnupg1. This transition is currently in the ftp-master's NEW queue. Once it makes it through that queue, and both
gnupg2 have been in experimental for a few days without reports of dangerous breakage, we'll upload both
gnupg2 to unstable.
We'll also need to do some triage on the BTS, reassigning some reports which are really only relevant for the "classic" branch.
Please report bugs via the BTS as usual! You're also welcome to ask questions and make suggestions on #debian-gnupg on irc.oftc.net, or to mail the Debian GnuPG packaging team at firstname.lastname@example.org.
Reproducible Builds is another example of the kind of audacious project that I celebrated in my last blog post.
It's a fun way to learn a little bit about different parts of the archive, and to help on an incrementally-improving process. My workflow below is meant to encourage folks to join in. The documentation on the wiki is certainly more authoritative (and will be more up-to-date in the future).
My usual workflow is this:
debcheckout clocIf that failed for some reason, I would use:
apt-get source cloc
Source: packagename Version: packageversion Tags: patch Severity: wishlist User: email@example.com Usertags: closest-usertag X-Debbugs-CC: firstname.lastname@example.orgWhen choosing the
closest usertag, i look at the "Usertagged bugs" block on the R-B continuous integration dashboard or the wiki documentation to see what makes sense.
The information at the R-B wiki page is quite detailed if you want more info.
Finally, many many thanks to all of the people involved in the project, and particularly to h01ger and Lunar^, who have both contributed a ton of work, and have also made it easy to plug in and help as a less-involved contributor. The nice automatically-updated statistics provided by the team's continuous integration work makes it a fun game to help out.
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:
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:
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.
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.
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:
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.