I noted this in reply to the comment above, but: the YAML 1.2 spec doesn't actually mandate that parsers use the Core Schema. They left it as a recommendation. So I don't consider it to be "fixed" at all.
I would not say it "fixed" the problem. It removed the _recommendation_ for parser implementations to use the regex `y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF` for parsing scalars as bools, it changed the _canonical_ presentation of bools from `y|n` to `true|false`, and it introduced the "schema" concept. It also introduced and recommended the use of the Core Schema, which uses `true|True|TRUE|false|False|FALSE` as the regex for inferring bools from scalars. But unsurprisingly, since using this schema is only a recommendation and not a requirement, many implementations elected to keep their backwards-compatible implementations that use the original regex.
Correction, the petition for the TRO was filed ex parte. Digicert did not have any opportunity to respond before it was granted.
They certainly could have filed a response contesting the TRO. Then their customer could have filed another motion, and eventually (7 days later in this case) the judge would have ruled on the substance of it. Their judgement was that it would be preferable to work with the customer to resolve the technical issues with revocation, and submit a joint request to dismiss the TRO. The stated reasoning behind this was that it would be significantly faster than contesting the TRO. This is true: the certs were revoked and the TRO dropped within 3 days.
I think the communication on that point was severely lacking, as they only clarified it three months later and after significant hectoring in two different bug threads: https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c43
I also think it's reasonable not to take Digicert's statements at face value, given their history. But I think both of the points you made here are wrong:
> You can stick with your policies and revoke the certificate within 24 hours, instead of delaying revocation until a case is open and a motion for a TRO is filed. Digicert failed to do so.
Let's be clear about the timeline: Digicert notified their customers that the certs would be revoked. In between the time they notified the customer and the time of revocation (less than 24 hours), the customer got the ex parte restraining order. Are you suggesting that issuers should revoke certificates without notifying their users, so that the users don't have time to get an emergency TRO? I believe that would be in violation of the BRs.
> You can stick with your policies and revoke the cert in face of the legal consequences, and deal with them accordingly. Again, Digicert failed to do so.
By "revoke the cert in face of the legal consequences" do you mean "openly defy a valid and legal court order"? Because that would also violate the BRs.
> Ten years ago, GitHub was behind on certain topics (hello CI), but they are now way ahead of the competition.
This is an absolutely wild statement to me. I find github actions to be really terrible for any reasonably complex CI flows; gitlab's CI is the primary reason we use it instead of github. If github's CI was worth a damn we'd certainly be there; as it is we mirror a bunch of repos to github just for discoverability.
My guy, read the blog post before responding. Not only has Stevan written a stateful property-based testing library, the article you didn't read addresses at great length the question of "why".
Yes, but people are allowed to express a strong opinion on a complex subject without also specifically mentioning all the caveats and possible counter-arguments to their position.
By all means argue back and add the nuance you think is missing, but it's intellectually dishonest and lazy to just say "ah, but it's more complicated than that".
One brand new wifi gotcha I just learned about, specific to 5GHz wifi: in the EU, that frequency band is used by other things, including radar for air traffic control and emergency services aircraft. The solution we decided on for that was to mandate that all 5GHz wifi devices stop broadcasting for a period of 1-10 minutes whenever a "privileged user" demands it.
I discovered this only when I moved to a place that has a higher-than-usual incidence of helicopters flying by and my wifi would randomly disconnect. I eventually solved it by finding the channel within the 5GHz frequency band that was least used by privileged users in my area, and now I only have a drop about once a month. But it used to be 3 or 4 times a day.
I have a big soft spot in my heart for idealistic crypto stuff like this. Everything the author argues is true...but there's no way in hell commercial email providers would actually publish their private keys. The only way it would be in their interest to make it easy to forge old emails would be if a substantial portion of users demanded it, and that's never going to happen.
> docker-compose is slow and not quite parallel (because it's written in Python and uses requests internally).
This hasn't been true for quite some time. Docker compose v2, written in Go, was released in 2020; v1 finally officially stopped receiving security updates this summer.
That's the problem, there isn't a good objective measure. Some type of "reasonableness" standard is usually invoked in situations like this, but that kinda just takes us back to square one: what's currently considered reasonable in the industry is pretty terrible.
This would be an absolutely terrible standard. CVEs really, really suck. See, for example, this CVE for curl[1] that was assigned a 9.8. Or read sqlite's page on CVEs[2]. The sqlite issues alone would make this a non-starter, because you're not gonna convince everyone in every piece of software you use to update their version of sqlite.
One thing that regulators need to be very careful about is how "security updates" are defined, and exactly what manufacturer obligations for issuing security updates should be. CVEs are a notoriously terrible representation of actual security risks, so a measure like "manufacturer must issue new releases that include any released patches for CVEs with a severity rating greater than 9" would be a clear non-starter.
There are also often practical issues related to security patching embedded devices: for example, a downstream supplier's driver can make it impossible to upgrade a kernel unless/until the supplier provides a fix. Of course, strong regulation here could help to drive bad practices like that out of the industry, but I'm not going to hold my breath on that one. The effect of regulation like this would make it harder for manufacturers who don't have the market power to lean on their suppliers to provide security patches.
Finally, it's important that any regulation that mandates or strongly encourages software updates also mandates that the update system itself be implemented in a secure way. This is my specific area of expertise, and I can tell you that it's very often done very badly. A bad update system is a gigantic, flashing red target for attack. So something like mandating signatures (and sig validation) on software update images would be a good start. Mandating the use of TUF-compliant repositories would be even better.
It's not about security by obscurity. A better analogy would be the fight over "tivoization". In safety-critical and highly-regulated systems like automotive and health care, there's a meaningful regulatory interest in ensuring that the devices as sold and authorized to be on the road (or in patients' hospital rooms) don't get modified in dangerous ways. That means that the software and firmware running on each of the dozens of ECUs in a vehicle is part of the (regulated) functional safety spec of the system. There are real, meaningful technical challenges to overcome if you want to meet both the goal of ensuring that dangerous and malicious software can't run in safety-critical domains, and the goal of allowing users to modify their vehicles as they see fit.
I'm speaking as one of the authors of the Uptane standard for secure software updates in vehicles, and as a life-long proponent of user freedom and open access to the computers we buy. There are possible solutions here, but they are not easy.
> No organisation should be "called out" for a lack of - insert-race-here- representation unless that organisation is in fact discriminatory.
I don't think you're being very reasonable here. A lack of diversity is just a piece of data: it might be complete coincidence, or it might be related to some underlying bias or discrimination. "Calling out" a lack of diversity is just bringing attention to that piece of data. If you want to ignore it, fine. If you want to make a case that the lack of diversity isn't a problem and/or has nothing to do with bias, by all means do so. But you can't just tell people to shut up about inconvenient facts until discrimination is proved in a court of law (or to your own satisfaction, or whatever unstated burden of proof you think is sufficient).
Free speech and dissent is important. You might not like it when people point out obvious and available data like "hey, this group seems to be pretty homogeneous", but that doesn't mean those people should shut up.
That's silly. If we followed your logic, there is no such thing as "at most once" delivery. It's actually "exactly-once" delivery, since if it is 0 it is not a delivery.