Hacker Newsnew | past | comments | ask | show | jobs | submit | tempay's commentslogin

Are they still? I thought this project was no longer really active.

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.

You also want them to be the person with the most ideal weight: https://en.wikipedia.org/wiki/Coxswain_(rowing)


The "our story" menu bar item has it in the drop down.


I assume OP interpreted it as encryption that hides the prompts from OpenAI rather than OpenAI hiding information from users.


I'd be all for homomorphic encryption on inference, but as you say, this is probably mostly to prevent end users from observing intermediate results.


Homomorphic encryption for LLMs is extremely expensive and nowhere near computationally possible for the scale of current LLMs.


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.


ooooooof yeah totally misinterpreted it lmao


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.


Given what we know about the company, I find it crazy anyone would misinterpret along those lines lol.


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.


to be fair, the title is very misleading, it took me a minute to understand what they meant


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...


No they're not. At CERN physics data is on:

* CTA for tape storage: https://cta.docs.cern.ch/v5/

* EOS for disk storage: https://eos-web.web.cern.ch/eos-web/

There is a large CEPH cluster as well but that isn't really used for physics data.


More specifically, from the EOS page:

> 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.


These DoS Regex 10/10 CVEs in some minor helper function in some package that is used once in some random side code pathway are so damn annoying.

If I could filter out DoS CVEs‚ I would.


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.


> if there is such a bug, I'm sure someone will figure out how to get in touch with Daniel and co

No, that is the point, they are not going to accept your vuln report. They are taking a holiday.


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.


Curl maintainers are clearly going to still be using computers to provide support for paid customers.

But the message is pretty clear: if you’re not a paid customer, you are not getting patches or support from upstream during this month.

Plan accordingly.


Not if it's a real vacation. If it was me then there would be no way I'd log in. Maybe this will increase the sales of support contracts.


Except if you pay them for a support contract. So there is a way, and it's actually a pretty obvious way.


I wonder if the likes of Red Hat, SuSE and Canonical have a support contract as they are commercial redistributors.


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...


curl is the sandbox. It exchanges packets with the internet and then outputs a safely sanitized byte stream.


curl is only the sandbox if you don't then do anything with the byte stream.

Pipe it to bash? game over

Pipe it to less/more? Better hope your distro keeps those patched

Open the file in a browser or PDF reader? Hey, look at all this shiny new attack surface!


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.


Right, but nobody actually uses curl as the end destination, right? You use it to download something so that you can run another tool on it.

And as such, you need to already be sandboxing the tool (since it processes untrusted data you received over the internet).


How would sandboxing curl help with vulnerabilities in your pdf reader?


Obviously, you need to sandbox all tools in the chain that handles untrusted data. This is security 101 stuff


Do you sandbox the sandbox? When do you stop?


How do you set up the sandbox without having downloaded anything from the internet? I guess there’s still places where you can buy Linux CDs.


curl is not anti-virus.


To be fair, the entire problem space sucks and I’m not sure it’s possible not to.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: