dpkg

~ubuntu-support-team/dpkg/+git/dpkg:stretch

  1. Git
  2. lp:~ubuntu-support-team/dpkg/+git/dpkg
  3. stretch
Last commit made on 2022-05-24
Get this branch:
git clone -b stretch https://git.launchpad.net/~ubuntu-support-team/dpkg/+git/dpkg

Branch merges

Branch information

Name:
stretch
Repository:
lp:~ubuntu-support-team/dpkg/+git/dpkg

Recent commits

e195a9f... by Guillem Jover <email address hidden>

Release 1.18.26

0b9b099... by Guillem Jover <email address hidden>

po: Regenerate .pot files and merge .po files with them

b974d0e... by Guillem Jover <email address hidden>

Dpkg::Gettext: Document textdomain() and ngettext() replacement functions

We should mention when these functions are present and what they do,
so that users know when they can rely on these.

Warned-by: Test::Pod::Coverage
(cherry picked from commit 1d0be95366c19fbc88c891dbedf7613aedbbdea5)

faa4c92... by Guillem Jover <email address hidden>

Dpkg::Source::Archive: Prevent directory traversal for in-place extracts

For untrusted v2 and v3 source package formats that include a debian.tar
archive, when we are extracting it, we do that as an in-place extraction,
which can lead to directory traversal situations on specially crafted
orig.tar and debian.tar tarballs.

GNU tar replaces entries on the filesystem by the entries present on
the tarball, but it will follow symlinks when the symlink pathname
itself is not present as an actual directory on the tarball.

This means we can create an orig.tar where there's a symlink pointing
out of the source tree root directory, and then a debian.tar that
contains an entry within that symlink as if it was a directory, without
a directory entry for the symlink pathname itself, which will be
extracted following the symlink outside the source tree root.

This is currently noted as expected in GNU tar documentation. But even
if there was a new extraction mode avoiding this problem we'd need such
new version. Using perl's Archive::Tar would solve the problem, but
switching to such different pure perl implementation, could cause
compatibility or performance issues.

What we do is when we are requested to perform an in-place extract, we
instead still use a temporary directory, then walk that directory and
remove any matching entry in the destination directory, replicating what
GNU tar would do, but in addition avoiding the directory traversal issue
for symlinks. Which should work with any tar implementation and be safe.

Reported-by: Max Justicz <email address hidden>
Stable-Candidates: 1.18.x 1.19.x 1.20.x
Fixes: commit 0c0057a27fecccab77d2b3cffa9a7d172846f0b4 (1.14.17)
Fixes: CVE-2022-1664
(cherry picked from commit 7a6c03cb34d4a09f35df2f10779cbf1b70a5200b)

bb73779... by Guillem Jover <email address hidden>

Bump version to 1.18.26

2270497... by Helge Kreutzmann <email address hidden>

Proofreading on debian-l10n-german

a722cc6... by Helge Kreutzmann <email address hidden>

Further fix as discussed in #931135

and in the follow up on debian-l10n-german

ca82873... by Helge Kreutzmann <email address hidden>

Fix German man page translation of canary

b08068d... by Guillem Jover <email address hidden>

Release 1.18.25

eb870c7... by Guillem Jover <email address hidden>

po: Update translations from master branch