Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] Problems with pacman signatures (Read 3218 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

[SOLVED] Problems with pacman signatures

Hello. Recently my X200's hdd died so I had to reinstall Artix after replacing it with an SSD. It had been some time since I last installed Artix, but I hadn't come up with any major problems before.

This time, however, I had a lot of problems with packages signatures. After basestrap'ing the system and trying to install the packages that I needed, I got a lot of packages with "marginal signature" errors. I was using a somewhat old base-runit iso, so first I tried refreshing the mirrorlists and after that refreshing the keyring by removing /etc/pacman.d/gnupg and reinitializing it (pacman-key --init, pacman-key --populate archlinux artix, etc.) but I got the exact same problems. So I thought I would try just downloading the latest base-runit iso on the site and starting from scratch, but I just got the exact same erros with the exact same packages.

After all that I just said f' it and just rsync'ed over the /etc/pacman.d/gnupg directory from my functioning desktop to my X200 in the process of installation. That helped a bit, but I noticed that there are still some keys that are "marginal" that are being used to sign packages. More precisely the "Morten Linderud <[email protected]>" key. In the end I just wanted a working system so I just "pacman-key --lsign-key"'d that key and I was finally able to install the packages I needed.

Now, my question(s) is/are, why might I be having so many problems with "marginal" PGP keys used to sign packages? Is anybody else having the same problems as me? Could it be related to the fact that for some reason the current gnupg version on Artix's repositories is a development version?

Loving the great work on Artix, btw. Such a shame that most Linux distros are infected by the soystemd virus.

Re: Problems with pacman signatures

Reply #1 –
there are no problems,  only you have some wrong configured on your side.

https://wiki.archlinux.org/title/Pacman/Package_signing works very well. . .
i have the gnupg 2.3.1 installed too, and i noticed no problem with nothing. and i sign a lot packages every day...

it will be good nextime just put the output with errors here, or a picture with your problem, which say us more as 100 words.  and use new iso, not "somewhat old base-runit iso,"  which is probably source of your problems.... seems that archlinux changed some signatures of his devs... [email protected] don't sounds as artix developer

Re: Problems with pacman signatures

Reply #2 –
I only had problems with signatures when running Artix in QEMU as a tool to chroot KISS Linux into existence as a guest system. Even then, there is a working solution which can be found by web search and applied by basic knowledge of pacman, gpg and <insert favorite editor>. On a real hardware I never had any problems with installing Artix. It is pretty much mandatory to run pacman -Syyu as the very first thing when you boot after installation, which assumes a working Internet connection, though.

Re: Problems with pacman signatures

Reply #3 –
Quote from: alium – on
there are no problems,  only you have some wrong configured on your side.

https://wiki.archlinux.org/title/Pacman/Package_signing works very well. . .
i have the gnupg 2.3.1 installed too, and i noticed no problem with nothing. and i sign a lot packages every day...

it will be good nextime just put the output with errors here, or a picture with your problem, which say us more as 100 words.  and use new iso, not "somewhat old base-runit iso,"  which is probably source of your problems.... seems that archlinux changed some signatures of his devs... [email protected] don't sounds as artix developer

If you would have read my post carefully, you would have known that I actually used the latest iso in my last attempt at installing from scratch. I didn't change any configs before attempting to install packages. I literally ran basestrap, then chrooted, updated pacman's database, tried to install a bunch of different packages and got the "marginal trust" signature error on different packages. To be fair the errors were keys from Arch's keyring and not  Artix's. My "side" is literally the latest vanilla "base-runit" iso from the official artixlinux.org website.

Also, I tried everything in the Arch Wiki article you linked, which I also mentioned trying on my first post. As I said, I also hadn't had any problems installing before, but this time I got a bunch of "marginal trust" signature errors. In the end I "solved" it just by manually signing the offending keys to full trust. I still am curious if anybody who has installed Artix recently has gone through the same troubles.

Re: Problems with pacman signatures

Reply #4 –
Seems strange. The last time Arch updated their keyring was this January. So if there really are some problems with some of their signatures, I'd expect it to also occur on the Arch iso.
 

Re: Problems with pacman signatures

Reply #5 –
please do pacman -Sy gnupg and you can see, if propblems persist or not

Re: Problems with pacman signatures

Reply #6 –
EDIT: As I composed this message, alium posted:

Quote from: alium – on
please do pacman -Sy gnupg and you can see, if propblems persist or not

This solves the issue for me: I have installed fzf and remmina.

I'll leave my post here. Mods may delete it if they don't want it, or instruct me to do so.

____________________________

I have a similar problem. Perhaps the same. I too have seen "Morten Linderud".

I've set up a new Artix machine using artix-base-runit-20210426-x86_64.iso. I've done pacman -Syu and I installed the packages I use. With two exceptions: fzf and remmina. Here's me trying to install fzf:

Code: [Select]
[ax alp]# pacman -S fzf
resolving dependencies...
looking for conflicting packages...

Packages (1) fzf-0.27.0-1

Total Installed Size:  3.10 MiB

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                     [#########] 100%
(1/1) checking package integrity                   [#########] 100%
error: fzf: signature from "Morten Linderud <[email protected]>" is marginal trust
:: File /var/cache/pacman/pkg/fzf-0.27.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

I have another computer which I had set up a while ago using artix-base-runit-20210101-x86_64.iso. I am able to install fzf and remmina on that machine. So I thought, maybe the packages really are corrupt. But ls /var/cache/pacman/pkg/{fzf*27*,remmina*} | xargs sha512sum produces the same signatures.

I've tried the steps on https://forum.artixlinux.org/index.php/topic,1969.0.html and https://forum.artixlinux.org/index.php/topic,220.0.html
Namely:
Code: [Select]
pacman -S artix-keyring
pacman-key --init --keyserver hkps://keys.openpgp.org
pacman -Syu
pacman -Syyu
pacman-key --populate
pacman-key --refresh-keys
I have tried some of these multiple times. Then once again in this order. But I am shooting in the dark. Shotgun debugging. Yes, I only partially possess the aforementioned "basic knowledge of pacman". But then again, if I read the whole manual for every single program I use, I would not get anything done. I suspect I know enough: I always read relevant portions of man pacman whenever I am about to issue a command I found on the internet.

It is indeed possible that OP and I have both configured something wrong. However, since OP and I are both having problems with a fresh install, and I had managed to install Artix without this problem once before, it is also possible that something really is amiss. Maybe some instruction was not quite clear.

Could you make sure that OP and I indeed deserve a RTFM? If not, could you help us? I don't want to force-accept signatures blindly.

 I'm not sure what diagnostics I should post. I don't want to clutter the post with irrelevant details.

Here's a diff of the outputs of pacman-key -l on my two machines: http://txt.do/tsuhi (Expires in two weeks)

Perhaps the first few lines are the most relevant:
Code: [Select]
3,4c3,4
< pub   rsa4096 2021-03-18 [SC]
<       C85119BD280EC9F0F8C603D366DAADB4CAF690BB
---
> pub   rsa4096 2021-05-10 [SC]
>       6A39C608EB5BC3E65EB7882437AF5810323309D7
The machine on which pacman -S fzf remmina works appears to have an older version (2021-03-18).

Maybe Morten Linderud's and Sergej Pupykin's portions are relevant as well (same on both machines):
Code: [Select]
pub   rsa4096 2014-09-05 [SC]
      C100346676634E80C940FB9E9C02FF419FECBE16
uid           [  full  ] Morten Linderud <[email protected]>
uid           [  full  ] Morten Linderud <[email protected]>
uid           [marginal] Morten Linderud <[email protected]>
uid           [marginal] Morten Linderud <[email protected]>
uid           [marginal] Morten Linderud <[email protected]>
sub   rsa4096 2014-09-05 [E]
sub   rsa4096 2018-11-13 [S]
sub   rsa4096 2018-11-26 [A]
Code: [Select]
pub   rsa4096 2011-07-15 [SC]
      3E518BF2526FD1979E8AAE4965C110C1EA433FC7
uid           [marginal] Sergej Pupykin <[email protected]>
uid           [marginal] Sergej Pupykin <[email protected]>
uid           [  full  ] Sergej Pupykin <[email protected]>
uid           [marginal] Sergej Pupykin <[email protected]>
sub   rsa4096 2011-07-15 [E]

I've also compared the /usr/share/pacman/keyrings directories. ls -1 | xargs sha512sum produces the same output.

remmina's problematic signature might also be worth mentioning:
Code: [Select]
[ax keyrings]# pacman -S remmina
resolving dependencies...
looking for conflicting packages...

Packages (8) libappindicator-gtk3-12.10.0.r296-1  libdbusmenu-glib-16.04.0-4  libdbusmenu-gtk3-16.04.0-4
             libindicator-gtk3-12.10.1-9  libsodium-1.0.18-2  vte-common-0.64.1-1  vte3-0.64.1-1
             remmina-1:1.4.14-1

Total Installed Size:  7.44 MiB

:: Proceed with installation? [Y/n] y
(8/8) checking keys in keyring                                        [######################################] 100%
(8/8) checking package integrity                                      [######################################] 100%
error: remmina: signature from "Sergej Pupykin <[email protected]>" is marginal trust
:: File /var/cache/pacman/pkg/remmina-1:1.4.14-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Re: Problems with pacman signatures

Reply #7 –
Retry with 'y' to  "Do you want to delete it?"

Re: Problems with pacman signatures

Reply #8 –
Quote from: ndowens – on
Retry with 'y' to  "Do you want to delete it?"

That I had done too. Those are the outputs of my n-th installation attempt (n>1). The reason I said no to "Do you want to delete it?" was so that I could compare the packages' sha512sums to those on my other machine.

`pacman -S gnupg` solved the issue for me by the way (in case you didn't see my edit above). Thank you nevertheless.

Re: Problems with pacman signatures

Reply #9 –
Quote from: alium – on
please do pacman -Sy gnupg and you can see, if propblems persist or not

I don't know what to test it on, since I've already signed the keys for the packages I needed, but seeing that it solved alp's problem I guess that it would have also solved mine. So I guess in the end the gnupg dev version accidently sneaked in by the Arch maintainers was indeed the culprit ¯\_(ツ)_/¯. Anyway, I've downgraded gnupg as you recommended, I'll report back if there are any further problems, but I don't (or hope not) expect any more.

Thanks for the help!

Re: [SOLVED] Problems with pacman signatures

Reply #10 –
+1
Issue solved here too.

Re: [SOLVED] Problems with pacman signatures

Reply #11 –
This solved the issue for me too. The package was  "downgraded" from the dev to the normal version.