Is the difference between the NT-style and POSIX-style semaphores essentially just that NT (and now this new API in Linux) supports setting a max value? Why don't POSIX semaphores support this?
WaitForMultipleObjects is fascinating behind the scenes. A single thread can wait on up to 64 independent events, which is done by plumbing the KTHREAD data structure with literally 64 slots for dispatcher header stuff, plus all the supporting Ke/dispatcher logic in the kernel.
There’s never been a POSIX equivalent to this. It requires sophisticated kernel support and the exact same parity can’t be achieved in user space alone.
Linux native semaphores are enough. Linux has been able to be very performant without it. That feature seems like way too over engineered for little gains.
Reading the link provided by https://news.ycombinator.com/item?id=47511778, I believe "atomically acquire multiple objects". The link states they try to emulate it by performing a poll then a read, but the gap between those results in a race, which is a terrible thing to have in a synchronisation primitive.
There was also something about needing to back out if any of the reads fails to acquire, which also sounds nasty.
Ah, interesting, so wfm does both the wait and the acquire!
When using eventfd it is indeed annoying having to both poll and later read to disarm the object (there are epoll tricks that can be used but are not generalizable).
The signal+wait is also a primitive that it is hard to implement atomically on posix.
But they had dark themes for the XP theming engine, e.g. the Zune theme, didn't they? They could make the dark mode switch to a dark theme for XP-style themed controls and configure dark colors for the Win32 system colors.
Yes, and this is also how Windows 10/11 explorer turns some parts of its UI dark like scrollbars. But notably, Microsoft refuses to officially support Explorer's dark control themes or ship a complete dark theme, and because the theming engine only loads themes signed by Microsoft, no one else can ship one either without patching the OS.
Could this be worked around by installing a single shell app which then loads other apps internally? I think it's possible to dynamically load Dalvik byte code in ART these days, right?
Obviously permissions would be a problem, as you can't update the app manifest, so there would either have to be one shell app per publisher (which would at least solve the problem of installing updates for their apps) or the shell would need its own internal system for managing permissions (like a browser does). Maybe it could also sandbox different apps from each other in different subprocesses, unless that needs root privileges, but maybe it's possible with Landlock?
Or we can always fall back to the "sweet solution" Steve Jobs offered us with the original iPhone, and just let the web browser be the shell.
That would be very similar to LiveContainer for iOS [1]. I think that unsandboxed JIT is still possible as of Android 16, but Google has been cracking down on it.
It's a race condition that can be used as a primitive to achieve privilege escalation which makes it legitimate but even if it you couldn't use it for anything else but to trick the system into acting on a directory it didn't meant to it would still be a valid vulnerability (regardless of the application).
Claiming it's not a valid bug would be similar to claiming an infoleak isn't as well when it's one of the building blocks of modern exploitation.
I'm not trying to be an ass, I'm just trying to add a bit of context to ensure that the implication is well understood.
But this vulnerability is enabled by a very creative exploitation of the complicated bind mounting scheme used by snap-confine. Just reading about these mounts between /usr/lib to /tmp and back triggered my sense of a potential security vulnerability.
Slightly tangential but I never ended up switching to nix (or guix) precisely because I don't fully understand the theory behind why things were done the way they were done and where the security boundaries are supposed to lie relative to a "regular" distro. I found plenty of prescriptive documentation giving me recipes to do anything I might be interested in doing but not much in the way of design documents explaining the system itself.
I never asked around so maybe that's on me. Debian works just fine though and containers are (usually) simple enough for me to wrap my head around.
I didn't end up using Flatpak for the same reason.
When you sandbox your apps on debian already, there should be no security difference doing so on nixos, no?
The globally accessible /nix/store is frigthening, but read-only. Same applies to the nixos symlinks pointing there. This vulnerability was enabled by a writable /tmp and a root process reaching into it. This would be bad on debian and nixos.
I'm not suggesting the presence of a vulnerability just that I'm not comfortable switching to a complex system where I have little to no understanding of the logic behind the design. My remarks were nothing more than a tangential gripe.
NixOS is incredibly complicated at build time, but the filesystem & runtime state is pretty simple. Run it in a VM and look around, there's very little magic at runtime; the trickery is mostly in the build time rpath hack to load shared libs from the specific /nix/store paths, and a lot of configuring software to read files from specific /nix/store paths.
To the best of my understanding it means that a system made by CGI for digital signing of documents (as in: you get something like a PDF from a government agency and need to digitally sign it and send it back) has had its source code and/or some data belonging to it leaked.
Skatteverket, the Swedish tax authority, has been quoted in media as confirming that they use CGI's system for digital document signing but that none of their data nor that of any citizens has been leaked.
"One of the government agencies that uses CGI’s services is the Swedish Tax Agency, which was notified of the incident by the company. However, according to the Swedish Tax Agency, its users have nothing to worry about.
“Neither our data nor our users’ data has been leaked. It is a service we use for e-signatures that has been affected, but there is no data from us or our users there,” says Peder Sjölander, IT Director at the Swedish Tax Agency."
So if no data was leaked from the tax agency or from the users, then the leaked "digital signing documents" must have belonged to the only remaining party, which is CGI, so perhaps they were just some marketing documents about the benefits of their digital signing service?
The original phrasing from the attacker, from the website that put the data up for download/sale, was ”documents (for electronic signing)” which implies that they’re documents that would be signed in said system. I would take all of this with a large helping of salt though. CGI claims it’s not real production data anyway; maybe it is and maybe it’s not.
The best case scenario is in line with what CGI claims: these are lorem ipsum fake docs from an old git repo for a test instance of the system.
If that is case, then it would have been wrong from the beginning for any government to keep hold of the private keys for the signature on my citizen card.
Because in that case they can sign documents on my behalf without my permission. In a court case, it would be near impossible for me to prove that the government gave my private key to someone else and that it wasn't me signing an incriminating document.
I apparently didn't phrase that very well. If what is the case? I was trying to ask which case was the case, not trying to claim that something specific was the case.
I'm familiar with electronic signatures, and I know what documents are, but I have never heard the phrase "electronic signing documents" and don't know what that is supposed to mean. What kind of documents? Documents about signing, documents that were signed, documents in the sense that files containing keys could be considered documents, or what?
In Portugal we were early adopters for digital signatures on citizen cards.
You use the card reader, insert your gov-issued identification and can sign PDF papers which have legal validity since the private key from the citizen card was used.
Now imagine someone signing random legal documents with your ID for things like debts, opening companies or subscritions to whatever.
Signed documents can be as simple as an ID of the transaction, a statement in text, PII data that identify what you sign, or a store of larger PDF files for download and verification. We do not know. I base this on how signing works technically in Sweden.
We might've lucked out here, there is some signature data on ID cards today and official _plans_ to make a government backed signing service, but practically _nobody_ uses them in practice to just revoking all those keys will be a minor issue.
Currently most Swede's use a private bank consortisum controlled ID solution for most logins and signatures.
The PR doesn't disclose that "an LLM did it", so maybe the project allowed a violation of their policy by mistake. I guess they could revert the commit if they happen to see the submitter's HN comment.
But search engines are not a good interface when you already know what you want and need to specify it exactly.
See for example the new Windows start menu compared to the old-school run dialog – if I directly run "notepad", then I get always Notepad; but if I search for "notepad" then, after quite a bit of chugging and loading and layout shifting, I might get Notepad or I might get something from Bing or something entirely different at different times.
Although PowerShell borrows the syntax, it (as usual!) completely screws up the semantics. The examples in the docs [1] show first setting descriptor 2 to descriptor 1 and then setting descriptor 1 to a newly opened file, which of course is backwards and doesn't give the intended result in Unix; e.g. their example 1:
dir C:\, fakepath 2>&1 > .\dir.log
Also, according to the same docs, the operators "now preserve the byte-stream data when redirecting output from a native command" starting with PowerShell 7.4, i.e. they presumably corrupted data in all previous versions, including version 5.1 that is still bundled with Windows. And it apparently still does so, mysteriously, "when redirecting stderr output to stdout".
IIRC PowerShell would convert your command's stream to your console encoding. I forget if this is according to how `chcp.com` was set or how `[Console]::OutputEncoding` was set (which is still a pain I feel in my bones for knowing today).
It's also not a file descriptor. It's a PowerShell Stream, of which there are five? you can redirect to that are similar to log levels.
reply