Re: Re: Re: Re: CVE request(?): gpg: improper file permssions set when en/de-crypting files

["Steven M. Christey" <coley () rcf-smtp mitre org>]

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.

Personally, I would expect a security/privacy-preserving product to select 
the most conservative file permissions that it knows won't violate the 
user's intention; in this case, the permissions of the original "source" 
file, as further restricted by the user-specified umask.  If the user 
calls gpg with a world-readable file and a "promiscuous" umask, then they 
deserve what they get.  If a product decides to be more restrictive than 
even the user specifies, then that's OK, but I would view it as a 
hardening measure, which generally doesn't get a CVE.

Note that's a personal view, not any "official" CVE decision. This is 
still an ongoing discussion.

There is historical precedent for archivers like ZIP or tar that have race 
conditions where they initially create files world-readable (in some 
cases, probably inheriting umask) and don't restrict the permissions until 
after the extraction is complete.  That's a more clear example, however, 
because the products have functionality that intends to impose the 
required permissions, but don't do it quickly enough.

- Steve