Bug 768012 – WOT verification of install*.DIGESTS.asc not possible

• Status: UNCONFIRMED
• Product: Gentoo Release Media

[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) <[e-mail]>
sig 3        BB572E0E2D182910 2013-08-24  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2015-08-26  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2017-08-22  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2019-02-23  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2019-04-27  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2019-10-30  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2020-04-24  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sig 3        BB572E0E2D182910 2019-02-24  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>
sub   rsa2048 2019-02-23 [S] [expires: 2022-07-01]
sig          BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering (Automated Weekly Release Key) <[e-mail]>


any idea? am i doing sth wrong ?

cheers
dirk

[Comment 1 Matt Turner 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) 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) <[e-mail]>
> sig 3        BB572E0E2D182910 2013-08-24  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2015-08-26  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2017-08-22  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2019-02-23  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2019-04-27  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2019-10-30  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2020-04-24  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sig 3        BB572E0E2D182910 2019-02-24  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> sub   rsa2048 2019-02-23 [S] [expires: 2022-07-01]
> sig          BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering
> (Automated Weekly Release Key) <[e-mail]>
> 
> 
> 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) <[e-mail]>
> > sig 3        BB572E0E2D182910 2013-08-24  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2015-08-26  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2009-08-25  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2017-08-22  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2019-02-23  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2019-04-27  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2019-10-30  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2020-04-24  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sig 3        BB572E0E2D182910 2019-02-24  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > sub   rsa2048 2019-02-23 [S] [expires: 2022-07-01]
> > sig          BB572E0E2D182910 2020-09-20  Gentoo Linux Release Engineering
> > (Automated Weekly Release Key) <[e-mail]>
> > 
> > 
> > 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 2021-01-31 10:03:18 UTC]

You're looking for:

sig 3   P    55D3238EC050396E 2019-04-01  Gentoo Authority Key L2 for Services <[e-mail]>

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 <[e-mail]>
> 
> 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 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 <[e-mail]>

dont you know each other ? would __really__ help me ...

[Comment 8 Alec Warner (RETIRED) 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
> <[e-mail]>
> 
> 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
> > <[e-mail]>
> > 
> > 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