Re: Review of new lintian tags
Le 6 janv. 2014 00:34, "Justin B Rye" <justin.byam.rye@gmail.com> a écrit :
>
> Bastien ROUCARIES wrote:
> > Could you review and improve the new lintian tags ?
>
> I can certainly try, though I won't be able to produce a patch for a
> diff...
>
> [...]
> > +++ b/checks/changelog-file.desc
> [...]
> > +Tag: bad-intended-distibution
> ^
> Well, there's an easy one to start off with:
> Tag: bad-intended-distribution
see answer to jonanthan
> > +Severity: normal
> > +Certainty: wild-guess
> > +Experimental: yes
> > +Info: The last changelog entry is intended to be uploaded
> > + to a particular distribution, whereas the changelog said otherwise.
>
> I'm not sure I understand what problem this is detecting (for a start,
> it talks about uploading a changelog entry rather than a package). Is
> it trying to say something along the lines of:
>
> Info: The last changelog entry implies this version is not for release.
> Instead it should specify the distribution it is to be uploaded to.
>
> (That's "distribution" in the Debian-specific sense.)
>
> [...]
> > +++ b/checks/cruft.desc
> [...]
> > +Tag: source-contains-prebuilt-flash-object
> > +Severity: pedantic
> > +Certainty: possible
> > +Info: The source tarball contains a prebuilt flash object. They are usually
> > + left by mistake when generating the tarball by not cleaning the source
> > + directory first. You may want to report this as an upstream bug, in case
> > + there is no sign that this was intended. An exception is multimedia files.
>
> What are multimedia files an exception to? I'm guessing:
>
> Info: The source tarball contains a prebuilt Flash object. These are usually
> left by mistake due to not cleaning the source directory first when
> generating the tarball. If there is no sign that it was a deliberately
> included multimedia file, you may want to report this as an upstream bug.
>
> Or maybe just (bringing it in line with the Java version):
>
> If there is no sign that it was deliberately
> included, you may want to report this as an upstream bug.
>
> > + .
> > + Please also ensure that flash object is under the preferred form
> > + of modification.
>
> How would that work? Do you mean:
>
> Please also ensure that the source is included under the preferred form for
> modification.
>
> Or is it in fact possible for a Flash object to count as source?
>
> Please also ensure that Flash object constitutes the preferred form for
> modification.
>
> (I notice the Java and Silverlight blobs don't have equivalent text, so
> maybe you do mean the latter after all.)
>
> > +
> > +Tag: source-contains-prebuilt-java-object
> > +Severity: pedantic
> > +Certainty: possible
> > +Info: The source tarball contains a prebuilt java object. They are usually
> > + left by mistake when generating the tarball by not cleaning the source
> > + directory first. You may want to report this as an upstream bug, in case
> > + there is no sign that this was intended.
>
> Info: The source tarball contains a prebuilt Java object. These are usually
> left by mistake due to not cleaning the source directory first when
> generating the tarball. If there is no sign that it was deliberately
> included, you may want to report this as an upstream bug.
>
> > +
> > +Tag: source-contains-prebuilt-silverlight-object
> > +Severity: serious
> > +Certainty: possible
> > +Info: The source tarball contains a prebuilt silverlight object.
> > + This file are not buildable under debian and need non free
> > + dependencies. This must be completely removed.
>
> There are some straightforward grammar errors here. Also, I suspect
> if I installed enough extra non-free homebrew Moonshine or whatever
> it's called then I would be able to build these objects under Debian.
> Simplify it down to:
>
> Info: The source tarball contains a prebuilt Silverlight object. These files
> are not buildable using free software and must be removed.
>
> I notice that the following "source-contains-prebuilt-windows-binary"
> description adds a paragraph that suggests "Check if upstream also
> provides source-only tarballs that you can use as the upstream
> distribution instead". Should that be offered for all these checks?
>
> [...]
> > +Tag: license-problem-non-free-rfc
> > +Severity: serious
> > +Certainty: possible
> > +Info: The given source file is licensed under the newer RFC
> > + license
> ^
> Missing punctuation.
Done
> > + .
> > + The majority of IETF documents, such as RFCs, are not licensed
> > + under DFSG-free terms, and should thus not be included in Debian's main.
>
> That's like the Spanish Main except without the piracy, right? It
> should be "in Debian's main archive" or just "in Debian main" - or
> maybe "in the main archive". (Oh, I see it's also in the Wiki page.)
>
> > + .
> > + Should this file be multi-licensed, please override the tag.
> > + .
> > + Should this be a false-positive, please report a bug.
> > +Ref: https://wiki.debian.org/NonFreeIETFDocuments
>
> That use of "should" is valid but easy to overuse - I'd recommend:
>
> If this file is multi-licensed, please override the tag.
> .
> If this is a false-positive, please report a bug against Lintian.
>
> [...]
> > +Tag: license-problem-nvidia-intellectual
> > +Severity: serious
> > +Certainty: possible
> > +Info: The given source file include part license under a
>
> I think this should be:
>
> Info: The given source files include material licensed under a
>
> And in what sense are the files "given"? Will Lintian name them in
> its output? Later descriptions say "the following file"; I'll assume
> that's correct.
following file is correct.
>
> > + non-distributable license from NVIDIA. Therefore, it is
> > + not even possible to ship this in non-free.
> > + .
> > + Please re-package the package without the file (if possible)
> > + or ask the ftp-masters to remove the package.
> > + .
> > + If the package has been uploaded to Debian before, please
> > + remember to also notify snapshot.debian.org about this
> > + package containing a non-distributable file.
> > + .
> > + Should this be a false-positive, please report a bug
> > + against lintian.
>
> Fixing some capitalisation:
>
> Info: The following source files include material under a
> non-distributable license from Nvidia. Therefore, it is
> not even possible to ship this in non-free.
> .
> Please re-package the package without the file (if possible)
> or ask the FTP-masters to remove the package.
> .
> If the package has been uploaded to Debian before, please
> remember to also notify snapshot.debian.org about this
> package containing a non-distributable file.
> .
> If this is a false-positive, please report a bug against Lintian.
>
> (No "Ref:"? I for one have no idea what this bad license looks like.)
Done
>
> > +Tag: license-problem-md5sum-non-distribuable-file
> ^
> > +Severity: serious
> > +Certainty: certain
> > +Info: The following file is not distribuable even in non free archive.
> ^
> Oh, you avoided it above, but here it is: "distribuTable".
>
> (So Lintian will give the filename _following_ this text?)
exactly
> > + .
> > + Please re-package the package without the file (if possible)
> > + or ask the ftp-masters to remove the package.
> > + .
> > + If the package has been uploaded to Debian before, please
> > + remember to also notify snapshot.debian.org about this
> > + package containing a non-distributable file.
> > + .
> > + Should this be a false-positive, please report a bug
> > + against lintian.
>
> Tag: license-problem-md5sum-non-distributable-file
> Severity: serious
> Certainty: certain
> Info: The following file is not distributable even in the non-free
> archive.
> .
> Please re-package the package without the file (if possible)
> or ask the FTP-masters to remove the package.
> .
> If the package has been uploaded to Debian before, please
> remember to also notify snapshot.debian.org about this
> package containing a non-distributable file.
> .
> If this is a false-positive, please report a bug against Lintian.
done
> > +
> > +Tag: license-problem-md5sum-non-free-file
> > +Severity: serious
> > +Certainty: certain
> > +Info: The following file is not suitable for main or contrib.
> > + .
> > + Please re-package the package without the file (if possible)
> > + or ask the ftp-masters to remove the package.
> > + .
> > + You could also split this package and move this file in the
> > + non free archive.
> > + .
> > + Should this be a false-positive, please report a bug
> > + against lintian.
>
> Only minor tweaks, most of which you've seen before:
>
> Info: The following file is not suitable for main or contrib.
> .
> Please re-package the package without the file (if possible)
> or ask the FTP-masters to remove the package.
> .
> You could also split this package and move this file into the
> non-free archive.
> .
> If this is a false-positive, please report a bug against Lintian.
>
> [...]
> > +Tag: homepage-in-binary-package
>
> Looks OK.
>
> [...]
> > +Tag: build-depends-on-an-obsolete-java-package
> > +Severity: normal
> > +Certainty: certain
> > +Ref: java-policy 2.2
> > +Info: The package build-depends on an obsolete java dependency
> > + It should built-depends on default-jdk instead.
> ^ ^
> Missing punctuation, among other things:
>
> Info: The package build-depends on an obsolete Java dependency.
> It should build-depend on default-jdk instead.
Done
> > Tag: vcs-field-uses-not-recommended-uri-format
> > -Severity: minor
> > +Severity: normal
> > Certainty: possible
> > Info: The VCS-* field uses an URI which doesn't match the recommended
> ^
> I know this hasn't changed, but "an URI" seems unlikely. Are there
> people who pronounce "URI" as "ooree"? I've never heard that - it's
> always "you-are-eye", and "you" begins with a consonant sound; so it's
> "a URI", not "an". Likewise below:
>
> > format, but still looks valid. Examples for not recommended URI formats
> > are protocols that require authentication (like SSH). Instead where
> > possible you should provide an URI that is accessible for everyone
> ^
> > without authentication.
> > + .
> > + This renders debcheckout(1) unusable in these cases.
>
> (The changed part is fine.)
>
> [...]
> > +++ b/checks/files.desc
> [...]
> > +Tag: package-install-into-obsolete-dir
> > +Severity: normal
> > +Certainty: certain
> > +Info: The package installs files in an obsolete dir. You
> > + should consider to move to newer path.
>
> Ungrammatical. "You should consider moving them to a newer path", or
> given that it's already gone past the stage of being merely deprecated
> and is considered obsolete, it's time they did more than just consider
> it:
>
> Info: The package installs files to an obsolete directory.
> Please use a newer path.
Done
>
> > +Tag: privacy-breach-generic
> > +Severity: important
> > +Certainty: wild-guess
> > +Experimental: yes
> > +Info: This package creates a privacy breach by fetching some data from
> > + an external website. Please remove these scripts or external html
> > + resources.
>
> This needs to be a lot more explicit about what the problem is - as it
> stands it could be describing wmweather or indeed wget. I gather it
> doesn't mean unintentional webbugs like a valid-HTML button, because
> that's got its own check; so what does it mean? For a start if it's
> talking about a *potential* *runtime* privacy breach then those words
> should be in the text:
>
> Info: This package creates a potential privacy breach by fetching data
> from an external website at runtime. Please remove these scripts or
> external HTML resources.
>
> (I'm standardising towards "website" and "runtime" rather than "web
> site" and "run time", our usual preference on d-l-e, since this is for
> developer consumption.)
Done
>
> > +Tag: privacy-breach-google-adsense
> > +Severity: serious
> > +Certainty: possible
> > +Info: This package creates a privacy breach by using Google Adsense.
> > + Google Adsense is a service run by Google that allows publishers of web
> > + sites to automatically serve advertisements. Unfortunately, it requires
> > + tracking and breaching privacy of our users.
> > + .
> > + This tag can also indicate the use of related obsolete privacy breaker
> > + software, Urchin WebAnalytics.
> > + .
> > + Note that using Google Adsense in a local copy of a page is a violation of
> > + Google Adsense terms of use. This violation renders this package not
> > + distributable in Debian, and thus a serious bug.
>
> It's capitalised as "Google AdSense". It needs some tweaks:
>
> Info: This package creates a privacy breach by using Google AdSense.
> Google AdSense is a service run by Google that allows publishers
> of websites to automatically serve advertisements. Unfortunately, it
> requires tracking and breaching the privacy of web users.
> .
> This tag can also indicate the use of the related obsolete privacy
> breaching software, Urchin WebAnalytics.
> .
> Note that using Google AdSense in a local copy of a page is a violation of
> the Google AdSense terms of use. This violation renders this package not
> distributable in Debian, and is thus a serious bug.
Done
>
> Notice that I have replaced "our users" with "web users", since the
> victims of the security breach aren't necessarily *our* users (in the
> sense of having ever heard of Debian).
>
> > +Tag: privacy-breach-donation
> > +Severity: serious
> > +Certainty: possible
> > +Ref: https://wiki.debian.org/UpstreamMetadata
> > +Info: This package create a privacy breach by fetching some data from
> > + a donation website.
> > + .
> > + Please remove these privacy problem and add a note on debian/upstream
> > + file using the donation field.
>
> I still don't understand what the privacy breach is here...
>
> * Does it give users the opportunity to visit an external website by
> choosing to click a button? That might be done in an annoyingly
> naggy way, but it wouldn't be even a potential privacy breach.
>
> * Does the package's web interface display a "please donate" button
> which it fetches from upstream? If so, okay, that's a trivial
> unintentional webbug that should be replaced with some sort of
> generic free image hosted locally.
Yes, it fetch from external website. flattlr upload some script from
external website.
>
> * Or is it some noxious Javascript plugin that posts my browser
> history on Facebook if I so much as think of visiting this site?
>
> I just don't know what it's talking about. But leaving aside the fact
> that it fails as a description of the issue, here's a slightly
> patched-up version:
>
> Info: This package create a potential privacy breach by fetching data
> from a donation website at runtime.
> .
> Please remove this privacy problem and add a note to the
> debian/upstream file using the donation field.
Done
> > +
> > +Tag: privacy-breach-logo
> > +Severity: serious
> > +Certainty: possible
> > +Info: This package phone home by retrieving some logo.
> > + .
> > + Before using a local copy you should be sure that the corresponding
> > + logo is suitable for main. Ask debian-legal for advices.
>
> Surely "phoning home" is what it's called when it's an *intentional*
> (malicious or at least premeditated) privacy breach, like, say, a
> one-pixel webbug? Whereas this is talking about an externally-hosted
> image which is quite probably only being fetched because they didn't
> want to make the package non-free by including a trademarked logo. It
> hardly seems "Severity: serious".
>
> Info: This package creates a potential privacy breach by fetching a
> logo at runtime.
> .
> Before using a local copy you should check that the logo is suitable
> for main. Ask debian-legal for advice.
Done
> Or if they often turn out to be non-free, maybe it should be:
>
> Please replace the image with a local copy, or (if the logo is not
> suitable for inclusion in main) a freely licensed substitute.
>
> > +Tag: privacy-breach-facebook
> > +Severity: serious
> > +Certainty: possible
> > +Info: This package create a privacy breach by fetching some data from
> > + facebook like share or like buttons.
> > + Please remove these scripts or frames.
>
> Okay, this one's serious: "privacy breach" and "Facebook" are more or
> less synonyms, in my experience, and a "Like" button isn't just an
> image that can potentially leak visitors' IP addresses, it's an iframe
> designed to harvest their login IDs. But you've got a malformed
> indent and uncapitalised Facebook.
>
> Info: This package creates a privacy breach by exchanging data with
> Facebook at runtime via plugins such as "Share" or "Like" buttons.
> .
> Please remove these scripts or frames.
Done
> > +
> > +Tag: privacy-breach-google-cse
> > +Severity: serious
> > +Certainty: possible
> > +Info: This package create a privacy breach by fetching some data from
> > + google search engine and feed some private data to google.
> > + Please remove these scripts.
>
> Is this here because it passes Google Custom Search Engine queries to
> Google (and the NSA and whoever else) in the usual way, or does the
> CSE plugin actively harvest Google+ IDs from casual visitors? Is it:
second part is true, first part surelly
> Info: This package creates a potential privacy breach by fetching
> data from Google at runtime, and may feed private data to Google via
> Custom Search Engine queries.
> .
> Please remove these scripts.
>
> Or is it:
>
> Info: This package creates a privacy breach by exchanging data with
> Google at runtime via the Google Custom Search Engine plugin.
> .
> Please remove these scripts.
>
> > +
> > +Tag: privacy-breach-piwik
> > +Severity: serious
> > +Certainty: possible
> > +Info: This package creates a privacy breach by using piwik.
> > + Piwik is a free and open source web analytics application.
> > + .
> > + Even if piwik is free and respect the "do not track" browser
> > + option, it is nevertheless a breach on our user privacy.
>
> I'll import a few words from privacy-breach-google-adsense:
>
> Info: This package creates a privacy breach by using Piwik.
> Piwik is a free and open source web analytics application, designed to
> allow publishers of websites to track visitors.
> .
> Even though Piwik is free and respects the "Do Not Track" browser
> option, it is nevertheless a breach of the privacy of web users.
>
> That last line might be going a bit far - it seems to me that an app
> that respects DNT is at worst a *potential* privacy breach. And
> besides, if I'm building the website of the Society For Web Users Who
> Value Personalisation Over Privacy, why shouldn't it have a Piwik
> plugin? (But then again, if I'm being paid to do web design I suppose
> I can't expect "sudo apt-get install website" to give me the whole
> thing on a silver platter.)
done
> > +Tag: privacy-breach-statistics-website
> > +Severity: important
> > +Certainty: possible
> > +Info: This package creates a privacy breach by fetching some
> > + data from external website in order to made visitor statistics.
> > + .
> > + Please remove these scripts from the local copy of the page.
>
> There's some other copy of the page?
>
> > + .
> > + Please ask upstream to use free software piwik that respect
> > + "do not track" browser option.
>
> Now I'm confused. If they use an analytics plugin that isn't Piwik
> then they should replace this Severity: important Lintian bug with the
> above Severity: serious Lintian bug?
I means use piwik for their upstream site
>
> > + .
> > + This tag include the following website:
> > + - cruel-carlota.pagodabox.com
> > + - linkexchange.com (defunct)
> > + - nedstatbasic.net
> > + - statcounter.com
> > + - sitemeter.com
> > + - webstats.motigo.com
>
> If the formatting works the way I think it does this should have an
> extra indent (and preferably asterisks instead of dashes). Compare
> the one in unknown-file-in-debian-source.
>
> Info: This package creates a privacy breach by fetching data from
> an external website in order to compile visitor statistics.
> .
> Please remove these scripts.
> .
> Please ask upstream to use the free software web analytics engine
> Piwik, which respects the "Do Not Track" browser option.
> .
> This tag covers the following websites:
> * cruel-carlota.pagodabox.com
> * linkexchange.com (defunct)
> * nedstatbasic.net
> * statcounter.com
> * sitemeter.com
> * webstats.motigo.com
Done
>
> > +Tag: privacy-breach-w3c-valid-html
> > +Severity: serious
> > +Certainty: possible
> > +Ref: http://validator.w3.org/docs/help.html#icon,
> > + http://www.w3.org/Consortium/Legal/logo-usage-20000308
> > +Info: This package creates a privacy breach by w3c valid documents icons.
> > + .
> > + To show readers that one has taken some care to create an interoperable
> > + Web page, a "W3C valid" badge may be displayed on any page that validates.
>
> "Interoperable" seems like the wrong jargon term - shouldn't it take at
> least two things to be inter-anything-able? Just say "standards
> compliant".
>
> And the use of quotes implies that the badge's lettering includes the
> words "W3C valid", which they don't - they say "W3C HTML 4.01 ✓" or
> the like (while the filenames are things like "valid-html401.png").
>
> > + .
> > + Unfortunatly it means phoning home and download image from w3c website,
> > + and thus allowing to track users.
> > + .
> > + Note that these icons are non free and must not be copied
> > + inside the package. You could safely delete this "W3C valid" badge.
>
> Again, calling this "phoning home" is tendentious. Do we have some
> reason to think the W3C are in fact tracking the IP addresses of all
> the web users who happen to visit a page with a "valid HTML" button?
> How is this the same severity as the Facebook "share-my-secrets"
> plugin?
>
> (Then again, what's this icon doing in a Debian package? We can only
> certify that the page was valid HTML "out of the box", before the
> local webmaster started sabotaging it!)
>
> Info: This package creates a potential privacy breach by fetching W3C
> validation icons.
> .
> These badges may be displayed to tell readers that care has been
> taken to make a page compliant with W3C standards. Unfortunately,
> downloading the image from www.w3.org might expose the reader's IP
> address to potential tracking.
> .
> Note that these icons are non-free and must not be copied into the
> package. You could safely delete this W3C validation badge.
Done
> [...]
> > Certainty: certain
> > Ref: http://lists.debian.org/debian-devel/2009/03/msg00119.html
> > Info: Files in <tt>/etc/modprobe.d</tt> should use filenames ending in
> > + <tt>.conf</tt>. modprobe silently ignores all files which do not match
> > + this convention.
>
> No problem here.
>
> [...]
> > Info: The arch all pkg-config file contains reference to an multi-arch path.
> ^ ^
> Hmm, are phrases like "arch all" and "arch any" just DD slang for
> "Architecture: all"? Should the spelling be "Arch:all" or "ARCH=all"
> or "--arch-all" or what? I'll leave it as it is.
>
> Info: The arch all pkg-config file contains a reference to a multi-arch path.
>
> Or maybe refers to a multi-arch path.
>
> If this was intended for user consumption I'd think about translating
> it as something like "multi-arch-compliant library path", but I'll
> assume for Debian developers this is intelligible.
>
> No, wait, isn't it "multiarch"? Everyone else seems to think so...
> but Lintian consistently spells it with a hyphen.
>
> > .
> > This can be usually be fixed by moving this file to a multi-arch path.
> > + .
> > + Another likely cause is using debhelper 9 or newer (thus enabling
> > + multi-arch paths by default) on a non multi-arched package.
> > + The usual cure is in this case to render your package multi-arch.
>
> Another likely cause is using debhelper 9 or newer (thus enabling
> multi-arch paths by default) on a package without multi-arch support.
> The usual cure in this case is to update it for multi-arch.
Done
> [...]
> > +Tag: debian-rules-should-not-use-underscore-variable
> > +Severity: normal
> > +Certainty: possible
> > +Ref: policy 4.9
> > +Info: The rules file use the make variable $(_).
> ^
> s/use/uses/
>
> > + .
> > + According to Policy 4.9, "invoking either of `make -f debian/rules
> > + _args..._' or `./debian/rules _args..._' must result in identical
> > + behavior." One way to inadvertently violate this policy is to use the $_
> > + variable.
>
> Getting a bit nitpicky: I don't see any uses in Lintian descriptions
> of `this' style of quotes, or _underscores_ to mark variables.
> Looking at the original in Policy 4.9 and coverting that into
> Lintian-style markup, it's:
>
> According to Policy 4.9, "invoking either of 'make -f debian/rules
> <args...>' or './debian/rules <args...>' must result in identical
> behavior." One way to inadvertently violate this policy is to use the $_
> variable.
>
> Though at other times Lintian seems to use markup along the lines of:
>
> According to Policy 4.9, <q>invoking either of <tt>make -f debian/rules
> <args…></tt> or <tt>./debian/rules
> <args…></b>' must result in identical behavior.</q>
> One way to inadvertently violate this policy is to use the $_ variable.
>
> > + .
> > + If rules file uses $(dir $(_)) to discover directory containing
> > + source package (presumably in order to implement get-orig-source
> > + target), please replace it by $(dir $(firstword $(MAKEFILE_LIST))).
>
> Missing articles:
>
> If the rules file uses $(dir $(_)) to discover the directory containing
> the source package (presumably in order to implement the get-orig-source
> target), please replace it by $(dir $(firstword $(MAKEFILE_LIST))).
Done
> [...]
> > +Tag: maintainer-script-should-not-use-update-alternatives-set
> > +Severity: normal
> > +Certainty: certain
> > +Info: <tt>update-alternatives --set <alternative> foo</tt> or
>
> Sentence fragment.
>
> > + <tt>update-alternatives --config <alternative></tt> or
> > + <tt>update-alternatives --set-selections</tt>
> > + called in maitainer script. Thus it's impossible to distinguish
> ^
> > + between an alternative that's manually set because the user set it,
> > + vs. one that's manually set because the package set it.
> ^^
> > +Ref: update-alternatives(8)
>
> Info: The maintainer script calls <tt>update-alternatives --set
> <alternative> foo</tt> or <tt>update-alternatives --config
> <alternative></tt> or <tt>update-alternatives --set-selections</tt>.
> This makes it impossible to distinguish between an alternative that's
> manually set because the user set it and one that's manually set because
> the package set it.
>
> Or to say the same thing without the tags:
>
> Info: The maintainer script calls 'update-alternatives --set <alternative>
> foo' or 'update-alternatives --config <alternative>' or
> 'update-alternatives --set-selections'. This makes it impossible to
> distinguish between an alternative that's manually set because the user
> set it and one that's manually set because the package set it.
>
> (Or maybe "The maintainer script apparently calls"...)
>
> [...]
> > +Tag: maintainer-script-should-not-use-install-sgmlcatalog
>
> No problems.
>
> > +Tag: maintainer-script-should-not-use-service
> > +Experimental: yes
> > +Info: The maintainer script apparently runs service command.
>
> the 'service' command.
>
> > + This command is reserved for local
> > + administrators and must never be used by a Debian package.
>
> > +
> > +Tag: maintainer-script-should-not-use-adduser-system-without-home
> > +Severity: serious
> > +Certainty: certain
> > +Info: The maintainer script apparently runs adduser --system
> > + without specifying --home option outside /home/.
>
> Er, what? Oh, when it says "*without* specifying it *outside* /home"
> does it mean "while specifying it as inside /home"?
>
> > + The FHS says "/home is a fairly standard concept, but it
> > + is clearly a site-specific filesystem. The setup will differ
> > + from host to host. Therefore, no program should rely on this
> > + location."
> > +Ref: fhs homeuserhomedirectories
>
> Info: The maintainer script apparently runs 'adduser --system'
> but hardcodes a path under '/home' for the '--home' option.
> The FHS says "/home is a fairly standard concept, but it
> is clearly a site-specific filesystem. The setup will differ
> from host to host. Therefore, no program should rely on this
> location."
Done
> [...]
> > +Tag: debian-watch-may-check-gpg-signature
> > +Severity: pedantic
> > +Certainty: certain
> > +Ref: uscan(1)
> > +Info: This watch file does not include a means to verify
> > + the upstream tar using cryptographic signature.
>
> the upstream tarball using a cryptographic signature.
>
> > + .
> > + If upstream distributions provide such signatures please
> > + use the pgpsigurlmangle options in this watch file
> > + opts= to generate the upstream URL of an GPG signature.
> > + This signature is automatically downloaded and verified
> > + against a keyring stored in debian/upstream-signing-key.pgp
>
> If upstream distributions provide such signatures, please
> use the pgpsigurlmangle options in this watch file's
> opts= to generate the URL of an upstream GPG signature.
> [...]
>
> > + Of course, not all upstream distributions provide such
> > + signatures but you could try to request such signatures
> > + from upstream and thus verifying that not a third party
> > + modified the code after the release against the will
> > + of upstream. We all know the phpmyadmin, unrealircd
> > + or proftpd security bugs (only to mention some of
> > + them). This would at least make it a lot harder for an
> > + attacker to get such code to a wider audience through
> > + distributions like Debian.
>
> ("We" here must be DDs, because I hadn't heard of those bugs.)
>
> Of course, not all upstreams provide such signatures, but
> you could request them as a way of verifying that no third
> party has modified the code against their wishes after the
> release. We have all heard of the phpmyadmin, unrealircd, or
> proftpd security bugs (to mention only a few). This would at
> least make it a lot harder for an attacker to get such code
> to a wider audience via distributions like Debian.
Done
> > +Tag: debian-watch-file-pubkey-file-is-missing
> > +Severity: important
> > +Certainty: certain
> > +Ref: uscan(1)
> > +Info: This watch file verify cryptographic signature but
> > + the upstream public key is missing.
> > + .
> > + Please add upstream public keys in debian/upstream-signing-key.pgp.
>
> Info: This watch file verifies a cryptographic signature but
> the upstream public key is missing.
> [...]
>
> Phew!
Thank you will send you the new diff.
Bastien
> --
> JBR with qualifications in linguistics, experience as a Debian
> sysadmin, and probably no clue about this particular package
Reply to: