Question to people more knowledgeable about #BSD systems (primarily #FreeBSD, but the more answers the merrier)!
On Linux, I can use ipset (or nftables sets) to create a set of IP addresses I can match against with one rule. Like:
# ipset create test-set iphash
# iptables -I INPUT -m set --match-set test-set src -j DROP
This would drop any and all source addresses that I add to test-set in the future, without having to update INPUT. It also does some magic hashing thing to make all this efficient.
The reason I want this is because I'll be adding a lot of unique IPs to this set (about half a million, if not more). When adding them directly to iptables, the Linux kernel was very unhappy about that. But with a set? Worked like a charm.
Can pf or any other packet filter tool on the BSDs do something similar? Allow me to block a very large number of unique IPs?
Blocking ASNs or ranges is not feasible, I need to block unique IPs.
Bonus points if it can automatically expire entries that were added or updated N seconds ago.
Boosts appreciated.
I recently bought something from poshmark.com, for the first time. While I haven't heard of them before, I figure with credit card protections as they are in the US, there's really no harm with giving it a shot.
Within about 30 minutes of placing my order, I got a not-very-good phishing email from purchase-orders@loyverse[.]com, claiming to be "Poshmark".
The first time in my life that I've received a phish from somebody claiming to be Poshmark.
My wonders at this point:
🤔
MDN is more than just a resource. It's a community of developers, contributors, and learners passionate about web development.
Contribute to,
📚 MDN documentation
🤝 Help other devs
💟 Localize content
📝 Review or write on MDN
Start now 👇
https://developer.mozilla.org/en-US/community
MongoDB have a blog out about #MongoBleed
Notably:
- Internal find at MongoDB
- they notified customers of the issue and patch availability on December 23rd
- A security vendor published technical details on December 24th, Christmas Eve
- Somebody at Elastic, a direct competitor, published an exploit with full secret extraction feature on December 25th, Christmas Day
That was an impossible situation for orgs - the security industry poured fire on them and set their own customers on fire.
The US Treasury has lifted sanctions on three executives tied to spyware maker Intellexa, reversing a designation imposed by the Biden administration in 2024 (Suzanne Smalley/The Record)
https://therecord.media/treasury-sanctions-intellexa-removed
http://www.techmeme.com/251230/p18#a251230p18
BTW, glitching the early UART boot path that is fuse protected gives you access to very early nvidia-only key material that is locked down pretty early during the normal boot path. Every single other key on the TX2 is either derived from the FEK1 or FEK2 depending on a fuse bit. Default seems to be FEK2.
SHA1(FEK1) = 9d00fe0637b15de7b417c740a6210d19932c7eb4
SHA1(FEK2) = 0e0fdef7a31d32aaf0fee77679e065652daecb44
I initially did all this to reverse engineer the Denver microcode, however I never could make sense of the instruction set encoding. If anyone wants to tackle this, I can decrypt both microcode stages - seemingly a loader and the final JIT and I more or less completely reverse engineered MB1 that loads the Denver microcode.
/cc @elise
If you're interested in obscure details of the microcode in the Intel 8087 floating-point chip, I have a new blog post...
https://www.righto.com/2025/12/8087-microcode-conditions.html
Today I saw this UNIX v4 PDP11 emulator (running simh in the browser) and decided to write an IO plugin for radare2 to load tapes. Here's the source in case you are curious about how tapes are structured and how to extend r2 with new features like IO backends. https://github.com/radareorg/radare2/commit/aeeccc1d23d3b75edcd6e0013f1372830a6af134
Gentle Reminder for Newcomers
:
Boosting posts keeps Mastodon alive!
Boost what you love! 💚
Boost freely!
✨
New post on my blog! Decapping with DMSO.
https://dev-zzo.github.io/blarg/2025/12/19/decapping-dmso.html
LMAO.
https://www.cve.org/CVERecord?id=CVE-2025-68120
To prevent unexpected untrusted code execution, the Visual Studio Code Go extension is now disabled in Restricted Mode.