Assuming US gallons, $8/US gallon works out as £1.60/litre. That sounds about right for current UK prices, depending on what and where you're buying it. (Yes, fuel is expensive here compared to the US; that's largely down to fuel duty and taxes.)
Outdated certificates are actually fine with regards to SAML, oddly enough; the logic being that the trust is handled out of band at metadata level, and the certificate is just a public-key distribution method. (That applies to Shibboleth at least; other implementations may disagree.) This does of course assume that you have a means of safely keeping metadata for the other end of the trust relationship up to date. In an eduGAIN/local federation setting, that's easy enough to do with signed XML metadata feeds and daily fetches, but far less so for bilateral trust.
The XMLDSig stuff is definitely a mess though. There were definitely issues with comments in signed content allowing values to be truncated to the start of the comment, along with some similar weirdness with XML entities. And that's before any of your (entirely valid!) complaints...
I'd say the main difference is that OAuth is granting the SP the ability to "do stuff" as the original user (including reading the user's profile details, as OIDC does), as opposed to SAML's approach of just sending attributes describing them.
For what it's worth, it is certainly possible for SAML SPs to flag that certain attributes should/must be released to them via their metadata, but the actual release is at the whim of the IdP and its operators. It's also possible for a SAML IdP to expose that level of detail to its end users and allow them to agree/disagree to the attribute release, although I'd be surprised if that behaviour was particularly common in practice.
> What is an "OAuth key"? Do you mean an OAuth token? No, Golden SAML is worse than stealing an OAuth token, because an OAuth token is valid for 1 user, but Golden SAML can be used to impersonate any user. Also, OAuth tokens expire, but Golden SAML doesn't expire (although if you steal an OAuth refresh token, that won't expire).
Stealing the OAuth token signing key, since then any fake OAuth tokens signed by it would be considered authentic.
> But that's the thing: deciding how software is built and which features are shipped to users _is_ under our control. The case with xz was exceptionally bad because of the state of the project, but in a well maintained project having these checks and oversight does help with delivering better quality software. I'm not saying that this type of sophisticated attack could've been prevented even if the project was well maintained, but this doesn't mean that there's nothing we can do about it.
In this particular case, having a static project or a single maintainer rarely releasing updates would actually be an improvement! The people/sockpuppets calling for more/faster changes to xz and more maintainers to handle that is exactly how we ended up with a malicious maintainer in charge in the first place. And assuming no CVEs or external breaking changes occur, why does that particular library need to change?
Yes, but as MongoDB is a document database, storing and updating giant blobs of JSON as a single operation as opposed to breaking the JSON down into individual fields is intended behaviour. This works in Postgres too, of course, but then you lose the relational database advantages on top of the large-single-field issues.
All this really comes down to is picking the right database type for the problem you're trying to solve.
In fairness, they also gave us the joys of `strcpy(src_ptr, dest_ptr)` and `scanf("%s", str_ptr)`, which with the benefit of hindsight and many buffer overflows later were a terrible idea.
Those numbers look like they could be about right for 2020/2021, but using them in a 2023 article is meaningless given the effects of the war in Ukraine on gas and electricity prices. I don't know how much Portugal's grid depends on gas, but I could believe that it's less affected by gas prices than the UK grid is.
"EnableSendfile On" will enable that on Apache, and has been around since Apache 2.0.44. It's not enabled by default though, and as you say, TLS breaks it.
It's true that Blue Pill and friends were an issue 15 years ago. I would have expected VT-x to be on by default now though given that Windows 10 and 11 both use virtualisation for various security features (Credential Guard, HVCI and so on). There's no advantage to disabling it...
(Edit: of course, that wasn't the case when this particular article and BIOS was written.)
The thing is though that 40% of the German gas supply comes from Russia at the moment. That means that if you can eliminate the 15% used for electricity, you've reduced the demand for Russian gas by about 38%. Put that way, reopening the newly shut nuclear plants makes a lot of sense. Refuelling and starting an existing power plant should be far quicker than building a brand new power plant or wind farm. You'll still have a lot of demand for gas from heating, but the warm winter and arrival of spring should reduce that too in the next few months.
Longer term, you are right about the need for more heat pumps to replace gas heating, and I'd also add extra insulation to that to reduce the heating needed from any source. The heat pumps can be powered by nuclear, renewables or gas depending on cost and preference.
You can actually do most of this today; you just need to have the metric equivalent amount at least as visible on the packaging and pricing labels to satisfy the EU rules. Milk is still sold in pints (technically some multiple of ~0.57 l, but near enough), some foods (e.g. jam) are still sold in 454g (i.e. 1 lb) amounts. All changing the rules does is allow you to remove the metric sizing, and I'm not convinced there's any burning desire for that. (The "metric martyrs" were largely against the additional work to add metric prices alongside Imperial ones; most places today no doubt use software to generate the price labels and will just keep things as-is.)
Likely because DNS worked just fine without EDNS client IP (and indeed DNS) for decades. For example, I remember the use of the 4.2.2.2 server, which was globally accessible but US-based. The responses though were 100% usable wherever you were on the planet. Equally, a national ISP running DNS servers would get you a country at most; a /24 gives you city or better location, carrier-grade NAT aside. Latency between the client and server may be slightly higher, but that's the end user's problem and not an issue for the site. In any case, it sounds like the Cloudflare source IPs for recursive DNS lookups are locatable via GeoIP, so I fail to see the problem.