-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KEYEXPIRED on opensuse.org download site (jgeboski) #375
Comments
pub 2048R/1C85BB5E 2015-07-23 [expired: 2017-09-30] |
Verified. Tried removing the key and re-adding from scratch. Old key is still old. |
Try again? |
Uhm, nope, still expired. |
This download [1] is exactly the same as prior to the expiry (at least since 8th April, 2016, no different today). I deliberately added to key to gpg2 to see if it would get an update via --refresh-keys ... but it didn't gpg2 --import obs.key gpg2 --keyid-format long --fingerprint jgeboski@build.opensuse.org |
gpg2 --keyid-format long --refresh-keys jgeboski@build.opensuse.org |
Yeah I just noticed that, https://jgeboski.github.io/obs.key had an outdated copy instead of just using the real repo key from https://download.opensuse.org/repositories/home:/jgeboski/xUbuntu_17.04/Release.key It's updated now |
Okay, I imported that key and it is happy now, got an update too. |
I have had the same problem with http://download.opensuse.org/repositories/home:/jgeboski/Debian_9.0. When I run
It took me some time to figure out that I had to follow the instructions at https://jgeboski.github.io/#package-repositories and add the key once again. |
Same issue on Debian Jessie. Redownloading key fixed the [strange] issue... |
But redownloading the key is not something we want to do when there may be MITM attack in progress. How do we know that nobody took control over https://jgeboski.github.io/ ? |
@jkufner , you don't. You also don't know if the SuSE repo was taken over. Frankly, you have the same chicken-and-egg problem when you're downloading your copy of Debian / CentOS / other, when you download the Debian/Ubuntu ca-certificates package, or your browser. This is not an easy problem, and no one has proposed a viable solution I've heard of. First, since you don't know the packager personally, you're already taking a calculated(?) risk using the software. Second, the key's actually published on at least one or two keyservers, if you think there's a reason to trust them more than GitHub or the SuSE repo. See keyserver.ubuntu.com for the (new) one under discussion, for example. |
TOFU (trust on first use) is reasonable good solution to the chicken-and-egg problem. But this issue is about updating a key with another key by just redownloading it with no check. Other repositories have a |
@jkufner , TOFU doesn't solve chicken-and-egg. It's just an agreement to trust something that isn't provably trustworthy. You get the same problem with the PKI roots: you're just agreeing to hope that they never act maliciously... which they have, repeatedly. You're correct, though, that various non-distro packages use a package to solve continuity. Most do not use an actual, separate package called "keyring", but instead include a package repository definition and a package signing key in the first installed package and in subsequent packages. The Google Earth or Google Chrome packages are good examples, at least on Debian-based distros. Same for Opera, I believe. Thereafter, the package is used both to manage keys and to change package repository definitions if necessary. I'm not aware of a direct apt-/ dpkg-level or RPM-level solution to warn on expiration, request new keys in advance, or do other things to mitigate against lapsed signing keys. I assume both popular package-building tools will at least issue warnings when you're trying to sign packages with keys that are near expiration, but I've watched developers ignore that exact kind of problem until after it's already a crisis, so it's not an iron-clad guarantee of a fix. |
Chrome packages are not a good example. Bundling everything into a single package is really bad practice. Just keep current Distributions use keyring packages to manage keys to the repositores. Once a key is about to expire, relevant package is updated and this update gets to users. Therefore, there is no need for additional warning mechanism at users' end. At developer's end, it is up to GnuPG to warn anyone. |
It looks like the whole repository site is down now? |
Ya ... I simply removed the respository from my sources file. Frankly, this kind of thing is a huge red flag. |
I'm not removing it from the repo again, but I wish this was 100% reliable or closer to it. I do like the idea of a separate package for a special keyring as well. This is getting to be too much of a problem, if it keeps doing this, then eventually I might remove it too. |
The downtime was this https://news.opensuse.org/2017/10/04/planned-downtime-to-affect-opensuse-services/ Closing this as it was already resolved. |
Okay, great, was it only 24 hours this time? I'm not sure how long it actually was, but I didn't know if or when it would be "fixed" again..... |
Is there downtime again? Been unable to check if there is an update (apt-get unable to update). |
An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://download.opensuse.org/repositories/home:/jgeboski/xUbuntu_16.04 ./ Release: The following signatures were invalid: KEYEXPIRED 1506804343Failed to fetch http://download.opensuse.org/repositories/home:/jgeboski/xUbuntu_16.04/./Release.gpg The following signatures were invalid: KEYEXPIRED 1506804343Some index files failed to download. They have been ignored, or old ones used instead.
The text was updated successfully, but these errors were encountered: