View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007012||Kali Linux||[All Projects] Queued Tool Addition||public||2021-01-28 14:44||2021-02-25 13:47|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version||2021.2|
|Summary||0007012: Feroxbuster - A simple, fast, recursive content discovery tool written in Rust|
description: A simple, fast, recursive content discovery tool written in Rust
deps: only rust compiler for build, otherwise none
been using this instead of gobuster for long time with no issue. benefit is only dir scanning and can do recursive searches. seems also faster and has shell comp
can this plz be added to repos?
@kali-team, please could this be packaged up.
@author, If you want to help the packaging process, you can check the documentation here ~ https://www.kali.org/docs/development/public-packaging
Tool author here; a friend of mine let me know this was here. I'll see if I can get this working today.
I took a look at the link from @g0tmi1k, it doesn't look like the normal debian build process. It seems as though it's mostly an install script and some of the debian build files?
It doesn't appear that cargo/rustc is included in kali. I currently distribute musl-built static binaries via github actions. Are there any considerations/standards for packaging a rust project?
@epi I have no experience in rust project packaging but I think this link can help you to start:
It's the documentation of the rust-team in Debian (there is some information that is only relevant for Debian like ITPs).
||@sbrun ill take a look at that; I haven't been successful yet without it, lol|
@sbrun I've got this all working. How do I handle the final remote repo? Following through the documentation, i have this in my debian/control
Should I create a 'packaging' repo on gitlab instead, or do ya'll create one that i can push/PR to?
@epi You don't need to create a 'packaging' repo on gitlab.
You can create a branch on your github repo including the debian directory.
I will create the repo on gitlab.com/kalilinux and will import your pacakging work.
@sbrun i pushed the three branches and tags to https://github.com/epi052/feroxbuster.
What's the normal way of handling those branches going forward? I assume I can merge kali/master, putting debian/ into my main branch. What about pristine-tar and upstream?
@epi thanks for the packaging. I will import it into kali as soon as possible.
You don't need to keep pristine-tar and upstream in your repo.
They are required only in kali repo. They wil be updated by importing new upstream tarball.
For the kali/master branch, you can do what you want: you can keep it or/and merge it into your main branch or/and remove it.
||new version 2.2.1-0kali1 is in kali-rolling|
|2021-01-28 14:44||subduing_flask||New Issue|
|2021-01-29 13:05||g0tmi1k||Summary||request for feroxbuster => Feroxbuster - A simple, fast, recursive content discovery tool written in Rust|
|2021-01-29 13:07||g0tmi1k||Note Added: 0014146|
|2021-01-29 13:07||g0tmi1k||Status||new => acknowledged|
|2021-01-29 13:07||g0tmi1k||Category||New Tool Requests => Queued Tool Addition|
|2021-01-29 14:52||epi||Note Added: 0014171|
|2021-02-02 10:05||sbrun||Note Added: 0014187|
|2021-02-03 21:46||epi||Note Added: 0014196|
|2021-02-22 22:45||epi||Note Added: 0014238|
|2021-02-23 09:34||sbrun||Note Added: 0014242|
|2021-02-23 09:34||sbrun||Note Edited: 0014242||View Revisions|
|2021-02-23 13:29||epi||Note Added: 0014244|
|2021-02-24 14:22||sbrun||Note Added: 0014248|
|2021-02-25 13:47||sbrun||Assigned To||=> sbrun|
|2021-02-25 13:47||sbrun||Status||acknowledged => resolved|
|2021-02-25 13:47||sbrun||Resolution||open => fixed|
|2021-02-25 13:47||sbrun||Fixed in Version||=> 2021.2|
|2021-02-25 13:47||sbrun||Note Added: 0014251|