full-disclosure - RPM verification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3D6E2DAE.3050507@pre-secure.de>
From: ag at pre-secure.de (Axel Grossklaus)
Subject: RPM verification

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Griffiths wrote:

moin,

just a few remarks...

| Product: rpm
| Version tested: 4.0.4

| - SuSE recommends to verify with rpm -v --checksig file.rpm. They were
not
| contacted.

on the suse distribution the keys for rpm validation are already kept in
a separate file /usr/lib/rpm/gnupg/pubring.gpg.
and gpg ist called with "--keyring /usr/lib/rpm/gnupg/pubring.gpg"
(suse patched that into rpm) but
- --keyring only _adds_ keys in the keyring. the keys in the
default keyring in the users home are used as well.
seeing /usr/lib/rpm/gnupg/pubring.gpg might fool someone into believing
that _only_ those keys are used, which would require setting
- --no-default-keyring as well.

i dont know if /usr/lib/rpm/gnupg/pubring.gpg was added just to make
sure the key is available regardless of what the user has in his
gnupg-home or for security reasons.

if it was for security reasons (which i dont think), its broken :-}

this might be a matter of taste, but keeping keys for rpm-signatures
in a different file is certainly a good idea, i think.

unfortunately, this is not really easy to do system-wide, since gpg
wants to lock files and write temp-files into its home-directory,
so setting %_gpg_path to /usr/lib/rpm/gnupg/ doesnt work.
each admin on a system has to fix it for himself.

otoh, i dont think that using rpm -v --checksig is a good
idea either. its too easy to make a key that looks almost (but
not quite ;) ) like a given other key. and who really wants to
memorize the complete fingerprint and key id?

maybe it would work if rpm created an empty temporary directory,
used that directory with --homedir and then add --keyring
/usr/lib/rpm/gnupg/pubring.gpg and --no-default-keyring
(and maybe some option to deal with the trustdb handling) might work.
but there has to be a more elegant solution than this.

i will look a little deeper into the last two points..

| - Future versions of RPM (4.1) will not be using gpg externally, but
| will be maintaining the keys to verify internally.

how exactly will that version work?

tty, axel

p.s.: all tests were done using 3.0.6 (suse still uses rpm 3.x)
~      and gpg 1.0.7

- --
Axel Grossklaus                            PRESECURE (R)
Security Specialist,                     Consulting GmbH
Phone: (+49) 040 / 480 4224             ag@...-secure.de

~      Check on European Security Incident Response Teams
~      http://www.ti.terena.nl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9bi2tHAHtNfez9GYRAo5FAJ9PZKUqBVXUbS1nFieGZXDHYRsb5gCffBFq
+wFh1nlPGkchO4vDrdBSF7U=
=B5T7
-----END PGP SIGNATURE-----