Can you think a little bigger about the implications here?? Please understand the root key for this cert has absolute mother fuckton of power ... Someone who has this key can sign certs and pretend to be your bank, your crypto provider, anything you visit!!!!

You need to understand that a root ca key is generally stored offline , in shamir secret sharing pieces, likely in some vaults... if this dude is just keeping this on his computer with a shitty router in front of it, they are being criminally negligent.

This isn't hyperbole.

Edit: missed a word

▲

reactordev 2 days ago | parent [-]

Except this is just a single validation root ca, not a wildcard across the whole internet CA. I agree that this is complete hyperbole and everyone is making a fuss about nothing.

To remind the viewers, in order for a certificate to be considered “valid”, at least an intermediate CA (certificate authority) certificate needs to be trusted by the OS. At work, we do this. When I release games, I do this. I give you my CA, so you can verify and guarantee my software was written by me, my org, and hasn’t been altered.

I get the perspective of letting end users know, but I don’t agree with giving them a choice.

The same intermediate CA is used by us for encryption of communications as well. So, we want to remove that? Make everything plain text binary? No. Get over yourself.

	▲	jdjdhdbdndbsb a day ago \| parent [-]
		So I take it you didn't read the github link where the poster says that the CA has too many many permissions including server and client authentication? No? So its not hyperbole. Evidence verbatim from GH post: However, even if this is in fact a well-intentioned bad execution of the code signature verification idea and not malicious in any way, it is still a pretty egregious security issue for the users of SBRW. For what it's worth, also consider the case wherein the private keys for the CA are stolen in some way from whomever currently has them. I also want to note that the certificate has a highly inappropriate and unnecessarily broad list of key usage IDs included, of which I would assume that no more than two or three are necessary for the advertised function of this certificate. The complete list follows: List Server Authentication (1.3.6.1.5.5.7.3.1) Client Authentication (1.3.6.1.5.5.7.3.2) Code Signing (1.3.6.1.5.5.7.3.3) Secure Email (1.3.6.1.5.5.7.3.4) Time Stamping (1.3.6.1.5.5.7.3.8) Unknown Key Usage (1.3.6.1.4.1.311.2.1.21) Unknown Key Usage (1.3.6.1.4.1.311.2.1.22) Microsoft Trust List Signing (1.3.6.1.4.1.311.10.3.1) Unknown Key Usage (1.3.6.1.4.1.311.10.3.3) Encrypting File System (1.3.6.1.4.1.311.10.3.4) Unknown Key Usage (2.16.840.1.113730.4.1) File Recovery (1.3.6.1.4.1.311.10.3.4.1) IP security end system (1.3.6.1.5.5.7.3.5) IP security tunnel termination (1.3.6.1.5.5.7.3.6) IP security user (1.3.6.1.5.5.7.3.7) IP security IKE intermediate (1.3.6.1.5.5.8.2.2) Smart Card Logon (1.3.6.1.4.1.311.20.2.2) OCSP Signing (1.3.6.1.5.5.7.3.9) Unknown Key Usage (1.3.6.1.5.5.7.3.13) Unknown Key Usage (1.3.6.1.5.5.7.3.14) KDC Authentication (1.3.6.1.5.2.3.5)