Le 6 janv. 2014 00:34, "Justin B Rye" <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/cae2spazus7f8y5jzu2ykhu3ym_0r65xtpptp8eo51w232yr...@mail.gmail.com
