On Fri, Nov 04, 2005 at 08:12:39AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: > > There are a number of outstanding "insecure tempfile vulnerabilities", > > and there has been some talk that they're both too numerous and of low > > enough impact that they're not even worth releasing DSAs for. Never the > > Where was that talk done? I've been the one auditing that and there have been > DSAs for most of the bugs I've reported to the audit team. Granted, they are > not being issued inmediately (I usually provide the report and a patch), but > they are on the queue as far as I know. Yes, your numerous reports are what lead to this discussion, which happened within team@security. Basically somebody was like "whoa, we'll never be able to fix all of these! And why should we, anyway, since the problems are so minor?" So it was proposed to at least provide an additional layer of safety so we can say that this class of bugs generally does not affect our default configuration. > The problem is, there's lots of those. And when I mean lots I mean that I > have a list of ~4780 binary packages of which at least ~2300 make use of > insecure tempfiles for sure and the others need to be reviewed (as the script So can we really be expected to release ~2300 DSAs to fix all these things? Even with patches to fix them, it's going to be an insane amount of work. This is exactly why we want libpam_tmpdir. > IMHO, it's a worthwhile goal for etch but it should be done at the same time > that there is a policy change mandating the use of mktemp/tempfile for shell > scripts, File::Temp in perl scripts, tempnam in Php, tmpfile in C and safe > constructs in those languages that lack a proper implementation (see #291389, > for example). You may be right that a policy change would be required. Packages would need to respect $TMP or $TMPDIR in order for this proposal to work. As has been pointed out earlier (Joey Hess mentioned CUPS breaking), this may result in a number of bugs. noah
Attachment:
signature.asc
Description: Digital signature