KEYEXPIRED on opensuse.org download site (jgeboski)

[affinityv]

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.

[affinityv]

pub 2048R/1C85BB5E 2015-07-23 [expired: 2017-09-30]
uid home:jgeboski OBS Project home:jgeboski@build.opensuse.org

[rmenessec]

Verified. Tried removing the key and re-adding from scratch. Old key is still old.

[dequis]

Try again?

[niklasholm]

Uhm, nope, still expired.

[affinityv]

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
gpg: key 1C85BB5E: public key "home:jgeboski OBS Project home:jgeboski@build.opensuse.org" imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: no ultimately trusted keys found

gpg2 --keyid-format long --fingerprint jgeboski@build.opensuse.org
pub rsa2048/12C6ADA61C85BB5E 2015-07-23 [SC] [expired: 2017-09-30]
Key fingerprint = 1E7B F737 CB87 09F0 F740 625B 12C6 ADA6 1C85 BB5E
uid [ expired] home:jgeboski OBS Project home:jgeboski@build.opensuse.org

[1] https://jgeboski.github.io/obs.key

[affinityv]

gpg2 --keyid-format long --refresh-keys jgeboski@build.opensuse.org
gpg: refreshing 1 key from hkp://keys.gnupg.net
gpg: key 12C6ADA61C85BB5E: "home:jgeboski OBS Project home:jgeboski@build.opensuse.org" not changed
gpg: Total number processed: 1

[dequis]

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

[affinityv]

Okay, I imported that key and it is happy now, got an update too.

[affinityv]

purple-facebook [20170916af391dc9ff9acf9fa14135 -> 201710044aa77de9ff9acf9fa14137]

Thank you!

[staspika]

I have had the same problem with http://download.opensuse.org/repositories/home:/jgeboski/Debian_9.0. When I run sudo apt-get update, I got back the following:

W: GPG error: http://download.opensuse.org/repositories/home:/jgeboski/Debian_9.0 ./ Release: The following signatures were invalid: EXPKEYSIG 12C6ADA61C85BB5E home:jgeboski OBS Project <home:jgeboski@build.opensuse.org> W: The repository 'http://download.opensuse.org/repositories/home:/jgeboski/Debian_9.0 ./ Release' is not signed. N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.

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.

[darkerego]

Same issue on Debian Jessie. Redownloading key fixed the [strange] issue...

[jkufner]

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/ ?

[rmenessec]

@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.

[jkufner]

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 something-keyring package, which contains keys and when a key is to expire soon, the package is updated and installs a new key. The trick is that the package is signed by the old key, so the continuity is preserved and user knows that the author is still the same person/entity. Without this continuity it would be a good oportunity for an attacker to infiltrate users when they update keys.

[rmenessec]

@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.

[jkufner]

Chrome packages are not a good example. Bundling everything into a single package is really bad practice. Just keep current purple-facebook package as it is now and add a new package jgeboski-keyring with the key. The purple-facebook package may recommend the keyring package, but not more.

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.

[fritzophrenic]

It looks like the whole repository site is down now?

[darkerego]

Ya ... I simply removed the respository from my sources file. Frankly, this kind of thing is a huge red flag.

[affinityv]

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.

[dequis]

The downtime was this https://news.opensuse.org/2017/10/04/planned-downtime-to-affect-opensuse-services/

Closing this as it was already resolved.

[affinityv]

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.....

[affinityv]

Is there downtime again? Been unable to check if there is an update (apt-get unable to update).