#GnuPG 2.4.5 comes with a number of improvements,
that look small at first sight, but can be decisive
if you have the use case. Like one additional NFC reader (ACR-122U)
and one ECC card from D-Trust are supported. Or getting pubkeys
from behind a proxy is fixed. Details: https://dev.gnupg.org/T6960
MacOS build: https://lists.gnupg.org/pipermail/gnupg-users/2024-March/066993.html
#endtoendcrypto #FreeSoftware

New versions of #gnupg (2.4.5) and #gpg4win (4.3.1) have been released. See https://lists.gnupg.org/pipermail/gnupg-announce/2024q1/000482.html

A build for #GnuPG v2.4.4 for MacOS was announced as well https://sourceforge.net/p/gpgosx/docu/Download/
https://lists.gnupg.org/pipermail/gnupg-devel/2024-January/035480.html

#GnuPG v2.4.4 is available and has a number of improvements for you, especially if you do your cryptography with "smartcards" like yubi-keys. Most important is that a recent defect was fixed that could leave unprotected copies of a secret key on disk. 🙁 Also more cards are supported and getting pubkeys is improved. See
https://lists.gnupg.org/pipermail/gnupg-announce/2024q1/000481.html (Which links the #Gpg4win v4.3.0 download before the webside does. 😉 )

Hello,

I’m not really new here since my first message on the #Fediverse was in… 2011 (!), but in more than 10 years I never actually introduced myself properly, so as many new people are joining these days, it seems like a good time for an #introduction.

Professionally, I am a #biologist. I was for a long time a wet lab scientist, but I have left the bench and am now a #Drosophila #biocurator and #ontology engineer. I work for the University of Cambridge (UK), where I am one of the biocurators behind the FlyBase.org website. (Usual disclaimer: Views expressed here are my own, not those of FlyBase or of the University of Cambridge, etc.)

Personally, some would say I am a geek, and I probably cannot deny it. I’ve been using #Linux #Slackware for the past 20 years or so, I have contributed to several #freesoftware projects and I develop a few of my own. I care about digital #privacy, am a contributor to the #GnuPG project and an #OpenPGP evangelist, and before the Covid pandemic was a regular speaker at London #CryptoParties.

I am also the proud dad of the most beautiful cat of the Fediverse, according to all the users of my (mono-user) #Friendica instance. Also, I like to believe I am funny, even though I am most likely not.

Beta-testers wanted for #GnuPG 2.3! Lots of new features to test in that new branch: support for the upcoming revision of the OpenPGP standard (including AEAD encryption), ECC keys by default, support for the X448 curve, a new public key storage (keyboxd) promising faster key lookup, and many more!

The 2.0.x branch of #GnuPG has reached its end of life with the release of the 2.0.31 version in December 2017. No new release in that branch has occurred since, and none will ever occur even to fix critical issues. The stable branch of GnuPG is now the 2.2.x branch.

Unfortunately, the latest stable release of #Slackware (14.2), which was released in 2016, still comes with GnuPG 2.0.x. Patrick Volkerding switched to GnuPG 2.2.x in the -current branch (the future Slackware 15.0), but not in the 14.2 release, which is thus stuck with GnuPG 2.0.31.

For Slackers who would want to switch to GnuPG 2.2.x (and benefit from the new features of modern GnuPG, such as support for ECC keys) without switching to the -current branch, I maintain #SlackBuilds to build GnuPG 2.2.x (currently 2.2.23) and its associated dependencies for Slackware-14.2. I also provide pre-built binary packages (but only for the x86_64 architecture).

Nearly two months have passed, meaning a new #GnuPG release should be around the corner… and here it is. 👍

New maintenance release for #GnuPG (2.2.6). Thanks GnuPG hackers!

#GnuPG 2.2.0 was released today. My SlackBuild has been updated, as well as the corresponding binary package for Slackware64-14.2.

GnuPG 2.2 is intended to be a stable, long-term support branch, while new development will occur on the 2.3 branch. I will probably follow the development branch (so the next version provided by my SlackBuild will be GnuPG 2.3.0, not GnuPG 2.2.1).

I have released version 0.4.4 of #gfsecret, my set of tools to facilitate secret sharing.

This is a bugfix release (sort of), the only change from 0.4.3 is that the newly introduced helper script for #GnuPG now recognizes gpg binaries with a version of 2.1 or higher (instead of recognizing only 2.1). This is to make sure the script is ready for the upcoming release of #GnuPG 2.2.0.

Here is the tarball of the 0.4.4 release, and the corresponding signature.

Freshly released #GnuPG 2.1.23 now installs as gpg by default instead of gpg2. My #SlackBuild has been renamed from gnupg2 to gnupg accordingly, it now replaces the Slackware-provided gnupg package.

I have released version 0.4.3 of #gfsecret, my set of tools to facilitate secret sharing. This version fixes a bug in the interactive menu of gfsec-split and add the --restore-cmd/--destroy-cmd options to have a command automatically executed when the secret is reconstructed and when it should be deleted.

A helper script to facilitate the splitting of a #GnuPG private primary key is also bundled with this release.

Here is the tarball of the 0.4.3 release, and the corresponding signature.

Newly-appointed maintainer of #Scute, the #GnuPG PKCS#11 module, I am pleased to announce the release of version 1.5.0.

The first release since 2010, Scute 1.5.0 brings support for 4096-bit RSA keys, TLS 1.2 client authentication, S/MIME signing, and works with the latest GnuPG versions from the 2.1 “modern” branch.

Download the release tarball and the corresponding signature. The latest source code is also available in a Git repository at git://git.gnupg.org/scute.git and may be browsed on the GnuPG project’s Git Viewer.

#GnuPG 2.1.19 was released two days ago. I provide #SlackBuilds to install it onto the latest #Slackware 14.2: https://incenp.org/dvlpt/slackbuilds.html

Et encore une raison supplémentaire de laisser (enfin) tomber la branche 1.4 de #GnuPG : les développeurs envisagent d’abandonner le support des cartes à puces dans cette branche.

Je commence sérieusement à penser que le plus gros problème de #GnuPG, ce sont ses plus anciens utilisateurs… Ceux qui ont appris à l’utiliser il y a dix ans au moins et qui ne voient pas, ou refusent de voir, que GnuPG a évolué entre-temps.

Là, j’ai quand même un « crypto-terroriste auto-radicalisé » qui me dit sans rire qu’il préfère compliquer la tâche de tous les nouveaux utilisateurs aujourd’hui (en leur demandant de faire des réglages totalement inutiles pour quiconque utilise une version pas trop vieille de GnuPG) pour le cas très hypothétique où il y aurait dans l’assistance une personne utilisant encore une version de GnuPG sortie avant 2010.

Avec des amis comme ça, GnuPG n’a pas besoin d’ennemis…

Que ce soit clair : quelqu’un qui en 2017 prétend que les paramètres par défaut de GnuPG doivent impérativement être modifiés par l’utilisateur, ou qui parle encore de GnuPG 1.4, n’est pas crédible pour conseiller des débutants.

Un débutant, je lui dis d’installer GnuPG 2.1 et de faire gpg --quick-gen-key alice@example.org. Ça n’a aucune raison d’être plus compliqué que ça. Il est plus important de leur expliquer comment bien utiliser GnuPG que de vouloir les impressionner en leur présentant une procédure de génération de clefs en 23 étapes.

Je viens de publier une mise-à-jour de mon article sur la carte #OpenPGP (version PDF). Il prend en compte les nouveautés des dernières versions de #GnuPG 2.1 et inclut des liens à jour vers les différentes implémentations de la spécification.

Voilà qui ne plaira pas à tous les réfractaires au changement, mais le compte à rebours a commencé pour les branches 1.4 et 2.0 de #GnuPG : la branche 1.4 (classic) n’est plus listée comme une branche majeure et n’apparaît même plus sur la page des téléchargements, et la branche 2.0 (stable) est désormais annoncée comme arrivant en fin de vie en décembre 2017.

GnuPG 2.1.0 est sorti en novembre 2014, on en est aujourd’hui à GnuPG 2.1.16. Il est grand temps de mettre tant les distributions que les tutos à jour, les gens…

And yet another example of bad advices for #GnuPG users…

• Useless warning about SHA-1, which is not the preferred hashing algorithm in any version of GnuPG published since 2009.
  
• Systematic use of the biggest key sizes available.
  
• Suggestion to create a revocation certificate, even though recent GnuPG versions do that already (either the author is not aware of that, or he uses an obsolete version—either way, it’s bad).
  
• Reckless advice to delete the master private key, without any discussion of the pros and cons.

Please, do not send beginners to tutorials like this. It may be fine for experienced users, but not for first-timers.

Many #GnuPG users looking for advices on how to best use the software are directed toward the OpenPGP Best Practices page from Riseup.net. Unfortunately, that document is, as of April 2016, largely obsolete, to the point that I believe it is actually harmful for GnuPG beginners.

GnuPG versions
While the document recommends to “keep [the software] up to date”, it actually says nothing about the version of GnuPG to use. This is, in my opinion, the single most important advice: use the latest GnuPG version. This means: use GnuPG 2.1. At the very least, if your distribution does not provide GnuPG 2.1 yet, use the latest version from the 2.0 branch. But you should not use GnuPG 1.x anymore.

Seriously: the 1.x branch is deprecated on a modern desktop. The developers maintain it only for some old systems on which the 2.x branch cannot be built, or for those who need to handle messages and/or keys generated sometimes in the ’90s. All the interesting new features (including: elliptic curve cryptography, the TOFU trust model, DANE and TOR support, etc) are only added to the 2.1 branch.

On keyservers
The document recommends to “use the sks keyserver pool instead of one specific server”. While it is a sound advice, it should be noted that the keyserver proposed by default, keys.gnupg.net, is not a “single server”, but actually… an alias for the very same sks keyserver pool. It also recommends to download the pool’s root certificate, something that is not needed anymore since this certificate is now bundled and automatically used by GnuPG.

Another unneeded advice is the suggestion to use the no-honor-keyserver-url option, to always use the configured key server instead of the key server specified in the key to refresh. This is already the default behavior, one has to use the honor-key-server option instead to overcome it.

The advice to use Parcimonie to refresh keys through the Tor network is doubly obsolete: the provided link to the tool is dead, and GnuPG can now use Tor directly, no third-party tool is required.

One last note: all options regarding key servers should go in ~/.gnupg/dirmngr.conf (the configuration file for the dirmngr daemon) instead of ~/.gnupg/gpg.conf.

On keys and key generation
All the advices regarding key generation are only useful for users who have generated their keys a long time ago. New users, or long-time users wishing to generate a new keypair, can safely ignore them, as GnuPG already does The Right Thing™.

Specifically, you do not have to

• generate a revocation certificate: GnuPG automatically creates one in ~/.gnupg/openpgp-revocs.d;
  
• generate a separate subkey for encryption: this has been the default setup for a long time now;
  
• “make sure the key is OpenPGPv4”: no current version of GnuPG will ever generate a v3 key;
  
• check that self-signatures do not use the MD5 hash algorithm: seriously, this is 2016, you have nothing to do to prevent GnuPG from using MD5, it will never do that;
  
• check that self-signatures do not use the SHA-1 hash algorithm: although many people seem unaware of that, GnuPG uses the SHA-256 algorithm for self-signatures since version 2.0.13, back in 2009.

For key generation, the document refers to another howto, which is also obsolete (for example, it explains how to manually create an encryption subkey, ignoring that GnuPG already does that).

Like many other similar pages, the “best practices” also suggest to tweak the default preferred algorithms… completely ignoring what the current defaults are. Their proposed list is actually almost the same as the GnuPG default, except that GnuPG prioritizes SHA-256 over SHA-512 (which should be fine with everybody—there is no weakness in SHA-256). Consequently, all the steps regarding the default preferences are completely unneeded and can be skipped.

Conclusion
Any “best practice” document can only be useful if it is kept up to date. At the very least, the date of the last revision should always appear, so that the reader may know he is reading an old document.

New users should not be directed toward this kind of tutorials. Long lists of unneeded steps and warnings about obsolete algorithms that are not used anymore in the default configuration can only confuse the beginner and let him think that GnuPG is more complicated than it already is.

The two most important advices I would give to new users are: ① use the “modern” branch of GnuPG (2.1), ② stick to the default settings, they were selected as the defaults for a good reason.

Auto-promotion éhontée : collection de liens vers tous les articles que j’ai écrit sur #OpenPGP ou #GnuPG.

• Présentation de la carte OpenPGP (version PDF et source DocBook — aussi publié sur LinuxFR.org)
  
• Utilisation de GnuPG pour l’authentification SSH (en anglais)
  
• Mettre sa clef privée primaire OpenPGP hors-ligne (en anglais)
  
• Quelques remarques sur la gestion des clefs OpenPGP, sur LinuxFR.org
  
• Quelques brèves sur OpenPGP, sur LinuxFR.org

À venir : un article sur le rôle et le fonctionnement de la confiance dans le monde OpenPGP, dans la foulée de la présentation que j’ai donnée dans le cadre des Ateliers CLI de Bordeaux.