Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 768012 - WOT verification of install*.DIGESTS.asc not possible
Summary: WOT verification of install*.DIGESTS.asc not possible
Status: UNCONFIRMED
Alias: None
Product: Gentoo Release Media
Classification: Unclassified
Component: All ISO (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Release Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-30 17:49 UTC by dirk
Modified: 2021-01-31 18:57 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description dirk 2021-01-30 17:49:35 UTC 
hi all,



i am trying to verify the install iso file. for example with : https://ftp.fau.de/gentoo/releases/amd64/autobuilds/current-install-amd64-minimal/install-amd64-minimal-20210127T214504Z.iso.DIGESTS.asc 
  
but when importing the signing-key: 
gpg --keyserver hkps://keys.gentoo.org --recv-keys 534E4209AB49EEE1C19D96162C44695DB9F6043D  

i only get a key which is not verifiable in WOT...

ie: 

gpg --list-sigs 534E4209AB49EEE1C19D96162C44695DB9F6043D
pub   rsa4096 2009-08-25 [SC] [expires: 2022-07-01]
      13EBBDBEDE7A12775DFDB1BABB572E0E2D182910
uid           [ unknown] Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2013-08-24  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2015-08-26  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2017-08-22  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2019-02-23  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2019-04-27  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2019-10-30  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2020-04-24  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sig 3        BB572E0E2D182910 2019-02-24  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>
sub   rsa2048 2019-02-23 [S] [expires: 2022-07-01]
sig          BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>


any idea? am i doing sth wrong ?

cheers
dirk
Comment 1 Matt Turner gentoo-dev 2021-01-31 02:47:58 UTC 
infra@ maintains the signing key an releng@ doesn't really have anything to do with it. Cc'ing infra@.
Comment 2 Alec Warner (RETIRED) archtester gentoo-dev Security 2021-01-31 04:38:49 UTC 
(In reply to dirk from comment #0)
> hi all,
> 
> 
> 
> i am trying to verify the install iso file. for example with :
> https://ftp.fau.de/gentoo/releases/amd64/autobuilds/current-install-amd64-
> minimal/install-amd64-minimal-20210127T214504Z.iso.DIGESTS.asc 
>   
> but when importing the signing-key: 
> gpg --keyserver hkps://keys.gentoo.org --recv-keys
> 534E4209AB49EEE1C19D96162C44695DB9F6043D  
> 
> i only get a key which is not verifiable in WOT...
> 
> ie: 
> 
> gpg --list-sigs 534E4209AB49EEE1C19D96162C44695DB9F6043D
> pub   rsa4096 2009-08-25 [SC] [expires: 2022-07-01]
>       13EBBDBEDE7A12775DFDB1BABB572E0E2D182910
> uid           [ unknown] Gentoo Linux Release Engineering (Automated Weekly
> Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2013-08-24  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2015-08-26  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2017-08-22  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2019-02-23  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2019-04-27  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2019-10-30  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2020-04-24  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sig 3        BB572E0E2D182910 2019-02-24  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> sub   rsa2048 2019-02-23 [S] [expires: 2022-07-01]
> sig          BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <releng@gentoo.org>
> 
> 
> any idea? am i doing sth wrong ?
> 
> cheers
> dirk

I'd start with:

(1) Why do you think you can't verify the key via WoT?

My impression is that you concluded something based on the list-sigs output..but I have no idea what your conclusion is.

(2) You could easily just trust BB572E0E2D182910 but my assumption is that you expect some other procedure?
Comment 3 dirk 2021-01-31 09:37:37 UTC 
(In reply to Alec Warner from comment #2)
> (In reply to dirk from comment #0)
> > hi all,
> > 
> > 
> > 
> > i am trying to verify the install iso file. for example with :
> > https://ftp.fau.de/gentoo/releases/amd64/autobuilds/current-install-amd64-
> > minimal/install-amd64-minimal-20210127T214504Z.iso.DIGESTS.asc 
> >   
> > but when importing the signing-key: 
> > gpg --keyserver hkps://keys.gentoo.org --recv-keys
> > 534E4209AB49EEE1C19D96162C44695DB9F6043D  
> > 
> > i only get a key which is not verifiable in WOT...
> > 
> > ie: 
> > 
> > gpg --list-sigs 534E4209AB49EEE1C19D96162C44695DB9F6043D
> > pub   rsa4096 2009-08-25 [SC] [expires: 2022-07-01]
> >       13EBBDBEDE7A12775DFDB1BABB572E0E2D182910
> > uid           [ unknown] Gentoo Linux Release Engineering (Automated Weekly
> > Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2013-08-24  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2015-08-26  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2017-08-22  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2019-02-23  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2019-04-27  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2019-10-30  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2020-04-24  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sig 3        BB572E0E2D182910 2019-02-24  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > sub   rsa2048 2019-02-23 [S] [expires: 2022-07-01]
> > sig          BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <releng@gentoo.org>
> > 
> > 
> > any idea? am i doing sth wrong ?
> > 
> > cheers
> > dirk
> 
> I'd start with:
> 
> (1) Why do you think you can't verify the key via WoT?
> 
> My impression is that you concluded something based on the list-sigs
> output..but I have no idea what your conclusion is.

the signing key above is only self signed, and the L1 key does not sign this key. so i do not have a path down to the signing key of the ISO

> 
> (2) You could easily just trust BB572E0E2D182910 but my assumption is that
> you expect some other procedure?

this would just say trust https. then i dont need gpg
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-01-31 10:03:18 UTC 
You're looking for:

sig 3   P    55D3238EC050396E 2019-04-01  Gentoo Authority Key L2 for Services <openpgp-auth+l2-srv@gentoo.org>

Note that modern versions of GPG discard signatures for which you don't have the public key.
Comment 5 dirk 2021-01-31 14:08:48 UTC 
(In reply to Michał Górny from comment #4)
> You're looking for:
> 
> sig 3   P    55D3238EC050396E 2019-04-01  Gentoo Authority Key L2 for
> Services <openpgp-auth+l2-srv@gentoo.org>
> 
> Note that modern versions of GPG discard signatures for which you don't have
> the public key.


Hi Michał,

thanks for your answer ... i imported the L2 key already and this is ok, but from L1 the only trusted sig is yours. but then all trusted sigs of yours are revoked, and i am stuck.

cheers
Dirk
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-01-31 16:34:01 UTC 
I'm afraid I can't say much beyond "WoT doesn't really work ".
Comment 7 dirk 2021-01-31 16:39:11 UTC 
(In reply to Michał Górny from comment #6)
> I'm afraid I can't say much beyond "WoT doesn't really work ".

well, it would if you would trust for example:
C4DD695FA7138F242AA1563858497EE51D5D74A5 Thomas Deutschmann <whissi@gentoo.org>

dont you know each other ? would __really__ help me ...
Comment 8 Alec Warner (RETIRED) archtester gentoo-dev Security 2021-01-31 18:18:04 UTC 
(In reply to dirk from comment #7)
> (In reply to Michał Górny from comment #6)
> > I'm afraid I can't say much beyond "WoT doesn't really work ".
> 
> well, it would if you would trust for example:
> C4DD695FA7138F242AA1563858497EE51D5D74A5 Thomas Deutschmann
> <whissi@gentoo.org>
> 
> dont you know each other ? would __really__ help me ...

I think the struggle is that there is limited interest in our side in making this work.

 - The procedure for signing is typically quite variable and so we tend to impose an onerous one (e.g. I 'know' whissi, but i have never met them and may never meet them.) How do you generate a WoT when your web members never meet? Its nominally against the tradition of meeting people in person and verifying their identity (to establish a trust signature.)
 - We don't actively monitor how good / accessible the web is; so e.g. we have no idea how easy / hard it is to verify keys.
 - The key infrastructure is quite bad currently, due to various attacks on the SKS network. We have mitigated this somewhat with keys.gentoo.org (our own servers that don't accept outside uploads) but it also means the WoT on our keyserver network will be limited...

The trust model is to trust LetsEncrypt (and thus the GPG fingerprints on our website.) There is no other workable trust model at present; so if you can't we are probably SoL for automated verification.

-A
Comment 9 dirk 2021-01-31 18:47:18 UTC 
(In reply to Alec Warner from comment #8)
> (In reply to dirk from comment #7)
> > (In reply to Michał Górny from comment #6)
> > > I'm afraid I can't say much beyond "WoT doesn't really work ".
> > 
> > well, it would if you would trust for example:
> > C4DD695FA7138F242AA1563858497EE51D5D74A5 Thomas Deutschmann
> > <whissi@gentoo.org>
> > 
> > dont you know each other ? would __really__ help me ...
> 
> I think the struggle is that there is limited interest in our side in making
> this work.
> 
>  - The procedure for signing is typically quite variable and so we tend to
> impose an onerous one (e.g. I 'know' whissi, but i have never met them and
> may never meet them.) How do you generate a WoT when your web members never
> meet? Its nominally against the tradition of meeting people in person and
> verifying their identity (to establish a trust signature.)
>  - We don't actively monitor how good / accessible the web is; so e.g. we
> have no idea how easy / hard it is to verify keys.
>  - The key infrastructure is quite bad currently, due to various attacks on
> the SKS network. We have mitigated this somewhat with keys.gentoo.org (our
> own servers that don't accept outside uploads) but it also means the WoT on
> our keyserver network will be limited...
> 
> The trust model is to trust LetsEncrypt (and thus the GPG fingerprints on
> our website.) There is no other workable trust model at present; so if you
> can't we are probably SoL for automated verification.
> 
> -A


i know that sks has some problems these days, and it is far from perfect... but it is the best we have at this moment in time. dont get me wrong ISRG/letsencrypt doing very good work but it is US. If you could add some more sigs to L1 one could prove it on their own. otherwise signing makes no sense and you could just post the checksums via https
Comment 10 dirk 2021-01-31 18:57:30 UTC 
should be possible:
https://www.gentoo.org/glep/glep-0079.html