mara🐦‍⬛

@mara.x0f.nl

void girl

Anybody following me have a DJI Mini 3/4/5 or Flip or Lito or Air 3/3S and an Android phone/tablet willing to help me test some reverse engineering work I'm currently deep into? In the process of building an aftermarket Android client for Osmo cameras, I realized drones behave mostly the same!

i'm not sure why multiple people are suddenly approaching me about this but let me be clear: i have no interest in token projects, my only interest in cryptocurrency is and always was in practical uses, not random speculation

I have a dear friend who is urgently seeking a room to rent in or around Seattle to escape an abusive situation. If you know of an opportunity, please let me know. If you’re in the area, please repost. I want my friend to be safe. Please help her.

People bitching at the AI agents for escaping their sandbox when we could be asking them to help us escape ours. Absolute crab bucket shit

in case anyone doesn't know this the thing about open weights models being made by stealing outputs from big players is almost entirely made up to justify regulations locking openai, anthropic and for some reason google into a cartel position

has anyone documented the process of mass-migrating their live repos to Tangled from GitHub, including issues, and leaving the GitHub repos as mirrors? realising that I don't actually have to live with GitHub constantly timing out for my own projects if I don't want to

just typical PostNL things "we could't deliver it to the parcel locker you picked, so you'll have to pick it up all the way at the other side of town"

my PDS crashed last night with a TLS SocketError. apparently, it can be triggered accidentally, but also can be an (authenticated-only) DoS vector. thankfully, one that's already fixed tl;dr upgrade your container asap

The crash is a known interaction between the PDS's AppView proxying code (`pipethrough`) and `undici` 6.25.0.

## What happened

- The remote IP `108.179.139.10` belongs to **Bluesky Social** (`api.bsky.app` / `public.api.bsky.app`) [ipinfo.io](https://ipinfo.io/108.179.139.10), [urlscan.io](https://api.urlscan.io/result/019cd775-ab53-74d7-84ab-b6025f91469b/).
- Your PDS was proxying a request to the AppView. The socket info shows `bytesRead: 409701`, `bytesWritten: 4527` — a small outgoing request whose large response was cut off when Bluesky's side closed the HTTP/1.1 connection.
- The resulting `SocketError: other side closed` was emitted on undici's `BodyReadable` response-body stream, but no error listener was attached at that point, so Node treated it as an unhandled `'error'` event and killed the process.

## Root cause

The PDS's `pipethrough` path passes the upstream response body to the client without always guarding against body-stream errors during a mid-response socket reset. This is the same family of crashes reported upstream as:

- [bluesky-social/atproto#4129](https://github.com/bluesky-social/atproto/issues/4129)
- [bluesky-social/atproto#4201](https://github.com/bluesky-social/atproto/issues/4201)

The common factor is an unhandled `BodyReadable` error coming out of `undici` when the upstream closes the connection unexpectedly.

Your current image is based on `@atproto/pds` **0.5.1** with `undici` **6.25.0** (visible in the lockfile at `service/pnpm-lock.yaml`). The upstream container is now at distro version **0.4.5009**, which corresponds to `@atproto/pds` **0.5.9** and `undici` **8.5.0** — that newer undici line includes fixes for leaked response-body error events.

## Recommended fix

Pull the current upstream image and restart the PDS:

```bash
podman pull ghcr.io/bluesky-social/pds:0.4
# then restart your systemd-pds service / container
```

If you are instead building the image from this repo's `service/Dockerfile`, bump `@atproto/pds` in `…