For local services, I don't see the benefit of using DNS challenges and a Let's Encrypt certificate over running my own CA and generating my own certificates. It's not that much work to trust my root certificate on each device, and then I don't need an internet connection to verify local service certificates.
> It's not that much work to trust my root certificate on each device
Sure, but is trusting your homebrewed CA on all your devices for essentially everything really a good idea?
When your homebrewed CA somehow gets compromised, all your devices are effectively compromised and not only for local connections, but everything that uses PKIX.
Make sure all the TLS clients you use have support for name constraints. When I evaluated this in 2023, Chrome was in the process of adding support. I'd love to see a caniuse style analysis of TLS features, people assume they work but support varies.
I can either add a Cloudflare API key and Certbot on my NAS, or I could generate a root certificate and add it to my desktop computers, laptop, tablet, phones, Apple TV, etc.
Doesn't seem that tough of a choice. I guess in the future I could even forego the Cloudflare API key and just have the persistent DNS record there once.
Not the original commenter, but I noticed it too. I guess it's hard since AI is trained on human content, so presumably humans write like this too, but a few that stood out to me:
> Five entire countries vanished from GreyNoise telnet data: Zimbabwe, Ukraine, Canada, Poland, and Egypt. Not reduced — zero.
> An attacker sends -f root as the username value, and login(1) obediently skips authentication, handing over a root shell. No credentials required. No user interaction.
> The GreyNoise Global Observation Grid recorded a sudden, sustained collapse in global telnet traffic — not a gradual decline, not scanner attrition, not a data pipeline problem, but a step function. One hour, ~74,000 sessions. The next, ~22,000.
> That kind of step function — propagating within a single hour window — reads as a configuration change on routing infrastructure, not behavioral drift in scanning populations.
(and I'm not just pointing these out because of the em dashes)
GPTZero (which is just another AI model that can have similar flaws and is definitely not infallible, but is at least another data point) rates my excerpts as 78% chance AI written, 22% chance of AI-human mix.
To me at least, the article still seems to be majority human-written, though.
Also, one of the authors is "Orbie", which looks like an AI name, and if you go and read through some of the recent posts, all of the posts with that author feel very LLM-y and bland, and the posts without that author are much more normal.
Quite a lot of interesting stuff - for example there are mesh networks setup worldwide that attempt to run IP over RF using these - and then use the internet to forward packets from one to another.
They also offer simpler ‘turn-key’ wireguard tunnels too for things like Web SDR setups.
For BGP direct announce in practice it seems to be in the spirt of non-commercial ‘self learning and experimentation’ which is what a lot of legislatures around the world do use as their base definition for the ‘amateur’ in amateur radio. So I guess much like having slices of radio frequencies reserved for it, we’re lucky there are slices of address space reserved for this.
> When the device powers on, the Primary Boot Loader in the processor's ROM loads and verifies the eXtensible Boot Loader (XBL). XBL reads the current anti-rollback version from the Qfprom fuses and compares it against the firmware's embedded version number. If the firmware version is lower than the fuse value, boot is rejected. When newer firmware successfully boots, the bootloader issues commands through Qualcomm's TrustZone to blow additional fuses, permanently recording the new minimum version
What exactly is it comparing? What is the “firmware embedded version number”? With an unlocked bootloader you can flash boot and super (system, vendor, etc) partitions, but I must be missing something because it seems like this would be bypassable.
It does say
> Custom ROMs package firmware components from the stock firmware they were built against. If a user's device has been updated to a fused firmware version & they flash a custom ROM built against older firmware, the anti-rollback mechanism triggers immediately.
and I know custom ROMs will often say “make sure you flash stock version x.y beforehand” to ensure you’re on the right firmware, but I’m not sure what partitions that actually refers to (and it’s not the same as vendor blobs), or how much work it is to either build a custom ROM against a newer firmware or patch the (hundreds of) vendor blobs.
Firmware (XBL and other non OS components) are versioned with anti rollback values. If the version is less than the version burned into the fuses the firmware is rejected. The “boot” partition is typically the Linux kernel. Android Verified Boot loads and hashes the kernel image and compares it to the expected hash in the vbmeta partition. The signature of the hash of the entire vbmeta metadata is compared to a public key coded into the secondary boot loader (typically abl (fastboot before fastbootd was done in user space to support super partitions))
The abl firmware contains an anti rollback version that is checked with the eFuse version.
The super partition is a bunch of lvm logical partitions on top of a single physical partition. Of these, is the main root filesystem which is mounted read only and protected with dm-verity device mapping. The root hash of this verity rootfs is also stored in the signed vbmeta.
Android Verified Boot also has an anti rollback feature. The vbmeta partition is versioned and the minimum version value is stored cryptographically in a special flash partition called the Replay Protected Memory Block (rpmb). This prevents rollback of boot and super as vbmeta itself cannot be rolled back.
>What exactly is it comparing? What is the “firmware embedded version number”? With an unlocked bootloader you can flash boot and super (system, vendor, etc) partitions, but I must be missing something because it seems like this would be bypassable.
This doesn't make sense unless the secondary boot is signed and there is a version somewhere in signed metadata. Primary boot checks the signature, reads the version of secondary boot and loads it only if the version it's not lower than what write-once memory (fuse) requires.
If you can self-sign or disable signature, then you can do whatever boot you want, as long as it's metadata satisfies the version.
You may not be stealing the actual content, more so “making a copy”, but in doing that you’re taking away money the artist would have earned if you bought their album or streamed it on Spotify (admittedly that’a a very small amount for the artist but that’s another thing)
And if I stole something physical you had for sale, you wouldn’t make the money, so the end result is effectively the same.
The “if you bought their album” is the non-trivial part of that sentence. A pirate is not necessarily going to fork over $20 for an album if they couldn’t pirate. Chances are they will simply not buy the album. In either case the artist doesn’t get their $1.20 (6% to the artist the rest to the studio and distributors). So the result is really not the same because the artist and the pirate can both have the album in different ways and in both cases the artist doesn’t get their $1.20 unlike a physical good which cannot be cloned.
What this really is exposing is that most art is not worth the same. A Taylor Swift album is not worth the same on the open market as a Joe Exotic album. Pricing both at say $20 is artificial. Realistically most music has near zero actual value, hence why if you are a B tier or lower artist you won’t make much compared to an A tier artist on platforms like Spotify or YouTube which pay per listen/watch.
Very cool. Seeing how almost everything from WiFi, to NVME SSDs, (to apparently USB ports sometimes?) are connected to it, is PCIe the only high-speed interconnect we have for peripherals to communicate with modern CPUs?
The high speed signals that come out of mainstream CPU chips are generally DDR, SMP, and PCIe. Outside of a very few exotic things that use QPI or HT to connect, or exotic storage might use DDR, yes high speed off-chip peripherals use PCIe.
NVLink is another one you might have heard of, although it might also fall in the exotic category. I think some systems take AXI off-chip too. So there's various other weird and wonderful things. But none you're likely to have in your PC I think.
On-chip is another story, you can connect USB or NVMe or GPU "peripherals" using an on-chip interconnect type. But I guess you are asking about off-chip.
reply