#734402 lintian: [refining a test] take in account man macros existing in the build tree

Package:
lintian
Source:
lintian
Submitter:
Georges Khaznadar
Date:
2014-08-24 11:18:04 UTC
Severity:
normal
#734402#5
Date:
2014-01-06 22:07:15 UTC
From:
To:
Dear Maintainer,
I propose to refine a little the check for warnings in manpages
Here are my replies to the ordinary questions:

   * What led up to the situation?
       when I tried to enhance the package tix, lintian complained for every
manpage
       because the file tix.tmac could not be found. However the right macro
file
       did exist under the debian directory, in a right place for groff.

   * What exactly did you do ?
      I patched the current version of lintian to add one feature: searching a
directory
      which may contain man macros, and adding an environment variable for the
      test based on "man --warnings"
   * What was the outcome of this action?
      When I installed the modified lintian package, the false warnings
disappeared.
#734402#10
Date:
2014-01-07 05:47:17 UTC
From:
To:
Hi,

Thanks for reporting this issue.
    my $macro_path = $info->unpacked

If so, we can probably settle this one by quoting the $macro_path
variable in the ``.  Otherwise, this is a possible CVE (if $macro_path
is taken from the package, it is a "trivial" matter creating a file/dir
in the package which causes the above line to suffer from shell command
injection).
  Maybe use -print0 if tr supports null -> ":", but that is nitpicking.
 Alternatively there is File::Find.

Personally, I am not familiar with the "tmac" files; are they always
expected in a dir called "tmac"?  And can they really be anywhere in the
package?  Or can we narrow it down to say usr/share/ ?

~Niels
#734402#15
Date:
2014-01-07 05:47:17 UTC
From:
To:
Hi,

Thanks for reporting this issue.
    my $macro_path = $info->unpacked

If so, we can probably settle this one by quoting the $macro_path
variable in the ``.  Otherwise, this is a possible CVE (if $macro_path
is taken from the package, it is a "trivial" matter creating a file/dir
in the package which causes the above line to suffer from shell command
injection).
  Maybe use -print0 if tr supports null -> ":", but that is nitpicking.
 Alternatively there is File::Find.

Personally, I am not familiar with the "tmac" files; are they always
expected in a dir called "tmac"?  And can they really be anywhere in the
package?  Or can we narrow it down to say usr/share/ ?

~Niels