Raphael Hertzog <hert...@debian.org> writes: > I think that cleaning the environment will create way more problems than > what you expect.
Perhaps, though there's certainly room for discussion on how extensively to clean, and even whether to use a whitelist or a blacklist. > - for a start, the debconf UI might be pre-existing Good point, I'd forgotten the d-i case, and likewise acknowledge that some Debconf frontends use DISPLAY (and for that matter XAUTHORITY). > - dropping http_proxy might break maintainer scripts calling wget Right, that would be appropriate to keep too. > - we obviously don't want to drop LANG and LC_* Pas du tout! ;-) > - respecting TMPDIR seems a good idea rather than a bad one That's more debatable; private TMPDIRs may not be world-writable, which could bite scripts that (directly or indirectly) launch processes as non-root users. (For that matter, root might not even be able to use private TMPDIRs if they're on remote filesystems for some reason). > I think it should be invoke-rc.d or something below this. Perhaps both. There are variables (DISPLAY and XAUTHORITY, for instance) that are desirable to expose to maintainer scripts but not to long-running services, but also some that I'd still argue neither should see, including for instance the three initial examples of KRB5CCNAME, TEXMF, and TMP(DIR). BTW, the file-rc package ships an alternate invoke-rc.d implementation; I've added its maintainers to the Cc: list. > For dpkg, the only place where it might be helpful is start-stop-daemon. I do agree that changing only s-s-d would be insufficient. At any rate, thanks for the quick response! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org