pdtm
pdtm copied to clipboard
projectdiscovery
feat: naabu binary install
Please describe your feature request:
Support binary install for naabu
Describe the use case of this feature:
The go install takes a long time and leaves a large cache of Go modules behind. The assets are there on the release page so I'm not sure why binary install doesn't happen.
We recently added an installation method to enhance UX, as detailed at https://github.com/projectdiscovery/pdtm/issues/201. This update mitigates compatibility issues with dynamically linked C libraries in tools like naabu and katana by advocating for go install, which leverages the existing Go environment for consistent system compatibility. Therefore, I don’t know whether we should introduce some flag to override this. I’m mentioning @Mzack9999 @ehsandeep for discussion.
I don’t know much about dynamic C libraries, but I do know that if I pull down the binary release from GitHub and try to run it, I just need to install libpcap-dev which I think would still be the case with a go install.
On Fri, Apr 5, 2024 at 7:32 AM, Dogan Can Bakir @.***(mailto:On Fri, Apr 5, 2024 at 7:32 AM, Dogan Can Bakir < wrote:
We recently added an installation method to enhance UX, as detailed at #201. This update mitigates compatibility issues with dynamically linked C libraries in tools like naabu and katana by advocating for go install, which leverages the existing Go environment for consistent system compatibility. Therefore, I don’t know whether we should introduce some flag to override this. I’m mentioning @.(https://github.com/Mzack9999) @.(https://github.com/ehsandeep) for discussion.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
@sa7mon in the past naabu was installed in that way, but we got multiple reported cases where on older distributions the pre-compiled binary couldn't run due to mismatch with the system shared libraries. So we tried to extend the compatibility and coverage by leveraging the existing go environment which performs the compilation and linking on the system the tool it's going to run, ensuring 100% compatibility
@Mzack9999 Perhaps the installed libraries could be compared to those of the build system used to compile the binaries?
It's going to be difficult to maintain such approach considering the plethora of potential edge cases. At current time the go install way seems the one offering the best advantages, including updating the binary itself via go install -u.
To cleanup the system after compilation, you can execute the following command:
$ go clean -cache -testcache -modcache