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
