The bits in https://gitlab.com/cznic/sqlite/-/blob/master/tcl_test.go run the full suite of SQLite TCL tests as part of a Go test. That's in turn run as part a CI setup with results at https://modern-c.appspot.com/-/builder/?importpath=modernc.o....

Those are not all the tests for SQLite: https://sqlite.org/testing.html#harnesses

Only the TCL and SQL Logic Test are publicly available; it's one of the ways that the SQLite developers get paid.

You are correct, I should have clarified that it's just the publicly-available tests. Still, those are pretty expansive.

Hey, sorry to hear that. I'm a contributor on the project and if you're able to open an issue (https://gitlab.com/cznic/sqlite/-/issues/new) with any info you have it would be very appreciated.

Hi, Heroku engineer here. We rekeyed our certificates, including the one for *.herokuapp.com, meaning we resent our original certificate requests (CSR) to our CA but signed with new private keys. This is why the dates didn't change.

Our CA will eventually revoke the previous incarnations of our certificates, signed with the old private keys, making them invalid.

Am I missing something, or doesn't the browser have to explicitly check for key revocation? I know the checkbox was off in my version of Chrome. Maybe I set it, but I'm not sure.

This [1] Seems to suggest that Firefox, for instance, only checks for EV certs?

[1] http://news.netcraft.com/archives/2013/05/13/how-certificate...

So is there a simple way to check if an arbitrary site updated their certs?

Thanks! It might be reassuring to others who see the same mixed-signals if the official blogpost made specific mention of APPNAME.herokuapp.com HTTPS, and that the certificates may look older but really are fresh.

Thanks for the feedback, we have updated the blog post to include some information regarding this.

This is completely the wrong approach. Your private key might have been compromised and you're generating another certificate for the same compromised private key? What is that supposed to do?

As discussed on twitter (https://twitter.com/grittygrease/status/453606054698692608), I should have said:

We generated new CSRs, with new private keys, but with the same dates and details as the originals. This let us get fresh certs without going through a full renewal.

Thanks for the prod.

Thanks for the update. Happy revocation day!

I think you misread... the poster said they used a new private key with the same CSR.

The CSR contains the public key for a unique private key. How do you have a new private key with an old CSR?

Maybe for rubygems, not so easy for apt/rpm as they use gpg signing/verification of package indices.

RubyGems also have signing facilities. Most authors don't bother signing however because generating a key is too much trouble.