cimnine

Takeaway from this:

If you operate your own DNS, choose an NS within the same TLD als the domain you resolve: `example.COM` -> `ns.example.COM`, `example.NET` -> `ns.example.NET`, `example.ORG` -> `ns.example.ORG`

It'd be great if a CDN like Cloudflare handed out matching NS records for their most popular TLDs. This would probably speed up DNS resolution time (a little).

So e.g. `*.ns.cloudflare.com` for COM, `*.ns.cloudflare.net` for NET, `*.ns.cloudflare.org` for ORG, etc.

At least for Cloudflare, I believe they have these domains (`cloudflare.TLD`) for most of the important TLDs anyway. And the actual resolvers could be the same servers/IPs, afaict. It's mostly _just_ the (glue) records.

(I know, nothing is _just_ done on a CDN scale. Like, they'd need to also add the logic for handing out the correct NS names for the respective TLDs, which NS.TLD to fall back on for TLDs that they don't operate their own NS in, how to handle this for their bring-your-own-* customers, etc.)

https://archive.is/5ShUf

I'm thinking similarly, but not via PCIe, but via USB: There are plenty of USB->VGA and USB->HDMI adapters that contain a dumb graphics card. So, embedd one of these and grab the video signal internally.

Thereby, plugging in just a single USB cable would deliver the power needed, keyboard, video and mouse. And bonus for an emulated USB-Stick/DVD drive.

What I don't know if these USB video cards are initialized during early boot and usable during the UEFI/BIOS phase. Is that why they grab the HDMI?

The OS of PS4 and PS5 is apparently based on FreeBSD. Netflix uses FreeBSD for its CDN servers. pfSense and OPNsense are popular firewalls that are based on FreeBSD.

See also https://en.wikipedia.org/wiki/List_of_products_based_on_Free...

Talk to https://www.codey.ch/.

I've written a short blogpost about how to link SSH Keys to Git identities: https://brainfood.xyz/post/20241030-use-a-specific-ssh-key-i...

I still prefer ifconfig.co, which is open-source (BSD-3), supports IPv6 as well and has a nice JSON response as well.

I think it's good advice to not pass secrets through environment variables. Env vars leak a lot. Think php_info, Sentry, java vm dumps, etc. Also, env vars leak into sub-processes if you don't pay extra attention. Instead, read secrets from a vault or from a file-system from _inside_ your process. See also [1] (or [2] which discusses [1]). Dotnet does this pretty good with user secrets [3].

[1] https://blog.diogomonica.com/2017/03/27/why-you-shouldnt-use... [2] https://security.stackexchange.com/questions/197784/is-it-un... [3] https://learn.microsoft.com/en-us/aspnet/core/security/app-s...

Nope.

Yes, and I like to combine two established concepts instead of rolling my own: URI and UUIDv7. So my IDs become `uri:customer_shortname:product_or_project_name:entity_type:uuid`. An example ID could be `uri:cust:super_duper_erp:invoice:018fe87b-b1fc-7b6f-a09c-74b9ef7f4196`. It's even possible to cascade such IDs, for example: `uri:cust:super_duper_erp:invoice:018fe87b-b1fc-7b6f-a09c-74b9ef7f4196:line_item:018fe882-43b2-77bb-8050-a1139303bb65`.

It's immediately clear, when I see an ID in a log somewhere or when a customer sends me an ID to debug something, to which customer, system and entity such an ID belongs.

UUIDv7 is monotonic, so it's nice for the database. Those IDs are not as 'human-readable' for the average Joe, but for me as an engineer it's a bliss.

Often I also encode ID's I retrieve from external systems this way: `uri:3rd_party_vendor:system_name:entity_type:external_id` (e.g. `uri:ycombinator:hackernews:item:40580549:comment:40582365` might refer to this comment).

And another one! I actually used this regularly on my PC to remember places I'd gone to on trips, or back in time.

Me too. High-noon to engage Google Takeout [1] – so that I at least have a copy of all that data.

Off-topic: TIL, that Google Takeout can do regular backups automatically for up to one year when you link it to some cloud storage account (GDrive, Dropbox, One Drive, Box).

[1] https://takeout.google.com

So, this begs the question when we'll see ML put in place to avoid AdBlocker detection. Or ads as we know them just disappear from the web and are replaced with other kinds of ML-enabled ads. I imagine deep-fake models used for interchangeable product placement in videos or pictures or so.

Thanks. I wasn't aware this was submitted recently already.

Have a look at GitLab's plans then: https://docs.gitlab.com/ee/architecture/blueprints/activity_...

Edit: Better link

I often hit CTRL-R to reload a services config. I press `CTRL+R`, enter `reload`, and continue to hit `CTRL+R` until the right service appears. Enter. Done. Usually way quicker, especially when switching between distros. As one calls it httpd and one apache, once it's systemd and once it's and init script, and so on.

After a re-deployment, our website's back in business. But that shouldn't happen.

Devices should offer a quick way too disable the feature for a limited amount of time, so that people don't forget to turn it back on. Like it's possible with Do Not Disturb features. Perhaps that could be called Action Mode.

It's possible to disable that, see https://discussions.apple.com/thread/4995042

Good point. So there is more to it, which I didn't consider before. As I understand [1], the client uses the public key of the key pair used by the SNI to encrypt the SNI value, additionally to any TLS encryption. Only the actual SNI has the private key to decrypt the SNI value. The client must look up the public key in the DNS (I guess at least if it doesn't know the key already, which it could have in the cache).

This whole thing is still a draft RFC [2] and currently called encrypted client hello.

What I don't get: The client will have to disclose, which public key it used to encrypt the client hello / SNI value. But don't we know "all" the public keys from the certificate transparency logs? Usually a public key is only valid for a limited set of domains, so it would be easy to associate the public key used for encrypting the SNI value with the relevant service. Just look up the public key, read it's SAN or CN, and you pretty much know the SNI value. Or at least the service, which might be good enough. What am I missing?

[1] https://blog.cloudflare.com/encrypted-sni [2] https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html

As I understand, the public key that is used for authenticity is not the same as the one being used for encryption — at least since TLS 1.3, before it depends. The scheme is known as forward secrecy. For the encryption, an ephemeral key pair is used on both sides. These pairs are only used for the Diffie-Helman (or similar) key exchange. Therefore an encrypted connection can be established, then SNI can be exchanged over the encrypted connection, and then the remote can provide the signed nonce together with it's PKI public key, with which it establishes trust respective to the SNI.

Several opensource projects, especially Linux distributions, have solved this problem long ago by setting up a web of volunteer mirrors. They docs and scripts to quickly set up an additional mirror.

The central HTTP server of easylist could then hand out 302s to fetch the actual file from one of the mirrors. Alternatively to 302s, a modern scriptable DNS server, that uses the mirror list, responds with different IPs, round-robin (or even better if it's geo-aware).

DNS TXT records could maybe be used to serve a digest of the file, do that mirrors can't modify it without that being detected.

I wonder why they use nginx, and not Caddy or similar. Some service, which would handle all the certificate stuff natively, without having to deal with an extra script for certificates and without having to ensure that certbot runs from time to time.

Afaik 1password together with Fastmail, see https://1password.com/fastmail/ or https://www.fastmail.com/1password/, respectively.

Did anybody else notice that the link to this article about speed limiters is to a site called breaking news?

Why wouldn't they hire a person that is a professional electronic forensics expert to look into such a device? (Yes, cost, most probably.) I say this as «not connecting ground» sounds like a rooky mistake. Using their procedure – i.e. by what looks to me like amateurishly poking around the device – they would have destroyed anything that could be brought forth as evidence in a court.

I love OSMAnd too and used it in places where Google Maps was subpar, e.g. in India or places in the middle east. But also all over Europe when roaming data was still expensive and recently when I crossed Canada east to west by car. The benefit of the map data coming from the open street map community paid off massively where there was little commercial interest for Google to map the area in detail.

I also love that you can edit and add POIs to OSM right from within OSMAnd.

On a side note: If you like to improve details of OSM, have a look at Street Complete, a gameified app to add details of your area to OSM. One of the tasks is to check/provide opening hours of nearby facilities.

Also https://www.youtube.com/watch?v=nRLNpQfRb1c

I wonder why the private keys of these signing-certificates don't live exclusisvely in HSMs.

At least if they do, then the range of suspects should be pretty narrow.

Thanks.

Here are direct links for the curious:

- https://patents.google.com/patent/US8588949B2

- https://patents.google.com/patent/US9195258B2

- https://patents.google.com/patent/US9219959B2

- https://patents.google.com/patent/US10209953B2

- https://patents.google.com/patent/US10439896B2

(Edit: Formatting)

It'd be a more or less automated version of this (German) article:

https://www.fabiblog.de/2018/08/21/openssh-certificate-autho...

Google Translate'd Version:

https://translate.google.com/translate?sl=de&tl=en&u=https:/...