On Sat, 2014-12-20 at 02:10 -0200, Henrique de Moraes Holschuh wrote: > IMHO, the suggested wording does get the point across that whomever wants to > use RPATH/RUNPATH must be prepared to defend its use with strong technical > reasons.
Exactly. Without it I was concerned this would tacitly condone use of RPATH/RUNPATH and that's counterproductive. (At the same time there seem to be cases where complete avoidance is difficult hence the escape clause). > > This part looks good. > > IMO, it is too weak. This is about introducing security hazards, so... "weak" is a feature :) My suggested text is not perfect. My aim is to seed uncontroversial text that will educate, delimit bad practice, serve as a basis for further refinement. Perfect has been the enemy of good here. > And in fact, I'd add: > > "Packages are not allowed to create *and* execute libraries or executables > with unsafe RPATH or RUNPATH at any time, not even during their build > process." But actually "Package maintainers should not make or run dangerous stuff"? Agreed -- and also seems uncontroversial. Although I think you mean "or" not "and"? Perhaps neither/nor to kill any ambiguity: > 8.7 RUNPATH and RPATH > > Libraries and executables should not define RPATH or RUNPATH unless > absolutely necessary. > > Those that do should ensure that relative paths or paths that traverse > insecure directories (eg /tmp or /var/tmp) are not included. This > is to prevent an executable from loading a library from an untrusted > location. (This should include the corner cases whereby the path list > starts or ends with a colon, or includes two consecutive colons). > > Packages should neither create nor execute libraries or executables > with unsafe RPATH or RUNPATH at any time, not even during their > build process. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org