[-] paco@infosec.exchange 1 points 1 year ago

@django I obviously didn’t know that. Thanks for taking the time to explain.

[-] paco@infosec.exchange 4 points 1 year ago

@smokinjoe An interesting reaction to react is Svelte: https://svelte.dev/. Instead of sending an entire application to the browser and making the poor client run all of it, do a crap ton of compute and calculation at build time. Send minimal code and computation to the browser. Totally different paradigm.

[-] paco@infosec.exchange 5 points 1 year ago

@hedge doing the math is one thing. Deciding on the semantics of what it MEANS is something else. If it verifies, what does that mean? Does it mean the contents of a file are “good” (valid, trustworthy, not malicious, complete, etc)? Does it mean you know WHO signed it? And what does that WHO really mean? A person, an organisation? Was the user that caused the signature authorised to do so? What do you believe about the identity, knowing that the certificate validated?

And if the certificate DOESNT verify…what does it mean? Does it mean the contents were modified? Does it mean the contents are invalid? And HOW does it fail to verify? Was the signature made before the NotBefore date? Was the signature made after the NotAfter Date? Is the certificate fine and the signature valid, but the certificate who signed the certificate who made the signature somehow untrustworthy? Or maybe the certificate you have is a tampered certificate where the identity has been modified, but the cryptographic math of the signature on your file checks out. So the contents of the file are probably fine.

We don’t ask these questions. And we definitely don’t answer them. As James Mickens says in his talk about computer science, “The stuff is what the stuff is, man.”

paco

joined 6 years ago