chrismsnz

> What have you blocked the attacker from doing?

Not blocked necessarily, but if they want to leverage a stolen token, they’re now forced down a more difficult and highly visible pathway.

You can imagine anomaly detection along the lines if “hey your rails app just made a type of request that it has never made before”, but even just monitoring the metrics of the proxy could tip you off if something is going on.

> That being said, you could probably create a pair of colliding images, give one to a news outlet or something, then later post the second (presumably banned) one. The app would on short notice need to decide between banning neither or banning both.

Yeah they did this - except the contraband was automatically recognised and both images were banned via hash.

Ignoring MD5/image format-specific collision realities, theoretically an attacker could submit a contraband image that collides with a valid, allowed image they may want to remove.

When action is taken on the first image, the collided image could also be censored.

Not for me - seems it depends on libssl1.0 and buster ships 1.1

Clips were autoplaying in the live updates tab of twitter.

Well, it's not obsolete - more incomplete. OpenBSD has supported ipv6 natively for a long, long time.

Additionally, with a "home/office" router, there's many ways that IPv6 may be implemented by their ISP (e.g. static configured prefix, DHCPv6, prefix delegation etc...) all which require specific configuration on the WAN and LAN side to make it work.

So, I agree, but splitting that particular part into a different FAQ/walkthrough is going to be a better approach.

Not 100% sure, but I think this is to mitigate exploitation of UAF (Use After Free) flaws.

Adding an unpredictable delay in between when an application frees some memory, and it becomes available for reuse elsewhere will likely reduce the window of vulnerability where an exploit may be able to leverage the issue.

> anyone wanting to know OpenBSD's position on virtualization should spend 20m-1hr digging through threads like that

Okay, okay. Personally, I think the fact that OpenBSD did not support any of the current virtualisation solutions, and now have an appropriate one in the works says a lot about their position.

And, frankly, what use is an organisations "position" on VM hosting to a user? It either supports it or it doesn't, and if you don't plan on developing it the reasons don't really matter.

EDIT: I'm also going to point out that mailing list posts in general rarely stand on their own, and exist within a context.

If you actually read the thread he was reacting to the premise that: as a secure operating system, OpenBSD should implement virtualisation (in this case, Xen) due to its security benefits.

A premise which he rightly shat directly on, and is his statement is completely congruent with the presence of a VM hypervisor in OpenBSD.

On the flip side, if they were offering TLS services to these sites, they're literally man-in-the-middling encrypted comms to those sites. And in scope of US law-enforcement/intel collection.

Might be that they were asked to continue to provide services.

OpenBSD has had VirtIO (supported by KVM, VMWare and now virtualbox too) guest support for a while now.

AWS uses Xen and domU support is a lot more invasive - OpenBSD had supported it in the past but I believe it was dropped?

> How do you justify the 1.3% share on servers[1]?

OpenBSD is a research operating system.

A lot of their development and deployment methods do not align with the needs/wants of large infrastructure deployments (e.g. biannual releases, supported for 1 year).

Happy to cull/reinvent legacy to suit modern systems and practices (e.g. utf8, doas, opensmtpd/ntpd/bgpd/sshd etc...)

Refusal to support hardware without documentation or binary kernel blobs.

Focus on simplicity and correctness, rather than legacy and kludges, which often gets in the way of sysadmins wanting to Get Stuff Working.

Take your pick?