c0l0

Back in the early- to mid-2000s, I used to frequent a yearly recurring LAN party ("Hobslan") for up to some 100 people hosted in Germany, about 1300km away from my home. Of course, my midi tower PC that was specifically geared towards attending LAN parties was riding with me on the train(s) going there, and after a refreshing 14 to 18h trip (depending on the year's train schedule and my monitor-and-ride-providing German buddy (thanks, Han! :)) giving me the last-200-mile lift to the proper place), it arrived with me in all its glory: A Pentium 4 "Northwood" 2.6GHz (overclocked to 3.5GHz) on an ABIT AB-AI7 motherboard, a Geforce 4 4200 Ti AGP-based GPU with 64MB of VRAM, 512MB of dual-channel DDR-SDRAM at a frequency I cannot remember, and, of course, my trusty 160GB RAID0(!) SATA HDD array to store all the things you could leech on the sweet, sweet Fast Ethernet (100Mbps) fully-switched LAN that I was going to plug this thing into! The little beast had Gentoo Linux installed, and its hardware was perfectly balanced to provide that highly sought-after stable 125fps (where a certain physics bug in the game engine allowed for maximum jumping distance) under all possible conditions in Quake ]|[ Arena ;)

The events were a blast, and even the tournaments I did majorly suck at (playing Super Street Fighter II Turbo on an original SNES, hooked up to a projector that illuminated pretty much all of one of the walls of the school gym that the event took place in, for example) are forever etched into my memory.

One year, the network was plagued by the infamous W32.Blaster worm, and most of the Windows-based machines the local admins had provided fell to it in short order. People were starting to get desperate - most of their gameservers and DC++ hubs AWOL or even FUBAR, and many were going through the motions of redoing the Windows XP setup left an right, only to see their machines becoming infected again on the first network-enabled boot-up. It was mayhem, and a weekend of pure Quake awesomeness was threatened to be reduced to a week of reciting FCKGW-... from (muscle) memory ad nauseam. Luckily, my Gentoo machine was invulnerable to that particular problem, and my little gaming beast ended up on a separate network segment for "vetted", provden-clean Windows machines only, providing FTP and several Quake ][ and Quake ]|[ game servers at the same time for those who HAD machines that still worked, or were brought back from the dead. I even saved a relevant screenshot from back then as a cherished digital artifact: https://coloss.us.to/blaster.jpg

Makes me smile whenever I happen to revisit it :)

War Is Peace. Freedom Is Slavery. Ignorance Is Strength. Ad Targeting Is Privacy.

Over the past few months with Google/Chrome threatening the rollout of "Web Integrity API", Apple's "Private Access Tokens" having more or less silently been deployed, and Windows 11 effectively mandating a TPM to be able to enforce Measured Boot across the majority of the PC landscape, I have come to the realization that the fight to preserve freedom for those who want to participate in the digital world using software they themselves can control is on the brink of being lost for good. Because of these chess pieces being moved in position, platforms of the present and future will become ever more locked down on the quest to achieve air-tight "security" and "trust", as defined by some compliance boards' checkbox item list.

Originally, I had assumed and hoped that for those of us who would rather write, compile and run their own software would be given enough rope to use (much less convenient,) alternative means to at least perform essential transactions and use necessary services online - things that are necessary to participate in modern society (banking, filing your taxes, etc.), but not driven by DRM-inducing profit regimes. Alas, not even that does seem to be the case...

My government is beginning to phase out its phone-based federal ID service that authenticates requests using a combination of Username/Phone number, passphrase, and an SMS-based OTP code in favor of a mobile app. The proprietary app is available for Android and iOS devices that implement and pass Remote Attestation as decreed by Google and Apple.

Of course, my de-googled Android phone will never pass that particular attestation gate, and my government's ID app will therefore refuse to work on it. However, to also enable people without any kind of smarthpone to use the federal ID service on their PC that using the official ID app enables, there's a supported alternative: one can also use a FIDO "Level 2"-compliant hardware authenticator, that will enable the use of WebAuthn to authenticate its owner against the federal ID service.

Having taken a bit of a dive into the differences of available FIDO/U2F hardware tokens on the market today, I've stumbled over the dismaying fact that WebAuthn, too, integrates Remote Attestation as a first-party concept. Remote attestation seems to be, in fact, the one major thing that separates FIDO "Level 2" certified devices from others that fail to attain that level of certification. FIDO Level 2 devices contain a private key (that is shared between all devices of the same make and model), which had its public key/certificate component signed by a certifying CA. This is used to verify that the WebAuthn assertion keypair of user X has been generated on a genuine, attested "Yubico Security Key NFC" (for example), and not any other kind of WebAuthn-capable device.

This, however, is not the only Remote Attestation-related datum that may hitch a ride on your WebAuthn request to a remote service provider. The docs provided by Mozilla take care to enumerate `android-key`, `android-safetynet`, `tpm`, and others as potential fields in the transmitted `attestationObject`.

To me, this makes it abundantly clear that even the faux escape hatch provided by WebAuthn available will not delay, but to the contrary, actively enable privatized providers of "trust" to kill off Free Software (in way that is useful for participating in everyday life, like my custom-compiled build of Mozilla Firefox on my Archlinux system is right now) for good. Banks et al. will simply (have or want to) deny WebAuthn assertion attempts that cannot cryptographically prove they originate from a SafteyNet- or Windows-11-TPM-attested device, and that's that. No "login successful" for you, dear user, who you were daring enough to build Chromium yourself, or use a fork not having been granted with Google's holy blessings.

See also: https://fidoalliance.org/fido-technotes-the-truth-about-atte...

Maybe "commonly encountered Free Software desktop and server userspace components"? After all, much of that is what you will also find on BSDs et al., and will give you the same trouble (if any) there.

The Linux kernel itself is in fact very, VERY extensively backwards-compatible, which is why I find it particularly unfair (on top of being wrong) to use the label Dalewyn did. It's the installed userspace libraries that aren't - at least not in all cases, but the situation sure has improved a lot over the last decade or so.

That "rest of Linux" that you talk about is not Linux at all.

I am not sure I understand what they (the business behing "authentik") hope to gain from having their Open/Libre variant available under MIT instead of under GPLv3, when they do have a fully proprietary ("you may look at the source" or not, meh) alternative that they are trying to sell INSTEAD of the free variant? Is it because they hope that MIT-licensed software is more readily adopted by businesses, and they hope to get their foot in more doors for their proprietary "premium" version that way? Or is there something else/in addition to that that I cannot see?

Maybe (hopefully :)) also interesting for those who enjoyed this article: https://johannes.truschnigg.info/writing/2022-07_advanced_ss...

Let's just hope Apple will not alter the deal any further, right? [-:

In 2012, I interviewed at Google Ireland for an SRE position. I ended up not taking the job due to family issues, but I somewhat regretted having missed the opportunity to tackle Google-sized problems and make FAANG-sized money for a few years after.

This feeling has ceased entirely in the meantime, due to what Google has become, and how its understanding of its role in the world seems to have shifted. Or maybe its true corporate nature has only become more apparent? I am not sure - but I was a firm believer that Google was a force of good in the corporate landscape of the 00s, and I am fully convinced it is not any more. It actually makes me sad, and I am afraid of the damage it will end up doing to the places (the 'net) and communities (most of the FOSS world) I love.

I'm sorry to say that I am not convinced. In recent years, Microsoft has introduced [Virtualisation-based Security](https://learn.microsoft.com/en-us/windows-hardware/design/de...) - funnily enough while recycling one of actual security experts' most-loathed acronym, "VBS" - for OS components that are deemed critical, such as Windows Defender Credential Guard. If your OS, that is now also a hypervisor, shards off some "critical" computation, such as computing RA-TLS nonces - into a privileged domain that your regular user domain may not access, and that privileged, TMP-attested domain is protected by all the secure/measured boot shenanigans that are going on with Windows 11 and its mandatory TPM, it's as game over as it was with SGX directly in your CPU (barring some grave implementation bugs that will make everything vulnerable to state-level actors regardless).

Also, Arm silicon, for example, has TrustZone, which afaiui serves a similar purpose as SGX did.

Unfortunately, that is only correct for the example cited in the article I linked to. The RFC being drafted contains attestation possibilities for both clients and servers, as per sections 4.1. (TLS Client as Attester) and 4.2. (TLS Server as Attester).

Nothing in this prevents servers from discrimincating against clients that fail to produce TPM-backed attestation that they run exclusively the exact software builds, cryptographically signed by a central arbiter of trust, that the server expects/requires them to.

I wanted to draw attention to this since it has strong "Web Integrity API" vibes, but works at a level that imho might be even more worrisome than what goes on between your browser and a web server - the TLS connection layer.

The standard aims to integrate "platform attestion tokens" (like those provided by Arm CPU platforms, for instance: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-to...) into TLS handshake client metadata, which will enable remote services to deny serving clients that do not pass SafetyNet/Play Integrity/Web Integrity-like attestation schemes before any application layer data has been exchanged at all.

It is being drafted here: https://datatracker.ietf.org/doc/draft-fossati-tls-attestati...

I feel like I have to repeat this, since so much is at stake here, where it is about the preservation of the web as we know it today, at the peril of having it turned into yet another walled garden:

The only way around the dystopia this will lead to is to constantly and relentlessly shame and even harass all those involved in helping create it. The scolding in the issue tracker of that wretched "project" shall flow like a river, until the spirit of those pursuing it breaks, and the effort is disbanded.

And once the corporate hydra has regrown its head, repeat. Hopefully, enough practise makes those fighting the dystopia effective enough to one day topple over sponsoring and enabling organisations as a whole, instead of only their little initiatives leading down that path.

Not a pretty thing, but necessary.

Perfect is the enemy of good. If you postpone or skip using Firefox because of this reason/excuse, you are even more a part of the problem than you probably realize ;)

Mozilla's opposition to such initiatives matters only because of their users. And there are no other significant fighters in this ring on _our_ side, unfortunately.

"Yes."

That is not possible, because the User Agent (UA) does not return a simple boolean value to the endpoints that requests attestation.That endpoint requests a cryptographic proof that originates at a shared root of trust between that endpoint and the device you are using (which has an embedded secret that its user cannot extract, and which was blessed by this shared root of trust with a cryptographic signature at the device's factory). Being able to generate that proof will attest that your device, its operating system, the software it has installed, as well as the UA have all been deemed acceptable (i.e., cryptographically signed by something/someone that root of trust has extended its trust to) by the attestation arbiter - so probably either Apple, Google, or Microsoft.

The banking sector is EXACTLY where "cyber 'security'" and "compliance" will mandate for this to be implemented.

When I worked a bank at $oldjob, compliance mandated we had a full-blown anti virus engine (from Microsoft or McAfee, "at your option") deployed in quasi-ephemeral container images.

It does not have to be reasonable, it doesn't have to be a net positive - it just has to tick some box on some compliance sheet for this to be required, and I will never again be able to perform a banking transaction from my personal computer or degoogled phone again.

Of course, that is the most obvious consequence of this whole mess.

I feel like I have to repeat this, since so much is at stake here, where it is about the preservation of the web as we know it today, at the peril of having it turned into yet another walled garden:

The only way around the dystopia this will lead to is to constantly and relentlessly shame and even harass all those involved in helping create it. The scolding in the issue tracker of that wretched "project" shall flow like a river, until the spirit of those pursuing it breaks, and the effort is disbanded.

And once the corporate hydra has regrown its head, repeat. Hopefully, enough practise makes those fighting the dystopia effective enough to one day topple over sponsoring and enabling organisations as a whole, instead of only their little initiatives leading down that path.

Not a pretty thing, but necessary.

Debian GNU/Linux (a mix of stable and oldstable) on all my personal servers, the work desktop and laptop, and servers at work (I am responsible for that part of the compute env at $dayjob).

Arch Linux on my personal desktop(s) and laptop.

openSUSE Tumbleweed on my wife's desktop, which I co-admin.

OpenWrt on my personal network devices.

LineageOS on my personal phone.

LibreELEC on the Raspberry Pi 4 used as a media center at home.

Called it, unfortunately: https://news.ycombinator.com/item?id=30104740

The only way around the dystopia this will lead to is to constantly and relentlessly shame and harass all those involved in helping create it. The scolding in the issue tracker of that wretched "project" shall flow like a river, until the spirits of those pursuing it breaks and it is disbanded.

And once the corporate hydra has regrown its head, repeat. Hopefully, enough practise makes those fighting the dystopia effective enough to one day topple over sponsoring and enabling organisations as a whole, instead of only their little initiatives leading down that path.

Not a pretty thing, but necessary.

Congrats! I am certain you will enjoy it! :) It's a GREAT time to choose KDE Plasma 5 on Debian 12 - the desktop is at its peak in terms of polish after many years of incremental refinements, and the non-free-firmware-choice Debian made for the 12/"bookworm"-release rendered it much easier to use for most people.

This looks like... an unconstrained amalgamation of YAML, python, and zsh/bash. Knowing all these building blocks quite well, I cannot say I find this attractive at all. Seems like it is bound to incur all the problems that having everything in YAML cursed configuration management and deployment orchestration with in ansible.

This seems to have been written under the assumption that these "elaborate security implementations" discussed are designed to serve the interests of the owner (or, these days, let's better call that person the "user" instead?) of the particular machine/hardware/node. I do not share that sentiment, and believe they are designed and implemented to service the interests of the content industry and their ilk, and purported benefits for Joe User are a pretty much a gigantic fig leaf.

All I have to say from personal experience (some of it gained working for a big bank) is that if you want and seek compliance, you will get neither security, nor saftey - but you will get compliance. :)

Whoever tells you otherwise has got a bridge to sell, as well as some compliance- and "security"-facilitating "solutions" on top.

Yet still correct.

I am not a Red Hat user or customer (I've been living on Debian and using it at work for nearly 15 years now), but I can perfectly understand their decision to not play along so nicely with EL rebuilders any more.

Look at Amazon, who, until very recently at least, simply took what RHEL provided, used that to lure customers into their "RHEL-compatible" cloud platform, far away from any need to compensate Red Hat in any way, and contributed back into RHEL and its upstreams... what exactly?

I can see this only become worse with other cloud heavyweights throwing their 800+ pounds behind other EL downstreams (such as Microsoft with Alma Linux) to continue this play, which will bleed most of Red Hat's established revenue streams - and with it, RHEL itself, and all the projects Red Hat is funding development of today - dry in the long run. They are trying to stop the bleeding, and I sure hope they will succeed. There is a LOT of Red Hat-funded software in Debian that I actually depend on, and if Red Hat withers away, chances are those projects will not survive either.

> I guess that reflects the fact that debian is a distro from another time, when you had to be mindful of the resources you consumed.

I am inclined to argue that the fact NixOS is having this problem and discussion goes to show that you *still* have to be mindful of the resources you consume :)

While public cloud resources may seem infinite to some, at least the depth of the pockets of those shouldering the resulting costs should not.

And which of those are in use/available at the Python Package Index?

If you enjoyed this article, you may also find other useful tips in a piece I submitted to HN a while ago on "advanced SSH usage": https://johannes.truschnigg.info/writing/2022-07_advanced_ss...

Yes, for instance. Because defaults actually matter.