View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007012 | Kali Linux | Queued Tool Addition | public | 2021-01-28 14:44 | 2021-02-25 13:47 |
Reporter | subduing_flask | Assigned To | sbrun | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | ||
Fixed in Version | 2021.2 | ||||
Summary | 0007012: Feroxbuster - A simple, fast, recursive content discovery tool written in Rust | ||||
Description | name: feroxbuster 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. |
|
morning! 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. 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. 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 |
|
Date Modified | Username | Field | Change |
---|---|---|---|
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 | |
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 |