I'm not actually sure about this specific project, but people are still hard at work making CPython faster. Many of them the same people as where in this project.
When I say things like that, I'm talking about a hypothetical version that would be computationally possible. I'm not talking about today's homomorphic encryption.
Apple's Private Cloud Compute is E2EE between the client and the attested node. Not sure if anyone else is legitimately doing that -- Apple has definitely gone the furthest in terms of verifiably ensuring that requests and responses are not misusable by Apple.
I can only say I am a little too optimistic about the technology world in general. Or at least would love to see some good news once in a while given the state of the world.
Maybe not that bad, stopping the accelerator means the storage requirements drop now that data is no longer being taken. Storage is instead just used for simulation and reprocessing which is small in comparision.
So long as the market recovers before HL-LHC starts and the data volume increases it'll be okay. If it doesn't...
They will buy the hardware last, at the end of LHC to get the best hw possible. Helium is a bigger problem, since CERN is the biggest Helium cryo-installation in the world...
> Data is stored natively in XFS filesystems on hard disks or SSDs or on virtualised back-end storage (e.g. RADOS block devices) or distributed filesystems like Lustre or CephFS.
Interesting, they used to be the largest ZFS user.
Hard to Google for it without getting AI slop on it, but apparently they built their own stack in 2019.
Not sure I like their solution, "Meta-data is persisted in RocksDB databases using a proprietary KV store called QuarkDB." Unless QuarkDB has magically removed RocksDB's amazing ability to corrupt and lose data frequently, this whole thing sounds like a bad idea.
Also, their data is not stored on any one system (local XFS, Ceph, Lustre), a recipe for disaster.
There's at least 3 copies of all the data and possibly more spread around the world at different Tier1 and Tier2 centers. The T1 and T2 centers are very likely using different filesystems and everything is checksummed pretty much at every major step (data generation, before and after any network transfers, before analysis, etc).
The problem with RocksDB is Facebook uses it, and has a similar system that replicates data across the world... and still faces unrecoverable data loss because of RocksDB.
This is very real, but such CVEs are such a tiny fraction in relation to denial-of-service-due-to-regex that it’s hard to take the system seriously.
So far as I’m concerned the solution is to isolate everything as much as possible. I’d love to see something on the CVE classification side to also address the signal to noise problem but I don’t see it happening.
Pretty much - I don't know too much about the CVE process but if ReDoS stuff was flagged at the CVE level as "exploitable only with unconstrained inputs" then great - I know my tests have sane inputs, so I'll close thanks.
So I have a library and its ultimate purpose is converting globs to regexes. Someone sent me a ReDoS vulnerability report with a 4.0 CVSS score because if you write an obscene glob pattern you'll get a correspondingly obscene (and inefficient) regex. What else would you have it do!?
The key point here is the “pay less” part. I know people that have turned down offers from meta that would 5x their salary and their personal situation would notably improve from at least some of that extra cash.
The OP is a bit preachy and maybe some employees really don’t have any other options even with accepting lower salaries, but the majority should at least realise the golden handcuffs their bound by even if they choose not to act on them.
For anyone who thinks this might matter for security:
* curl is mature enough that the chance of an impactful bug is basically zero
* if there is such a bug, I'm sure someone will figure out how to get in touch with Daniel and co
* if there is such a bug, it's more important that it gets patched in package managers and rolled out. Upstream releases can wait.
There's a pretty big difference between a random report submitted via email, and, say, a close friend of the maintainers letting them know a serious vuln was found and they should login.
Probably not. Why pay someone who's willing to work for free? When he stops working for free, then you pay him. Open source is not exempt from economic principles.
> curl is mature enough that the chance of an impactful bug is basically zero
Curl is also something that should be thoroughly sandboxed to begin with, because even if there are no vulnerabilities in curl itself, its a tool for downloading arbitrary data over the internet, and you may well accidentally trigger vulnerabilities in every other part of your environment just by downloading arbitrary data to your shell...
Well yeah, that's true for any sandbox. If you pipe stuff outside of the sandbox, outside of any sandbox, and run it there, then you're not running it in a sandbox.
reply