Make zstd warning a debug log-level statement

People and packages are unhappy about the Zstd compatibility mismatch, for good reasons, because it is a bit of a hack. Maybe we should consider lowering the log-level of this warning?

See also https://bugs.debian.org/963151

changed milestone to %Tor: 0.4.9.x-freeze

added Backlog label

@omni poked me about this one as well a while ago https://gitlab.alpinelinux.org/alpine/aports/-/issues/14745

and anarcat asked us about it like a month ago too, pointing to the debian bug

Here is the current warn, for context:

Jun 19 13:29:14.005 [warn] Tor was compiled with zstd 1.4.4, but is running
with zstd 1.4.5. For safety, we'll avoid using advanced zstd functionality.

"For safety" probably freaks people out, because they run Tor for safety and they wonder if something about their system is making them unsafe.

But maybe we shouldn't just get rid of the message entirely, because then we will develop a new class of surprises, where people think they installed the zstd package but for some reason their Tor isn't performing zstd actions?

What is the advanced functionality that we opt out of doing? Is it something that the user might notice (as a relay or as a client), or is it just about what kind of compression we ask for, and we auto fall back to a perfectly valid choice if we choose not to use this part of zstd?

If it is something the user might notice, maybe we want to pick 'notice' level and craft a more reassuring message. But if it something Tor adapts to automatically and the user will realistically never care about, moving to info level seems best.

What is the advanced functionality that we opt out of doing? Is it something that the user might notice (as a relay or as a client), or is it just about what kind of compression we ask for, and we auto fall back to a perfectly valid choice if we choose not to use this part of zstd?

IIRC it is our ability to discover how much memory is used in zstd buffers so that we can better respond to memory-based DoS attacks. When we can't do that, we instead make a wild guess, and risk using too much RAM or making worse decisions under RAM pressure.

Correct.

I just looked in the more recent Zstd releases and unfortunately these calls are still considered experimental even though they haven't changed since we adopted Zstd a while ago :-(

changed milestone to %Tor: 0.4.7.x-post-stable

assigned to @ahf

added Doing label and removed Backlog label

mentioned in commit ahf/tor@3d160b37

mentioned in merge request !764 (merged)

Added a patch for this for the 0.4.7 (and later) releases next week.

mentioned in issue tpo/applications/tor-browser-build#22341

All is done here.

closed