security/seclists: Collection of multiple types of lists used during security assessments

[salvadore]

Summary

SecLists is the security tester's companion. It's a collection of multiple types
of lists used during security assessments, collected in one place. List types
include usernames, passwords, URLs, sensitive data patterns, fuzzing payloads,
web shells, and many more. The goal is to enable a security tester to pull this
repository onto a new testing box and have access to every type of list that may
be needed.

This project is maintained by Daniel Miessler, Jason Haddix, and g0tmi1k.

WWW: https://github.com/danielmiessler/SecLists

[danfe]

Regarding the port's Makefile I don't have much to complain. As for the long file name, I don't like the idea of installing the shortly named file and asking the user to rename it; if you need it with its original name is bogus reasoning, the whole point to have this file in the payloads collection is its very long name, it is useless otherwise, which is a bad thing for security-related software. Would it be possible to install it under the original name in the post-install script instead?

security/seclists/pkg-descr

1

We typically expand contractions in our official texts, which includes ports' descriptions (it's -> it is). Personally I'd also use double space to separate sentences (looks better for monospaced fonts, e.g. on the terminal), but won't insist.

[salvadore]

In D35026#793758, @danfe wrote:

As for the long file name, I don't like the idea of installing the shortly named file and asking the user to rename it; if you need it with its original name is bogus reasoning, the whole point to have this file in the payloads collection is its very long name, it is useless otherwise, which is a bad thing for security-related software. Would it be possible to install it under the original name in the post-install script instead?

I am investigating the issue more deeply. For the moment, I have not found any solution: a post install script can indeed rename the file, but then

pkg info --list-files

would still report the file with the old name and we would probably have more related issues (checksums?).

Good news is that it seems the problem appears only when using poudriere: building the port with make does not generate any error with the original name.

At the moment, these are the solutions I am considering:

1. the one I have submitted in the review, with a better wording in the pkg-message: I could change if you need it with its original name into if you want to use this file you need to ;
2. removing the file: port management would be easier and user might be less confused;
3. ignoring the fact that poudriere cannot build it. Building it from ports is not a big deal since there is nothing to build. Is it possible to prevent the pkg builders to even try?
4. trying to work with the poudriere maintainers to make it support longer filenames, but I have no idea if the fix is possible and/or easy.

Maybe the best idea is to combine solutions: trying to work with poudriere maintainers to make it support longer filenames, but in the meantime, if the fix is not immediate, commit the port with solution 1.

---

Changing topic, could someone please take a closer look as to wether the process of adding the port is completed? I have only created the port's files and added the line in security/Makefile, nothing more. According to the Committer's guide, the addport script should be used, but it expects svn, so that part is now out of date and the process of adding a new port is then undocumented, as far as I know.

[danfe]

@salvadore wrote:

According to the Committer's guide, the addport script should be used, but it expects svn, so that part is now out of date and the process of adding a new port is then undocumented, as far as I know.

I've never seen the need for those helper scripts once we moved away from CVS. Both Subversion and Git (to a lesser extent) are convenient and pleasant enough to work with directly. Just git add and git commit your changes once you're happy with them (provided you're not copying or resurrecting a port, in this case you might want to take special steps to help Git deduce history better).

[gerald]

In D35026#793792, @salvadore wrote:

trying to work with the poudriere maintainers to make it support longer filenames, but I have no idea if the fix is possible and/or easy.
Maybe the best idea is to combine solutions: trying to work with poudriere maintainers to make it support longer filenames

This sounds like a good idea in any case.

but in the meantime, if the fix is not immediate, commit the port with solution 1.

Works for me.

[bapt]

security/seclists/Makefile

31

The problem here is the file is 241 caracter long, the max length accepted by freebsd is 255, when installing to be as atomic as possible pkg do create a temporary file and rename in last action to the final name this temporary file prepend the file with .pkgtemp (so it is obvious where this file comes from) and append a random suffix to ensure there are no collision which results in a filename of 260 which is bigger than NAME_MAX (255)

I can reduce the prepended part, but will be less obvious where the temporary file comes from.

(please say pkg not pkg-static here as pkg will have the same problem and pkg-static is juste a specific version of pkg).

[bapt]

https://github.com/freebsd/pkg/commit/ce75303c613f2f5d04fdd7c9edd6f4cd40eb9dac this should fix this specific case

[salvadore]

Thanks all for reviewing and thanks again to bapt for the pkg commit.

I modified the pkg-message and the comment in Makefile to make things clearer. I also removed the reference to pkg-static everywhere except in the error message, where I prefer to keep the message exactly as I have got it. Is that fine?

By the way, after having read bapt's comment about the problem being with pkg (and then not with poudriere as I thought) I tried again installing the port with make install and this time I got indeed the same error message: I must have done something wrong in the precedent test (maybe I only did make).

[salvadore]

I had forgotten danfe's comment about expanding "it's". Now it is fixed.

[tcberner]

afterwards lgtm

security/seclists/Makefile

34

^ still says pkg-static here

[tcberner]

security/seclists/Makefile

34

nevermind, as that is from the error message :D