FSF Events: Free Software Directory meeting on IRC: Friday, June 07, starting at 12:00 EDT (16:00 UTC)
Join the FSF and friends on Friday, June 07, from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.
#gnuorg
GNU Guix: Source code archiving in Guix: new publication
We are glad to announce the publication of a new research paper entitled Source Code Archiving to the Rescue of Reproducible Deployment for the ACM Conference on Reproducibility and Replicability. The paper presents work that has been done since we started connecting Guix with the Software Heritage (SWH) archive five years ago:
The ability to verify research results and to experiment with methodologies are core tenets of science. As research results are increasingly the outcome of computational processes, software plays a central role. GNU Guix is a software deployment tool that supports reproducible software deployment, making it a foundation for computational research workflows. To achieve reproducibility, we must first ensure the source code of software packages Guix deploys remains available.
We describe our work connecting Guix with Software Heritage, the universal source code archive, making Guix the first free software distribution and tool backed by a stable archive. Our contribution is twofold: we explain the rationale and present the design and implementation we came up with; second, we report on the archival coverage for package source code with data collected over five years and discuss remaining challenges.
The ability to retrieve package source code is important for researchers who need to be able to replay scientific workflows, but it’s just as important for engineers and developers alike, who may also have good reasons to redeploy or to audit past package sets.
Support for source code archiving and recovery in Guix has improved a lot over the past five years, in particular with:
- Support for recovering source code tarballs (
tar.gzand similar files): this is made possible by Disarchive, written by Timothy Sample.
- The ability to look up data by nar hash in the SWH archive (“nar” is the normalized archive format used by Nix and Guix), thanks to fellow SWH hackers. This, in turn, allows Guix to look up any version control checkout by content hash—Git, Subversion, Mercurial, you name it!
- The monitoring of archival coverage with Timothy’s Preservation of Guix reports has allowed us to identify discrepancies in Guix, Disarchive, and/or SWH and to increase archival coverage.
94% of the packages in a January 2024 snapshot of Guix are known to have their source code archived!
Check out the paper to learn more about the machinery at play and the current status.
findutils @ Savannah: GNU findutils 4.10.0 released
This is to announce findutils-4.10.0, a stable release.
See the NEWS below for more details.
GNU findutils is a set of software tools for finding files that match
certain criteria and for performing various operations on them.
Findutils includes the programs "find", "xargs" and "locate".
More information about findutils is available at:
https://www.gnu.org/software/findutils/
Please report bugs and problems with this release via the the
GNU Savannah bug tracker:
https://savannah.gnu.org/bugs/?group=findutils
Please send general comments and feedback about the GNU findutils
package to the mailing list (
There have been 88 commits by 8 people in the - sigh - 121 weeks since 4.9.0:
Antonio Diaz Diaz (2) James Youngman (24)
Bernhard Voelker (57) John A. Leuenhagen (1)
Bjarni Ingi Gislason (1) Shuiqing Zhou (1)
Helmut Grohne (1) ribbon (1)
This release was bootstrapped with the following tools:
Autoconf 2.72
Automake 1.16.5
M4 1.4.18
Gnulib v1.0-187-g623bcc22f4
Please consider supporting the Free Software Foundation in its fund
raising appeal; see <https://www.fsf.org/appeal/>.
Thanks to everyone who has contributed!
Have a nice day,
Bernhard Voelker [on behalf of the GNU findutils maintainers]
================================================================================
Here are the compressed sources:
https://ftp.gnu.org/pub/gnu/findutils/findutils-4.10.0.tar.xz
Here are the GPG detached signatures[*]:
https://ftp.gnu.org/pub/gnu/findutils/findutils-4.10.0.tar.xz.sig
Use a mirror for higher download bandwidth:
http://www.gnu.org/order/ftp.html
Here is the SHA256 checksum:
1387e0b67ff247d2abde998f90dfbf70c1491391a59ddfecb8ae698789f0a4f5 findutils-4.10.0.tar.xz
[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify findutils-4.10.0.tar.xz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
gpg --keyserver keys.gnupg.net --recv-keys A5189DB69C1164D33002936646502EF796917195
and rerun the 'gpg --verify' command.
================================================================================
NEWS
- Noteworthy changes in release 4.10.0 (2024-06-01) [stable]
** Bug Fixes
Find now defaults to optimization level 1 rather than 2 and the
cost-based optimizer will only run at level 2 and above. This
should prevent changes of operation order which result in
user-visible differences in behaviour. [#58427]
If the -P option to xargs is not used, xargs will not change the way
in which the SIGUSR1 and SIGUSR2 signals are handled. This means
that they will cause the program to terminate if the signals were
not ignored in the process which started xargs. This also means that
xargs does not use parallel execution at all.
If you start xargs with '-P 1', then xargs will not be killed by these
signals, and they instead change the degree of parallelism.
This change improves xargs' POSIX compliance.
'xargs -P' now waits for all its child processes to complete before
exiting, even if one of them exits with status 255. [#64451]
If the -P option of xargs is in use, reads on standard input which are
interrupted by a signal are re-started. [#64442]
'find -name /' no longer outputs a warning, because that is a valid pattern
to match the root directory "/". Previously, a diagnostic falsely claimed
that this pattern would not match anything. [#62227]
'find -gid' (without the mandatory argument) now outputs a correct error
diagnostic. Previously it output: "find: invalid argument -gid' to-gid'".
The error diagnostic for non-numeric arguments has been improved as well.
Likewise for -inum, -links and -uid.
'find -user' and 'find -group' now allow to specify larger UIDs/GIDs.
Previously, that was limited to INT_MAX, although the types uid_t and gid_t
are larger on many systems, including x86_64 GNU/Linux. [#64900]
'find -xtype l' no longer fails on symbolic links that point to
themselves. These are treated similarly to broken links. [#51926]
** Improvements
The find predicates -used, -amin, -cmin, -mmin, -atime, -ctime, and -mtime
now properly diagnose a not-a-number argument. Previously, find dumped
core via an assertion. [#64717]
** Changes to the build process
findutils now builds again on systems with musl-libc.
This requires gettext-0.19.8.
findutils programs no longer fail for timestamps past the year 2038
on obsolete configurations with 32-bit signed time_t, because the
build procedure now rejects these configurations.
On systems without any year2038 support configure with --disable-year2038.
** Documentation Changes
When generating the Texinfo manual, makeinfo is invoked with the --no-split
option for all output formats now; this avoids files like find.info-[12].
The xargs documentation now describes the double dash "--" option delimiter.
The xargs examples in the Texinfo manual now use the -L and --replace options
instead of the deprecated -l and -i options. [#64480]
The TexInfo manual now uses upper-case 'B' as birthtime for the -newerXY
comparison consistently. [#65378]
** Translations
Updated the following translations: Belarusian, Brazilian Portuguese,
Bulgarian, Catalan, Chinese (simplified), Chinese (traditional),
Croatian, Czech, Danish, Dutch, Esperanto, Estonian, Finnish, French,
Galician, Georgian, German, Greek, Hungarian, Indonesian, Irish,
Italian, Japanese, Korean, Lithuanian, Luganda, Malay, Norwegian
Bokmaal, Polish, Portuguese, Romanian, Russian, Serbian, Slovak,
Slovenian, Spanish, Swedish, Turkish, Ukrainian, Vietnamese.
poke @ Savannah: GNU poke 4.1 released
I am happy to announce a new release of GNU poke, version 4.1.
This is a bugfix release in the 4.x series.
See the file NEWS in the distribution tarball for a list of issues
fixed in this release.
The tarball poke-4.1.tar.gz is now available at
https://ftp.gnu.org/gnu/poke/poke-4.1.tar.gz.
GNU poke (http://www.jemarch.net/poke) is an interactive, extensible
editor for binary data. Not limited to editing basic entities such
as bits and bytes, it provides a full-fledged procedural,
interactive programming language designed to describe data
structures and to operate on them.
Thanks to the people who contributed with code and/or documentation to
this release.
Happy poking!
Mohammad-Reza Nabipoor
parallel @ Savannah: GNU Parallel 20240522 ('Tbilisi') released
GNU Parallel 20240522 ('Tbilisi') has been released. It is available for download at: lbry://@GnuParallel:4
Quote of the month:
GNU Parallel é mais um daqueles "como eu vivia sem isso?!"
-- Ivan Augusto @ivanaugustobd@twitter
New in this release:
- --onall now supports sshpass - user:pass@host.
- --memfree kills do not count as --retries.
- Bug fixes and man page updates.
GNU Parallel - For people who live life in the parallel lane.
If you like GNU Parallel record a video testimonial: Say who you are, what you use GNU Parallel for, how it helps you, and what you like most about it. Include a command that uses GNU Parallel if you feel like it.
About GNU Parallel
GNU Parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. The typical input is a list of files, a list of hosts, a list of users, a list of URLs, or a list of tables. A job can also be a command that reads from a pipe. GNU Parallel can then split the input and pipe it into commands in parallel.
If you use xargs and tee today you will find GNU Parallel very easy to use as GNU Parallel is written to have the same options as xargs. If you write loops in shell, you will find GNU Parallel may be able to replace most of the loops and make them run faster by running several jobs in parallel. GNU Parallel can even replace nested loops.
GNU Parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially. This makes it possible to use output from GNU Parallel as input for other programs.
For example you can run this to convert all jpeg files into png and gif files and have a progress bar:
parallel --bar convert {1} {1.}.{2} ::: *.jpg ::: png gif
Or you can generate big, medium, and small thumbnails of all jpeg files in sub dirs:
find . -name '*.jpg' |
parallel convert -geometry {2} {1} {1//}/thumb{2}_{1/} :::: - ::: 50 100 200
You can find more about GNU Parallel at: http://www.gnu.org/s/parallel/
You can install GNU Parallel in just 10 seconds with:
$ (wget -O - pi.dk/3 || lynx -source pi.dk/3 || curl pi.dk/3/ || \
fetch -o - http://pi.dk/3 ) > install.sh
$ sha1sum install.sh | grep 883c667e01eed62f975ad28b6d50e22a
12345678 883c667e 01eed62f 975ad28b 6d50e22a
$ md5sum install.sh | grep cc21b4c943fd03e93ae1ae49e28573c0
cc21b4c9 43fd03e9 3ae1ae49 e28573c0
$ sha512sum install.sh | grep ec113b49a54e705f86d51e784ebced224fdff3f52
79945d9d 250b42a4 2067bb00 99da012e c113b49a 54e705f8 6d51e784 ebced224
fdff3f52 ca588d64 e75f6033 61bd543f d631f592 2f87ceb2 ab034149 6df84a35
$ bash install.sh
Watch the intro video on http://www.youtube.com/playlist?list=PL284C9FF2488BC6D1
Walk through the tutorial (man parallel_tutorial). Your command line will love you for it.
When using programs that use GNU Parallel to process data for publication please cite:
O. Tange (2018): GNU Parallel 2018, March 2018, https://doi.org/10.5281/zenodo.1146014.
If you like GNU Parallel:
- Give a demo at your local user group/team/colleagues
- Post the intro videos on Reddit/Diaspora*/forums/blogs/ Identi.ca/Google+/Twitter/Facebook/Linkedin/mailing lists
- Get the merchandise https://gnuparallel.threadless.com/designs/gnu-parallel
- Request or write a review for your favourite blog or magazine
- Request or build a package for your favourite distribution (if it is not already there)
- Invite me for your next conference
If you use programs that use GNU Parallel for research:
- Please cite GNU Parallel in you publications (use --citation)
If GNU Parallel saves you money:
- (Have your company) donate to FSF https://my.fsf.org/donate/
About GNU SQL
GNU sql aims to give a simple, unified interface for accessing databases through all the different databases' command line clients. So far the focus has been on giving a common way to specify login information (protocol, username, password, hostname, and port number), size (database and table size), and running queries.
The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell.
When using GNU SQL for a publication please cite:
O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32.
About GNU Niceload
GNU niceload slows down a program when the computer load average (or other system activity) is above a certain limit. When the limit is reached the program will be suspended for some time. If the limit is a soft limit the program will be allowed to run for short amounts of time before being suspended again. If the limit is a hard limit the program will only be allowed to run when the system is below the limit.
Parabola GNU/Linux-libre: makepkg.conf change
Parabola's default makepkg.conf has long loaded /etc/makepkg.d/*.conf. As of makepkg 6.1.0, the program itself now loads /etc/makepkg.conf.d/*.conf, so this part of our makepkg.conf has been removed. Users who have /etc/makepkg.d/*.conf files need to move them to /etc/makepkg.conf.d/.
FSF Events: Free Software Directory meeting on IRC: Friday, May 24, starting at 12:00 EDT (16:00 UTC)
Join the FSF and friends on Friday, May 24, from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.
education @ Savannah: Schools in Italy Migrated to Free Software
New Addition to Education Case Studies - Italy
All Italian-Language Schools in South Tyrol Migrated to Free Software
libtool @ Savannah: libtool-2.5.0 released [alpha]
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.5.0, a alpha release.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.
There have been 91 commits by 29 people in the 113 weeks since 2.4.7.
See the NEWS below for a brief summary.
Thanks to everyone who has contributed!
The following people contributed changes to this release:
Albert Chu (1)
Alex Ameen (3)
Antonin Décimo (3)
Brad Smith (2)
Bruno Haible (2)
Dmitry Antipov (1)
Florian Weimer (1)
Gilles Gouaillardet (1)
Ileana Dumitrescu (24)
Jakub Wilk (1)
Jonathan Wakely (2)
Manoj Gupta (1)
Mike Frysinger (23)
Mingli Yu (2)
Oliver Kiddle (1)
Olly Betts (1)
Ozkan Sezer (2)
Paul Eggert (2)
Paul Green (1)
Raul E Rangel (1)
Richard Purdie (5)
Sam James (4)
Samuel Thibault (1)
Stephen Webb (1)
Tijl Coosemans (1)
Tim Rice (1)
Uwe Kleine-König (1)
Vadim Zeitlin (1)
Xiang.Lin (1)
Ileana
[on behalf of the libtool maintainers]
Here is the GNU libtool home page:
https://gnu.org/s/libtool/
For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=libtool.git;a=shortlog;h=v2.5.0
or run this command from a git-cloned libtool directory:
git shortlog v2.4.7..v2.5.0
Here are the compressed sources:
https://alpha.gnu.org/gnu/libtool/libtool-2.5.0.tar.gz (1.9MB)
https://alpha.gnu.org/gnu/libtool/libtool-2.5.0.tar.xz (1008KB)
Here are the GPG detached signatures:
https://alpha.gnu.org/gnu/libtool/libtool-2.5.0.tar.gz.sig
https://alpha.gnu.org/gnu/libtool/libtool-2.5.0.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
fb3ab5907115b16bf12a0d3d424c79cb0003d02e libtool-2.5.0.tar.gz
1DjDF0VdhVVM4vmYvkiGb9QM/L+DTWCzAm9PwO1YPSM= libtool-2.5.0.tar.gz
70e2dd113a9460c279df01b2eee319adb99ee998 libtool-2.5.0.tar.xz
fhDMhjgj1AjsX/6kHUPDckqgiBZldXljydsL77LIecw= libtool-2.5.0.tar.xz
Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.
Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify libtool-2.5.0.tar.gz.sig
The signature should match the fingerprint of the following key:
pub rsa4096 2021-09-23 [SC]
FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
uid Ileana Dumitrescu ileanadumi95@protonmail.com
uid Ileana Dumitrescu ileanadumitrescu95@gmail.com
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key ileanadumi95@protonmail.com
gpg --recv-keys 6570EA01146F7354
wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=libtool&download=1' | gpg --import -
As a last resort to find the key, you can try the official GNU
keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify libtool-2.5.0.tar.gz.sig
This release was bootstrapped with the following tools:
Autoconf 2.72e
Automake 1.16.5
Gnulib v0.1-6995-g29d705ead1
NEWS
- Noteworthy changes in release 2.5.0 (2024-05-13) [alpha]
** New features:
- Pass '-fdiagnostics-color', '-frecord-gcc-switches',
'-fno-sanitize*', '-Werror', and 'prefix-map' flags.
- Pass the '-no-canonical-prefixes' linker flag.
- Pass '-fopenmp=*' for Clang to allow choosing between libgomp and
libomp.
- Pass '-shared-libsan', '-static-libsan', 'rtlib=', and
'unwindlib=' for Clang.
- Expanded process.h inclusion on Windows for more than the
proprietary MSVC compiler. Other alternative Windows compilers
also require process.h.
- Pass 'elf32_x86_64' and 'elf64_x86_64' to the linker on hurd-amd64.
- Recognize - -windows* config triplets.
** Important incompatible changes:
- Removed test_compile from command line options.
- By default executables are created with the RUNPATH property for
the Android linker. RUNPATH works for libraries which are not
installed in system locations.
- Removed AC_PROG_SED fallback, as the macro has been supported
in Autoconf since the 90's.
** Bug fixes:
- Check for space after -l, -L, and -R linker flags.
- Updated documentation for tests, the demo directory, and
elsewhere.
- Fixed Solaris 11 builds.
- Clean trailing "/" from sysroot path.
- Fixed shared library builds for System V.
- Added mingw to the list of systems not requiring libm.
- Fixed support for nios2 systems.
- Fixed linker check for '--whole-archive' support for linkers other
than ld.
- Use -Fe instead of -o with MSVC to avoid deprecation warnings.
- Improved reproducibility of libtool scripts.
- Avoided MinGW warning by adding CRTIMP.
- Improved grep portability.
- Fixed cross-building warnings when checking for file.
** Changes in supported systems or compilers:
- Removed support for bitrig ( - -bitrig*).
- Added support for flang (Fortran LLVM-based) compilers.
Enjoy!
GNU Guix: Authenticate your Git checkouts!
You clone a Git repository, then pull from it. How can you tell its contents are “authentic”—i.e., coming from the “genuine” project you think you’re pulling from, written by the fine human beings you’ve been working with? With commit signatures and “verified” badges ✅ flourishing, you’d think this has long been solved—but nope!
Four years after Guix deployed its own tool to allow users to authenticate updates fetched with guix pull (which uses Git under the hood), the situation hasn’t changed all that much: the vast majority of developers using Git simply do not authenticate the code they pull. That’s pretty bad. It’s the modern-day equivalent of sharing unsigned tarballs and packages like we’d blissfully do in the past century.
The authentication mechanism Guix uses for channels is available to any Git user through the guix git authenticate command. This post is a guide for Git users who are not necessarily Guix users but are interested in using this command for their own repositories. Before looking into the command-line interface and how we improved it to make it more convenient, let’s dispel any misunderstandings or misconceptions.
Why you should care
When you run git pull, you’re fetching a bunch of commits from a server. If it’s over HTTPS, you’re authenticating the server itself, which is nice, but that does not tell you who the code actually comes from—the server might be compromised and an attacker pushed code to the repository. Not helpful. At all.
But hey, maybe you think you’re good because everyone on your project is signing commits and tags, and because you’re disciplined, you routinely run git log --show-signature and check those “Good signature” GPG messages. Maybe you even have those fancy “✅ verified” badges as found on GitLab and on GitHub.
Signing commits is part of the solution, but it’s not enough to authenticate a set of commits that you pull; all it shows is that, well, those commits are signed. Badges aren’t much better: the presence of a “verified” badge only shows that the commit is signed by the OpenPGP key currently registered for the corresponding GitLab/GitHub account. It’s another source of lock-in and makes the hosting platform a trusted third-party. Worse, there’s no notion of authorization (which keys are authorized), let alone tracking of the history of authorization changes (which keys were authorized at the time a given commit was made). Not helpful either.
Being able to ensure that when you run git pull, you’re getting code that genuinely comes from authorized developers of the project is basic security hygiene. Obviously it cannot protect against efforts to infiltrate a project to eventually get commit access and insert malicious code—the kind of multi-year plot that led to the xz backdoor—but if you don’t even protect against unauthorized commits, then all bets are off.
Authentication is something we naturally expect from apt update, pip, guix pull, and similar tools; why not treat git pull to the same standard?
Initial setup
The guix git authenticate command authenticates Git checkouts, unsurprisingly. It’s currently part of Guix because that’s where it was brought to life, but it can be used on any Git repository. This section focuses on how to use it; you can learn about the motivation, its design, and its implementation in the 2020 blog post, in the 2022 peer-reviewed academic paper entitled Building a Secure Software Supply Chain with GNU Guix, or in this 20mn presentation.
To support authentication of your repository with guix git authenticate, you need to follow these steps:
Enable commit signing on your repo:
git config commit.gpgSign true. (Git now supports other signing methods but here we need OpenPGP signatures.)Create a
keyringbranch containing all the OpenPGP keys of all the committers, along these lines:git checkout --orphan keyringgit reset --hard
gpg --export alice@example.org > alice.key
gpg --export bob@example.org > bob.key
…
git add *.key
git commit -m "Add committer keys."
All the files must end in .key. You must never remove keys from that branch: keys of users who left the project are necessary to authenticate past commits.
Back to the main branch, add a
.guix-authorizationsfile, listing the OpenPGP keys of authorized committers—we’ll get back to its format below.Commit! This becomes the introductory commit from which authentication can proceed. The introduction of your repository is the ID of this commit and the OpenPGP fingerprint of the key used to sign it.
That’s it. From now on, anyone who clones the repository can authenticate it. The first time, run:
guix git authenticate COMMIT SIGNER
… where COMMIT is the commit ID of the introductory commit, and SIGNER is the OpenPGP fingerprint of the key used to sign that commit (make sure to enclose it in double quotes if there are spaces!). As a repo maintainer, you must advertise this introductory commit ID and fingerprint on a web page or in a README file so others know what to pass to guix git authenticate.
The commit and signer are now recorded on the first run in .git/config; next time, you can run it without any arguments:
guix git authenticate
The other new feature is that the first time you run it, the command installs pre-push and pre-merge hooks (unless preexisting hooks are found) such that your repository is automatically authenticated from there on every time you run git pull or git push.
guix git authenticate exits with a non-zero code and an error message when it stumbles upon a commit that lacks a signature, that is signed by a key not in the keyring branch, or that is signed by a key not listed in .guix-authorizations.
Maintaining the list of authorized committers
The .guix-authorizations file in the repository is central: it lists the OpenPGP fingerprints of authorized committers. Any commit that is not signed by a key listed in the .guix-authorizations file of its parent commit(s) is considered inauthentic—and an error is reported. The format of .guix-authorizations is based on S-expressions and looks like this:
;; Example ‘.guix-authorizations’ file.
(authorizations
(version 0) ;current file format version
(("AD17 A21E F8AE D8F1 CC02 DBD9 F8AE D8F1 765C 61E3"
(name "alice"))
("2A39 3FFF 68F4 EF7A 3D29 12AF 68F4 EF7A 22FB B2D5"
(name "bob"))
("CABB A931 C0FF EEC6 900D 0CFB 090B 1199 3D9A EBB5"
(name "charlie"))))
The name bits are hints and do not have any effect; what matters is the fingerprints that are listed. You can obtain them with GnuPG by running commands like:
gpg --fingerprint charlie@example.org
At any time you can add or remove keys from .guix-authorizations and commit the changes; those changes take effect for child commits. For example, if we add Billie’s fingerprint to the file in commit A , then Billie becomes an authorized committer in descendants of commit A (we must make sure to add Billie’s key as a file in the keyring branch, too, as we saw above); Billie is still unauthorized in branches that lack A. If we remove Charlie’s key from the file in commit B , then Charlie is no longer an authorized committer, except in branches that start before B. This should feel rather natural.
That’s pretty much all you need to know to get started! Check the manual for more info.
All the information needed to authenticate the repository is contained in the repository itself—it does not depend on a forge or key server. That’s a good property to allow anyone to authenticate it, to ensure determinism and transparency, and to avoid lock-in.
Interested? You can help!
guix git authenticate is a great tool that you can start using today so you and fellow co-workers can be sure you’re getting the right code! It solves an important problem that, to my knowledge, hasn’t really been addressed by any other tool.
Maybe you’re interested but don’t feel like installing Guix “just” for this tool. Maybe you’re not into Scheme and Lisp and would rather use a tool written in your favorite language. Or maybe you think—and rightfully so—that such a tool ought to be part of Git proper.
That’s OK, we can talk! We’re open to discussing with folks who’d like to come up with alternative implementations—check out the articles mentioned above if you’d like to take that route. And we’re open to contributing to a standardization effort. Let’s get in touch!
Acknowledgments
Thanks to Florian Pelz and Simon Tournier for their insightful comments on an earlier draft of this post.
Gary Benson: git submodule forgetting
Did you forget the -r when cloning a git repo with submodules? The command you’re looking for is git submodule update --init
gnulib @ Savannah: GNU gnulib: gnulib-tool has become much faster
If you are developer on a package that uses GNU gnulib as part of its build system:
gnulib-tool has been known for being slow for many years. We have listened to your complaints. We have rewritten gnulib-tool in another programming language (Python). It is between 8 times and 100 times faster than the previous implementation.
Both implementations behave identically, that is, produce the same generated files and the same output. Nothing changes in your way to use Gnulib; it's only faster.
In order to reap the new speed:
1. Make sure you have Python (version 3.7 or newer) installed on your machine.
2. Update your gnulib checkout. (For some packages, it comes as a git submodule named 'gnulib'.) Like this:
$ git checkout master
$ git pull
Set the environment variable GNULIB_SRCDIR, pointing to this checkout.
If the package is using a git submodule named 'gnulib', it is also advisable to do
$ git commit -m 'build: Update gnulib submodule to latest.' gnulib
(as a preparation for step 4, because the --no-git option does not work as expected in all variants of 'bootstrap').
3. Clean the built files of your package:
$ make -k distclean
4. Regenerate the fetched and generated files of your package. Depending on the package, this may be a command such as
$ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
or
$ export GNULIB_SRCDIR; ./autopull.sh; ./autogen.sh
or, if no such script is available:
$ $GNULIB_SRCDIR/gnulib-tool --update
5. Continue with
$ ./configure
$ make
as usual.
Enjoy! The rewritten gnulib-tool was implemented by Dmitry Selyutin, Collin Funk, and me.