There have been users spamming CSAM content in [email protected] causing it to federate to other instances. If your instance is subscribed to this community, you should take action to rectify it immediately. I recommend performing a hard delete via command line on the server.
I deleted every image from the past 24 hours personally, using the following command: sudo find /srv/lemmy/example.com/volumes/pictrs/files -type f -ctime -1 -exec shred {} \;
Note: Your local jurisdiction may impose a duty to report or other obligations. Check with these, but always prioritize ensuring that the content does not continue to be served.
Update
Apparently the Lemmy Shitpost community is shut down as of now.
I nuked my personal instance because of this :(
Dealing with pictrs is just frustrating currently since there’s no tools for its database format and no frontend for the API. I half-expected this outcome but I hope it gets better in the future.
[This comment has been deleted by an automated system]
Pict-rs has been the single largest pain of self-hosting a tiny Lemmy instance. I really hope things improve. I like hosting it myself but I can’t do it as a second job, having to figure out my own hacks and workarounds just to keep it running and not serving up illegal crap.
[This comment has been deleted by an automated system]
yeah this has got me second guessing hosting my own instance as well.
That finalized my decision to not self-host. I’m savvy enough to set it up but not enough to keep up with maliciousness like this. I’d never even considered a deliberate CSAM attack as a possibility - I thought it was just something (atrocious) users might inadvertently post.
You always gotta prepare for the worst case. It’s certainly why I am never going to bother with hosting something like this unless I’m serious about it akin to a job. If there’s even a remote chance of CASM getting on your machine, you gotta assume it will and be prepared to fight to prevent it/remove it.
Agreed, pict-rs is not ready for this. Not having an easy way to map URL to file name is a huge issue. I still don’t understand why non-block storage doesn’t just use the UUID it generates for the URL as a filename. There is zero reason to not have a one-to-one mapping.
yeah, I just spent the last hour writing some python to grab all the mappings via the pict-rs api. Didn’t help that the env var for the pictrs api token was named incorrectly (I should probably make a PR to the Lemmy ansible repo). EDIT: Nevermind, seems there is one already! https://github.com/LemmyNet/lemmy-ansible/pull/153