Sergey G. Brester

> You observed a segfault if .close() was called at the wrong time, but in general, the problem is much wider. But only close() is dangerous in the way that...

I back-ported my experimental branch to current master (742393fb9102a252df0c927a91d02f1a72d9426c)... It has not been tested extensively yet, so please test it by yourself (the binaries are in [artifact of the build](https://github.com/sebres/7-Zip-zstd/actions/runs/14316767900))....

Looks indeed like a nice "feature", however I see the potential in additional (similar to bantime parameters), like `rndtime` etc. As well as in vice versa settings (attempts counter increasing...

> Effectively forcing the high 32bit to 0 for every call Nope. Firstly it has not really an "initialization" (if one carefully follows the mixing algorithm inside the blocks). Secondly...

> I would feel much safer if there would be a way to just execute a command directly, without a shell looking for `$`, ``` , `\\`, etcpp. (and this...

> So I actually cannot use single quotes for this currently? You can, but for simple plain values (without special characters). If you don't know the content or know that...

> `bantime.rndtime` only applies to the second through n-th bans. Hmm... Basically all `bantime.increment` features are complete stuff of observer module (asynchronously monitoring worker), which is involved for known as...

Initial (first) ban is mostly short (to prevent long mistaken bans on some false positive), so a random part without a multiplying factor can be very fast predicted and would...

> Step 3: Have each host send a second SMTP request to my server after 300.1 seconds. Sure. Just at this moment it is known as bad (if `bantime.increment` enabled)...

Did you ever notice a concrete case of such attack?.. Thinking a bit about that, I see one real concern where it may be good (well, at the moment): if...