peanut-walrus

Why exactly do you think public code on Codeberg is not used to train AI? I would assume the opposite...it's unlikely to be Codeberg themselves doing it, but for sure your code is going to be used as training data somewhere.

What this tells me is that musl+openssh-server is an incredibly uncommon setup, as "at least 257 character string" is literally the third thing I try after "admin" and "12345" when greeted with a password input.

It exists: https://saasocalypse.com/scan

MPTCP uses TCP options fields, the vulnerability is in IP options.

Some notes I've got about this:

- MPTCP is not a requirement, it is a generic use-after-free.

- Exploitability over the internet is unlikely, most ISP routers drop packets with IP options fields.

- At least according to Red Hat, dropping packets with IP options yourself helps, but is not a full mitigation.

- Successful exploit requires multiple CPU cores to process packets, so systems with just a single core or packet processing pinned to a single core are not affected.

> also, doesn't DNSSEC prevent this anyway?

As per usual, the answer is no. DNSSEC prevents resolver cache poisoning for trusted resolvers which validate DNSSEC. That is literally it. It provides no security against the vast majority of attacks against DNS.

Also limited protection against MitM upstream of the resolver, spoofing is prevented but denial of service is still possible.

The typical scenario for majority of users unfortunately does not include a password manager, passkeys are a huge step up from that.

For the people already using password managers, it's not a huge step to get a Yubikey and use that for hardware-backed passkeys.

Absolutely not. Phishing resistance is the big one. But also if hardware backed, resistant to stealers.

I've been using my own domain with a catchall for over 10 years and never had problems with spam. Spammers tend to send to harvested address lists, not just try to send to random mailboxes for a domain.

IP and Ethernet were developed around the same time and also became the dominant standards around the same time. But they were mostly unrelated, so you had token ring networks running TCP/IP and Ethernet networks running IPX and all sorts of other combinations. So it's not quite as simple as that. I don't think there's ever been a time when there was a significant adoption of Ethernet without using it in combination with some L3 protocol.

Quite common to run unnumbered IS-IS backbones. Whether this can rightfully be considered a "LAN" is up for debate.

Transparency logs. It's mandatory for a cert to be in CT logs for browsers to trust it. Those are public, if this was happening, someone would have noticed already.

There is no such thing as unfixable. It's just kicking the can down the road. Look at how email devolved because of the features that made spam "unfixable". I would like dns not to go down the same path, which seems all too likely if nothing is done. Already most corporate networks are blocking most "new" domains. It's only a matter of time before new domains you buy are essentially unusable.

> The rational soul can be made only by creation.

From Aquinas' Summa Theologiae. The argument this article presents does seem very similar. Weirdly, the article itself is very dismissive of religion, while making a similar argument to the one Aquinas made 750 years ago.

Because web security has a lot of legacy crap. Such as cookies. Oh you added Domain=foo.com to your cookie? Now marketingvibecodedapp.foo.com can access the cookie from your main domain. What do you mean you thought adding the domain field restricts the cookie to just that domain? Lol no, it's the exact opposite, gotcha, dumbass.

In theory, yes, in practice this will currently result in deliverability issues, both for servers which don't speak dmarc and for spam signals. I have tried this :)

If this mode of operation was an explicit choice, this would give me the option to have a fallback SPF record for legacy mail systems, but most up-to-date servers will use the more secure and (for my use case) operationally simpler verification.

Missed opportunity to get rid of SPF. What I want to my DMARC policy to say: if someone is sending you an email that claims to be from my domain and it's not signed by one of the keys I have published under my domain, you should reject it, regardless where it came from.

And on the receiving side, the policy is similarly simple: if I receive any unsigned or unaligned email, I will reject it.

Edit: to clarify, I want there to be an option where I specify my DMARC policy to explicitly tell well-configured receiving servers "ignore whatever I have configured as my SPF record, only look at the signatures". There will no doubt be a long tail of mail servers where I will still need an SPF record for them to accept my mail.

Edit2: Another feature that I feel is lacking is ability to give dkim selectors a scope - e.g. this key is only valid for these particular From addresses.

Turns out you don't actually need top-tier engineering talent if your only business is selling ads to scammers to prey on the elderly?

It's a feedback loop between governance, social structures and individuals. But out of those, only individuals are the ones with free will who are able to "break" the loop and direct society along a different path. It's not just building "big things" that changes us, it's every small individual decision about what you choose to spend your labor on. No revolution would succeed without people willing to rebel and no dictator could dictate without people willing to follow them.

It's your personal toy server, you are optimizing for something entirely different than high availability.

Yup, podman quadlets autoupdate quite nicely. Setting up a local registry mirror with ~3d delay before applying updates is on my todo list.

My own service images already have a script that runs daily that pulls latest git updates and builds fresh images.

I see no reason not to go with a rolling release distro for personal servers. Run all the services in containers and have the base OS auto-update itself as often as it needs.

Went with openSUSE MicroOS myself, it updates and reboots almost daily so I can be pretty confident my server is healthy and it's atomic so if something does break and I don't feel like dealing with it, I can just click rollback button from cockpit and deal with it whenever I have time.

I do fight botnets, malware and scams. Criminals flock to any service where they can spread their stuff and appear legitimate. Google, Facebook, Vercel, Netlify, Amazon, Oracle, Microsoft, OVH, etc. In my experience, Cloudflare is not any more or less of a dead end than any of the other providers, there are some others in that list who deserve being called out a lot more.

Oh absolutely agreed. Cloudflare becoming a giant internet chokepoint is certainly a real problem. It would be a much better world where ddos protection would not be a needed service or where we it was provided as a public service, rather than by private companies. However, that's not the world we live in.

So "big companies only, absolutely no anonymous sign-ups" should be the only ones able to put stuff on the internet without fearing that a random teenager can take your site offline for days just because they're bored?

Articles like these seem to hold a weird belief that Cloudflare does not react to security reports or legal orders? From my experience, they react appropriately and relatively quickly compared to rest of the industry.

Could Cloudflare be more proactive or add more friction to their signups? Yes, probably, but the reasons they have outlined for not playing internet police make sense to me.

I don't think it should be a requirement to provide your credit card, phone number and a copy of your ID in order to host content on the internet...

90% of those sites don't have anything resembling a sysadmin. If they've not already been hijacked by one of the Wordpress vulns or hijacked plugins years ago, they will be now. And absolutely nobody will spend any effort to fix them, so they will just end up chugging along until safebrowsing flags them and basically removes them from the internet.

Yes. But it's quite an uncommon setup. For IPv6 multiple addresses is the default.

I've always found the most complicated part of IPv6 to be address scopes and source address selection. The fact that one interface can have any number of addresses in different scopes and prefixes complicates things a lot.

Another thing that will always trip up new IPv6 network engineers is solicited-node multicast. You know the theory, computers talk to ff02::1 for neighbor discovery and then you hop onto a real network and see none of that actually happening.

And probably the most complicated thing for network engineers - how to set up firewall rules if machines are constantly changing their addresses.

For developers and security people - just parsing and validating v6 addresses is a whole bunch more work, but at least for this, the tools are available to help you now.

And eventually even a worm will turn.