Pacman looking for database signature files

Support
1

I have a weird issue with pacman and database signatures.

The default pacman.conf reads (partially) - in fact I cannot remember it has been different

# By default, pacman accepts packages signed by keys that its local keyring
# trusts (see pacman-key and its man page), as well as unsigned packages.
SigLevel    = Optional DatabaseOptional
LocalFileSigLevel = Optional
#RemoteFileSigLevel = Required

In the repo there is no .db.sig file so the file cannot be downloaded from the mirror but for some time now I have been having issues like this

➜  sync sudo pacman -Syu 
:: Synchronizing package databases...
 core                                                                                                               165,8 KiB  54,0 MiB/s 00:00 [########################################################################################] 100%
 core.sig                                                                                                          1057,0   B  0,00   B/s 00:00 [########################################################################################] 100%
error: GPGME error: No data
error: failed to update core (invalid or corrupted database (PGP signature))

Clearing the sync folder and rerunning pacman -Syu gives the above errors and the sync folder is populated with db.sig files which has no correlation to pacage databases.

They all have the same size and the same timestamp?

On further investigation the sig files is the 404 html file send in response to the request for the non existing files

➜  ~ ls /var/lib/pacman/sync -l
total 9092
-rw-r--r-- 1 root root 6882304 28 feb 09:01 community.db
-rw-r--r-- 1 root root    1057 17 jan 11:22 community.db.sig
-rw-r--r-- 1 root root  169795 27 feb 23:52 core.db
-rw-r--r-- 1 root root    1057 17 jan 11:22 core.db.sig
-rw-r--r-- 1 root root 2045061 27 feb 23:52 extra.db
-rw-r--r-- 1 root root    1057 17 jan 11:22 extra.db.sig
-rw-r--r-- 1 root root  185670 27 feb 23:52 multilib.db
-rw-r--r-- 1 root root    1057 17 jan 11:22 multilib.db.sig

This problem can be made go away by setting the SigLevel to

SigLevel    = Optional DatabaseNever

That approach is a cure but not a solution.

  1. The issue is new and it appears on my pinephone as well as my various computers.
    My first record of the issue is Update archive corrupted - #7 by linux-aarhus from January 22
    There is a similar issue here Pacman -Syyu error: GPGME error: No data and failed to update due to invalid or corrupted database but apparently this could be solved by running an update using a different mirror?
  2. Why is there suddenly db.sig files in the sync folder - where there is usually none?
  3. In my mirror log I see frequent requests from clients using pacman/5.2.x and Pamac/10.x requesting the signature files but none exist - they are responded to as 404.
  4. When I build ISO the buildiso script fails because pacman fails when pulling databases and only by editing the buildiso versions of pacman.conf (/usr/share/manjaro-tools) I can successfully build ISO.

Partial content listing of the mirror’s unstable → core → x86_64 folder

➜  x86_64 ls -l core*
lrwxrwxrwx 1 root http      14 Jan  5  2020 core.db -> core.db.tar.gz
-rwxr-xr-x 1 root root  169791 Feb 28 14:04 core.db.tar.gz
lrwxrwxrwx 1 root http      17 Jan  5  2020 core.files -> core.files.tar.gz
-rwxr-xr-x 1 root root 1615995 Feb 28 14:04 core.files.tar.gz

This occurs both with pacman 6.0-alpha and pacman 5.2

➜  sync pacman --version

 .--.                  Pacman v5.2.2 - libalpm v12.0.2
/ _.-' .-.  .-.  .-.   Copyright (C) 2006-2020 Pacman Development Team
\  '-. '-'  '-'  '-'   Copyright (C) 2002-2006 Judd Vinet
 '--'
                       This program may be freely redistributed under
                       the terms of the GNU General Public License.

What is going on?

@Manjaro-Team

Is this by any chance connected to the change made in pacman 5.2 regarding delta packages which according to Allan McRae created security issue?

If it is - why is it only surfacing after more than a year?

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. - Pacman 5.2 Release | Allan McRae

I think I will take a look at my mirror script - see if something hides there.

Nope - nothing there - if the db.sig files exist the primary mirror is not providing them.

rsync -rtlvH --safe-links \
    --bwlimit=${BWLIMIT} \
    --delete-after --progress \
    -h ${QUIET} --timeout=300 --contimeout=120 -p \
    --delay-updates --no-motd \
    --temp-dir="${TMP}" \
    ${SOURCE} \
    "${TARGET}"

This leads back to the questions

  • why has pacman begun to create .db.sig files?
  • why it is requesting sig files from the mirror?

Partial mirror log

...

2021/02/28 14:12:45 [error] 609#609: *909 open() "xxxx/manjaro/stable/multilib/x86_64/multilib.files.sig" failed (2: No such file or directory), client: 93.185.26.xx, server: uex.dk, request: "GET /xxxx/manjaro/stable/multilib/x86_64/multilib.files.sig HTTP/1.1", host: "www.uex.dk"
2021/02/28 14:12:50 [error] 609#609: *922 open() "xxxx/manjaro/stable/extra/x86_64/extra.db.sig" failed (2: No such file or directory), client: 98.128.181.xx, server: uex.dk, request: "GET /xxxx/manjaro/stable/extra/x86_64/extra.db.sig HTTP/1.1", host: "www.uex.dk"
2021/02/28 14:12:50 [error] 609#609: *922 open() "xxxx/manjaro/stable/multilib/x86_64/multilib.db.sig" failed (2: No such file or directory), client: 98.128.181.xx, server: uex.dk, request: "GET /xxxx/manjaro/stable/multilib/x86_64/multilib.db.sig HTTP/1.1", host: "www.uex.dk"
2021/02/28 14:12:55 [error] 609#609: *926 open() "xxxx/manjaro/arm-unstable/core/aarch64/core.db.sig" failed (2: No such file or directory), client: 94.31.84.xx, server: uex.dk, request: "GET /xxxx/manjaro/arm-unstable/core/aarch64/core.db.sig HTTP/1.1", host: "www.uex.dk"

...

2021/02/28 14:13:19 [error] 609#609: *936 open() "xxxx/manjaro/stable/extra/x86_64/extra.db.sig" failed (2: No such file or directory), client: 98.128.181.xx, server: uex.dk, request: "GET /xxxx/manjaro/stable/extra/x86_64/extra.db.sig HTTP/1.1", host: "www.uex.dk"
2021/02/28 14:13:19 [error] 609#609: *936 open() "xxxx/manjaro/stable/multilib/x86_64/multilib.db.sig" failed (2: No such file or directory), client: 98.128.181.xx, server: uex.dk, request: "GET /xxxx/manjaro/stable/multilib/x86_64/multilib.db.sig HTTP/1.1", host: "www.uex.dk"
2021/02/28 14:13:24 [error] 609#609: *927 open() "xxxx/manjaro/stable/community/x86_64/community.db.sig" failed (2: No such file or directory), client: 82.203.162.xx, server: uex.dk, request: "GET /xxxx/manjaro/stable/community/x86_64/community.db.sig HTTP/1.1", host: "www.uex.dk"
2021/02/28 14:13:25 [error] 609#609: *927 open() "xxxx/manjaro/stable/multilib/x86_64/multilib.db.sig" failed (2: No such file or directory), client: 82.203.162.xx, server: uex.dk, request: "GET /xxxx/manjaro/stable/multilib/x86_64/multilib.db.sig HTTP/1.1", host: "www.uex.dk"
2021/02/28 14:13:28 [error] 609#609: *938 open() "xxxx/manjaro/stable/extra/x86_64/extra.db.sig" failed (2: No such file or directory), client: 98.128.181.xx, server: uex.dk, request: "GET /xxxx/manjaro/stable/extra/x86_64/extra.db.sig HTTP/1.1", host: "www.uex.dk"
2021/02/28 14:13:28 [error] 609#609: *938 open() "xxxx/manjaro/stable/multilib/x86_64/multilib.db.sig" failed (2: No such file or directory), client: 98.128.181.xx, server: uex.dk, request: "GET /xxxx/manjaro/stable/multilib/x86_64/multilib.db.sig HTTP/1.1", host: "www.uex.dk"
...
2 Likes
2

So I think I have found the culprit.

After more digging and then again some - I have found that pacman or libalpm is not using the response code from the server - but is looking in the response text - which for my mirror - using a custom error page - was not containing the word 404 as I have setup the system to expose as little about itself as possible. As soon as I added the word 404 to the html - pacman stopped bugging me.

That appeared strange at first but - rethinking pacman.,conf it occurred to me - pacman does not do the fetching work but is ‘outsourcing’ the request to curl or wget or ftp - or what is defined in pacman.conf.

So my mirror trouble was fixed by adding the word 404 to the actual 404 response and I learned something new about hosting a Manjaro mirror.

1 Like
3

Interesting. Not that this was the issue, but I’m curious about the “default pacman.conf”. If I look at my system it shows: SigLevel = Required DatabaseOptional which is the same as Files · master · Packages / Core / pacman · GitLab. I see you mentioned that further in your post.

4

That is correct - I see that I have experimented more than I remember. I recall now the default is in fact as you quote

5

I got this all wrong and the issue is back to haunt me.

On FS#44445 : "GPGME error: No data" if no SigLevel DatabaseNever + no *.db.sig files quote

I got that tip from https://bbs.archlinux.org/viewtopic.php?id=133711

| “falconindy” (http://blog.falconindy.com/), Date: 2012-01-17
|
| Re: [Solved] Pacman 4 Looking for .db.sig files which aren’t there?
|
| I can only recommend using the internal downloader.
| “Optional” extends to “DatabaseOptional” which means your downloader will
| attempt to grab the sig file.
| You’ll need to add in DatabaseNever to your SigLevel if you want to avoid
| this behavior with an external downloader.

I am not using any external downloader so what is it with pacman and my mirror setup?

When I remove the customized and anonymized error response pacman works as expected - the server sends the response (404) and all is good.

But as soon as I activate the customized error response file - pacman fetches the .db.sig file - which of course is not a signatere but the 404.html response - which gets saved as .db.sig - and pacman complains on the non valid signature - which is the expected result when the signature doesn’t match.

Now I am speculating if this is really a pacman issue as I have found it is how nginx responds when a custom error file has been configured.

Nginx no longer sends the expected 404 - instead it sends a 200 with the html and this makes pacman reject the package database as the fetched signature file is not a signature but html.

And of course this affects not only me but all users which happens to have uex.dk as the primary mirror.

Now I have removed the custom error message and the server exposes that it is in fact powered by nginx - but for the time being it have to be so.

I will raise the issue with Nginx developers - maybe a config exist I have not found.

1 Like
6

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.