jcgl

Outside of interface identifiers, what is so complex about them? I think they end up being purely simpler than IPv4 addresses since they can’t be mistaken for DNS names.

How do you make sure you’re getting enough iodine?

> Zero days for chrome will cost more than zero days for Firefox because Chrome takes security more seriously

They may cost more for Chrome, but it needn’t be because Chrome takes security more seriously; Chrome’s greater market share alone would be enough to account for this.

Not that I’m denying the overall conclusion. Just this bit of reasoning.

Damn, good call. Really reinforces the need for sandboxing.

Still doesn’t negate the value of OpenSwitch, since the majority of malware won’t do that. But really good to keep in mind.

Excellent example, thank you. This is the kind of stuff that skeeves me out and is entirely within the model of threats that I want to guard against. Sandboxing + OpenSnitch is good stuff. And, ofc, npm bad.

> Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me.

Yep, exactly. Reject by default, with reasonably judicious always-allow rules.

> That wouldn't help in that case as exfiltrated data is committed to public GitHub repositories

Correct in general that it doesn't protect against stuff like that. But this whitelisting is done per-command (in this case, the whitelisting is scoped to the node executable). I've had no need to allow node access to Git in the first place, so no problem there.

> Unless you have to accept every time an app posts or requests data from known hosts?

OpenSnitch doesn't have access to application-level information, so it has no concept of "post" or "request." It's got DNS names, layer 3 info, layer 4 info, and other such things that are visible to the kernel. Your rules get matched to network traffic based on these various properties.

On my personal machine, I run OpenSnitch. Much better defense against data exfil if you reject outbound connections to unexpected/unwanted hosts.

I originally bought the touchpad for my UHK. But, much to my surprise, I have gravitated towards the keyboard's built-in mouse layer over time! Now I scarcely plug in the touchpad (or even key cluster) modules at all.

As a sidenote, I love my UHK. Just a joy to use, and it's so easy to customize. I don't have any experience with competitors like the ZSA Voyager, but the UHK's configuration software and macro language do make it quite pleasant to bend to your will. For instance, I do some funky stuff with macros and lighting here: https://www.cgl.sh/blog/posts/wnl.html

Forgot to mention: you can use systemd-socket-proxyd to bridge to an application that doesn't support socket activation too: https://www.man7.org/linux/man-pages/man8/systemd-socket-pro...

Yes, I agree that device-bound credentials (DBC?) are a really big deal here. Just wanted to get the story straight.

When it comes to the notion of requiring DBCs without also requiring remote attestation, how do you deal with solving the problem of virtualized credential devices, e.g. swtpm? If some application wants to leverage DBCs, it will make some DBC API call, e.g. call out to a TPM. However, without some sort of attestation scheme, there's no way to verify who/what is on the other end of that API call.

Maybe it's not important for applications to be able to require DBCs without attestation. But at first blush it seems like a valid thing to want.

> For all they know you’re just some gullible user that clicks through every fishing email you get.

Passkeys are non-phishable. That's part of their schtick. I'm not a huge passkey fan myself, but this is a real benefit.

Point taken about the core team being stretched thin. But I don't see how the "increase stability of some core crates" is enough to change the packaging practices/culture. Maybe I'm wrong, but you really don't get those ecosystem benefits unless the ~entire ecosystem buys into that set of packages. Which really doesn't happen without stdlib.

Also, I think that your example of Go's breaking crypto changes misses the forest for the trees--the stdlib has been incredibly stable through its history, and the vast majority of packages just never have to worry about it. I'm honestly not aware of a language out there with similar adoption, featureset, and robustness. More to the point, I'm not aware of a language out there with a more reliable stdlib that permits the ecosystem to have small dependency graphs.

One man's bloat is another man's batteries-included, I guess?

My argument would be that if a more featureful standard library could get Rust closer to the superior dependency culture of Go, it'd be worth it. As-is, Rust dependency trees are just wild.

> Even for sites that don't offer granular feeds, every major feed reader offers filtering options, a lot of them offer fairly complex regex filtering.

This is true to some degree, but regex filtering or really any strictly logical filtering is often too coarse or too fragile to work well in practice for all but the most dedicated RSS gardeners.

What I’d really like to see is some sort of fuzzier logic that gives the user a more semantic interface to filtering and/or ranking feed items.

Take, for example, the feed for a medium-sized newspaper where you want to filter for/prioritize articles about your local area and particular topics of interest. Those news feeds are often very high volume and don’t make good use of tags or other metadata that can be consumed by strictly logical filtering systems. So a fragile, badly-behaving filtered list is what you’re likely to get. Whereas a fuzzier, more semantic interface (local LLMs?) would be far more reliable and easier to use.

If the application supports it, there’s also systemd socket activation (or traditional inetd sorta stuff too if that fits)

You don’t need to roll your own LMS—you can self-host Canvas: https://github.com/instructure/canvas-lms/wiki/Production-St...

> Nope. Key material rotation is just circus when it's done for the sake of rotation.

I'm a mere sysadmin and not a cybersecurity expert. But this is always something that leaves me torn.

On the one hand, yes, rotation periods for many/most credentials are long enough that you're not really de-risking yourself all that much.

On the other hand, doing regular rotations allows you to tighten up your threat model. A regularly-rotated credential allows you to say "I implicitly trust that this credential has not been compromised prior to the previous rotation."[0] Whereas, without credential rotation, you're saying "I implicitly trust that this credential has not been compromised ever."

The latter to me seems clearly like the inferior model. The question is just whether the cost-benefit pencils out. And that is obviously very situationally dependent. That calculus doesn't pencil out when dealing with user-owned passwords for instance (i.e. the costs of regular password rotation dominate the benefits of the improved threat model). Human limitations with memory and such are the main issue there. However, that doesn't apply to e.g. hypothetical sufficiently developed DNSSEC infrastructure. Does that calculus pencil out there? I don't know. But it seems plausible at least.

[0] Modulo attackers having been able to pivot into a persistent threat with a previously-compromised credential.

I think that's why this new IPv6-Mostly stuff is so exciting. You can dual stack a network segment if some of those v4-only devices exist there, but IPv6-Mostly will make sure that the other devices stay on v6 (translated or native).

Same experience here. Linux admin. I’d absolutely love to be told I’m holding it wrong, but all I can see is that there’s no way to hold it right.

Your consternation is seconded.

Agreeing with my sibling commenter, this writer is extremely experienced and has been writing this blog for many years. I’d be appalled if this were LLM-written, but thankfully it reads with the same style and tone that he’s always had.

> Revocation is an emergency measure, not a routine one. That's ok.

At the scale modern CAs operate, even emergency measures (i.e. measures that are an emergency for the party receiving the leaf cert) are also routine for the CA/the party granting the leaf cert.

Preface: I’m not sure exactly who runs this blog or whatever viewpoint they hold. Seems to be a lot of AI boosting mostly? But my response is really just about this article itself.

This article seems mostly content-free. It alleges (correctly, imo) that k8s implies far more operational complexity and degrees of freedom than most orgs need. This becomes especially true when orgs adopt cloud-specific features or patterns that hinder the vendor-agnosticism that they (the orgs) to provide.

However, this article is entirely absent of any helpful degree of detail as to what alternatives do or should exist. They gesture at some cloud (or other?) providers wrapping and abstracting k8s. They assert that orgs do indeed find that appealing. It’s unclear to what extent that’s true in reality, and it’s unclear what paths are available to most orgs. This article really doesn’t provide any insight for someone who has already realized that k8s has steep costs for the supposed benefit of vendor-agnosticism that gets more or less invalidated for the many orgs that also use non-portable cloud features.

See Podman quadlets.

Depending on the model though, aftermarket (or even new old stock) is readily available. If you buy used business class laptops like I do, you’re all but guaranteed to be in good shape regarding at least batteries.

> The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM

Or have whatever deployment tool that currently populates the env vars instead use the same information to populate files on the filesystem (like mounting creds).

> Only if the L2 network actually supports L2-multicast. Ethernet doesn't, except if your switches are intelligent enough. With cheap ethernet switches, multicast will be simulated by broadcast.

True, but outside bottom-barrel switches, any switch that's not super old should support multicast, no?

Regarding the rest of your comment, I really don't see how all those things count as layering violations. Yes, there is tight coupling (well, more like direct correspondence) between l2 and l3 addresses. However, these multicast addresses are actual addresses furnished by IPv6; nodes answer on these addresses. Basically, the fact that there is semantic correspondence between l2 and l3 is basically an implementation detail. Whereas ARP even needs its own EtherType!

And, yes, nodes need to keep state. But why is that relevant to whether or not this is a layering violation? When two layers are separate, they need to be combined somewhere ("gluing the layers together"). The fact that the glue is stateless seems irrelevant. But again, I'm just a sysadmin.

I guess it depends on what you mean by "impossible." If you only mean that it's theoretically possible, then sure, one can imagine a world where that is done. But even with IPv4's meager 32 bits of address space, it would explode TCAM requirements on routers if routers would start accepting announcements of /32s instead of the /24s that are accepted now. And /64 (or, jesus, /128) for IPv6? That's impossible.

But it's not the only way to tackle the problem of resolving layer 2 addresses, and you can do so without introducing the layering violations and expansive broadcast traffic that ARP implies (along with the consequent problems with WiFi and such).

For instance, IPv6's NDP is built on actual IPv6 packets (ICMPv6), rather than some spoofed IP-lookalike thing. No layering violation, and, thanks to multicasting, no need to dump a bunch of broadcast traffic on the layer 2 network.

Ironic, considering that Meta is one of the more notable companies to run IPv6-only internally.

> The stuff on my network assigns itself ipv6 addresses based on their mac address? That's how you can do stateless ipv6?

Nit: per RFC8064[0], most modern, non-server devices do/should configure their addresses with "semantically opaque interface identifiers"[1] rather than using their MAC address/EUI64. That stable address gets used for inbound traffic, and then outbound traffic can use temporary/privacy addresses that are randomized and change over time.

Statelessness is accomplished simply by virtue of devices self-assigning addresses using SLAAC, rather than some centralized configuration thing like DHCPv6.

[0] https://datatracker.ietf.org/doc/rfc8064/ [1] https://datatracker.ietf.org/doc/rfc7217/