Bug#889066: lintian should warn if the maintainer scripts include "chown -R" or "chmod -R"
Hi,
On Fri, 02 Feb 2018, Chris Lamb wrote:
> > you do not suggest any alternative (how do I fix change
> > permissions/ownership securely?)
>
> Indeed, as the consensus is still not clear at this point. Do you
> have any suggestions for such a text?
Consensus? Has there been a broader discussion on this topic that I
missed?
In any case, maybe we could encourage the use of "-h / --no-dereference"
on such calls?
Of if there is no consensus, but multiple suggestions have been made,
then it's probably best to list all the possible solutions that have been
pointed out (maybe usage of systemd's dynamic user feature).
> > Please try to be a bit more restrictive in what new tags you are
> > accepting.
>
> You seem to be implying this is a pattern. If so, please could you
> provide some other examples so I could understand better?
Well, it seems to me that you could put a bit more thought up-front
when a new tag is added... it seems to me that tags are added and
that sub-sequesent versions often provide a longer explanation
with more context and/or with new ways to not trigger the tag (i.e. that
do not require adding an override).
That was the case with new-package-should-not-package-python2-module
and dependency-on-python-version-marked-for-end-of-life.
In any case, it's not a big deal, I largely prefer having lintian very
actively maintained with a few mistakes quickly fixed than having no new
checks... but you are still the gatekeeper, Debian developers have lots
of (sometimes weird) desires/wishlists for a tool like lintian and you
should help them better define their checks before merging them.
You could have a checklist:
- Does the long description tell the maintainer how to fix the problem?
Can it include a reference te some relevant documentation?
- Does the long description gives the rationale why this is a problem
in the first place?
- Can we have a mechanism to not trigger the tag when the maintainer
knows that it's a false positive (without adding an explicit override
tag)?
- Did someone do an estimation of the false positive ratio? Is it
reasonable?
> This was a judgement call based on the severity of the problem (it,
> after all, had a CVE). Personally I'd rather have a check for such
> an issue that had an incomplete long description than not have the
> check at all. Clearly, this would not apply to a trivial or even a
> normal issue..
Sorry, what CVE are you referring to?
In my case, I remember having touched many packages with dedicated
users created and I expect this tag to have a very high false positive
ratio. If you know this, you might want to acknowledge it in the long
description explaining that you accept the false positives because
of the security impact of any case where nobody took the time to
analyze the security implications (but then again you should help the
maintainer to do his own assessment, what is safe and what is not safe?).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
Reply to: