Page MenuHomekolab.org

Debian Stretch Repo
Closed, ResolvedPublic

Description

Since some days there is something wrong with the repo signing key...

Ign:1 http://ftp.de.debian.org/debian stretch InRelease
Hit:2 http://ftp.de.debian.org/debian stretch-updates InRelease
Hit:3 http://security.debian.org stretch/updates InRelease
Hit:4 http://ftp.de.debian.org/debian stretch-backports InRelease
Hit:5 http://ftp.de.debian.org/debian stretch Release
Ign:6 http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./ InRelease
Get:7 http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./ Release [985 B]
Get:8 http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./ Release.gpg [827 B]
Err:8 http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./ Release.gpg

The following signatures were invalid: A21E96611060CF0B4DF11E64A01D0CA80038D0DB

Fetched 1,812 B in 0s (1,816 B/s)
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./ Release: The following signatures were invalid: A21E96611060CF0B4DF11E64A01D0CA80038D0DB
W: Failed to fetch http://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0/./Release.gpg The following signatures were invalid: A21E96611060CF0B4DF11E64A01D0CA80038D0DB
W: Some index files failed to download. They have been ignored, or old ones used instead.

Is there a new one or did I miss something???

Regards
Darius

Details

Ticket Type
Task

Event Timeline

johndoe created this task.Feb 18 2019, 4:13 PM
johndoe lowered the priority of this task from Needs Triage to High.Feb 19 2019, 11:09 AM

Does nobody have this problem with Debian Stretch?

The key was changed on 16th February.

I have two Kolab 16 Community Installations. Both suffer from this. And before someone asks - there is no proxy in between.

Regards
Darius

johndoe raised the priority of this task from High to Unbreak Now!.Feb 19 2019, 11:14 AM
sicherha added a subscriber: sicherha.

I can confirm this issue. See here for a workaround: https://git.kolab.org/T4049#60227

Hello sicherha,

thanks for your response.

The workaround does not work... both keys are the same!
Force "trusting" an untrusted repo is in no way acceptable.

I hope "vanmeeuwen" can fix this soon.

Regards
Darius

Hello sicherha, hello vanmeeuwen,

I've found some GPG issues (from january) with OBS on github...
Are you guys using gpg-2.2.x by any chance???

Look here...
https://github.com/openSUSE/open-build-service/issues/6233
https://github.com/openSUSE/obs-sign/pull/19

This seem to solve the problem...
https://github.com/openSUSE/obs-sign/pull/19/commits/bf3c981f791c612dbc6370f0b7af6c0bf780853c

Regards
Darius

Good spot, that may very well be the reason. ๐Ÿ‘

Since I'm just a volunteer from the community, I don't have shell access to the OBS infrastructure, so @vanmeeuwen is the only one that can fix this issue.

The APT repository can be accessed over HTTPS, which adds to the baseline integrity provided by the repository's GnuPG signature a second level of integrity (via X.509 certificates + transport encryption) and a first level of confidentiality (via transport encryption). Depending on how paranoid security-conscious you are, this may or may not render it acceptable for you to temporarily force-trust the repository until the issue is sorted out.

johndoe added a comment.EditedMon, Feb 25, 10:47 PM

Yes, I care a lot about security... and HTTPS is one I do not trust very much... but better than nothing.

SSL certificates are fine, but nothing worth when controlled by "third" parties (imagine Symantec CA).
Whenever "third" party comes into play there is NO "real" security.

Kolab had always the reputation to be secure (I recall German BSI) - this should be well-preserved.

Let us not get off topic and wait what vanmeeuwen has to say.

Regards
Darius

This isn't going to be a discussion about whichever level people may think they require for checksummed payload obtained over a secure channel, but should instead revolve around how something like the OBS starts failing to sign packages/repositories, and seemingly for APT repositories only.

It seems the signatures are valid:

obs05:/srv/obs/repos/Kolab:/16/Debian_9.0 # gpg --verify Release.gpg Release
gpg: Signature made Thu 21 Mar 2019 12:11:35 PM UTC using RSA key ID 0038D0DB
gpg: Good signature from "Kolab Package Signing (Community Packages) <devel@lists.kolab.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: A21E 9661 1060 CF0B 4DF1  1E64 A01D 0CA8 0038 D0DB
obs05:/srv/obs/repos/Kolab:/16/Debian_9.0 # gpg2 --verify Release.gpg Release
gpg: Signature made Thu 21 Mar 2019 12:11:35 PM UTC using RSA key ID 0038D0DB
gpg: Good signature from "Kolab Package Signing (Community Packages) <devel@lists.kolab.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: A21E 9661 1060 CF0B 4DF1  1E64 A01D 0CA8 0038 D0DB

and the key published is the correct key;

obs05:/srv/obs/repos/Kolab:/16/Debian_9.0 # gpg Release.key
pub  4096R/0038D0DB 2018-05-24
uid                            Kolab Package Signing (Community Packages) <devel@lists.kolab.org>

either this is somehow also magically resolved (it wouldn't surprise me), or the original failure originally used a different / older key.

Note we've had issues with OBS signing using a self-generated key, then signatures were no longer deemed valid/secure by APT foo, and the signing key needed to be regenerated -- which at different points in time may or may not have worked.

vanmeeuwen closed this task as Resolved.Thu, Mar 21, 10:38 PM
sicherha reopened this task as Open.Thu, Mar 21, 11:51 PM

If only things were that easy. :-/

APT is still giving me this error, sans any further explanation:

W: GPG error: https://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./ Release: The following signatures were invalid: A21E96611060CF0B4DF11E64A01D0CA80038D0DB

Now the error message isn't helpful at all, but I suspect we're somehow back at square one with the signature-algorithm issue previously discussed in T3820. Remember, starting with Stretch, Debian does not allow SHA-1 signatures for repositories any more.

$ pgpdump Release.gpg
Old: Signature Packet(tag 2)(533 bytes)
        Ver 3 - old
        Hash material(5 bytes):
                Sig type - Signature of a binary document(0x00).
                Creation time - Thu Mar 21 13:11:35 CET 2019
        Key ID - 0xA01D0CA80038D0DB
        Pub alg - RSA Encrypt or Sign(pub 1)
        Hash alg - SHA1(hash 2)
        Hash left 2 bytes - b3 9c 
        RSA m^d mod n(4094 bits) - ...
                -> PKCS-1

This fundamentally flawed version of a build system has needed to be patched again, but this crap should now be resolved.

vanmeeuwen closed this task as Resolved.Fri, Mar 22, 11:06 AM
vanmeeuwen moved this task from Backlog to Maintenance on the Bug Reports board.