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/
