Bug 69186 - Add configurable signature checking policies.
Add configurable signature checking policies.
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
OS
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-18 14:17 EDT by Aleksey Nogin
Modified: 2009-01-30 03:48 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-30 03:48:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hdrchk configuration and simple benchmark (2.71 KB, text/plain)
2002-07-24 15:24 EDT, Jeff Johnson
no flags Details

  None (edit)
Description Aleksey Nogin 2002-07-18 14:17:40 EDT
It would be nice to be able to add something to a config file that would make
the "require a valid signature" a *local* default.

IMHO, this might be implemented as a configuration/macro variable that specifies
how much attention should be payed to signatures. The values should probably be:

- ignore (do not check the signatures unless explicitly requested - e.g. 
pre-4.1 behavior).
- warn (current Limbo behavior)
- error (abort if signature is present, but can not be checked or fails)
- require (same as "error", but also abort if no signature present).

( According to Jeff Johnson, lib/package.c already contains a comment:
  /** @todo Implement disable/enable/warn/error/anal policy. */         )

It should be possible to specify the value of this macro both in a config file
(which would ship with "warn" by default) and on command line (with command line
taking precedence)...

This way for people who do not care that much it would look identical to how it
looks right now, but people who care more, can always replace "warn" with
"error" or "require" in their config files (and still be able to override it on
command line when desired).
Comment 1 Jeff Johnson 2002-07-24 15:22:44 EDT
rpm-4.1-0.53 now has more mechanism (not policy, yet)
to configure checking headers retrieved when 1st encountered.
Comment 2 Jeff Johnson 2002-07-24 15:24:20 EDT
Created attachment 66845 [details]
hdrchk configuration and simple benchmark
Comment 3 Jeff Johnson 2002-08-06 09:48:49 EDT
OK, the hdrchk mechanism has been simplified/generalized
so that headers are signature checked on all import pathways,
and on database export pathways, all per-mode configurable.

Wiring the policy of what ignore/warn/error/require action
to take with OK/UNTRUSTED/NOKEY/BAD events is gonna take
a bit more time to implement, particularly since rpm has
not a clue ATM about UNTRUSTED.

The other major problem is drilling the policy up through
applications (very few ATM) that use rpm-4.1. That's gonna
take some time and patience and porting as well.

Deferred until rpm-4.2.
Comment 4 Aleksey Nogin 2002-11-05 23:43:58 EST
> Deferred until rpm-4.2.

Rawhide has 4.2-0.5 now, reopening.
Comment 5 Bastien Nocera 2004-05-27 09:07:03 EDT
Moving to the Enterprise version.
Comment 10 Jeff Johnson 2004-08-18 13:46:22 EDT
--signature is not the reverse of --nosignature, as it implies
mandatory failure on certain conditions; rpm default behavior
already verifies signatures as present.

The option, if attempted, also needs to be peristently configurable.
My original thoughts were to set up bit masks for each of the
failure modes for each of the modes of rpm for each of the 4
signatures/digests so that the user could, say, permit query
with a warning, but prevent install independently.

Most of this mechanism is already implemented, what remains is to
design the error return path ways for FAILNOW, exit(1) within rpmlib
is not good enough, nor is a secret side effect like skipping
a package. That is basically my comment cited above
      disable/enable/warn/error/anal
where the "error/anal" behaviors are not yet implemented.   

The inertia to change comes from the plethora of applications
that are using rpm, where each and every application is attempting
a different form of key ring management, and hence has a different
meaning for TRUSTED.
Comment 14 Jeff Johnson 2004-08-19 15:48:29 EDT
rpmlib does exit(1) only for OOM, been that way for long time now.

OTOH, immediate exit is essentially what the "anal" level is about,
where an instant and immediate full stop may be appropriate.

"error" returns an error code from rpmlib. The rate limiting steps are that
the rpmlib API is not adequate to return well-defined error codes
on well-known pathways. The other impediment is that new error
returns must be taught to all applications that use rpmlib.
Comment 16 Robert Perkins 2004-09-08 21:45:14 EDT
This feature is not far enough along for U4.  Because the deadline is today,
moving to RHEL3 U5 as a candidate.
Comment 17 Robert Perkins 2005-01-05 10:52:49 EST
Closing because of lack of customer/partner demand.
Comment 18 Robert Perkins 2005-01-05 19:33:15 EST
Reopening and moving to Fedora at request of originator.
Comment 20 Red Hat Bugzilla 2007-02-05 14:18:08 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 21 Red Hat Bugzilla 2007-08-21 01:17:04 EDT
User pnasrat@redhat.com's account has been closed
Comment 22 Panu Matilainen 2007-08-22 02:29:32 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 23 Panu Matilainen 2008-04-01 06:50:33 EDT
Fixing summary to something more sensible..
Comment 24 Panu Matilainen 2009-01-30 03:48:29 EST
Moved to upstream tracking: http://rpm.org/ticket/29

Note You need to log in before you can comment on or make changes to this bug.