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.
the recommendation was what caused the norway problem. it now strongly recommends not to do this, and it says that a Yaml parser should use the core schema unless instructed otherwise. going against the recommendation while saying that you're yaml 1.2 compliant feels like an issue that should be raised with the parser to me. I've never run into this issue in practice though.
is there a parser that says that it's Yaml 1.2 compliant that uses that regex? I don't know of one.
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.
Just to be clear, the whole incident covered over 80,000 certificates.
The TRO was applicable to only those of one subscriber - just over 70 certificates, yet caused the revocations of all 80k+ to be delayed.
To add to this, 3 days after the TRO was filed both parties moved to vacate the TRO.
DOCKET TEXT ORDER. 9 Joint Motion to Vacate 3 Order Granting Ex Parte Motion for TRO is GRANTED
I'm not sure DigiCert could have done anything about the TRO or the impacted certs, but it should have been able to move forward with the revocation of all other certificates. That IMO is the real issue/failure, alongside the concern/impact of TRO's on security processes in the future.
> 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.
Yes, I think this would have been appropriate action. If the contractual language is extremely clear between the CA and the subscriber, there is no legal basis on which the customer can prevent revocation. The fact they found a court that doesn't understand technology is frankly irrelevant. This detail is exactly why Tim and other parties are requesting the exact language of the agreement between Digicert and the subscriber that filed the TRO. A customer acting in bad faith and abusing the legal system does not compel you to violate your own contract terms, your terms under the CAB/BR, or to take actions which are detrimental to the entire Internet. This is exactly the type of circumstance where you do what you are required to do, and then sort it out afterwards. Any appeals court would have easily overturned the TRO as it has no legal basis.
> A customer acting in bad faith and abusing the legal system does not compel you to violate your own contract terms, your terms under the CAB/BR
Yes, it absolutely does. "I think the court will agree with my view of what the contract says once the case is heard in full" is not a valid reason to disregard a TRO.
> or to take actions which are detrimental to the entire Internet
That would be harder. But a delayed revocation stemming from a flawed validation process, when the CA is responsible for the flaw and knows that the result of the validation was in fact correct, simply does not cause any detrimental effects to the entire Internet.
> 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.
Same. GitLab CI isn’t perfect, but it is quite excellent and GitHub seems very rudimentary in comparison. At my job we’ve been using GitLab CI for a few years now. We did an analysis of what it would take to move to GitHub and the answer was on the order of hundreds / thousands of person-hours and there are some things we just couldn’t port, period.
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".
Posting to HN is not like writing a finalized spec or publishing an academic paper. It’s ok to ignore complicated edge cases and speak in generalities. Nobody expects commenters to 100% cover every issue with every post.
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.
Unless your 5 GHz spectrum is crowded by other WiFi, you really want to be on channel 36, because that way you do not have DFS at all, see the table on Wikipedia: https://en.wikipedia.org/wiki/List_of_WLAN_channels
