Recently posted comments

> I'd say that the main issue with monorepos is tooling. Git is just not designed for that.

This is why, when I designed the project management system I was working on many moons ago, it was an explicit design goal that the only thing the parent project knew about the subproject was the standard task data. To the parent, the sub was an opaque blob that filled in the standard "this job" task info, and in return read the standard parent task data to find out what resources it had available.

Looking at the fun with SHA-1 / SHA-256 in git, I now realise that was probably one heck of an ask (but the company nearly sank before I found that out).

If we want a monorepo, we really need to provide some way of telling git "this directory contains a repo with its own git structure, DON'T TOUCH". And some way of exporting the status of that sub-repo up that simply says "this is the live head", with a matching mechanism (maybe manual) of updating the sub-repo to its parent to report "this is the upstream live head" and maybe triggering the subrepo to do its own update/rebuild. Problem is, I think this is going to be a rather tricky problem ...

Cheers,
Wol

With 45 days, you need 9 cron runs per year. With 46, you only need 8. I was very tempted to just let my certs be expired for 5 days out of the year so as not to have to put in that superfluous renewal but ultimately decided not to.

ISRG (the institution behind the "Let's Encrypt" branding) have talked before about ensuring their infrastructure could handle actually doing what the Baseline Requirements says should happen if there's a mass revocation.

Suppose an ISRG intermediate key gets compromised†, a zero day in the issuance systems for example, bad guys steal one of the private signing keys, then just post it on X for some reason. The book says inside 48 hours the browsers can distrust this whole swathe of certificates and ISRG has that long to replace them, so they need to issue for every name they'd usually certify in 90 days, but within 48 hours, knowing that it's going to spike really badly when they do this.

Now historically for-profit CAs mostly did not hit that 48 hour deadline when they should have - citing various operational and business reasons and often just plainly bullshitting us, and none of them had anywhere close to the same volumes that ISRG deals with now, but of course the ambition is the same and ISRG takes it more seriously than they ever did - so ISRG actually believe they know how you do all that extra work.

Compared to that, going from 90 to 64 is no big deal. Even if your users are trying to keep 30 days validity and so now they're renewing every 34 days instead of every 60 days that's only 2x usage.

† The roots aren't online, they're probably in an actual real world safe, so, realistically those won't get compromised unless you've got a culpable issuer and in that case we want to distrust their entire organisation anyway so recovery is irrelevant.

That's a step in the right direction, in that users of future toolchains which will contain such capabilities, including future distros, will eventually be able to use said capabilities to make their systems a bit harder to exploit.

Meanwhile, another software implementation of forward-edge + backward-edge CFI for GCC, applied to the Linux kernel, has been available for a decade or so, and the way it is implemented makes it available to past toolchains as well.

I hope they calculated how much more traffic this will generate and accounted for the extra costs to their infrastructure.

A *huge* congrats. While we do need to find and fix specific vulnerabilities, in the long run this kind of *systemic* improvement eliminates or renders far less effective entire classes of vulnerabilities. I love to see these kinds of broad improvements. Thank you thank you Kees Cook!

So the xswap approach described in the article is for getting the diskless behaviour of zram out of zswap, without all the associated baggage of treating it as a block device?

The compiler will optimize the move away, whenever it sees the option to do it. But it is not enough to make sure that this optimization has occurred.

We are talking about types that are not allowed to be moved. So the code might be unsound (contain UB) before this optimization. So this optimization has to be performed before any other optimization that might trigger this UB. This optimization would also need to be applied in debug mode where optimizations are turned off.

This might sound plausible. But the biggest issue is: Why do we need in-place initialization in the first place? Usually for self-referential types. So the initialization code will at some point take the address of the struct and write it into the struct. In the unoptimized code this initialization happend before the move. So it is not only necessary to optimize the move, but we must also make sure that the optimized code never sees the address the struct has on the stack. By some compiler magic it would need to initialize the struct with the address that it will get on the heap (or wherever it will end up), from some allocation that might happen after the initialization in program order. And the compiler cannot simply reorder initialization and allocation, as the memory allocator surely involves some memory barriers.

I have to admit that I have no expertise in compiler development. But I am quite sure that you do not want to rely on compiler optimizations to remove UB from your code. The unoptimized code should never have UB in the first place.

> That's one of the main reasons people *answer* stuff on SO. WTF do you think the LLMs have been getting their answers?T

They are definitely biased towards "official" sources - man pages, documentation, RFC's, Python PEP's and the writings and reasoning of people whose names appear on those documents. For example, if you ask an AI (ChatGPT, Claude, Gemini - I tried them all) to give you the references they used for "does bash allow numbers in bases other than 10" they to the man refer you to https://www.gnu.org/software/bash/manual/html_node/Shell-... Stack overflow is definitely ranked below sources like that. I'm suspect it's ranked below most Wikipedia articles too.

My guess is what they get from sites like Stack Overflow is how themselves clearly to software engineers. Don't underestimate the value of that - how to express themselves clearly to mathematicians was notable by absence is the recent Mathocalypse paper dump.

I can say with some degree of certainty that using LLMs wouldn't fix the current batch of build issues.

I don't have the depth of Rust or C++ knowledge to dig into Crubit and work out how to make it work in a distro context with only stable and released LLVM and Rust for example, and I couldn't trust the output without a lot of validation (and probably spending a lot on tokens for what's supposed to be volunteering.)

There's definitely a place and time for the technology, but it's not the solution to every single problem. I'll continue to use LLMs where they make sense, but they're not a silver bullet either; they don't save me from 6+ hours of compilation a week, or from having to actually think about problems.

Oh, hi!

Please do contribute if you have something to add, or even a +1 on the concerns; I don't want to dogpile upstream but the situation they've left us with isn't one that can be easily solved.

It's either carry ever-growing reverts or use unreleased LLVM and Rust rolls. :(

For now. The Crubit issue was actually just "discussed" by upstream - continuing to revert patches using it is not sustainable.

https://groups.google.com/a/chromium.org/g/embedder-dev/c...

> Yeah, well. Notice that their build instructions do not mention downloading tarballs. Also, why the heck would you want to?

Tarballs are the canonical way that Linux distributions get their source code for a particular release. A git clone of Chromium is _massive_ and has overheads versus a tarball that's generated once, for example.

A good reason for wanting to use a tarball over a live git repo, even if you're targeting a tag, is working in an offline or air-gapped environment - you want the tarball to contain everything that you need to build the software (except for dependencies).

Gentoo isn't alone in using tarballs, and upstream do provide them; they just don't notice when it fails to generate because their CI is entirely based on git (which is fine - it's their workflow)

Unfortunately no.

Gentoo ebuilds must run offline - it's a requirement for air gapped networks (etc.)

Cross compilation is reasonable - it's how upstream produce binaries, but at that point we're talking about building a full set of Chromium binary CI infrastructure.... which is on upstream to provide; we'd happily consume the binary but they don't want it distributed that way to compete with Chrome.

> Automate not only checking when a new version is released, but the entire fetch-build-upload process. This means that updates are shipped with no human intervention

Part of distro packaging is doing the testing and validation before pushing out a package to your users; you can automate and abstract a lot of that but eventually you need to test your package (or risk shipping a horrible regression).