It may affect a small fraction of their user base directly, but developers and other git users are high-value targets because a compromise there can often lead to supply chain compromise that will affect a much larger group of people.
score 2 · canonical
Damn, thanks for catching that, I clearly wasn’t paying enough attention. So it is a language extension, but not one that removes UB.
score 1 · canonical
compilers are totally allowed to refine the standard and define behavior that the standard leaves as UB. They don’t have to wait for the committee to force them to remove UB. However, to my knowledge, neither GCC nor clang do this.
At least GCC lists a couple of these here: https://gcc.gnu.org/onlinedocs/gcc/Semantic-Extensions.html
Not all of these are UB in standard C and are just ill-formed, but at least arithmetic on void* is UB, to my understanding. The C23 standard draft says in 6.5.7.2 (emphasis mine):
For addition, either both operands shall have arithmetic type, or one operand shall be a pointer to a complete object type and the other shall have integer type
Where 6.2.5.24 says:
The void type comprises an empty set of values; it is an incomplete object type that cannot be completed.
And then 4.2:
If a “shall” or “shall not” requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined.
Beyond these, both GCC and Clang document optional extensions that remove some UB if you turn them on, e.g. -wrapv and -ftrapv making signed integer overflow well-defined.
score 1 · canonical
With bash being as widespread as it is, by doing it “correctly” in oils, aren’t you creating just another parser differential?
score 1 · canonical
What elevates the C standard to this special status above other standards such as POSIX and other documentation?
In my opinion, it’s nothing. If you’re targeting the C standard, its rules apply. If you’re targeting POSIX, you get to rely on its guarantees. If you’re targeting glibc, you get to rely on its guarantees.
The C standard is not the law. Heck, it’s not even a certification. C compilers can remain noncompliant for decades and face no consequences at all.
score 2 · canonical
Somebody on HN remarked that all the decimal numbers of the private keys have digits going from left to right on the keyboard, indicating that they might have been smashed in by hand.
I did a bit of quick math and you’d only expect to see this 1% of the time when generating 8 fully random 1-byte numbers. Is this unlikely enough to reject that null hypothesis? I don’t know, but it’s really fishy.
However, even if they were created that way by manual keysmashes, that doesn’t mean somebody at eMudhra did it. Maybe that’s how the reference valus were created by the author of a HSM integration library.
score 1 · canonical
If anything, this vulnerability was more of a C one than a PHP one. As in, the problem was in the implementation of PHP itself, which is written in C. Of course, there are also tons of bugs in PHP code too, including your garden variety Wordpress CVEs. This is not that.
This one is very characteristic of C vulnerabilities: Because of C’s lack of memory safety, it’s very hard to prevent memory corruption bugs. The conditions required to trigger these can be arbitrarily complex, making them hard to find (this one was hidden in plain sight for 20 years). They usually result in the most severe consequences, often remote code execution (as in this case). And because of C’s foundational role in the ecosystem, the affected components tend to be deep down in the stack and used very, very widely.
Sure, you could respond that it’s not C’s problem, it’s just that the PHP developers (who are bad, because PHP is bad, unlike us, who are good) are just also bad at C. That might hold some water if nearly every other important C project wasn’t also running into these issues.
score 1 · canonical
It’s wild to me that this is the fix. Why take the risk of having to find all those call sites just to keep the longjmp OOM handling working? Surely you’d just get rid of that longjmp and abort on OOM.
score 1 · canonical
I’m trying to design a custom shelf to fit underneath the weirdly angled roof in the attic. For this I’m learning some FreeCAD.
I’ve already had 2 attempts at getting started with FreeCAD in my life that ended in frustration but I think this time I’m slowly getting the hang of it. The software itself has also improved I think, it used to outright crash on me but today it’s stable. The learning curve is still quite steep though.
score 1 · canonical
I think there’s a lot to love about the idea of C, but its reality is much messier and more annoying.
Being around for fifty years doesn’t automatically mean it get polished to a sheen, because C is not one single artifact that one single group worked on for fifty years. Instead, it’s got fifty years of weird legacy cruft accumulated from divergence between various implementations, concessions to historical constraints that no longer apply and (yes!) human error.
This is kind of by design. The process by which C is developed (including the ANSI/ISO standardization processes) is very focused on backwards compatibility. That makes it an amazingly stable environment, there is tons of decades-old C code being used unchanged in production with modern compilers. However, that also means that all the really bad parts can’t ever truly be fixed. If you want something that looks like a perfectly cut and polished gem after fifty years, you need a process that is able to sand off some rough edges once in a while. I think we can have a systems programming language designed through such a process, even for decades, but it can’t also simultaneously have the kingpin role that C plays for compatibility and interoperability.
score 1 · canonical
I think the specific choice of 64 days is quite clever. Most ACME clients out there that don’t yet use ARI are set up to renew after 60 days, which means anybody still running these will now still not run into expiry but will get a bunch of “your certs are about to expire” warnings from Let’s Encrypt and also potentially their own monitoring, so they can update their automation accordingly. I think this choice demonstrates quite a bit of forethought and care for their users, kudos!
score 1 · canonical
I mean you can still go and pay for a cert, Let’s Encrypt is far from the only CA.
But really, what is the madness here? Who cares if it goes down to 64 days, or less for that matter? My ACME clients certainly don’t. Maybe anybody ingesting CT logs will notice the somewhat higher bandwidth requirements?
score 1 · canonical
Huh, that’s interesting. I’ll admit I haven’t used it in years, but back then it was always userdebug builds, which enabled adb root and thus full backups. They also used to recommend TWRP, which gives another method of proper backups. It seems like they’ve regressed in this domain, again in the interest of security, but still kind of regrettable. Is there no longer an Android distro focused on user control?
score 1 · canonical
There are basically 2 types of solutions:
Run Android with local root and/or unlocked bootloader, like Lineage OS. You lose some security such as defense against evil maid attacks but it’s very convenient and you’re fully in control
Run something like GrapheneOS, including the locked bootloader, but build and sign it yourself with your own key. If done correctly this would let you have your cake and eat it too, but it’s a bit of a hassle to set up. I think a project with proper support for this would be great.
score 1 · canonical
But it’s not just apps. ADB also does not get full access. Neither does the recovery (we used to be able to do full backups via TWRP, does anybody remember that?). The only party who could get full access to your data is whoever holds the signing keys - so either Google or GrapheneOS. This may be a fine tradeoff for many people but I’m not happy about it. This is not how I run my desktop Linux and I don’t think I want to run my Android like this either.
score 1 · canonical
In terms of user-control, I don’t think GrapheneOS is the best solution in the Android ecosystem. It may well be the best in terms of security, but that’s a different question.
Just like Google’s Android, GrapheneOS does not allow the user arbitrary filesystem access under any circumstances. This means a few things:
You cannot take full backups of your phone or otherwise take out all your data. All you can do is ask each app kindly via a backup API for the things it’s willing to give you.
If you ever want to replace GrapheneOS, maybe because you’ve found something better or because the project stops supporting your device, you need to re-unlock the bootloader, wiping all your data.
In essence, this means that replacing Google’s Android with GrapheneOS swaps out one gatekeeper for another. Your data is still not yours. The same is true for e.g. CalyxOS, which also insists on locking the bootloader (with a non-user-controlled key) and providing no arbitrary filesystem access.
This is a definite degradation compared to the previous generation of Android distros such as Lineage OS, where users kept full control of their device and their data. Is it worth giving that up in exchange for stronger security? Maybe, maybe not. All I’m saying is that GrapheneOS does not represent the optimum in terms of user control.
score 1 · canonical
I don’t think small is necessarily the target. It may be an aspect of the result, but only coincidentally.
That is because even very, very small programs can have behavior that we cannot reason about. There exists a 6-state Turing Machine for which we don’t know whether it halts. On the other hand, there exist programs far larger than that for which we can formally prove either termination or nontermination and also other much more useful properties. seL4 is an example. So smallness is at best a really iffy proxy for how well we can reason about a program.
Another problem with “small” is (as icefox points out) that it immediately leads to discussions around “well, how small?” and there is no good single answer. On the other hand, formal verification is pretty clear: Once you have a mechanized proof that checks, you’re done. Better yet, you’re allowed to add as many features and/or optimizations as you want as long as you can still prove their correctness.
Now of course, you will instead invite discussion around “what properties to verify?”. I think that is more productive than “how small”, though.
score 3 · canonical