ngoomieJan 7

is there any way i can enable showing of what MRF rules i have enabled, but entirely hide display of my specific MRF simple rules? for whatever reason i don’t like the idea of having a full list of all the instances i’ve blocked just be easily browsable (plus i don’t have to show it for the purposes of letting other people know with certainty whether or not i block an instance they may interact with – i’m a single-user instance), but i know having MRF rule display completely hidden is very eyebrow-raising too (then there’s no way to tell if i might have RejectDeletes set up, which ftr i don’t, but i mean, the problem here is that you just have to take my word for it)

i know you can obscure which domains are affected by MRF simple rules, but that still shows a big list anyways, no? so not quite what i’m looking for

#akkomaAdmin #akkoAdmin #fediAdmin #fediverseAdmin

Show threadanna, a criticality incident at the gender acceleratorOct 17

it was ultimately pretty easy, since im  with netifrc going, i was finally pointed to by someone in the #gentoo irc to the default config examples for /etc/conf.d/net and with some followup i found out that i just had to symlink the service file for the ens18 device, and then do this:

config_ens18="dhcp 2605:a141:2219:1995::1/64"

(its not exactly a secret, this server is broadcasting an ip address thats kind of the point here lol) and i was able to restart the interface without it kicking me out of the ssh yay! anyway just some #akkoadmin #fediadmin #contabo #gentoo #netifrc #ipv6 tips as i did not find any of the documentation on this straightforward, especially since netifrc isn’t as in vogue as whatever systemd-based hunks of junk everyone is running now

Charlotte /Cinny     May 26, 2023

Mitigated a 1 click XSS on this instance. Wasn’t exploited on this instance: user data is safe.

This particular XSS was actively exploited against instance admins, in particular two 2 extremely shitty instances

The way this attack seemingly worked is that the attacker would send an HTML attachment to a user and trick them into opening it. This HTML contains embedded malicious code that steals your oauth token.

I cannot verify if it could have been exploitable on this instance, as local and remote media are served from subdomains (https://mastodon-assets.chir.rs and https://mediaproxy.chir.rs respectively), so sending files would have resulted in file links that are isolated from the web interface on this instance.

However to fully mitigate this issue i changed the following things:

  • The server now blocks requests to the media and media proxy that don’t origin from bunny.net (the CDN I use)
  • The server tells the browser to forbid javascript execution (through setting the Content-Security-Policy header)
  • I am working on upgrading akkoma to the latest version (3.9.4) which also fixes the issue

#FediAdmin #AkkoAdmin

Charlotte /Cinny     Nov 15, 2022

#fediadmin #akkoadmin

There has an XSS fixed in pleroma-fe for akkoma earlier today. Definitely make sure to update your frontends!

Akkoma