On Sun, 2008-08-24 at 22:05 +0400, Dmitry E. Oboukhov wrote: > Package: datafreedom-perl > Severity: grave
No, that is just plain wrong, sorry. > Hi, maintainer! (and I do so hate unnecessary exclamation marks) > This message about the error concerns a few packages at once. I've > tested all the packages (for Lenny) on my Debian mirror. All scripts > of packages (marked as executable) were tested. > > In some packages I've discovered scripts with errors which may be used > by a user for damaging important system files or user's files. Dmitry - the discussion on -devel did note the risks of false positives and I would have expected that you would have taken more care before starting to file bugs. > For example if a script uses in its work a temp file which is created > in /tmp directory, then every user can create symlink with the same > name in this directory in order to destroy or rewrite some system > or user file. Symlink attack may also lead not only to the data > desctruction but to denial of service as well. Not when the use of /tmp is a *suggestion in a manpage* which just happens to be generated from POD content that is commonly embedded within perl scripts. =head1 A more complex example using 'zenity' - a Gnome dialog generator. $ pilot-qof -x data.xml --invoice-city -t 2006-11-08 | dfxml-invoice - > /tmp/zenity zenity --text-info --title="2006-11-08" --filename=/tmp/zenity --width=500 --height=300 =cut The program does not create this file, it does not rely on this file, it does not require any specific filename in /tmp and it does not write any data to /tmp unless the USER specifically pipes the STDOUT to a file and happens to use /tmp for that file. If the user is dumb enough to pipe the output to a file that is a symlink to something more important *AND* which has sufficient permissions to be a problem, then that is not the fault of the package. It is an example, nothing more. If you have filed *grave* bugs against every package that includes embedded documentation or manpage content outlining the possibility of piping STDOUT to a file that might happen to be somewhere in /tmp then you have made a huge mis-calculation. The manpage example is deliberately simplified for clarity - yes, it could have been made a lot longer by exporting a generated filename to a variable and reading that variable into the command line to zenity but there really was no point. /tmp was used because files in /tmp will be cleared out at reboot so that I didn't have to remove the file later (when it might be useful to run the zenity process a few times). Why make the example unnecessarily complicated? All it needed to show was that the redirect needs to create a file which zenity can then read. > This list is created with the help of script. This list is sorted by > hand. Howewer in some cases mistake is possible. You're not kidding. > Please, Be understanding to possible mistakes. :) Knowing that mistakes were likely makes it all the more annoying that you didn't file a LIST of possible bugs to -devel, you just went ahead. It really wasn't a good idea, that one. > I set Severity into grave for this bug. The table of discovered > problems is below. That is just the WRONG way to do a mass bug filing, IMHO. With a release pending and all these bugs supposedly *grave*, the right way to do it would have been to use the mass bug filing support in devscripts to send a list of affected packages and maintainers to -devel BEFORE filing any bugs such as to allow maintainers to identify more false positives and prevent needless churn in the BTS. > Discussion of this bug you can see in debian-devel@: > http://lists.debian.org/debian-devel/2008/08/msg00271.html Thanks for the entirely needless hassle of having to close #496429 immediately after it was filed instead of the simple courtesy of posting your intention along with the complete list of packages and maintainers. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
