Ошибка gpg debian wheezy
Обновлено: 07.07.2024
fails at apt-get update since this morning(European time) with:
guess some key timedout or got thrown out.
OS:
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
The text was updated successfully, but these errors were encountered:
rzo1 commented Sep 14, 2017
confirmed. Same here.
todeveni commented Sep 14, 2017
But that key isn't available (yet?) in keyservers.
viktorku commented Sep 14, 2017
Confirmed they fixed it. But this moring even readding it def. didn't work! I readded it in the morning and checked it now with ansible same server.
Readding the key now reported no change (now in the afternoon)
but it works now with the readed the key from the morning, so i guess there was a change in the key file but it took a while for the releases to be adjusted ?:
ansible ad hoc command used:
ansible -m apt_key -a "url=https://dl.yarnpkg.com/debian/pubkey.gpg state=present" TESTHOST
millette commented Sep 17, 2017
Daniel15 commented Sep 28, 2017
Sorry about this! I'm not sure how to improve the process at the moment, so I'll have to get some advice on it. The best practice is to rotate your signing keys periodically (eg. every year, or every two years), but I might need to get advice from other people that maintain package repositories to see how they handle it. Debian and Ubuntu both rotate their keys on each release, but that works well for those projects as they have a separate repo per release.
dmke commented Oct 5, 2017
hilbix commented Nov 1, 2017
This might be late to this "bug", but can you please:
- Provide a signature of the new key, signed with the old key.
- Give some advice how to check this against the old key.
- And please show this procedure on your webpage, too.
Because without, the whole purpose of signed repositories is voided, as any hacker can provide the exact same information as you, but with some forged key.
PS: I think of some simple client procedure like following:
First, create some scratchdir:
Then download the new key along with it's sig:
Now check integrity:
Then, do only if satisfied:
Daniel15 commented Nov 1, 2017
Provide a signature of the new key, signed with the old key.
@hilbix - I can do this, but is it actually necessary? The new key is a subkey under exactly the same master key as the old one, so there's already implicit trust between the two. Anyone that can sign a message using the key can also add a subkey.
For future key rotations, I can post a Github issue containing the fingerprint of the new key, signed with the old one. Would that be sufficient?
But this is not very obvious (not to tell: Very well hidden in the most secret basement ever) for people, who know everything behind the Mathematics of PKI but so far nothing about GnuPG in special (is this only me in the entire universe?).
For other, who want to know, too, here is what I came up for Debian after several hours of googling around and reading manuals about GPG and so on, but for no much avail. Hence I did trial and error, so beware again: Here be dragons, too!
- Does not use the intransparent /etc/apt/trusted.gpg , as I think, this should be avoided at all cost if possible.
- Instead it installs the pubkey into /etc/apt/trusted.gpg.d/ where it truely belongs in a portable and easy to manage way.
- This also makes etckeeper very happy. You all use etckeeper already, right?
First, get everything in a scratch directory:
Check, that both fingerprints of the master key are the same (here 72ECF46A56B4AD39C907BBB71646B01B86E50310 ).
If so, remove the old key and install the new one and commit etckeeper (please note that the sequence of the two apt-key -calls matters):
The text was updated successfully, but these errors were encountered:
luccioman commented Aug 15, 2017
I also have the problem since upgrading from Debian Jessie to Stretch.
It looks like these points will require some action from @Orbiter
chris-blues commented Sep 18, 2017
Same here. Is anyone ever going to fix this.
luccioman commented Oct 24, 2017
As an alternative I've set up a Debian repository on JFrog Bintray to distribute YaCy developer releases (including recent changes made after the latest stable official 1.92/9000 release).
With the following steps (as root or with sudo) you should be able to install a recent YaCy version (1.921.9232 when writing this) without error on a Debian Stretch :
- install the Bintray GPG key :
wget -qO - https://bintray.com/user/downloadSubjectPublicKey?username=bintray | apt-key add - - add the developer repository to your repositories, for example in a yacy.list file :
echo "deb https://dl.bintray.com/luccioman/yacy_search_server stretch main" > /etc/apt/sources.list.d/yacy.list - update with apt :
apt-get update - install yacy :
apt-get install yacy
Feedback will be welcome!
chris-blues commented Nov 1, 2017
Thanks! Will take a look at it, when I find the time and quiet.
As an alternative I've set up a Debian repository on JFrog
Just tried it and seems to work great!
This YaCy package worked for global search, but no pages that I crawled were indexed. I tried several different sites, and after crawling tens of thousands of pages, my index still had 0 documents.
luccioman commented Feb 22, 2018
@avh-on1 , thanks for your report. That's rather strange : did you notice any error message or any error entries in the log?
Would you like to try running the yacy_v1.921_20180102_9513.tar.gz tarball (at Release_1.921.9513-dev ) which is equivalent to the Debian package hosted on JFrog bintray ?
r4dh4l commented Nov 6, 2018
Unfortunately the problem still exist:
Anway: Thx for YaCy!
As an alternative I've set up a Debian repository on JFrog Bintray to distribute YaCy developer releases (including recent changes made after the latest stable official 1.92/9000 release).
With the following steps (as root or with sudo) you should be able to install a recent YaCy version (1.921.9232 when writing this) without error on a Debian Stretch :
Читайте также: