Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 26 Sep 2012 09:35:15 -0600
From: Kurt Seifried <>
Subject: Re: Re: Re: Re: CVE request(?): gpg: improper file
 permssions set when en/de-crypting files

Hash: SHA1

On Monday 24 September 2012 22:03:20 Steven M. Christey wrote:
> FYI, this discussion is an interesting example of what I've called the
> "snowball effect" in CVE when new kinds of issues arise that test the
> boundaries of what should or should not belong in CVE - allowing one (or a
> handful) could open the door to hundreds or thousands of other products
> that have the same issue.

I think it might make sense to look at this issue along the lines of RFC
rfc2119 and sort the problems out a bit.

Classification of program output sensitivity, on a sliding scale:

MUST - GPG private key, OpenSSH private key, OpenSSL private keys,
some log files for server apps, etc.
[MUST - where having the file revealed would grossly impact
security/negate the whole point of the operation/program or where
there is a significant chance of sensitive data being output in the
normal course of operations, for examples servers running in debug
mode that log credentials in the log file]

SHOULD - Generic output from crypto programs/etc. health/finance apps
[SHOULD - potentially sensitive data such as encrypted content, health
and finance data, other regulated output, chat logs, etc. Things that
would typically contain potentially sensitive data in output]

MAY - Generic output from things like tar/archivers, editors, etc.
[MAY - none or extremely minimal negative impact, performance
wise/etc, for example a file down loader]

SHOULD NOT - nothing comes to mind
[SHOULD NOT - where securing the output has a negative impact]

MUST NOT - nothing comes to mind
[MUST NOT - where securing the output would have a significant
negative impact]

OPTIONAL - catch all for weirdness
RECOMMENDED - anything can have one more more recommended

Basically stick programs into this framework with evidence/reasoning as
to why they fit there, please note that a program may fit into one or
more categories, e.g. some output (like key creation) falls under MUST
and some (like encrypted messages) fall under SHOULD (this is an
example, I'm not saying encrypted messages are a "SHOULD" and not a
"MUST", I just needed an example).

So at least this way we bring some sanity/order to the problem rather
than this general mishmash of "well it should" and so on.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.