**Agenda:** * 25-minute talk by [Rodrigo Girão Serrão](https://www.linkedin.com/in/rodrigo-gir%C3%A3o-serr%C3%A3o/) * One or more lightning talks ⚡ * Socializing! 🇵🇹 Va

Python class pollution turns getattr and setattr into RCE and auth bypass. Here is an Opengrep rule you can paste into your own ruleset to catch it in CI.

We benchmarked 15 LLMs on 142 real security findings to triage SAST false positives. Kimi K3 led on accuracy, with one caveat that matters for security.

🇬🇧 After 9 meetups full of talks, lightning talks, and even lightning turtles, it's time to take it easy. Join us at Linha d'Água — the café by the lake in Parque Eduardo

One of my servers has a weird problem after every reboot: it can ping IP addresses just fine, but it can’t resolve any DNS names. $ ping 8.8.8.8 # works $ ping google.com # ping: google.com: Temporary failure in name resolution I’ve been working around this for a while now: after every reboot I’d SSH in and overwrite /etc/resolv.conf to point straight at 8.8.8.8 instead of the local 127.0.0.53 stub. That got DNS working again, but it was never a real fix. /etc/resolv.conf is regenerated on boot, so my edit vanished the next time the machine came up and I was back to fixing it by hand. This time I decided to attempt to properly debug it with Claude.

Today I had almost 9 hours of downtime on fedidevs.com and some of my other sites that I run on a Raspberry Pi at home. The alert came in just as I was heading to bed and I didn’t see it until I woke ...

Socket detected 84 compromised TanStack npm package artifacts modified with suspected CI credential-stealing malware.

I have two Raspberry Pis at home. One hosts my various sites including fedidevs.com and the other supports it by storing backups of all the configs and data. This includes a streaming hot standby of the Postgres database that powers some of my sites. I am not (yet) brave enough to run Claude on my primary Pi, but I decided to let it loose on my secondary. Doing an in-place dist upgrade on a Raspberry Pi is generally not recommended. The official guidance is to do a clean install instead. Since it felt very likely that I’d be doing a clean install in any case to get from Bookworm (Debian 12) to Trixie (Debian 13), I figured this was the perfect opportunity to see if Claude could pull a miracle.

**Agenda:** * 25-minute talk: **Strong Ref, Weak Ref, and Garbage Collector Walk Into a Bar** by [Yulia Markelova](https://www.linkedin.com/in/yulia-markelova-a70434235/)

Before the conference My partner and I arrived in Athens a few days before the conference. It was a convenient excuse to visit a European capital we hadn’t been to yet, and of course to eat as much delicious food as possible. Django Social One day before the conference I went to the django.social event organized by Jon Gould and Andrew Miller. The bar they initially picked got too crowded, so the group moved to the backup place. I came late to the first bar, found no one there, and was a bit lost until I made it to the right spot. Once I did, I felt immediately at home. I met old friends, made some new ones, and had a very fun evening. So fun, in fact, that I forgot to take any photos, so I have no social proof that I was there 😅

With all the supply chain attacks happening lately (litellm being the most recent example) keeping dependencies up to date without risk has been on my mind. Below is everything I do to keep my personal projects secure, what we do at Fencer to keep our own codebase secure, and what we recommend to the startups we work with. Be hesitant about what you add The best way to reduce the risk of installing a compromised dependency is to avoid relying on it in the first place. Before adding a new dependency, I first make sure that implementing it ourselves would be too much work (or tokens!).