Hello @claudiociardelli , I tested rust_fast_port_scanner today. Not sure if this is an issue or a lack of understanding from me: I run the program with the IP address of my linux server to check what ports might be listening to requests. so I ran the command like this:

./target/release/rust_fast_port_scanner 192.168.1.70

I will not print the result here, But I get 1002 rows in the result so, all the ports tested. From @claudiociardelli (https://github.com/skerkour/bloom/issues/72)

However when I check what ports are listening as per https://www.techrepublic.com/article/how-to-locate-and-close-an-open-port-in-linux/ I only see 6 open ports

coco@dev01:~/projects/kerkour.com/2021/rust_fast_port_scanner$ sudo ss -tulwn | grep LISTEN
tcp   LISTEN 0      511                            127.0.0.1:41683      0.0.0.0:*

tcp   LISTEN 0      4096                       127.0.0.53%lo:53         0.0.0.0:*

tcp   LISTEN 0      128                              0.0.0.0:22         0.0.0.0:*

tcp   LISTEN 0      100                              0.0.0.0:25         0.0.0.0:*

tcp   LISTEN 0      100                                 [::]:25            [::]:*

Hello I found a small error or omission in the decryption function, you forgot to add 16 bytes to BUFFER_LEN (based or you other code to encrypt file

const BUFFER_LEN: usize = 500;

to

const BUFFER_LEN: usize = 500 + 16;

Hey Kerkour! Appreciate the blog posts and projects you have. Was going through the rust_file_encryption one and I'm getting a problem with slicing the buffer at lines 116 and 151 (via .as_slice()). Just letting you know that it is not building right :) thanks!

Thanks for sharing these useful samples. My question is: in production, should the key and nonce remain private or just the key (in this case, add the nonce to the cipher text as you did in this blog post https://kerkour.com/rust-file-encryption-chacha20poly1305-argon2)?

Tried to compile an example that shows email sending. Got this error.

error[E0433]: failed to resolve: could not find `smtp` in `transport`
 --> src/main.rs:2:17
  |
2 |      transport::smtp::authentication::Credentials, AsyncSmtpTransport, AsyncTransport, Message,
  |                 ^^^^ could not find `smtp` in `transport`

error[E0432]: unresolved imports `lettre::AsyncSmtpTransport`, `lettre::AsyncTransport`, `lettre::Tokio1Executor`
 --> src/main.rs:2:52
  |
2 |      transport::smtp::authentication::Credentials, AsyncSmtpTransport, AsyncTransport, Message,
  |                                                    ^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^ no `AsyncTransport` in the root
  |                                                    |
  |                                                    no `AsyncSmtpTransport` in the root
3 |      Tokio1Executor,
  |      ^^^^^^^^^^^^^^ no `Tokio1Executor` in the root

error[E0433]: failed to resolve: use of undeclared type `Credentials`
 --> src/main.rs:9:10
  |
9 |          Credentials::new("smtp_username".to_string(), "smtp_password".to_string());
  |          ^^^^^^^^^^^ use of undeclared type `Credentials`

Nice to meet you. I have some question about environmental variables in https://github.com/skerkour/kerkour.com/tree/main/2021/deploy_rust_on_heroku 's case. This is my first time to deploy Rust service to Heroku. I want to use environmental variables in this case. But I don't know how to do so. Could you please help me?

Hi! Would this code base be modifiable to support other scan types, for example a Syn scan? My suspicions are you would need a very different approach, since std::net and tokio::net don't give you control over this. (Maybe the socket2 lib?), but I'm curious.

In particular, at https://github.com/skerkour/kerkour.com/blob/main/2021/rust_file_encryption/src/main.rs#L147, if original file size was exactly multiple of 500, the code won't identify the last chunk correctly.

Thanks for your helpful articles!

I came across your blog post "Reproducible cross-compilation for Rust (with Docker)" via This Week in Rust #410 and want to say that your Dockerfiles are really cool.

However, there is already a way to cross-compile Rust via Docker. The tool is called cross and is maintained by the Rust Embedded devices Working Group.

So after installing cross via cargo install cross, you can compile to:

Windows:

cargo build --target x86_64-pc-windows-gnu

aarch64 / ARMv8:

cargo build --target aarch64-unknown-linux-gnu

ARMv7:

cargo build --target armv7-unknown-linux-gnueabihf

As said, your Dockerfiles are really awesome and doing something by yourself is always a worthwhile experience, however I just want to point out to you that there is already a way to cross-compile.

As you try to optimize the time to insert a lot of items into a sqlite database, in your blog post here I thought it may be interesting for you to know that sqlx is the wrong tool for that job. Because of the "all is async" approach there is a quite large overhead for executing any query there. According to my own benchmarks executing queries using sqlx is 7 - 70 times slower than doing the same query using diesel. Using rusqlite normally gives you even faster queries. Therefore it might be worth to just use another database framework to improve the numbers there. See the benchmarks here for details on the numbers.

Disclaimer: As maintainer of diesel I might be biased there.

Bumps axum-core from 0.2.5 to 0.2.8.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I started this PR to do some absolutely unnecessary nitpicking, but it turned out the crate ~~actually eats data like there is no tomorrow~~ leads to silent corruption in a number of places, by not handling length read and written.

Please update the article at https://kerkour.com/rust-file-encryption-chacha20poly1305-argon2 accordingly, if you have time. (Think of the children!)

The commits are well-isolated, and their commit messages tell a compelling (albeit overly-dramatic) story (or so some say), be sure to read.

Best regards!

In https://github.com/skerkour/kerkour.com/blob/main/2022/rust_file_encryption_with_password/src/main.rs#L75 (and in many other places), you are assumption that the only scenario where you'll get less than the number of requested bytes is when you are at the end of the file. This is wrong.

See the docs here:

https://doc.rust-lang.org/std/io/trait.Read.html#tymethod.read

In particular:

It is not an error if the returned value n is smaller than the buffer size, even when the reader is not at the end of the stream yet.

There are many reasons why this may be the case.

A great example is if the read you are doing happened to start on a region that is already in memory, but continues to a page that is not there yet. The file system will return what it has right now. That can lead to really hard to figure out bugs.