kingkilr

[Work at Anthropic, used to work at Mozilla.]

Firefox has never required a full chain exploit in order to consider something a vulnerability. A large proportion of disclosed Firefox vulnerabilities are vulnerabilities in the sandboxed process.

If you look at Firefox's Security Severity Rating doc: https://wiki.mozilla.org/Security_Severity_Ratings/Client what you'll see is that vulnerabilities within the sandbox, and sandbox escapes, are both independently considered vulnerabilities. Chrome considers vulnerabilities in a similar manner.

(pyca/cryptography dev here)

As Steve notes, Rust does support s390x. Even prior to shipping Rust code, we never tested or claimed to support s390x.

If there's genuine interest in more people supporting s390x in the open source world, folks will need to do the work to make it possible to build, test, and run CI on it. IBM recently contributed official PPC64le support to pyca/cryptography (by way of Github Actions runners so we could test and build in CI), and they've been responsive on weird platform issues we've hit (e.g., absl not support ppc64le on musl: https://github.com/pyca/infra/pull/710#issuecomment-31789057...). That level of commitment is what's really required to make a platform practical, treating "well, it's in C and every platform has a C compiler" as the sum total of support wasn't realistic.

RealPage was DoJ. As was the Google search litigation where DoJ proposed Google divest Chrome.

Which is by way of saying, the FTC and Chair Khan were not responsible for those.

I would strongly implore people not to follow the example this post suggests, and write code that relies on this monotonicity.

The reason for this is simple: the documentation doesn't promise this property. Moreover, even if it did, the RFC for UUIDv7 doesn't promise this property. If you decide to depend on it, you're setting yourself up for a bad time when PostgreSQL decides to change their implementation strategy, or you move to a different database.

Further, the stated motivations for this, to slightly simplify testing code, are massively under-motivating. Saving a single line of code can hardly be said to be worth it, but even if it were, this is a problem far better solved by simply writing a function that will both generate the objects and sort them.

As a profession, I strongly feel we need to do a better job orienting ourselves to the reality that our code has a tendency to live for a long time, and we need to optimize not for "how quickly can I type it", but "what will this code cost over its lifetime".

Since last year's AMG case in the Supreme Court, the FTC is not authorized to seek monetary relief in these cases.

The FTC can seek monetary relief if this order is violated.

I don't know Brett super well so I can't speak to the rest of his background, but it's not correct that the Obama admin asked him to take over DDS.

DDS's founding head was Chris Lynch, who served in that role until the middle of the Trump administration, when he left government service and that's when Brett got the job.

While I don't love the proliferation of dependencies, from a risk perspective the raw number of dependencies isn't always the right metric.

Looking at the authors and publishers numbers from https://github.com/rust-secure-code/cargo-supply-chain it's clear a lot of these are maintained by the same set of trusted folks.

I think it's fair to say that this work is quite likely to qualify :-)

Rust has a few interlocking behaviors that provide its memory safety, a few of the most important are:

- The borrow checker enforces mutable XOR shared references.

- The compiler does not allow use of local variables before they're assigned to, requires structs to be completely initialized, etc..

- All the builtin datastructures perform bounds checks

- The compiler disallows deferencing raw pointers except in unsafe blocks.

There's a lot of good things to be said about modern C++, particular smart pointers. However, it's significantly less resilient to common mistakes than Rust is: https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

Sure you can.

First, in a philosophical sense: pointers and x86 CPUs are real, ultimately any safe abstraction must be built on unsafe primitives. The ability and need to do that aren't specific to memory unsafety, we do that all over software engineering.

Second, empirically, my experience has been that the design of these abstractions can be safe, but moreover that the cordoning off of unsafe blocks makes 3p auditing for memory unsafety _much_ easier to do. It can be orders of magnitude faster than reviewing an entire C or C++ codebase.

I don't have any data on exploitability, but 19 of the last 22 vulnerabilities (since 2018) have C-induced memory unsafety as a cause: https://curl.haxx.se/docs/security.html

It's a great question!

a) It being acceptable to upstream is mandatory to receive a bounty, so a starting point might be: pick projects whose maintainers are sick of dealing with ASAN reports! b) A huge number of people get their libpng or anything else via a package manager like Debian. Debian packages libpng from upstream. If libpng changes something about it's implementation, that'll be reflected in a future debian release.

This is going to be a long process, but we firmly believe the question has to be "how" not "if". If you've got better ideas for how we can promote the transition to memory safe languages, please let us know!

Lots of drivers, network protocols, etc. in the kernel, and they're most of the attack surface -- not the scheduler :-)

We have to approach this as a question of how, not if. When we do that, we can change computer security.

The kernel maintainers have actively expressed interest in having upstream support for writing kernel modules in Rust!

Those of us who organized this both have a long history of involvement in open source. If we have even an iota of this becoming a problem, we will a) be incredibly saddened, b) figure out how to restructure the rules to address the behavior we see.

One of the folks behind the bounty here. Happy to answer questions.

(Former Firefox Security Engineer)

I suspect it's because Firefox exploits have looked the same for the last several years -- there has not been a lot of novelty required to implement an exploit, given an arbitrary read/write primitive.

P0 does report vulnerabilities to Firefox though, and they obviously get fixed, they're just not particularly interesting to exploit.

As far as we know the entire kernel for both is memory unsafe.

It's not clear to me how much Swift is in use internally for things besides apps (e.g. is there a future where Window Server is Swift?)

29/51 appear to be memory unsafety https://twitter.com/LazyFishBarrel/status/111032101282489958...

This release has our continued progress on sandboxing.

It's not in this post, but this will only apply to publicly trusted roots, not "enterprise" ones.

Happy Birthday Pandoc!

The ability to write and collaborate on memos in markdown, and turn them into fancy PDFs and .docs is seriously world changing.

Hi! Engineer at USDS here.

There's definitely quite a bit of PostgreSQL in use in government, so this does not need to be a blocker. As someone noted, PAM auth is a good solution; and I think if you use CentOS or RHEL (Use the latest release please!) you'll end up with a FIPS OpenSSL which PostgreSQL is linked against.

More generally, the VA TRM is not a permanent thing, it's precisely the type of existing process which can be improved with the feedback of on the ground software engineers. If this is a blocker for you, I'm sure folks at DSVA would be happy to help!

David's the best :-)

Super happy that the OpenSSL team decided to be proactive and just enable `SSL_OP_SINGLE_DH_USE` for all users, as well as bump the minimum DH key size. Better defaults for everyone!

It launched yesterday :-) https://alexgaynor.net/2016/jan/20/announcing-letsencrypt-aw... is some tooling I wrote for use on AWS.

Please be careful using urllib2, unless you are on Python 2.7.10+ or 3.5+ it does not do HTTPS certificate validation.

Can you articulate a _specific_ threat model under which this extension fails to protect against mass data collection by Google?

Or is this idle speculation.

https://github.com/department-of-veterans-affairs/vets-websi... :-)

(I work at USDS@VA)

I wouldn't say it's a philosophical difference. We're definitely tackling the problem in two different ways, but that's not because either group thinks the other is wrong, it's because this is a big problem that requires attacking it from many angles.