Hi,
On 2021-08-02 4:30 p.m., Samuel Henrique wrote:
> Hello,
>
>>> The best thing you could do, from our POV, is to push your packaging
>>> files to salsa, under your user. But hosting your work anywhere and in
>>> any way can be helpful, it's gonna be up to the people working on
>>> those packages to check it out, though.
>>> Guilherme (who's working on seclists) mentioned he would like to see
>>> what you've done in the other thread.
>>>
>> Not too sure how does Salsa work for "outsider" ?
>
> You can do pretty much anything under your user on salsa (just like
> when you use gitlab or github), you are only limited to not pushing
> changes to other people's/teams projects (but you can always create
> your own under your user).
>
Thanks for the information, I'll give it a deeper look today.
>> Those are the packages I made for Buster.
>>
>> Some of them are local compile of buster-backports, some of them may be
>> from testing, and some may not be related to security.
>> Mostly everything related to security comes from Kali.
>
> I checked out seclists and I don't think I understand, that packaging
> probably didn't come from Kali cause it's missing some important
> things from Kali's packaging of seclists around that time. I couldn't
> identify what changes there were required for the Debian packaging,
> eg.: why didn't you use Kali's package instead?
If you look at the link I gave you, it goes into a folder that is name
something like 2018.xx.xx, so it is based on a version of SecLists that
was made on this specific date. I don't remember why, but if I hadn't
used Kali's version, maybe it didn't exist at this moment.
Regarding this particular software (SecLists), it ain't much of artwork
for doing the install packages as it is only to put some files into
specific folders. Could update from the latest version (not on OWASP
site but on danielmiesle) in a matter of minutes for getting the watch
file done.
I haven't looked at this package since the time I build it because I
haven't used it much. I do simple have a git copy of the repository
laying around. For me it's a bit like the
exploitdb/exploitdb-bin-sploits/exploitdb-papers.
If you look over at some other software, for example Sandbox Cuckoo
(cuckoo) or Metasploit Framework, I've used as much I could from Kali.
Already that I find pretty much a waste of manpower all the forks
running around, I'm not going to write something other have already done.
Here's a list of some local git repository I have. You can see that
there's a Kali related ones to most of them. They we're the basis for
the packages themselves.
I've looked and these packages are still uploading.
Some may already be in Debian...
exploitdb-bin-sploits johnny nikto
social-engineer-toolkit veil-kali wpscan-kali
armitage-kali exploitdb-papers johnny-kali nmap-debian
sqldict-kali w3af zaproxy
beef-xss fuzzdb keepassxc nmap-kali
sqlninja-kali webshells-kali
burpsuite-kali hash-identifier-kali kismet-kali oscanner-kali
sqlsus-kali winexe
davtest john libdvdcss OWASP
theharvester wordlists-kali
exploitdb john-kali metasploit SecLists veil
wpscan
>
> My suggestion is to identify a package which you think it's the
> closest to be ready for Debian and then work on that. But it's
> important to check what are the differences in your packaging vs
> Kali's to evaluate if it's better to start from scratch (based on
> Kali's packaging) or continue with your version.
>
> You can also identify which of those packages have improvements
> performed over Kali's packaging, write down what those improvements
> are[0], and then only upload the packages which have these
> improvements. Unfortunately it might be unlikely that someone will
> have time to go through all of your packages looking for those
> improvements, as basing the packaging on Kali's is already quite a
> good baseline.
>
I didn't create any package "from scratch" unless the package hold a
name that doesn't exist inside Kali. I'm quite amazed not finding any
reference to the base Debian package for SecLists. Even more that
there<'s clearly nothing to do for maintaining this package.
It's like a documentation package except it goes into a different folder.
Maybe the package didn't exist in Kali when I started doing this.
Like I already said, this started in 2018 (and earlier).
For curiosity, I'll take a look at when did Kali started having a
SecLists package.
> [0] I suggest sending this summary here as well, as we can help
> identify which ones could save the most time.
>
> Thank you,
>
> --
> Samuel Henrique <samueloph>
>
--
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature