[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SCM] Debian package checker branch, master, updated. 2.5.12-18-g9414d59



On 2013-04-20 20:29, Jakub Wilk wrote:
> * Niels Thykier <niels@thykier.net>, 2013-04-20, 15:20:
>> Emitting a tag is fairly simple; the hard part is emitting exactly
>> -when there is an issue.
>> +when there is an issue and without introducing a security issue.
> 
> "issue" appears twice in the sentence, in slightly different meanings.
> Maybe change "security issue" to "security hole"?
> 
>> +Lintian.  The problem is people can in theory create some really nasty
>> +packages that exceeds our ability to imagine such trickeries.
> 
> s/exceeds/exceed/. But I think the whole sentence is awkwardly phrased...
> 
>> +When you any one of those wrong you introduce "arbitrary code
>> +execution"
> 
> I can't parse this sentence.
> 

Thanks for the review.  What do you think of the revised version in the
attached diff?

~Niels


diff --git a/doc/tutorial/Lintian/Tutorial/WritingChecks.pod b/doc/tutorial/Lintian/Tutorial/WritingChecks.pod
index bdf5c21..e4f5721 100644
--- a/doc/tutorial/Lintian/Tutorial/WritingChecks.pod
+++ b/doc/tutorial/Lintian/Tutorial/WritingChecks.pod
@@ -139,7 +139,8 @@ file, the above will faithfully emit said tag for all packages
 processed by this check.
 
 Emitting a tag is fairly simple; the hard part is emitting exactly
-when there is an issue and without introducing a security issue.
+when there is an issue and without introducing a security hole in
+Lintian/your check.
 
 
 =head2 Accessing fields
@@ -502,16 +503,16 @@ in binary packages and "Same as debfiles" in source packages.
 
 Over the years a couple of security issues have been discovered in
 Lintian.  The problem is people can in theory create some really nasty
-packages that exceeds our ability to imagine such trickeries.  Please
-keep the following in mind when writing a check:
+packages.  Please keep the following in mind when writing a check:
 
 =over 4
 
 =item * Avoid 2-arg open, system/exec($shellcmd), `$shellcmd` like the
 plague.
 
-When you any one of those wrong you introduce "arbitrary code
-execution" (we learned this the hard way via CVE-2009-4014).
+When you get any one of those wrong you introduce "arbitrary code
+execution" vulnerability (we learned this the hard way via
+CVE-2009-4014).
 
 Usually 3-arg open and the non-shell variant of system/exec are
 enough.  When you actually need a shell pipeline, consider using

Reply to: