You are not logged in.

#1 2012-06-11 20:39:09

mastergara
Member
Registered: 2007-10-05
Posts: 12

[RESOLVED] Post pacman upgrade woes with keys

After upgrading pacman (as the result of attempting one package upgrade, then system upgrade), it seems I am unable to install anything using pacman. After some searching, I set up pacman-key (yes, I RTFM, and hope I am not missing anything) and after moving the mouse around a bunch, it completed. Now, whenever I attempt to use pacman to install anything, I see the following:

[marc@couturier ~]$ pacman -Ss mesa-demos
extra/mesa-demos 8.0.1-2
    Mesa demos and tools
[marc@couturier ~]$ sudo pacman -S mesa-demos
[ sudo ] Please enter password for marc:
resolving dependencies...
looking for inter-conflicts...

Targets (5): dri2proto-2.6-1  glew-1.7.0-2  glproto-1.4.15-1  mesa-8.0.3-2
             mesa-demos-8.0.1-2

Total Download Size:    3.33 MiB
Total Installed Size:   14.76 MiB

Proceed with installation? [Y/n] y
:: Retrieving packages from extra...
 mesa-8.0.3-2-x86_64        3.3 MiB  2.06M/s 00:02 [######################] 100%
(5/5) checking package integrity                   [######################] 100%
error: dri2proto: key "94657AB20F2A092B" is unknown
error: key "94657AB20F2A092B" could not be looked up remotely
error: glproto: key "94657AB20F2A092B" is unknown
error: key "94657AB20F2A092B" could not be looked up remotely
error: mesa: key "94657AB20F2A092B" is unknown
error: key "94657AB20F2A092B" could not be looked up remotely
error: glew: key "EA6836E1AB441196" is unknown
error: key "EA6836E1AB441196" could not be looked up remotely
error: mesa-demos: key "7F2D434B9741E8AC" is unknown
error: key "7F2D434B9741E8AC" could not be looked up remotely
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.
[marc@couturier ~]$ cat /etc/pacman.conf
#
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives

#
# GENERAL OPTIONS
#
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
#RootDir     = /
#DBPath      = /var/lib/pacman/
#CacheDir    = /var/cache/pacman/pkg/
#LogFile     = /var/log/pacman.log
#GPGDir      = /etc/pacman.d/gnupg/
HoldPkg     = pacman glibc
# If upgrades are available for these packages they will be asked for first
SyncFirst   = pacman
#XferCommand = /usr/bin/curl -C - -f %u > %o
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#CleanMethod = KeepInstalled
Architecture = auto

# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg   =
#IgnoreGroup =

#NoUpgrade   =
#NoExtract   =

# Misc options
#UseSyslog
#UseDelta
#TotalDownload
CheckSpace
#VerbosePkgLists

# 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 = Never
#SigLevel = Optional TrustedOnly

# NOTE: You must run `pacman-key --init` before first using pacman; the local
# keyring can then be populated with the keys of all official Arch Linux
# packagers with `pacman-key --populate archlinux`.

#
# REPOSITORIES
#   - can be defined here or included from another file
#   - pacman will search repositories in the order defined here
#   - local/custom mirrors can be added here or in separate files
#   - repositories listed first will take precedence when packages
#     have identical names, regardless of version number
#   - URLs will have $repo replaced by the name of the current repo
#   - URLs will have $arch replaced by the name of the architecture
#
# Repository entries are of the format:
#       [repo-name]
#       Server = ServerName
#       Include = IncludePath
#
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
#

# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.

#[testing]
#SigLevel = PackageRequired
#Include = /etc/pacman.d/mirrorlist

[core]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

[extra]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

#[community-testing]
#SigLevel = PackageRequired
#Include = /etc/pacman.d/mirrorlist

[community]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

# If you want to run 32 bit applications on your x86_64 system,
# enable the multilib repositories as required here.

#[multilib-testing]
#SigLevel = PackageRequired
#Include = /etc/pacman.d/mirrorlist

#[multilib]
#SigLevel = PackageRequired
#Include = /etc/pacman.d/mirrorlist

# An example of a custom package repository.  See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#SigLevel = Optional TrustAll
#Server = file:///home/custompkgs

[marc@couturier ~]$

I am currently trying things in This thread, but I suspect I am missing the magic bullet someplace.

Various threads have lead me down the path to change the for loop for the master keys to start with 0x, and the error message is still the same:

[marc@couturier /]$ sudo -i
[ sudo ] Please enter password for marc:
[root@couturier ~]# cd /etc/pacman.d/
[root@couturier pacman.d]# cat keyfix.in
0x6AC6A4C2
0x824B18E8
0x4C7EA887
0xFFF979E7
0xCDFD6BB0
[root@couturier pacman.d]# for key in `cat keyfix.in`
> do
> pacman-key --recv-keys $key; pacman-key --lsign-key $key; printf 'trust\n3\nquit\n' | gpg --homedir /etc/pacman.d/gnupg/ --no-permission-warning --command-fd 0 --edit-key $key; done
gpg: requesting key 6AC6A4C2 from hkp server pool.sks-keyservers.net
gpg: keyserver timed out
gpg: keyserver receive failed: Keyserver error
==> ERROR: Remote key not fetched correctly from keyserver.
==> ERROR: The key identified by 0x6AC6A4C2 could not be found locally.
gpg: requesting key 824B18E8 from hkp server pool.sks-keyservers.net
gpg: keyserver timed out
gpg: keyserver receive failed: Keyserver error
==> ERROR: Remote key not fetched correctly from keyserver.
==> ERROR: The key identified by 0x824B18E8 could not be found locally.
gpg: requesting key 4C7EA887 from hkp server pool.sks-keyservers.net
gpg: keyserver timed out
gpg: keyserver receive failed: Keyserver error
==> ERROR: Remote key not fetched correctly from keyserver.
==> ERROR: The key identified by 0x4C7EA887 could not be found locally.
gpg: requesting key FFF979E7 from hkp server pool.sks-keyservers.net
gpg: keyserver timed out
gpg: keyserver receive failed: Keyserver error
==> ERROR: Remote key not fetched correctly from keyserver.
==> ERROR: The key identified by 0xFFF979E7 could not be found locally.
gpg: requesting key CDFD6BB0 from hkp server pool.sks-keyservers.net
gpg: keyserver timed out
gpg: keyserver receive failed: Keyserver error
==> ERROR: Remote key not fetched correctly from keyserver.
==> ERROR: The key identified by 0xCDFD6BB0 could not be found locally.
[root@couturier pacman.d]#

So what am I missing to be able to either
A) get the keys installed, or
B) not require the keys so pacman can install the packages


Please let me know. Many thanks!

Last edited by mastergara (2012-06-11 22:01:11)


There - At that location; Their - Belonging to them; They're - An abbreviation of "They are"
Your - Belonging to you; You're - An abbreviation of "You are"; Ur -An ancient Mesopotamian city

Offline

#2 2012-06-11 20:54:16

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,131

Re: [RESOLVED] Post pacman upgrade woes with keys

If the keyserver is timing out, you could try a different keyserver?


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#3 2012-06-11 21:26:42

mastergara
Member
Registered: 2007-10-05
Posts: 12

Re: [RESOLVED] Post pacman upgrade woes with keys

After some additional interweb searching (and realizing I am behind like 12 different firewalls), I started to suspect that the keyserver is not using a "Firewall Friendly" port. Survey says *ding!* 11371/tcp for the hks request!

SSH tunnel to a system with a firewall under my control, create a tunnel, modify the hosts file, and run the loops to get the Master Keys & Official Developer Keys, and presto!

My only concern (and why I am not ready to flag this thread as [ RESOLVED ] ) has to do with the setting in pacman.conf for "SigLevel = Never". If a system is buried deep and is not able to get the keys, that entry should bypass the GPG/Keyring setup. This is clearly a new feature of pacman, as it did not arise until after the update to the latest version of pacman. Is that line being honored, or do I have a misunderstanding of the function?


There - At that location; Their - Belonging to them; They're - An abbreviation of "They are"
Your - Belonging to you; You're - An abbreviation of "You are"; Ur -An ancient Mesopotamian city

Offline

#4 2012-06-11 21:28:57

Inxsible
Forum Fellow
From: Chicago
Registered: 2008-06-09
Posts: 9,183

Re: [RESOLVED] Post pacman upgrade woes with keys

You have Siglevel=Never, but you also have Siglevel=PackageRequired on each repo.

Try commenting out the ones on each repo and see if that bypasses signature checking although I would imagine that siglevel=never would override the individual repo level siglevels.


Forum Rules

There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !

Offline

#5 2012-06-11 22:00:33

mastergara
Member
Registered: 2007-10-05
Posts: 12

Re: [RESOLVED] Post pacman upgrade woes with keys

Whelp, it would seem I am blind. I did not see the "SigLevel = PackageRequired" for each of the repos. Next time I am going to use  `grep -b1 SigLevel /etc/pacman.conf` instead of looking for the first pattern in vi. Now that I have the trusts/keys established, even with breaking my connection to the keyserver, what previously would not install now does.

I suppose it would be academic (not really needed, but useful/interesting) to see if "SigLevel = PackageRequired" on the repositories does over-ride the "SigLevel = Never" globally. It makes some sense from a security standpoint to have that level of granularity.

Perhaps it would be useful to state in the pacman-key wiki page that it will require port 11371/tcp access (maybe under "How it works") to save some hassle of other folks who do read the manual? smile


There - At that location; Their - Belonging to them; They're - An abbreviation of "They are"
Your - Belonging to you; You're - An abbreviation of "You are"; Ur -An ancient Mesopotamian city

Offline

#6 2012-06-11 22:11:52

Inxsible
Forum Fellow
From: Chicago
Registered: 2008-06-09
Posts: 9,183

Re: [RESOLVED] Post pacman upgrade woes with keys

Please edit the wiki and add any relevant information you find lacking.


Forum Rules

There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !

Offline

#7 2012-06-11 22:21:35

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,131

Re: [RESOLVED] Post pacman upgrade woes with keys

I thought that "SigLevel=" was used to specify the default policy if you want to override the default default policy. Hence:

# 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 TrustedOnly

I take it that if you have added the line

SigLevel = Never

then the default will be to never check signatures. But the per-repo policies will still trump your customised default.

At least, that was my understanding of the situation. So when I first set this up, not all of the official repos were fully signed. So I left the (then default) policy as Never and gradually changed the repo-specific policies to PackageRequired as and when each repo completed package signing.

Re. the wiki: do you know that all key servers use the same port? If not, it might be that others would require different ports to be accessed.

Last edited by cfr (2012-06-11 22:22:57)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#8 2012-06-11 23:23:14

mastergara
Member
Registered: 2007-10-05
Posts: 12

Re: [RESOLVED] Post pacman upgrade woes with keys

Re: Wiki/Port for HKP

According to IANA, 11371/tcp is the standard for a key server. I have seen this in the past with Ubuntu, but am glad to know I can use SSH to pass the traffic through. I have updated the wiki with a slight blurb about the port usage, so others behind firewalls may avoid my pain smile

It would be nice if they all allowed communication using HTTP, as pretty much every firewall I work with passes that traffic!


There - At that location; Their - Belonging to them; They're - An abbreviation of "They are"
Your - Belonging to you; You're - An abbreviation of "You are"; Ur -An ancient Mesopotamian city

Offline

#9 2012-10-11 21:04:21

kristianf
Member
Registered: 2012-10-11
Posts: 2

Re: [RESOLVED] Post pacman upgrade woes with keys

Moderator edit:  See my post below.

I only stumbled upon this post, but to the extent it can be helpful for anyone else doing the same, note that https://sks-keyservers.net/overview-of-pools.php provide an option that should work in this scenario:

p80.pool.sks-keyservers.net

This is a pool containing only servers available on port 80 (needs to be used as hkp://p80.pool.sks-keyservers.net:80)

Last edited by ewaller (2012-10-12 15:19:40)

Offline

#10 2012-10-12 15:25:02

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,740

Re: [RESOLVED] Post pacman upgrade woes with keys

Moderator:  As a warning, the site linked above sets off security exceptions at at least two of your moderators' locations.
It appears that the linked site is flagged because the site certificate is self-signed.   Be Forewarned.

I did visit the site, and it appears to be benign and does seem to provide links to key-servers on port 80. 

kristianf:  Welcome to Arch Linux.  The moderators do get a bit twitchy when a first post includes a link to a site we don't know.  We generally assume that it is spam, malware, or a blog.  Could you please make a brief disclosure as to any association you may have with that site?  Thanks


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#11 2012-10-12 16:15:17

kristianf
Member
Registered: 2012-10-11
Posts: 2

Re: [RESOLVED] Post pacman upgrade woes with keys

If you note the keyserver used in the original report, it is pool.sks-keyservers.net. I was pointing out that a sub-pool exists for port 80 use. If this pool is unknown to a Gnupg user I'm a bit surprised as it is the default keyserver installed (keys.gnupg.net is a CNAME)

But indeed, I'm affiliated with it, and only came across this topic due to the mention of the pool so it showed up in a google search

Offline

#12 2012-10-12 18:07:53

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,740

Re: [RESOLVED] Post pacman upgrade woes with keys

kristianf wrote:

If you note the keyserver used in the original report, it is pool.sks-keyservers.net. I was pointing out that a sub-pool exists for port 80 use. If this pool is unknown to a Gnupg user I'm a bit surprised as it is the default keyserver installed (keys.gnupg.net is a CNAME)

But indeed, I'm affiliated with it, and only came across this topic due to the mention of the pool so it showed up in a google search

Okay, thanks.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

Board footer

Powered by FluxBB