rb12345

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.)

Usernames for new users always show up in green.

That's true for SAML2, but not SAML1 - not that anything should be using SAML1 these days.

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.

Try https://infinitedigits.co/tinker/thx/ instead?

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.)

LXC/LXD are probably the closest to that on Linux, although I'm not sure about nesting containers.

Linux has supported 240/4 addresses for years, but Windows still does not.

The 50.03% is specifically US traffic; for global traffic, it's 36.89%.

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.)

Even the kilogram is defined via physical constants these days (https://www.bipm.org/documents/20126/41483022/SI-Brochure-9...., pages 21 and 205 in the PDF).

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.

I'd say the main argument for using microk8s over minikube is that Canonical supports it, assuming that's a relevant concern.

The issue for both microk8s and minikube is how to actually build the containers in the first place. With Docker Desktop or the Docker Engine on Linux, you can use "docker build" to build them. Without that, you need to install a separate tool to do the build (buildah/podman/generating tarballs by hand?) and then push it into a suitable registry or import it into Kubernetes.

The problem you're possibly missing here is that oil is used for a lot more than just fuel and energy production. It's used for everything else: road surfacing, plastic production, synthetic fibres, chemical and pharmacutical production, lubrication, fertiliser production (although you could switch to green hydrogen for that), and much more. None of that demand disappears if you stop burning oil and gas, although maybe you could use bio-oils as a starting point for some use cases.

The real issue is that the people who want to use the product and the people needed to make it usable aren't necessarily the same. Marketing generally caters for the former set of people, who are the people buying the product they want to sell. The grandparent post is more about open access to technical support documentation to make the product work afterwards. (In the worst case, you frequently end up with non-technical people having to act as a go-between between their vendor and local technical staff, especially in sufficiently-large organisations.)

Taking the SAML/SSO example of the grandparent post, the odds are that the only time the poster will hear of the product is when they're asked to do the integration to make logins work. It is unlikely that they will know or even care about what shiny features the product has, since they're not the expected user base. If there's simple documentation on integration methods freely available online, it's easy enough to read it in half an hour or so and figure out how feasible the setup is likely to be in your environment. Going down the demo/chat route is likely to take a good 1-2 hours minimum, and the likelihood is that much of that is wasted sitting through presentations for the product side. That's great for the actual customers, but not useful for the technical staff the customers brought along to make it work. If you're lucky, you might get to actually speak to technical staff that can explain the SAML/OIDC setup steps in call 1; often, you might well have to set up a second call to actually discuss the technical requirements if not more. With many such integrations, the time quickly adds up...

There were similar issues more recently (2018/19) with custom XML entities or comments. The XML signature was unaffected, but if code used the equivalent of element.children[0] to get the contents, it was possible for attackers to truncate the attribute values seen by the service provider library.

I would be tempted to skip the Docker part entirely and use raw EC2 instances plus Packer or whatever tool of choice to.deploy the code. You still get autoscaling that way, and additional isolation of processes too. In addition, Amazon handle all the packing of VMs into hosts. With the Docker container route, you're still doing some of that work yourself to minimise waste.

They haven't been accepted in shops for over 10 years now. Cheques still see some use elsewhere, but are slowly being replaced by cash, cards and bank transfers depending on the use case. The Wikipedia entry (https://en.wikipedia.org/wiki/Cheque#United_Kingdom) sums it up pretty well.

No, the real reason is because it's trying to use an optional technical flag to enforce a social/political policy, and as such was doomed to failure from the start. If I recall correctly, the "tech community" was largely in favour of DNT, and anti-advertising in any case. The advertising industry, however, was not, so why bother implementing something that goes against their own interests?

The only workable solution to that problem in practice is legal/political: legislation and sufficient regulatory abilities to effect compliance (i.e. GDPR/PECR and the like). In the end, the US stuck with permit-all-by-default and largely don't care, the EU/UK went deny-tracking-by-default with penalties to back it up.

The reality is that this proposal will fail for much the same reasons: either you have an opt-in mindset from personal beliefs or legal requirements, in which case the global off-switch is worthless to you; or you're pro-tracking, in which case the incentives are to ignore the switch. Or you're Debian etc. and you remove the tracking code outright...

The problem here is that the latent firepower can be used in two ways: to help defend the blockchain, or to destroy it. With 62% of hashrate offline, it's entirely possible to buy up the old miners cheaply, wait for complexity to fall, and then use your newly acquired hardware for fun and profit. Bear in mind that the attacks here could be 51% transaction-invalidation, or simply just messing with the complexity (jumping from 25 minutes/block to 3 minutes/block and back again as the system corrects for the changes in hashrate).

As said elsewhere, for U2F/Webauthn, the biggest threat is creating a duplicate of the key rather than third parties using the physical key. The idea is that physical security plus needing to know the account password should be sufficient security for that use case. Yubikeys in smartcard or FIDO2 mode do use PINs or passwords to protect the private key, since in that case the private key+PIN are the two factors.

The Register used it back in 2018: https://www.theregister.com/2018/11/19/wombat_cube_poo_demys...