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>