Distributions

Key management with Gentoo Keys

In mid-January, Pavlos Ratis announced the first release of Gentoo Keys, which is a Python toolkit for handling OpenPGP keys. It is, in some sense, a complement to a plan for using OpenPGP keys within the distribution for signing files that has been adopted by the project. Ultimately, it is one of a number of efforts over the years for organizations of various sorts to standardize the best practices for using cryptographic keys. It is, it seems, something that each free-software project has to work out for itself.

While OpenPGP is the standard (codified in RFC 4880), one will commonly hear references to GNU Privacy Guard (aka GnuPG or GPG), since that is the dominant free-software tool that implements the standard. Essentially, GPG implements public-key cryptography for use in various ways. Some of the more common uses are for email encryption and for digital signatures that authenticate the source for a particular message or file. Those signatures can only be made by the holder of the private half of the key pair—that effectively means it was signed by the same person who registered the public half of the key pair.

Users, particularly security-conscious users, would like to know that the software they are downloading actually contains what they expect and has not been tampered with either in the repository or by some kind of "man in the middle" along the way. That is why distributions generally sign their packages with a distribution-specific key; package managers like RPM and dpkg can then verify those signatures. If the signatures do not match, the package manager can refuse to install the package.

But packages are built by developers and are uploaded into the project's infrastructure before they make their way out to users. Like with downloading packages, there are opportunities for attackers to tamper with the updated package source before users receive it. Ensuring that channel is secure requires a different strategy, with keys for each individual developer that can be used to sign the uploaded code.

As noted in the announcement, Gentoo Keys will help "establish the trust between the users and developers" by handling various key-related tasks. The intent is that it will verify keys and signatures "for Gentoo's release media, packages and other OpenPGP signed documents, i.e LiveDVDs, LiveCD's , stage* releases, Gentoo tree ebuild commits, [and] layman repositories list".

Gentoo Keys currently consists of two helper programs, gkeys-ldap and gkeys-gen, as well as the main gkeys program. gkeys-ldap is a tool that will be used inside the Gentoo infrastructure to do an LDAP lookup of developers' keys for use in "seed" files. Those files will contain a list of trusted key fingerprints, which can then be retrieved as needed by using the gkeys commands.

The gkeys-gen utility is meant to create keys for Gentoo developers based on the requirements adopted as part of Gentoo Linux Enhancement Proposal (GLEP) 63. The idea is to allow developers to generate keys that fulfill the GLEP 63 guidelines without needing to understand the details of GPG. Users can just run gkeys-gen, type in their name, email address, and password, and the program will generate a compliant key, as Gentoo Keys lead Brian Dolbec described. He also pointed to the project's first use page for additional information.

Another wiki page covers the steps to take after the keys are generated, such as backing up and publishing the generated keys. Given that those steps require using GPG directly, they would seem like something that might be pulled into gkeys-gen down the road.

The core of the new functionality resides in gkeys, itself. As described in its help page, gkeys has numerous sub-commands to manage keys and seed files, as well as to sign files and to verify signatures. When Gentoo Keys is first installed, it will install the keyring that holds the Gentoo release-media keys as well as a key that is used to sign seed files.

The seed files for Gentoo developers will also be installed. The actual keys can be retrieved as needed using the gkeys import-key command. The fingerprint of that key is then checked against what is listed in the signed seed file to ensure that the proper key has been retrieved. That provides a way for users and developers to retrieve the keys as needed but to ensure they have not been tampered with. In addition, gkeys spec-check can test keys to see whether they are GLEP 63 compliant.

As noted, Gentoo Keys is a toolkit. It provides tooling to help distribute, manage, and validate keys, but does not mandate how they are to be used. It would seem that more will be coming once the developers have generated their GLEP 63 keys, as the requirements for using the keys are still unspecified. But getting the right kinds of keys into the hands of developers, as well as the tools to manage them, is a good first step.

Comments (1 posted)

KaOS ISO 2015.02

KaOS has announced a new release. "This release brings the end of KDE 4 as the default Desktop Environment for KaOS. Almost ten months ago work started to fully migrate to a Frameworks 5, Plasma 5 based distribution and with the release of Plasma 5.2.1 this migration is now deemed ready to bring a better user experience then KDE 4. From the unset of this migration there was never a plan to mix the two environments. What you will see on this ISO is a pure Plasma 5 based environment."

Comments (none posted)

Ubuntu 14.04.2 LTS released + 15.04 ("Vivid Vervet") feature freeze

Ubuntu has announced the release of the second point release for its 14.04 long-term support (LTS). 14.04.2 comes with an updated kernel and X Window stack to support more hardware, along with "security updates and corrections for other high-impact bugs" all on updated installation media "so that fewer updates will need to be downloaded after installation". It is available for all of the members of the Ubuntu clan: Kubuntu, Edubuntu, Xubuntu, Mythbuntu, Ubuntu GNOME, Lubuntu, Ubuntu Kylin, and Ubuntu Studio.

One other note from the Ubuntu world: a feature freeze is in effect for 15.04 ("Vivid Vervet"), which is due in April.

Full Story (comments: 9)

Debian Technical Committee: Transition plan to systemd by default

The Debian Technical Committee (CTTE) previously decided that systemd would be the default init system for the upcoming jessie (8.0) release, for new installs. The CTTE has also decided that systemd will be default for upgrades. Thanks to the efforts of some Debian contributors, the transition should be a smooth one. Thanks to the efforts of other contributors it will be possible to upgrade without switching to systemd.

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 598 (February 23)
• Linux Mint Monthly News (February)
• Ubuntu Weekly Newsletter, Issue 405 (February 22)

Comments (none posted)

5 specialized Linux distributions for computer repair (Opensource.com)

Opensource.com takes a look at 5 distributions focused on rescue/repair. "Aimed at system administrators, SystemRescueCD is a powerful tool for repairing Linux systems. By default, SystemRescueCD boots into console interface with very little hand-holding, but a welcome message provides basic instructions for starting the network interface, running various command line programs (text editors and a web browser), enabling NTFS support in order to read Windows hard drives, and starting the XFCE-based graphical desktop environment. SystemRescueCD does include a large number of utilities, but you really need to know what you are doing to use it."

Comments (1 posted)