[gentoo-user] How to recover gentoo keys and verify portage following recent update debacle

[gentoo-user] How to recover gentoo keys and verify portage following recent update debacle

[Mick]

[-- Attachment #1: Type: text/plain, Size: 5701 bytes --]

My use case may be slightly different to others who use git or webrsync.  I've 
always used rsync to keep portage up to date.  Since the portage gentoo keys 
went out of sync a couple of days ago I ended up like other gentoo users with 
a 'chicken and egg' situation.  The rsync process would fail verification 
because the public key was not available without app-crypt/openpgp-keys-
gentoo-release first being updated to the latest 20180703 version.

A poster on another thread has provided advice on using gemato to verify the 
gentoo keys, but I don't know or understand the process gemato follows to just 
type incantations on a keyboard and hope for the best.

The process I ended up using involved:

- removing all stale portage files;
- refreshing the gentoo keys manually;
- downloading the latest portage snapshot md5sum and its gpg signature;
- verifying the snapshot with gpg and using it to install the latest app-
crypt/openpgp-keys-gentoo-release.

You may find all this too radical for your needs, but I post it here in case 
others benefit from it.


1. Fetch the gentoo keys on your user keyring:

From Gentoo Release media signatures web page[1] I can see the fingerprint of 
the Gentoo Portage Snapshot Signing Key is 0xDB6B8C1F96D8BF6D.

I assumed here if this key had gone bad then Release Engineering would have 
replaced it by now.

$ gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys 0xDB6B8C1F96D8BF6D

This downloads all keys and signatures.

$ gpg --check-signatures 0xDB6B8C1F96D8BF6D

The output shows the signature on the keyserver is still valid and has not 
been revoked.


2. Remove stale portage and download the latest portage snapshot from your 
local mirror[2]:

# cd /usr
# rm -Rf portage/*
# wget <ftp://your_local_mirror.com>/snapshots/portage-latest.tar.xz*


3. Verify the snapshot was signed by the gentoo keys:

$ cd /usr
$ gpg --verify portage-latest.tar.xz.gpgsig portage-latest.tar.xz
gpg: enabled debug flags: memstat
gpg: Signature made Thu Jul  5 01:51:21 2018 BST
gpg:                using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
gpg: using subkey EC590EEAC9189250 instead of primary key DB6B8C1F96D8BF6D
gpg: using classic trust model
gpg: Good signature from "Gentoo ebuild repository signing key (Automated 
Signing Key) <infrastructure@gentoo.org>" [unknown]
gpg:                 aka "Gentoo Portage Snapshot Signing Key (Automated 
Signing Key)" [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: DCD0 5B71 EAB9 4199 527F  44AC DB6B 8C1F 96D8 BF6D
     Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F  DF1C EC59 0EEA C918 9250
gpg: binary signature, digest algorithm SHA512, key algorithm rsa4096
gpg: keydb: handles=2 locks=0 parse=0 get=3
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=1 found=3 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=18 cached=18 good=18 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/65536 bytes in 0 blocks

OK, the "Good signature" message above and the correct fingerprint is an 
encouraging indication.  Had I selected to trust this key the signature would 
be shown as trusted.


4. Untar the snapshot into portage/

# tar -xvf portage-latest.tar.xz


5. Install the latest app-crypt/openpgp-keys-gentoo-release-20180703

# emerge -1aDv app-crypt/openpgp-keys-gentoo-release


6. Remove uneeded files:

# rm -Rf portage-latest.tar.xz*


7. Sync your portage as usual, in my case:

# eix-sync

This time the verification process completes without any complains about 
public keys missing:

..
Number of files: 161,932 (reg: 134,484, dir: 27,448)
Number of created files: 25 (reg: 24, dir: 1)
Number of deleted files: 13 (reg: 13)
Number of regular files transferred: 118
Total file size: 218.65M bytes
Total transferred file size: 2.67M bytes
Literal data: 2.67M bytes
Matched data: 0 bytes
File list size: 3.41M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 32.27K
Total bytes received: 5.88M

sent 32.27K bytes  received 5.88M bytes  358.23K bytes/sec
total size is 218.65M  speedup is 36.99
 * Manifest timestamp: 2018-07-05 15:38:30 UTC
 * Manifest timestamp: 2018-07-05 15:38:30 UTC
 * Valid OpenPGP signature found:
 * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
total size is 218.65M  speedup is 36.99
 * Manifest timestamp: 2018-07-05 15:38:30 UTC
 * Valid OpenPGP signature found:
 * Valid OpenPGP signature found:
 * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
 * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
 * - timestamp: 2018-07-05 15:38:30 UTC
 * - timestamp: 2018-07-05 15:38:30 UTC
 * Verifying /usr/portage ...                                    [ ok ]
=== Sync completed for gentoo
q: Updating ebuild cache in /usr/portage ...
q: Updating ebuild cache in /usr/portage ...
q: Finished 35632 entries in 0.330802 seconds

Action: sync for repo: gentoo, returned code = 0


Finally I was able to update my system(s) with a known good portage state.

PS. In the mirror I used I found .md5sum as well as .umd5sum files, containing 
different hashes.  I have not seen .umd5sum files before, any idea what type 
of hashes these are?

PPS. Given md5 collisions are known and md5 is considered completely broken, 
why are we still using it in 2018?


[1] https://www.gentoo.org/downloads/signatures/
[2] https://www.gentoo.org/downloads/mirrors/

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]