That would depend on what CDN you use and how it works. If the CDN is just a caching CDN in front of your own site then the CDN typically won't be any more secure than your own site.
One can hope. Blob and table storage still have no form of backup ~8 years after introduction.
When I've asked they have been referring to replication and to call them if we accidentally lose data. But we need to contact them within two hours otherwise it's too late. And of course Azure Support never responds that quickly when I submit a case to them.
Actually, I wish Microsoft would stop referring to replication when asked about backup. It's the modern way of saying "You probably don't need backup, because you have RAID". There's a reason Azure SQL Database has self-service point-in-time-recovery despite also having replication.
Do you see many use cases where there is no need for backup to protect against accidental deletion, overwriting, deletion by application vulnerabilities and so on?
As far as I understood the backup docs, I should contact Microsoft Support within 8 hours if any of those things happens. Is that still correct? What if we don't notice the issue until 7 days later?
How do you accomplish no application downtime if for 45 seconds you can't connect to the database?
In background processes you might get away with retrying connections for a minute but most users will probably consider your site broken if page load time is 45 seconds.
When Verizon enabled this they forgot to test with Firefox ESR. So they disabled enough ciphers that Firefox ESR could no longer connect to their servers. We reported it to them and they rolled back and disabled HTTP2 the next day. Guess they finished testing now.
I reported an issue a week ago and they have had developers verifying it beginning of this week. And that was a low impact bug. The previous issue I reported took 4 months to be verified and then another 3 to be patched. So my view at least is that not everyone is handling leaks.
I assume there are several examples of this where there will be a better client for database X than to use this. I rarely use my swiss army knife - if I want to do something serious I use a real saw, screwdriver etc, because while the Swiss army knife may have a lot of features is pretty bad at all of them. I often see examples of Swiss Army Knifes software which integrates poorly with several different systems and good with none.
Simplified: Instead of modifying a deployment by uninstalling the old software, updating the config files and installing a new version, you create a new virtual machine image with all you need and deploy instances of that. Even if you just want to change a setting in a file you deploy new virtual machines. There are variations of this such as using Docker.
It's a security patch in the sense that the only way to get the security patches is to install the new version.
But thanks for the info. That seems like a pretty bad practice when it comes to a lib such as OpenSSL. Having to do changes to the build process to integrate an urgent security fix seems less than optimal.
I can compile the previous versions. I've used the same script for several years, and its not until this version today I have an issue. When seeing the issue, I actually tried compiling the old versions again and those still worked.
It would seem odd if they actually change the build process in a security patch, right? The instructions on how to build OpenSSL on Windows has not been changed in 2 years.
I'm unable to compile this on Win32 (I don't have any problems compiling older versions). I don't understand how the code could compile for anyone, maybe it's a platform specific issue. Take a look here on line 80:
The variable cflags isn't defined. I suspect it should be CFLAGS. I can make it compile locally by changing that, and it would make the code in the function consistent with the other code in the same file.
I thought C defines were case sensitive on all platforms. Anyone knows better than me?