Cargo VS RustScan

Next, I'd like to extend my thanks to u/epage. epage maintains several famous crates like clap, cargo-edit, toml_edit, and more. epage is not afraid of engaging in heated debates with others. Such a characteristic helps move things forward, as seen with the support for lints table in Cargo.toml and MSRV support in dependency resolution.

But in the future, Cargo might want more directories for different purposes: - data (for installing other stuff like manpages, see https://github.com/rust-lang/cargo/issues/2729) - state (for storing CLI history or maintaining internal state between runs for some novel features)

just look at the versions

If nothing more it's useful for Rust projects that need a git library. eg: cargo, cargo-generate

I have choosen Rust, because it is a fast, low level language. It has comparable performance to C and C++, but unlike them it has a built-in and streamlined solution for package management and documentation generation. I was able to use them in 5 minutes as a first timer.

Also cargo set-version is part of cargo-edit which is incredibly convenient for setting the build version from CI since Cargo still doesn’t provide a means of overriding the version on the command line.

Do note that cargo vendor can’t handle duplicated dependencies 1. Not a very widespread issue, but there are some projects that (even intentionally) have duplicated dependencies, which prevents this command from working with them.

1.70 Upgrade to LLVM 16 1.69 Debuginfo for build dependencies is now off if not explicitly set. This is expected to improve the overall build time.

As a highlight, and more than three months after originally intended, shallow clones have become available in their respective PR. Furthermore it's now possible to try gitoxide in cargo nightly, which should be as easy as cargo -Zgitoxide=fetch and at least for me speeds up fetches on Windows considerably.

I’m not sure why I decided to create it, I think I tried to use RustScan for a simple task last week, but it was too convoluted for my needs, as well as the fact that it requires nmap to be installed. Thus havn was born, nothing else needed, and only directly using two dependencies, Tokio and Clap, although I think If I really wanted to, I could remove the Clap dependency, but it’s just so handy and easy to use.

My favourites are ripgrep, exa and rustscan

First, we will be checking for open ports. I will be using rustscan here (because it's fast, and it's basically the Rust implementation of nmap), but you are free to choose whatever port scanner you like.

There's also rustscan

RustScan - Lightweight and quick open-source port scanner designed to automatically pipe open ports into Nmap.

We can see there are 5 ports open. We may be able to exploit the HTTP service on port 80 or gain access to SSH on port 20. Port scanning can be slow, tools such as PyRCON and Rust Scanner may help us speed up this process. Typically this isn't necessary but in a KOTH or battlegrounds game, we can't spare the time.

I will do a more detailed analysis of this product, but based on these three source files: input.rs, mod.rs and Dockerfile, they made a wrapper over nmap, whereas sx is independent of third party utilities and generates and sends raw packets directly through the NIC using AF_PACKET socket

Would love to hear how it compares to RustScan: https://github.com/RustScan/RustScan