GitLab

Prevents build warning.
Signed-off-by: Allan McRae <allan@archlinux.org>

--dbonly is meant to only touch the database and not the actual system.
However hooks still run which can leave files in place or run commands
you may not want.

The hooks being run also means `fakeroot pacman -S --dbpath test/ foo --dbonly`
fails because alpm tries to chroot for hooks which requires real root.
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>

When constructing an import question we never really used a proper gpg
key. We just zero initialize the key, set the uid and fingerprint, and
sent that to the front end.

Instead lets just give the import question a uid and fingerprint field.
Signed-off-by: Allan McRae <allan@archlinux.org>

The docs [1] say keyid will always be there, so no need to check if it
exists.

[1] https://www.gnupg.org/documentation/manuals/gpgme/Key-objects.html

Signed-off-by: Allan McRae <allan@archlinux.org>

__foo is reserved in c and should not be used.
Signed-off-by: Allan McRae <allan@archlinux.org>

this type is only used internally by alpm
Signed-off-by: Allan McRae <allan@archlinux.org>

Pacman now downloads the signature files for all packages when present in a
repository.  That makes distributing signatures within repository databases
redundant and costly.

Do not distribute the package signature files within the repo databases by
default and add an --include-sigs to revert to the old behaviour.
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>

Every time we modify gpg's state by signing or revoking a key, gpg
marks the trustdb as stale and rechecks it the next time key_is_lsigned()
or key_is_revoked() is called.

Currently, we alternate calls signing of keys and calling key_is_lsigned()
(idem for revoking) which means that for each key we sign (or revoke), gpg
will check the trustdb once.

To avoid checking the trustb so many times, we can simply do all the
key_is_lsigned() and key_is_revoked() checks upfront. Inbetween read
operations the trustdb is not marked stale and inbetween write operations
the trustdb is also not marked stale. This reduces the amount of trustdb
checks from 50 to 1.
Signed-off-by: Allan McRae <allan@archlinux.org>

Currently, when running pacman-key --populate, gpg prints the
trustdb check output once for each locally signed and revoked key.
When bootstrapping a new container image, about 50 keys get signed
and revoked which leads to a huge amount of output when running
pacman-key which is repeated 50x.

To avoid overloading the user with gpg output, we add --quiet to the gpg
calls generating the trustdb checking output to silence those calls which
gets rid of the trustdb check output on the terminal.
Signed-off-by: Daan De Meyer <daan.j.demeyer@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io>
Signed-off-by: Allan McRae <allan@archlinux.org>

All of these links are broken since the recent move to
gitlab.archlinux.org.

A few projects are, apparently, only available on GitHub, so I've linked
to that source (hopefully that's only temporary).

For git-clone URLs, I've opted for the https URLs since those can be
used by anyone -- whereas the ssh URLs require the user to be registered
on the gitlab instance which is not open to the public yet.
Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io>
Signed-off-by: Allan McRae <allan@archlinux.org>

When downloading in parallel, sort by package size so that the larger
packages are queued first to fully leverage parallelism.
Addresses FS#70172
Signed-off-by: Charlie Sale <softwaresale01@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>

Test for downloads that redirect to some sort of cdn where the
redirected url does not relate to the original filename.
Signed-off-by: Allan McRae <allan@archlinux.org>

Github and other sites redirect their downloads to a cdn. So the
download http://foo.org/myrepo.db may redirect to something like
https://cdn.foo.org/83749327439.

This then causes pacman to try and download the sig as
https://cdn.foo.org/83749327439.sig which is incorrect. In this case
pacman should append .sig to the original url.

However urls like https://archlinux.org/packages/community/x86_64/0ad/download/
Redirect to the mirror, so .sig has to appended after the redirects and
not before.

So we decide if we should append .sig on the original or effective url
based on if the effective url (minus the query part) has .db or .pkg in it.

Fixes FS#71148

---

v2: move variable decleration to start of block
v3: use dbext instead of db

archweb's download links all ended in /download. This cause all the temp
files to be named download.part. With parallel downloads this results in
multiple downloads to go to the same temp file and breaks the transaction.

Assign random temporary filenames to downloads from URLs that are either
missing a filename, or if the filename does not contain at least three
hyphens (as a well formed package filename does).

While this approach to determining when to use a temporary filename is
not 100% foolproof, it does keep nice looking download progress bar names
when a proper package filename is given. The only downside of not using
temporary files when provided with a filename  with three or more hyphens
is URLs created specifically to bypass temporary filename usage can not
be downloaded in parallel. We probably do not want to download packages
from such URLs anyway.

Fixes FS#71464

Modified-by: Allan McRae (do not use temporary files for realish URLs)
...

Arch Linux has been setting PYTHONHASHSEED=0 to create deterministic
.pyc files.  After a thorough review by the Arch Security Team, setting
this variable was determined not to generated vulnerable .pyc files, as
when the loader loads the .pyc file and unmarshalls it, the internal
runtime will just populate the unordered data structures and use a new
runtime hash for them.
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>

We usually set this up to default to the build time configured install
location, but a couple of files crept in without this.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: André Schröder <andre.schroedr@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>

Binutils commit 93df3340fd5ad32f784214fc125de71811da72ff enabled readelf
to report "Position-Independent Executable" files.  Fix stripping to
account for this change.
Signed-off-by: Allan McRae <allan@archlinux.org>

pacman_date is set to the current date during build without respecting
SOURCE_DATE_EPOCH. As a result, a build cannot be fully reproduced on a later
date because the date embedded into the man pages does not match.

In contrast, the built-in asciidoc attribute "localdate" respects
SOURCE_DATE_EPOCH and has the desired ISO 8601 format, so simply use that
instead of the custom "pacman_date" attribute.

Fixes: FS#71154

Signed-off-by: Jonas Witschel <diabonas at archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>

If the original download redirects to to a different url then alpm would
try to name the sig file after the url instead of <original_file>.sig.
Instead force this naming scheme regardless of url.

Fixes FS#71274
Signed-off-by: Allan McRae <allan@archlinux.org>

Since commit 08f4ae70

, makepkg supports downloading from fossil.
However, the PKGBUILD man page was only partially updated to reflect
this change.
Signed-off-by: Allan McRae <allan@archlinux.org>

Comit 5151de30

 tried to fix leaking memory when importing a key. However
key_search_keyserver() writes to the key passed in, making the original
uid and fingerprint unreachable, causing the new uid and fingerprint to
double free.

Fixes FS#71107
Signed-off-by: Allan McRae <allan@archlinux.org>

Around the same time retry events were added, there was a patch to pass
sig download events to the frontend. The retry code was not updated to
account for this.
Signed-off-by: morganamilo <morganamilo@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: morganamilo <morganamilo@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>

Some servers respond with error pages (e.g. 404.html) when a package is
not present. These were getting written to packages before moving onto
the next server. Reset the download progress on 400+ error conditions
to avoid this.
Signed-off-by: Allan McRae <allan@archlinux.org>

This can not be specified on its own but requires a value.
Signed-off-by: Christian Hesse <mail@eworm.de>
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>

readelf --debug-dump sometimes reports inscrutable warnings which don't
actually affect our extraction of source filenames. For example:

readelf: Warning: There is a hole [0xd3d - 0xd89] in .debug_loc section.

Now gcc 11 seems to have dramatically increased the number of warnings:

readelf: Warning: Corrupt offset (0x0000008e) in range entry 9
[...]
readelf: Warning: Corrupt offset (0x000010f0) in range entry 250

The resulting debuginfo created by the very same toolchain works fine,
as does the list of source filenames. But the warnings are quite
noisy... send them to /dev/null since they are not actionable in the
context of getting source files
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>

Signed-off-by: Allan McRae <allan@archlinux.org>