As far as I'm aware there was no technical solution for key revocation when the EU Covid Certificate was first launched in July. The only possibility I saw for revocation was to revoke the whole CA, instead of e.g CRL check.
Can you elaborate what makes you think that key revocation is built into the system?
My understanding was that each node in a certificate tree/list consists of a key pair (public/private), and the entity metadata which needs to be verified. eg. the root CA has a private key that it uses to sign CAs, and those CAs have their own private key that it used to sign individual leaf node certificates.
Meanwhile, revocations are distributed as a separate CRL - certificate revocation list - which contains a list of certificates whose signees are no longer to be trusted. I'm not very clear on how this process works, but in any case I don't think keys can be revoked.
AWS Elasticsearch was one of the last services which didn't support VPC until late 2017 [1], moreover if you had created a cluster without VPC support the migration is very cumbersome and application changes (to enable double writes) are required to execute it without any downtime [2].
Not to mention it's a massive pain to use elastic search with serverless... Especially if you want it in a private VPC. Adding ES raised our monthly bill significantly since it required also adding a NAT gateway (which then double-dips data transfer charges, actual bandwidth out and NAT processed data), the cost was replicated across multiple "States" (Dev/test/prod), and increased cold start times (below they did work to optimize that) since the lambdas accessing ES needed to be in the VPC too.
I can see developers crunched for time (or businesses, money) not taking the additional steps to get there... And this is the same deal for Redis/memcache, which is another reason I think we see those exposed sometimes too.
(To be clear, the additional costs are minor compared to a big business budget, they would be more detrimental to a low (~<400/month) budget project .. or a team that can't dedicate 300-600 man hours to implement this)
HaveIBeenPwned now has feature set to find e-mail addresses which were breached under a domain, there is normally no need to search for separate aliases if you own the e-mail domain.
I have been going through Cisco Netacad materials for last 2 years and I've seen 1.1.1.1 in examples.
Though I just did a search and did not see 1.1.1.1 mentioned anymore.
You do need to register as a business if you are located in EMEA. There is no private/personal option.
This is a huge showstopper for me and, in my opinion, anyone who wants to use it for educational purposes.
I believe it's individual VAT handling. They've solved it for EU citizens but for instance, about Russia, it still says [1]:
"In Russia, Google Cloud Platform services can be used only for business purposes. Warning: If the sole purpose for which you want to use Google Cloud Platform services has no potential economic benefit you should discontinue your use of the service"
It used to say the same thing about EU citizens for a while. The line about "no potential economic benefit" is pretty bizarre as far as far as I've seen...
>Warning: If the sole purpose for which you want to use Google Cloud Platform services has no potential economic benefit you should discontinue your use of the service"
To me this says: "Anything and everything can become a side project at any moment or be used to help support a business and therefore (in my opinion) everything can be thought of as a business or supporting a business. If there is no potential conceivable way to view anything you might ever do on the platform as conceivably pivoting into a startup or supporting a startup or any other business need in the future, or creating any economic (business) benefit then you should discontinue it. Everyone else can just say they might be a side project / pivot or be used as a business in the future, or used to support a business or otherwise produce value, since there is no way to show otherwise."
With this lens it makes perfect sense that if the SOLE purpose has NO potential (potential!!!) economic benefit (i.e. used to at least support a business or create value) then you should discontinue it. This warning applies basically to no one.
It's really an excellent sentence, I like it a lot.
I am currently running an Nginx server which is using PAM service, which in turn is configured to authenticate against LDAP via pam_sss. I don't really see the use case having Nginx authenticating directly to LDAP.
Can you elaborate what makes you think that key revocation is built into the system?