Debian Stretch Repo
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	johndoe
	Feb 18 2019, 4:13 PM

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

Related Objects

Mentioned Here: T3820: Debian 9.0 does not accept SHA1 signature of OBS repository

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

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.

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

emunson subscribed.Mar 15 2019, 8:43 PM

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.Mar 21 2019, 10:38 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.Mar 22 2019, 11:06 AM

vanmeeuwen moved this task from Backlog to Maintenance on the Bug Reports board.

Many thanks vanmeeuwen and sicherha for your efforts.

Regards
Darius

Still having the same issue with my Debian Stretch system - but I'm using Winterfell:

user@host:~$ LANG=C sudo apt update
[...]
Ign:14 https://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./ InRelease                 
Hit:15 http://ftp.de.debian.org/debian stretch Release                                         
Ign:16 https://obs.kolabsys.com/repositories/Kolab:/Winterfell/Debian_9.0 ./ InRelease         
Hit:17 http://packages.ntop.org/apt-stable/stretch x64/ InRelease        
Hit:18 https://obs.kolabsys.com/repositories/Kolab:/16/Debian_9.0 ./ Release
Hit:19 http://packages.ntop.org/apt-stable/stretch all/ InRelease        
Hit:20 https://obs.kolabsys.com/repositories/Kolab:/Winterfell/Debian_9.0 ./ Release
Hit:21 http://ftp.us.debian.org/debian stretch-backports InRelease
Get:22 https://obs.kolabsys.com/repositories/Kolab:/Winterfell/Debian_9.0 ./ Release.gpg [827 B]
Ign:23 http://ftp.us.debian.org/debian stretch InRelease                            
Hit:24 http://ftp.us.debian.org/debian stretch Release
Ign:22 https://obs.kolabsys.com/repositories/Kolab:/Winterfell/Debian_9.0 ./ Release.gpg
Fetched 827 B in 2s (324 B/s)  
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.
W: GPG error: https://obs.kolabsys.com/repositories/Kolab:/Winterfell/Debian_9.0 ./ Release: The following signatures were invalid: A21E96611060CF0B4DF11E64A01D0CA80038D0DB

I have both the old and the new key installed, along with Kolabsys key:

user@host:~$ apt-key list
/etc/apt/trusted.gpg
--------------------
[...]
pub   rsa2048 2014-08-20 [SC]
      79D8 6A05 FDE6 C9FB 4E43  A6C5 830C 2BCF 446D 5A45
uid        [ unbekannt ] Kolab Development Coordination Mailing List <devel@lists.kolab.org>
sub   rsa2048 2014-08-20 [E]

pub   rsa4096 2018-05-24 [SC]
      A21E 9661 1060 CF0B 4DF1  1E64 A01D 0CA8 0038 D0DB
uid        [ unbekannt ] Kolab Package Signing (Community Packages) <devel@lists.kolab.org>

pub   rsa4096 2018-05-19 [SC]
      44BA F275 86FE 480F 3D03  89A0 BC9F 339D 02FD 95DA
uid        [ unbekannt ] Kolab Package Signing (Debian Stretch) <stretch-packages@kolabsys.com>

Any ideas how to solve?

It'll resolve itself once a package is built in Winterfell.

Debian Stretch RepoClosed, ResolvedPublicActions

Description

Details

Related Objects

Event Timeline

Debian Stretch Repo
Closed, ResolvedPublic
Actions