Pacman 5.2 Release

Nothing like a new pacman release to make me locate the password to this site…

Tradition dictates I thank people who have contributed to the release (as well as genuinely meaning the thanks!). We had 29 people have a patch committed this release, with a few new names. Here is the top ten:

$ git shortlog -n -s v5.1.0..v5.2.0 | head -n10
   108  Eli Schwartz
    38  Allan McRae
    30  morganamilo
    24  Andrew Gregory
    20  Dave Reisner
     9  Jan Steffens
     6  Michael Straube
     4  Jonas Witschel
     4  Luke Shumaker
     3  Que Quotion

We have a clear winner. Although I’m sure that at least half of those are in responses to bugs he created! He claims it is a much smaller proportion… And a new contributor in third.

What has changed in this release? Nothing super exciting as far as I’m concerned, but check out the detailed list here.

We have completely removed support for delta packages. This was a massively underused feature, usually made updates slower for a slight saving on bandwidth, and had a massive security hole. Essentially, a malicious package database in combination with delta packages could run arbitrary commands on your system. This would be less of an issue if a certain Linux distro signed their package databases… Anyway, on balance I judged it better to remove this feature altogether. We may come back to this in the future with a different implementation, but I would not expect that any time soon. Note a similar vulnerability was found with using XferCommand to download packages, but we plugged that hole instead of removing it!

Support for downloading PGP keys using the new Web Key Directory (WKD) was added to pacman. Both pacman-key and makepkg will also look there by default with the latest GnuPG release. This prevents DoS attacks through people adding very large numbers of signatures to PGP keys. The attack scope was limited for Arch Linux anyway, as most people obtain the pacman keyring through the archlinux-keyring package.

The much maligned --force made its way to /dev/null. The --overwrite option has been a replacement for over a year and is a precision surgical instrument compared to the blunt hammer of --force.

There is a small user interface change for searching files databases with -F. Specifying the -s option was redundant, so removed. More information such as package group and installed status is shown in the search results, bringing the output inline with -Ss.

The split of makepkg into smaller and extendable components continued. You can now provide new source download and signature verification routines (e.g. if you are living in the past and want to support cvs:// style URLs). We also added support for lzip, lz4 and zst compressed packages. Arch Linux will switch zst by default in the near future.

Under the hood, we are in the process of changing our build system from autotools to meson. This is relatively complete, but there still was a decent churn of patches to meson files as we approached release. You can build pacman from the release tarball using meson if you want to test. Next release is likely to be meson only. (Edit: you can’t test meson with the 5.2.0 tarball as it is missing a couple of the meson build files.)

Expect the release to land in Arch Linux “soon”. Expect to see another blog post in a year or so when I make the next release…

6 thoughts on “Pacman 5.2 Release

  1. “We have completely removed support for delta packages. This was a massively underused feature, usually made updates slower for a slight saving on bandwidth, and had a massive security hole. Essentially, a malicious package database in combination with delta packages could run arbitrary commands on your system. This would be less of an issue if a certain Linux distro signed their package databases…”

    Since when Arch devs care about distributions other than Arch Linux?

  2. Long time no see. Glad that you are still updating this blog.

    ” This was a massively underused feature, usually made updates slower for a slight saving on bandwidth”

    How small is that “slight saving” typically?

    • Depends… in my experience, most updates were ~10-20% smaller. But if you updated regularly, you could get more savings.

  3. I just read the complete field of the reason to switch to an ‘entreprise’ compression tools(zstd : https://lists.archlinux.org/pipermail/arch-dev-public/2019-March/029520.html.)
    I will past the fact that you not consider to use an ‘entreprise’ projects on a Open Source projects as a problem. You can argue that zstd is an Open Source which clearly not an argue but well this is depends of your point of view (Arch will loose a lot of ‘good’ and ‘active’ user for this choice for sure).
    The worse it’s that all Arch dev (except you apparently) do not want to let the time to past to the new format. Yes, user on Arch should have the new libarchive installed for a while, but what about spin off which use a lot of scripts? Whose care about that? Nobody.
    And again Arch Dev broke everything without giving attention to his child.
    Spin off give visibility to Arch,Arch Dev should consider this fact…

    • I doubt many users will leave over switching to ztsd. With a combined BSD + GPL2 license, I doubt many would consider it not open source. And users will notice the smaller download size and faster extraction. If they do leave, Arch devs don’t care.

      And spin-offs are not supported by Arch, so you are correct that nobody cares about them. But they have had half a year notice that we will switch if they followed arch-dev-public (which they should…). Also, we switched from .gz to .xz in the past and everyone survived.