Release 1.20.13

This is based on the LoongArch 64-bit little-endian hard-float ISA.

Closes: #1023486
Based-on-patch-by: 张丹丹 <zhangdandan@loongson.cn>
(cherry picked from commit 321e479b)

The function uses an intermediary varbuf to construct the string to then
pass to parseversion() to parse which then uses the non-freeing
allocator for any string it needs to preserve. We need to free that
intermediate varbuf otherwise we leak it.

Warned-by: gcc ASAN
Stable-Candidate: 1.20.x 1.21.x
(cherry picked from commit 740b5c88)

When dealing with virtual packages (such as the ones from Provides, or
for not-installed Recommends or Suggests), there might be no version
field at all, so we cannot assume we can use these when filling in the
version information in the fallback code handling the missing Source
field.

The commit that removed the check for not-installed packages missed that
this instance had not been protected, as the code in varbufversion() is
doing the correct thing, but unfortunately we are not using that because
we need to get at the upstream part, so we need to also check explicitly
for a non-NULL upstream part. This was causing a segfault.

Fixes: commit 560574b5
Stable-Candidates: 1.20.x 1.21.x
Reported-by: John Scott <jscott@posteo.net>
(cherry picked from commit 2c4814f7)

(cherry picked from commit d9f603f1)

This will allow testing the formatting code.

(cherry picked from commit cee8e4b5)

Sync with bullseye

See merge request !5

This was causing the po4a to concatenate a «=back» after the text, which
pod2man was unable to parse correctly with the following error:

  IO::File=IO(0x55d0015a00d0) around line 203: You forgot a '=back' before '=head1'
  POD document had syntax errors at /usr/bin/pod2man line 69.

For setups with completely untracked kernel and modules, we need to add
also /lib/modules to the list of pathnames that need to be copied over,
otherwise its contents will not find a directory to copy to.

Closes: #1008764
(cherry picked from commit f9bf9b37)

Kernel module files are required as part of the system boot, so we need
to make sure any such files gets moved or the system might end up not
being able to boot, once the initramfs images get regenerated.

In particular, kernel module files are easily found on systems as
untracked pathnames in the filesystem, either from custom built kernels,
or as part of modules built via machinery such as DKMS.

One complication is that there appears to be some documentation
referencing /usr/lib/modules/ pathnames for at least apache, python and
ruby module locations. Which we do not want to be moving.

To limit these unknowns, and as we are dealing with untracked pathnames,
we will restrict moving subdirectories that start with a digit, which
matches Linux and kFreeBSD module locations, in addition to the
modprobe.conf filename.

Closes: #1008316
(cherry picked from commit 48e33c40)
(cherry picked from commit b1898b81)

Even though we should already be explicitly setting user/group and mode
for created directories, we should in addition set a known umask we can
rely on, at least for defensive purposes.

Ref: #1008478
(cherry picked from commit b29c959c)

We should explicitly set the user/group and mode for the newly created
directories, to make sure they end up with the expected values, instead
of assuming a good environment (umask and user/group). We will still be
setting a known umask in a subsequent commit as a defensive measure.

Closes: #1008478
(cherry picked from commit 77756084)

Stable-Candidate: 1.20.x
(cherry picked from commit c7e2c93c)

These directories might contain untracked files, if they are not empty,
failing the whole script will be worse. Keep track of them, and print a
summary at the end of the run.

Stable-Candidate: 1.20.x
(cherry picked from commit cf55e9f0)
(cherry picked from commit 2165119f)

When in systemd emergency mode, starting (including restarting) services
will force exiting the emergency mode, which can leave the system in a
pretty bad state. Part of the reason for reconfiguring all packages is
to both force any regeneration of missing files, and ideally to possibly
restart services so that they use the new real pathnames, but restarting
services is the most fragile part and with the most potential to fail
for whatever reason, so we will skip restarting services entirely. A
reboot after the conversion is strongly advised.

Closes: #991190
Stable-Candidate: 1.20.x
(cherry picked from commit a335ee07)
(cherry picked from commit 2165119f)

Reconfiguring packages has the most potential for unaccounted breakage,
it is also the step that will take longer, and it should be the one
easier to recover from, by calling «dpkg --pending --configure» at a
later time. Move it at the end when we have done the reparation, and
performed the cleanup.

Ref: #991190
Stable-Candidate: 1.20.x
(cherry picked from commit 66a9a358)

Fixes: commit 20e181fc
Warned-by: coverity
Stable-Candidate: 1.20.x
(cherry picked from commit 29f3a8da)

We need to check for file conflicts during conffile removal, otherwise
we might end up removing files from any other packages that has started
owning them since we targeted the pathname for removal.

We remove the conffiles during upgrade, as configure is a local
action that does not load all file lists files, so we cannot check for
file conflicts.

Closes: #995387
Stable-Candidate: 1.20.x
(cherry picked from commit 20e181fc)

Since binutils 2.26 (commit bb4d2ac2cc637c61232624d9d359b8d3f031e3e9)
versioned symbols in copy relocations are output as «symbol@@version»
when they are in an undefined section (otherwise they use «@»). We were
not taking this into account which meant these did not match and did not
get marked as undefined, and got ignored for symbol dependency
calculation.

Try both the version qualified symbol and the bare symbol name to cope
with old and new formats.

Known to be affected are at least any-amd64, hppa and m68k architectures.

Closes: #1000421
(cherry picked from commit ecbd9f1b)

This is based on the ARCv2 32-bit little-endian hard-float ISA.

Closes: #980963
Based-on-patch-by: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
(cherry picked from commit 0d134cdc)

The change to fix the directory traversal for source package unpacks
with in-place extractions of the debian.tar archive modified the way
that last extraction was done, to extract it also out-of-place, then
move the result into the destination. This had the consequence of
no longer fixing the permissions for the entire source tree, and instead
only for the debian/ directory. The previous calls for the orig tarballs
were not fixing up the permissions to avoid duplicating work, which
meant that now these did not get fixed any longer.

Remove the options that avoid fixing the permissions for all calls,
restoring the previous behavior.

Fixes: commit 7a6c03cb
Closes: #1012195
Stable-Candidates: 1.18.x 1.19.x 1.20.x
(cherry picked from commit 52d285fe)

Initially the code was not handling missing data properly. It got changed
in two ways, in commit 536a3858 it was
first restricted to only operate on installed packages, which regressed
support for dpkg-deb show format, and then the code was made robust
against such missing data (which was really the only correct and necessary
part to the fix) in commit 9022f9e0.

Fixes: commit 536a3858
Closes: #1004372
Stable-Candidate: 1.20.x
(cherry picked from commit 560574b5)

When the read_line() function finds an unexpected end of file, it
returns 0, but the call site was not catching that, which let further
processing of the buffer, containing garbage.

Warned-by: coverity
Stable-Candidate: 1.20.x
(cherry picked from commit d9679e94)

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 <max@justi.cz>
Stable-Candidates: 1.18.x 1.19.x 1.20.x
Fixes: commit 0c0057a2 (1.14.17)
Fixes: CVE-2022-1664
(cherry picked from commit 7a6c03cb)

[guillem@debian.org: Fix typos in markup syntax. ]

Closes: #1007116
Signed-off-by: Guillem Jover <guillem@debian.org>