Re: mod_replace and mod_random

On 2 Nov 2025, at 10:46, Christian Folini via dev <[email protected]> wrote:

> On Sun, Nov 02, 2025 at 02:10:27AM +0000, Emmanuel Dreyfus wrote:
>> mod_random seems to extend mod_unique_id, by making the random
>> data more random (using apr_generate_random_bytes instead of
>> ap_random_insecure_bytes) and with a configurable length. Here
>> again, you could extend mod_unique_id, by adding directives so
>> that the administrator can set true or insecure randomness, 
>> chose generated data length, and environment variable name.
> 
> "Real" entropy in mod_unique_id would be very interesting. OWASP CRS, an OWASP
> flagship project, abuses mod_unique_id to get a bit of entropy to run a WAF
> sampling mode. It's good enough, but removing the wild hack in order to get a
> cleaner interface to entropy via an env variable would be so much easier.
> 
> And integrating it into mod_unique_id (already a prerequisite for
> ModSecurity, the engine for OWASP CRS) would be far better than adding
> another module that we have to tell our users('s hosting company) to add.

From my practical experience -- I use the two quite differently - the unique_id one in cases were I want something very cluster wide, guaranteed unique (& basically predicatable).

Whereas the random one is more where you want some sort of cryptographic `guarantee' -- e.g. at least N bytes of randomness or whatever easily maps to SOGIS.eu or other compliance expectations. And the fact that you can `set' this is really helpful in that context.

So I would say - they are complimentary. 

Dw