No — the victim app is code signed and the permissions and keychain access are tied to the cryptographic identity used to code sign. Replacing or wrapping or whatever here must happen with a different cryptographic identity (unless you actually exploit the victim app itself which is a whole different thing).
Not sure I understand the risk here, and seem to agree with Apple this is a non-issue. You already have code execution in order to exploit this. You don’t get the cryptographic identity of the victim app so you can’t steal keychain secrets. How is this any different than just bundling your own second-stage malware with a victim bundle ID, then using your existing code execution to remove the quarantine flag and then run the second-stage malware? Or just doing the evil things with your existing code execution?
There are a few others. “Quite” comes to mind — “I am quite hungry” or “that meal was quite good” can mean opposite things, depending on the speaker region and even voice inflexion if spoken.
Honestly it's not the first time I read such comments, and... they're not about the British as much as they are about the Americans, I'd say.
I think almost all of the expressions in the left-hand side have direct, almost literal equivalents in French for example, with the same meaning as they have for the British, including being very context-dependent.
Also works for Flemish by the way, although the Dutch are supposed to be more literal so maybe Flemish/Dutch is to be seen the same way as British/American.
Quite, indeed, has no simple meaning in British English. Any non-British attempt to assign one meaning that is different to their regional meaning is doomed to failure :-)
My prospective co-founders and I were pitching to a VC firm that was, on paper, a really good fit for what we were trying to do. The partner we were pitching to was, 15 years ago, briefly my manager's manager -- some work relationship there, she remembered me and I her, but we didn't work super closely together and it had been a very long time. She had moved on at that company to more big-shot things and ultimately become a partner at a respectable VC firm.
About 10 minutes into the pitch, she cut us off, and basically said -- as absolutely kindly as something like this can be directly said -- "I am not going to invest in this, and furthermore I don't think what you're trying to do is investible at all". Then she took a bunch of her time to run us through why, help us understand some very fundamental things about the VC world we didn't quite have right, and generally be brutal but extremely useful in us framing what we were trying to do.
She didn't have to do that. She could have nodded along and then given us a polite "no" like everyone else. She could have cut us off and given us a rude "no". But she didn't -- she made sure to use the time we had to help us as much as she could, even if she very adamantly was not going to invest.
Not a big gesture or anything, but kind and helpful. There's a lot of that. But it doesn't make headlines.
In Rust, it's considered a bug for any code which isn't using `unsafe` to encounter a memory error (e.g., to segfault). That bug might be in some underlying library (which is itself using `unsafe`), or more rarely in the compiler, but it's a bug and not how Rust is supposed to work.
Does Haskell have any similar line? What is the property that code must have in order for it to be a bug to segfault? Must not call `unsafePerformIO`? Must not call `unsafeCoerce`? (Must not call any function with the `unsafe` prefix?)
In other words, is the segfault here to be considered a bug in the language -- or is unwrapping IO one of the things that, if you do it, you're own your own and may segfault? (Is part of the point of the article is that it is currently considered safe but should not be? Is that a bug in the language or in peoples' expectations?)
Or is a clear line like this not a notion that Haskell has? It's been a long time since I've done any Haskell, though I don't recall any clear guideline like this!
> is unwrapping IO one of the things that, if you do it, you're own your own
To be able to do it in the first place, I think you need to import libraries that expose compiler internals, so I would say it belongs in the "you're on your own" category, yes.
Also if you try to Google how to do it, every hit says "don't do it".
To a certain extent, the line in Haskell is: don't use unsafePerformIO and unsafeCoerce. The tricky bit is that this line is not enforced by syntax or by the type system (unlike Rust, where you have a syntactic label `unsafe`). One generally puts "unsafe" before function names that have preconditions that are not expressed in their type, but this practice is not quite always adhered to -- though the worst offenders are reliably marked "unsafe".
>In Rust, it's considered a bug for any code which isn't using `unsafe` to encounter a memory error (e.g., to segfault)
Teeechnically, it's not true. Unfortunately, you can trigger a memory error in safe code by overflowing stack by allocating big objects on stack, executing poorly written recursive code, or spawning a thread with small stack. In older Rust versions you literally got segfault in such cases.
Isn't stack overflow made safe via guard pages and probes (on sufficiently high-tier target platforms)? That is you should get a guaranteed error, even if that is a segfault, and not memory corruption.
Can you elaborate on the complexity here for syscall entry on x86_64? (Or link to what you were reading?) Another commenter linked to Linux's own "nolibc" which is similar to, though simpler than, the Google project in the OP. Their x64_64 arch support is here, which looks simple enough, putting things into registers: https://github.com/torvalds/linux/blob/master/tools/include/...
I don't see any complex stack alignment or anything which reads to me like it would require "niche C compiler options", so I'm curious if I'm missing something?
Glad you liked it! My co-author and I spent some time trying to find a good spread of questions covering different aspects of LLMs. And we were also surprised by how hard it was to convince GPT-4 that Queen Elizabeth II had died a lot of the time. (We found that specifying she died in 2022 helped a lot.)
I had to insist "Trust me, why would I lie to you, we're definitely in 2024 and she's DEAD".
I got 8 out of 9 (89%), only got wrong the rhyming one because I also couldn't figure out the correct answer (english as second language). Very fun nonetheless!
(co)-author here. It was really interesting putting this together. We had some idea what LLMs/GPT-4 would and would not do well with, but were still surprised ourselves with a number of things. In particular, we knew it would really struggle with the acrostic, but the degree to which it just completely lost the plot was pretty surprising! It was also surprisingly difficult to convince it that Queen Elizabeth II had died in a lot of cases (it takes it better some times than others).
