Huh! Alright, that explains why this damned thing had so much music from my own Apple Music library yet was missing so much more! I’m mildly disappointed that it doesn’t just load a user’s Apple Music library.
Funnily enough that xkcd was created because Debian actually had a hardcoded random variable (the variable should have been randomly generated) ... It was noticed when certs/pub keys for different websites were coming up the same... Mind you this was close to A quarter century ago ....
You've misremembered, but it's worth me re-explaining this because lots of people even at the time tended to describe the mistake incorrectly.
Here's how the famous "Debian Weak Keys" come into existence:
OpenSSL had two buffers we care about here for generating random keys, with associated code to mix from those buffers into the data that's going to finally be used to produce cryptographically random numbers, lets call these bufferA, bufferB and mixA, mixB
In some cases bufferA is intialized by reading data from somewhere, in other cases it was never initialized. So mixA is doing uninitialized reads in those other cases. OpenSSL is written in C and in principle reading uninitialized data is Undefined Behaviour in C, but in practice nothing terrible happened here, you'd probably get zeroes, in some cases maybe unrelated trash. However, tools for spotting UB in your C library kept flagging mixA, which read this uninitialized data, as a problem.
bufferB is always crucial, if this isn't used the numbers won't be very random at all. This data is always initialized. But mixB is very similar code to mixA, after all it is doing similar work.
OpenSSL had rejected work to "fix" the mixA uninitialized bug but a Debian developer decided that it was too annoying so they patched mixA out. If that had been the whole story nothing terrible happens and nobody would remember today. However since mixB is similar, that Debian developer asked the OpenSSL developer list hey, is it OK to patch out mixB too?
And the developers said it was OK. The result is that Debian shipped OpenSSL which did not actually generate truly random keys. There were some number (thousands?) likely and of those a handful were especially most likely to be picked, based on exactly how soon after system start you wanted to make some keys with OpenSSL.
Now, after this blew up those developers said they thought the question was about testing. And IIRC it was possible to look at the same email and, if you know mixB is crucial, you think obviously they just want to test that their change does what they expected, nobody would patch out mixB in production, that's crazy. But the developer who wrote the email intended a different meaning, they really did mean to patch out mixB and were asking if that's OK.
Thank you for that trip back into a very dark corner of my memory. I had almost forgotten the whole circus of it all; right about then i was working in the hardware 'nearly true RNG' and had this whole can of worms happen right in the middle of an otherwise working setup. What fun.
That's as clear an explanation about the situation as I have ever read. I don't know the occasion to need to explain it to anyone else will arise, but when it does... or I may use it as example of the consequences of shallow communication when serious outcomes may arise. (Ill be sure to credit the source 'tialaramex' on HN)
Train driver and signaller both believe they've reached the same understanding of the situation, but their understanding actually remains divergent, and the driver (plus a MOM) nearly gets killed as a result.
I believe the specific change was to remove this line of C in two places
MD_Update(&m,buf,j);
And the reason it was a security bug is that in one of those two places the variable buf has the precious entropy we wanted in it and so now we're not really getting random numbers.
I've seen this mentioned a few times over the last day or two, but it's not true.
The xkcd was 2007 [0], the Debian issue was 2008 [1].
It was used in pretty much every blogpost describing the Debian issue, but it wasn't created because of the Debian issue (unless they gave Randall an 8-month head-start before disclosing it).
(I don't mean this as a "well akshully" - but for me it's more impressive that it's a truism that keeps coming true, than if it was just a swipe at them in the first place)
I vividly remember my father coming home from Borders Books & Music one fateful day in 1998 with a boxed copy of Red Hat Linux 5.1. (This was the distro that eventually became Fedora, not RHEL). It was the first Linux distro I’d ever used, but my dad also had some older SuSE and Slackware CDs and floppies in his archives as well. I’m confident Red Hat has always paid their employees, and I’m confident SuSE GmbH did as well.
Famously IBM did eventually buy Red Hat, but not for another 20 years. The fact is, Linux was alive and well and growing as far back as the late 1990s, and devs were getting paid. You could literally buy CDs in a box of an installable Linux distribution at an ordinary retail chain bookstore in 1998.
And for whatever it’s worth, the reason Linux took off the way it did when it did was because the Dot Com Bubble helped pump smaller companies like Red Hat or SuSE up, and they were certainly selling floppies and pressed CDs at a margin like Shareware as well, since most people didn’t have the time or hardware to download and burn ISOs until the early/mid-2000s when P2P music took over the world.
Historically, xx.us (where xx is a two letter state code) domains have been owned* by the named US state, which then would issue subdomains on top. I believe this was originally planned and set up by ICANN themselves.
*: I realize that “owned” is a loaded word here, but (1) I’m referring to a registrar/issuer, which makes it yet more complicated as to how much “ownership” (de facto or otherwise) a given entity may have, and (2) I really don’t give a fuck about pedantic word choice if the meaning is unambiguous.
My aside wasn't intended to be pedantic, rather observing the apparent inconsistency in how it appears people think about these matters versus what the present situation illustrates the reality to be.
> but (1) I’m referring to a registrar/issuer, which makes it yet more complicated
We're also talking about a ccTLD which makes it even more complicated. AFAIK those fall entirely under the jurisdiction of the respective UN recognized government although I don't know how strong that agreement is in practice (treaty versus something else).
So at that point I guess we've roughly got ICANN -> US federal government -> CA state government -> registrar -> private party -> sublet.
The way it worked is that someone nominally representing the CA State Government had* ca.us, and they in turn gave* san-jose to someone who nominally represented San Jose, los-angeles to someone who nominally represented Los Angeles, santa-cruz to someone who nominally represented Santa Cruz, and so on. city-name.ca.us domains were still free (and charging for .com and .org domains was a new thing at the time); you would look in the zone file to see who owned* a given domain, email them with your nameserver names and IP, and they would add it to their zone.
This isn’t how things are done these days; names visible to the public are pretty much always in the form {domain}.{tld} or sometimes {name}.{domain}.{tld} (e.g. my own https://samboy.github.io). Registration is now done by bots and companies that spam you to death to try and get more money from you (the Internet wasn’t like that in the beach.santa-cruz.ca.us days). Domain names with multiple levels of delegation aren’t around they way they used to be.
The old locality domains still exist, and in many localities you can still register them today by the same "email a request to some sysadmin" process. https://news.ycombinator.com/item?id=48122635
Your beach.santa-cruz.ca.us domain is still in DNS, just with a broken delegation chain. You could reclaim it right now by setting up a nameserver at reality.samiam.org.
It's complicated and political, like always. Officially, the ISO 3166-1 alpha-2 country code list is used to decide who gets a ccTLD. (And Taiwan is included there.) But for example ".su" still exists for historical reasons, even though the Soviet Union is long gone (and its code is listed as "exceptionally reserved", which I assume translates as "we have no fucking idea what to do here.")
This raises an interesting question. If they aren't strictly following UN recognition then would it be possible for ICANN to award control to one party while the UN recognizes an opposing party as the legitimate government?
Yeah, back in the firephone days everyone who worked on the hardware side had lab126 on their contract. The software teams all had digital products instead.
So what are the failings? A quick skim through the Wikipedia article found plenty of criticism, but all the evidence I could find in my quick skim was in support of the theory. It's very likely I missed something in my skim; could you point to a specific section of the article where the evidence against the theory is presented?
I would be surprised if we ever got evidence against the broken windows theory, simply due to crime in general being a (wicked problem)[https://en.wikipedia.org/wiki/Wicked_problem].
In fact I’ve used a 100 foot fiber optic DisplayPort cable that I “just bought” on Amazon, admittedly for a LOT of money (like, I think it was about $100 USD, 3 years ago or so).
I just wish they sold the transceivers separately from the fiber. Being able to use any random length of cheap off-the-shelf SMF/MMF fiber would be so much more convenient than having to get a custom one-off cable.
They exist for medium-speed HDMI (see for example [0]), but I haven't seen them for modern high-speed DP yet.
Huh, I thought I had mine earlier. Mine was from May 2021. They were very very new and had very few reviews, and it was $56. For a 100' fiber optic cable that promised 8k60 and was light.
This cable is absurdly long. I have no idea how to coil it nicely. At my last place I had three stories, and would sometimes just dangle most of it down to the ground then wind it up from the roof.
Whoa, this sent me back. I cut my teeth on Red Hat Linux 5.2 (pre-RHEL), and I remember when they first added Bluecurve… oh jeez, this means im old, doesn’t it?
If you want point-to-point communication between two network namespaces, you should use veths[1]. I think virtual patch cables is a good mental model for veths.
If you want multiple participants, you use bridges, which are roughly analogous to switches.
That would create an excessive amount of bridges in my case. Also this is another trivial suggestion that anyone can find with a quick search or asking an LLM. Not helpful.
I'm not sure why people are replying to my comment with solutioning and trivial suggestions. All I did was encourage the thread OP to publish their notes. FWIW I've already been through a lot of options for solving my issue, and I've settled on one for now.
