Open jonathanza opened 2 years ago
Thank you for creating this issue. I have been trying to find my way around the same problem for the last 30 minutes or so with no success. It looks like this issue comes up for various projects when the repo signing key changes.
I can confirm this problem on Debian as well. The repository key needs to be renewed or replaced.
Adding trusted=yes
to the repo definition is a very much not recommended workaround, if you really absolutely have to install goaccess
via the Debian / Ubuntu repositories now.
The GPG key has indeed expired:
/etc/apt/trusted.gpg.d/goaccess.gpg
-----------------------------------
pub rsa3072 2020-05-17 [SC] [expired: 2022-05-17]
C03B 4888 7D5E 56B0 4671 5D32 97BD 1A01 3344 9C3D
uid [ expired] Gerardo Orellana <goaccess@prosoftcorp.com>
Thanks everyone for reporting this. The key has been renewed, please download it again, e.g.,
$ sudo apt-key del 97BD1A0133449C3D
$ sudo rm -rf /usr/share/keyrings/goaccess.gpg
$ wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
The key fingerprint is the same: C03B 4888 7D5E 56B0 4671 5D32 97BD 1A01 3344 9C3D
Please let me know if that solves the issue on your end.
Resolved!
Thank you!
Thanks, however, in addition to the above instructions to avoid the "The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 97BD1A0133449C3D" I had to also do this:
cd /usr/share/keyrings;
sudo apt-key add goaccess.gpg
That didn't quite work for me on an Ubuntu 20.04 LTS x86_64 system, some other steps may help,
...9C3D
showing up in output): wget -O - https://deb.goaccess.io/gnugpg.key | gpg --show-keys
/usr/share/keyrings/goaccess.gpg
apt-get update
was failing with "N: Skipping acquisition of configured file 'main/binary-i386/Packages', as repository 'https://deb.goaccess.io focal InRelease' doesn't support architecture 'i386'"
/etc/apt/sources.list.d/goaccess.list
to (adding the arch
setting),
deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=amd64] https://deb.goaccess.io/ focal main
apt-key add /usr/share/keyrings/goaccess.gpg
), in which case I think that signed-by
option can be removed.on a recent 20.04 LTS install I took steps from @allinurl and added two lines to it and it worked with the extra two lines, see below:
sudo apt-key del 97BD1A0133449C3D
sudo rm -rf /usr/share/keyrings/goaccess.gpg
wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
cd /usr/share/keyrings
sudo apt-key add goaccess.gpg
On Debian Bullseye, I had to place the gpg key in /etc/apt/trusted.gpg.d instead of /usr/share/keyrings
On Debian Bullseye, I had to place the gpg key in /etc/apt/trusted.gpg.d instead of /usr/share/keyrings
I would have thought that when using the deb signed-by
setting as documented you could put it anywhere. Is that not the case?
@ahayes just for reference, here are some great answers on apt-key and the path of keyrings:
https://askubuntu.com/a/1307181 https://unix.stackexchange.com/a/582853
@ahayes just for reference, here are some great answers on apt-key and the path of keyrings:
Thanks, but I think @Nardol and @olstjos are the ones who needs to read those. That's why I pointed out that your instructions used signed-by with a path to the key. You had good reasons for doing it that way rather than asking people to have apt trust your signing key for any repo.
As an aside, I need to read up on this a bit more though because I don't see what stops a malicious repo admin who gets their repo added to a system with a repo-specific signing key from putting their own versions of other well-known packages up and waiting for someone to install them.
Edit: I see that steps 4 and 5 of the second link try to address my concern.
I would have thought that when using the deb
signed-by
setting as documented you could put it anywhere. Is that not the case?
It is, GoAccess was installed by a script which did not follow the same procedure. So I modified it now and won't use trusted.gpg.d.
Thanks @allinurl for the links.
On Debian Bullseye, I had to place the gpg key in /etc/apt/trusted.gpg.d instead of /usr/share/keyrings
I would have thought that when using the deb
signed-by
setting as documented you could put it anywhere. Is that not the case?
I thought so, too and it puzzles me, but apparently it's not the case. I had NO_PUBKEY 97BD1A0133449C3D
errors using the signed-by
option with the key in /usr/local/share/keyrings
. That error vanished when I moved the file into /etc/apt/trusted.gpg.d
and adjusted the signed-by
accordingly.
@allinurl Please consider changing your repo to match Debian's.
Thank you! ❤️
@szepeviktor I can take a look. Do you have some docs that reference how they're doing it? Thanks
- publish your GPG key unarmored
Just upload a binary file e.g. /goaccess.gpg.key
.
- make signed-by and arch unnecessary
It depends on what software you use to generate your repo. I use reprepro.
Currently this works for me on amd64 Debian.
wget -qO- https://deb.goaccess.io/gnugpg.key | gpg --yes --dearmor --output /etc/apt/trusted.gpg.d/goaccess.gpg
deb http://deb.goaccess.io/ buster main
It would be nice to have a binary key online and support people on multiarch: amd64+i386
.
@szepeviktor I see. So when you say match debian, I'm guessing you're referring to the guide you posted, correct? shouldn't users avoid putting them under trusted.gpg.d/
as described on the links below?
just for reference, here are some great answers on apt-key and the path of keyrings:
https://askubuntu.com/a/1307181 https://unix.stackexchange.com/a/582853
The official Debian wiki also does not recommend trusted.gpg.d: https://wiki.debian.org/DebianRepository/UseThirdParty
But a non-armored key and a package which should be updated when the signing key could also be two good points which would make things perfect :slightly_smiling_face:
shouldn't users avoid putting them under
trusted.gpg.d/
as described on the links below?
I take the risk of malicous packages being injected into the official Ubuntu mirrors network by Gerardo 🙃
Thanks for the feedback!
Unarmored key was added https://deb.goaccess.io/goaccess.gpg.key
@szepeviktor you should be able to already run it without signed-by or without arch, e.g.,
$ echo "deb http://deb.goaccess.io $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list
$ wget -O - http://deb.goaccess.io/gnugpg.key | sudo apt-key add -
$ sudo apt-get update
$ sudo apt-get install goaccess
Are you getting some sort of error?
Unarmored key was added
Thank you!
Are you getting some sort of error?
No! Only people on multiarch will get one.
@szepeviktor I think that would work for both 64 and 32-bit. But I'm not sure it will handle arm64 if I don't specify the arch in reprepro. Do you know how that would work?
No, I've never been in the 32 bit world.
I installed goaccess via this guide when setting up my server: https://www.howtoforge.com/tutorial/perfect-server-ubuntu-20.04-with-apache-php-myqsl-pureftpd-bind-postfix-doveot-and-ispconfig/
In that guide it installs via these commands:
wget -O - https://deb.goaccess.io/gnugpg.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/goaccess.gpg add -
sudo apt-get update
sudo apt-get install goaccess
Therefore to correct this issue, I modified the recommendation above slightly to:
sudo apt-key del 97BD1A0133449C3D
sudo rm -rf **/etc/apt/trusted.gpg.d/goaccess.gpg**
wget -O - https://deb.goaccess.io/gnugpg.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/goaccess.gpg add -
sudo apt-get update
Hope this helps anyone with the key in trusted.gpg.d
I am having issues when running the command described here https://goaccess.io/download
wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
--2022-12-04 06:21:01-- https://deb.goaccess.io/gnugpg.key
Resolving deb.goaccess.io (deb.goaccess.io)... 67.205.130.138, 2604:a880:400:d0::213c:1
Connecting to deb.goaccess.io (deb.goaccess.io)|67.205.130.138|:443... connected.
ERROR: The certificate of ‘deb.goaccess.io’ is not trusted.
ERROR: The certificate of ‘deb.goaccess.io’ has expired.
gpg: no valid OpenPGP data found.
Am I doing something wrong, or the certificate is truly expired?
@ypujante Certificate is fine. Have you run apt update and apt upgrade on your machine? I wonder if you have old cert packages... Then please try:
$ echo "deb http://deb.goaccess.io $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list
$ wget -O - http://deb.goaccess.io/gnugpg.key | sudo apt-key add -
$ sudo apt-get update
$ sudo apt-get install goaccess
@allinurl I tried your suggestion and I am getting an error.
If I look at my /etc/apt/sources.list
there is this:
deb http://deb.goaccess.io stretch main
When I run apt-get update
I get this:
Ign:11 http://deb.goaccess.io stretch InRelease
Err:12 http://deb.goaccess.io stretch Release
404 Not Found [IP: 67.205.130.138 80]
Reading package lists... Done
E: The repository 'http://deb.goaccess.io stretch Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
I am not too sure why it lists "Release" and not "main". Not sure what to do to fix this.
Looks like you are still running stretch which is no longer supported. It appears debian ended LTS on June 2022. You could try changing the name under /etc/apt/sources.list
to buster
to see if that does the job. Let me know.
I missed that :(. Thank you for pointing it out.
With ansible on debian 12 i use this
- name: Add GoAccess's APT signing key
ansible.builtin.get_url:
url: "{{ goaccess_repo_key_url }}"
dest: /etc/apt/trusted.gpg.d/goaccess.asc
mode: '0644'
force: true
- name: Add GoAccess's APT repository to system repository list and update cache.
ansible.builtin.apt_repository:
repo: "deb https://deb.goaccess.io/ {{ ansible_distribution_release }} main"
filename: goaccess
state: present
update_cache: true
Work fine without errors
The following command from https://goaccess.io/download#official-repo is failing:
I downloaded the key again but the same error occurred.