Yeah, I just updated the post. I blocked both of their /16 blocks today. No response, acknowledgement, or drop in spam even after close to 50 unique spam reports over the course of 2 and a half weeks. None of those customers are any my org would be dealing with, anyway, so fuck 'em. If they want to be a big boy player, then they need to take responsibility for what their platform is being used for.

Are compromised private keys that much of a problem in the real world to merit such a pain in the ass, heavy handed “solution”? On paper, sure, it makes sense. In practice, you’re forcing people to complicate the process by introducing, until now, unnecessary automation and introducing the possibility of brand new points of vulnerability.

I say this as someone who does maintain legacy systems (i.e. systems), so take it with a very angry, frazzled grain of salt. But I’ve done this for years decades and many, many systems and to my knowledge, I’ve never had a compromised private key.

This just seems like people who constantly lose their house keys mandating that everyone else change their locks as often as they do.

Just their access points. They’re all flashed to OpenWRT so can’t speak for their software/firmware, but the hardware is solid.

It’s like their entire product line can be named with a script seeded with random buzzwords:

function generateProductName() {
  const baseName = 'Dell'
  const buzzwords = ['Base', 'Plus', 'Premium', 'Pro', 'Max']
  let modelName = ''

  for (let i = 0; i < 1+ Math.ceil(Math.random() * buzzwords.length); i++) {
    modelName +=  ` ${buzzwords[Math.floor(Math.random() * buzzwords.length)]}`
  }
  return baseName + modelName
}

for (let i=0; i<6; i++) {
    console.log(generateProductName())
}

Dell Premium Pro Plus Pro Max
Dell Base
Dell Max Plus
Dell Pro Pro Pro
Dell Plus
Dell Base Plus

Lemmy doesn’t so much cache the images so much as “store them forever”.

Regular post thumbnails are just “internal” images. I’m not sure if newer Lemmy versions log these internally like user uploads are, but assuming not, there’s no direct way to deal with them.

Pict-rs keeps a true cache of image variants (alternate versions of images that were requested at different resolutions / formats). Those can be cleared programmatically:

curl -XDELETE -H "X-Api-token:YOUR_API_KEY" http://127.0.0.1:8080/internal/variants

Where your pict-rs API port is exposed to localhost on port 8080. Also note that those variants will be re-created on demand.

One easy-ish way to get rid of images is to select from the post table for any thumbnail_url that starts with your instance. e.g. https://your-instance/pictrs/image/%s. You can filter that by published date if you only want to wipe out thumbnails for posts older than a year, for example.

With that list, you can strip off the filename/alias (the uuid and extension) and pass each alias filename to a script that tells pict-rs to delete it (you need at least pict-rs 0.5 for this to work):

#!/bin/bash
ALIAS="$1"
API_KEY=FooBarAPIKeyIsFake

curl -XPOST -H "X-Api-token:$API_KEY" http://127.0.0.1:8080/internal/delete?alias=$ALIAS

Below 0.5, the only way to delete images fro pict-rs without the delete token was to use the purge endpoint. But that deletes all aliases and not just the one you want to delete since it does de-duplication under the hood.

If you want to get fancy so that image posts still render correctly, when building your list of thumbnails to delete, you can check if the value of the url column is an image. If it is, grab the current thumbnail image to pass to the delete function and then update the thumbnail URL value to that of the post URL.

Going to print that onto a card for the next time someone asks “WhY dO yoU rUn LiNUX??”

What are you guys working on?

Literally, absolutely nothing. For the first time in weeks. Just enjoying the evening.

I didn’t see a bug reported for it yet, but I was able to confirm it on Voyager as well as in the wild. Created bug #4172.

Tesseract is ready, though current release is still in backwards-compatible mode for 0.18.x (none of the new 0.19 API features are enabled, but all primary functionality is tested against 0.19.0).

However, it does have issues with the /comment/report/list and /post/report/list endpoints as well as /user/report_count. However, those are also throwing the same HTTP 400 errors as with Lemmy-UI 0.19.0-rc.4 (tested against voyager.lemmy.ml).

The first two throw a 400 with the error not_an_admin even though I am moderating a community.

I assume those are known issues?

Well, all the places that used that were passing it to a function that fuzzed the time somewhat. e.g. 2023-09-01 13:20:55.123456 becomes “1 mo ago”. So timezone really didn’t provide any benefit there.

Yeah, I took out the +Z concatenation in my frontend ahead of 0.19.0 support, and everything works fine without it.

Awesome. I just pushed up the latest release with a few features people had requested earlier today. 1.2.58.1 is current but 1.2.59 is building in GitHub workflow. Should be ready to pull in ~20 minutes or so.

Check out Tesseract.

It supports inline videos and various embeds (Youtube/Invidious/Piped, Spotify, and more).

With each passing day, the goat farm option sounds better and better. Lol