I may be too quick to pitchfork, but this seems FAR too implausible to be true:
This is so bad.
They're asking us to believe that a script flaw, on this specific day, for critical keys, silently generated a second, weaker key pair, and that the wrong pair was then used for the CSR because the labels looked similar. And "used by mistake because the labels were similar" means nobody checked the CSR's public key against the intended key before the root signed it. Worse, they had a direct signal months ago in Bug 1970728 their CRLs failed verification, and by their own account the fix was to re-sign with the flawed keys rather than ask why the "correct" keys didn’t match the certificates.
--
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
No sooner than I replied to OP, your message mirrors my experience. I really am interested now how many people had their introduction from similar things.
I’m in a similar boat - made my first private server when I was 11 and loved tech since
Back in those days I didn’t know about VPSes so I’d host the private server on our family computer. Going to bed I’d keep the computer on and pray that the server stayed on for at least 3 hours before crashing. Worst feeling was waking up and checking the logs to see the server crashed 10 mins after you went to bed :’)
You totally can, because most things are not truly air gapped, they have store-and-forward messaging via data diodes and manual transfer. Sometimes it is necessary to trick a human to initiate a transfer, but the press of events leads to inattention.
Never thought about it from that perspective, but I think you're right. It is by design, not deceptive intent, just the infinite monkeys theorem where we've replaced randomness with pattern matching trained on massive datasets.
Another way to look at it is everything a LLM creates is a 'hallucination', some of these 'hallucinations' are more useful than others.
I do agree with the parent post. Calling them hallucinations is not an accurate way of describing what is happening and using such terms to personify these machines is a mistake.
This isn't to say the outputs aren't useful, we see that they can be very useful...when used well.
The key idea is the model doesn't have any signal on "factual information." It has a huge corpus of training data and the assumption humans generally don't lie to each other when creating such a corpus.
... but (a) we do, and (b) there's all kinds of dimensions of factuality not encoded in the training data that can only be unreliably inferred (in the sense that there is no reason to believe the algorithm has encoded a way to synthesize true output from the input at all).
This is so bad.
They're asking us to believe that a script flaw, on this specific day, for critical keys, silently generated a second, weaker key pair, and that the wrong pair was then used for the CSR because the labels looked similar. And "used by mistake because the labels were similar" means nobody checked the CSR's public key against the intended key before the root signed it. Worse, they had a direct signal months ago in Bug 1970728 their CRLs failed verification, and by their own account the fix was to re-sign with the flawed keys rather than ask why the "correct" keys didn’t match the certificates.
--
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)