This has also been noted by Assured AB when they did their security audit of the service [0].
> 3.4.1 Note Plaintext search queries in cache database
> Assured recommended hashing search terms before insertion / lookup in the cache database. Since search term cache lookups are only performed with exact matching, this should not affect functionality.
> Mullvad: We are now hashing (and salting) the search terms before they are added to Redis
The *arr suite of apps is made to automate the whole process of building up your media library. You have Prowlarr for managing your download sites and clients, Sonarr/Radarr for TV shows/movies, Lidarr for music, Readarr for books, etc.
These apps can be self hosted and are fully open source. The basic workflow is that you add a movie/show, it automatically searches all of your download sites for the title, chooses the best download based on your filter criteria (resolution, size, etc.), sends it to your download client and then places the movie/show into your library based on the folder/file naming pattern you specified previously.
You can choose to automate as much of the process as you want or do most of it manually. E.g. grabbing new episodes as soon as they air vs supplying your own files (if you rip your media yourself for example) and only letting the program do the part of renaming and moving your files.
> I am meticulous at making sure the structure and filenames are correct before dumping anything new to the library to the point where I have a complex script to process movie and tv show filenames and folders.
I'm curious to know why you chose to write a custom (and complex) script yourself instead of using something like Sonarr/Radarr for this task? Does your script do something that the *arr apps are not capable off or is there another reason?
In the speed running community there is a pretty famous clip [0], where a glitch caused a Super Mario speed runner to suddenly teleport to the platform above him, saving him some valuable time.
Of course people tried to find ways to reproduce the bug reliably, as saving even milliseconds can mean everything in a speed run. They went as far as replicating the state of the game from the original occurrence 1:1, but AFAIK no one has been able to reproduce the glitch without messing with the games memory.
For that reason it is speculated that a cosmic ray caused a bit-flip in the byte that stores the players y coordinate, shooting him up into the air and onto the next platform.
> 3.4.1 Note Plaintext search queries in cache database
> Assured recommended hashing search terms before insertion / lookup in the cache database. Since search term cache lookups are only performed with exact matching, this should not affect functionality.
> Mullvad: We are now hashing (and salting) the search terms before they are added to Redis
[0] - https://mullvad.net/en/blog/2023/5/16/security-audit-of-our-...