jis

I suspect that the definition of "Safe" in this context is that it has limited ability to mess with your computer. From what I have read, the application didn't violate the security of anyone's computer, it didn't need to!

So we need to be careful with how we interpret "Safe!"

In the 1990's we had Netscape with SSL and Microsoft with PCT. We (the world) really didn't need two protocols to do the same thing. So, we (the IETF) got the Microsoft folks and the Netscape folks to work together to come up with a merged protocol. This resulted in the birth of Transport Layer Security, aka TLS, which is what we use in browsers today...

P.S. It is a Rust program, I compile it as a static binary, so my ansible script can push the binary out to any Linux distribution (that is x86_64) and it will run.

A less permanent solution is to use versioned buckets with MFA Delete turned on. You can then cleanup versions if you need to by disabling MFA delete, which requires the MFA to do. So as long as your MFA device is not on-line, then if someone compromises your servers, they cannot disable MFA delete and cannot remove versioned objects.

Congratulations from the MIT App Inventor Team. We're glad we could play a small part in your success. Wishing you continued success and happiness.

emacs -- Well, heck its emacs!

git -- Change history is your friend, and you get out what you put in (hashes verify data against corruption)

tinc -- There Is No Cabal: Mesh VPN lets you build a VPN across diverse environments including different clouds.

Sorry to reply to my own comment. But I want to clarify. Two certificates (at least) expired. The root named "AddTrust External CA Root" and a subordinate certificate with a subject of "USERTrust RSA Certification Authority." Both expired around the same time.

The "USERTrust RSA Certification Authority" certificate signed yet another layer of intermediate certificates.

The "USERTrust RSA Certification Authority" certificate was promoted to a self-signed certificate, now in the browser trust stores, using the same key pair as the original certificate that was signed by "AddTrust External CA Root." It has an expiration of 2038 (although that concept is a bit vague in a root certificate).

It's actually worse. The new root (good I believe until 2038) uses the same key as the now expired certificate. It has to or it would not be possible to validate the certificates that were issued. And this new one is a root certificate installed in browsers!

What "should" happen is that no certificate should be issued with an expiration date later than the issuing certificate. Then as the issuing certificate gets closer to expiration, a new one, with a new key pair, should be created and this new certificate should sign subordinate certificates.

Nope. It ran an in-house OS named "Delphi". There was a PDP 11/45 at LCS and a PDP 11/40 in building 38 used to teach 6.031 (the predecessor of 6.001).

Amendment: If you are on the Internet, consider your traffic to be public. If you care about it, protect it (encrypt it).

Yep. The problem is that most customers cannot judge the level of security offered by a company. So Company "A" says they are "secure," but has a cumbersome process to follow to get a certificate. Company "B" says they are "secure" and has a convenient process. Guess which one gets the business (all else being equal).

In reality Company "B" may well be much less secure then "A", but the customer has no way of knowing that or making a judgement on which company is more secure.