Review of seclists
Hello Guilherme,
I decided to start a different thread for the review of seclists.
Let's start with the lintian findings:
1) I believe you already have lintian setup like this, but just in
case; I suggest people to always use the options -i -I -E --pedantic
(you can check the manpage for the explanation on those).
2) E: seclists: python3-script-but-no-python3-dep
usr/share/seclists/Payloads/Zip-Traversal/make.py #!python3
Since this file is supposed to be used as a payload, this finding can
be overridden/suppressed.
You can get a little bit more context from reading the following:
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#lintian
https://manpages.debian.org/unstable/lintian/lintian.1.en.html#FILES
And by looking at how other packages are doing, for that you can
search either on salsa or codesearch.debian.net
Please reach out with any questions you might have.
3) seclists: executable-not-elf-or-script
This one can be a little tricky, you'll have to understand how those
files are used to be able to confirm what you should do there;
3a) Remove the execute permission
3b) Set the "correct" shebang
In order to know this, you're gonna have to contact upstream, as
either of those two options should be upstreamed anyway. My gut
feeling tells me upstream probably don't care about it, in the sense
that they don't expect those files to be called from the shell.
Ideally, in this scenario, they should also remove the execute
permissions to avoid setting the wrong expectations.
But there's also some low chance upstream does want them to be called
from the shell, and thus there's a bug there because of the missing
shebang.
Think about this issue, try to understand it fully, and then we can
have a discussion on how to approach this.
4) W: seclists source: missing-field-in-dep5-copyright Copyright
(paragraph at line 53)
The copyright holders are missing there.
5) seclists: national-encoding
There's two cases of this, and I'm still not sure about what to do there:
5.1) Fuzzing/Databases/MSSQL-Enumeration.fuzzdb.txt: I don't know if
this is intentionally not UTF-8
5.2) Passwords/dutch_wordlist: This one is probably intentionally not
UTF-8, and I'm not sure if we can convert it without breaking some
functionality.
6) seclists source: space-in-std-shortname-in-dep5-copyright
Please read the full description for this finding and fix the License
name according to the DEP-5 specification. This license might be
already in use by another package so you can copy it if you find it.
7) seclists: extra-license-file
Check if those license files are already declared in d/copyright and
then tweak d/rules to not install them,
You can do that with dh_install -X$file, as per:
https://manpages.debian.org/unstable/debhelper/dh_install.1.en.html
8) seclists: package-contains-documentation-outside-usr-share-doc
There appears to be a bunch of those, you should override the lintian
for all the files which are not documentation (you can use wildcards).
For the ones which are actually documentation, eg.: README.md, you
need to move it to /usr/share/doc/seclists/ or just not ship it.
9) seclists: package-contains-empty-directory usr/share/seclists/Payloads/Flash/
I don't see this folder on the upstream branch, even though it's
declared on d/copyright.
I can see the file is present in the latest upstream release at
https://github.com/danielmiessler/SecLists/archive/refs/tags/2021.2.tar.gz
This issue seems to be coming from:
https://salsa.debian.org/pkg-security-team/seclists/-/commit/79205bcdd06238e734378a8b0c548b8f1b126b28
3 of the 2 files there are not prebuilt windows binaries, so you will
have to fix the comment there. I understand those 3 files still
probably have to be excluded due to missing sources. So I recommend
contacting upstream about it and seeing if it's possible for them to
publish the source codes.
For an example of how to compile windows binaries on Debian (with
gcc-mingw-w64-i686), you can look at nmap.
I think this is a good start, I will do a deeper review once we fix
these lintian findings first.
Thank you for your contributions, and don't hesitate to reach out for help.
--
Samuel Henrique <samueloph>
Reply to: