I wonder who would be best equipped to see if any of those keys are traceable to individuals involved in special government affairs lately? There have been some good leaks...
That doesn't make any sense technically and sounds a lot like victim blaming.
It is far from certain that any application has such a "steady state", most of the ones I've worked on sure don't. There are obviously ways to analyze things and correlate enqueued and dequeues, but it is far from as simple and black and white as you suggest, especially with truly distributed systems and unknown cause of the reported behavior.
Heck, we don't even know if the messages are being "dropped" or just duplicated.
Generally somewhere between terrible and non-existent if you stick with Fire OS. They will drop occasional small patch releases with broken links to non-existent release notes.
Indeed. I am sure there are lots of things under development, I have little knowledge in the area but I ran across this video the other day which suggests refueling and rearming via drone: https://www.youtube.com/watch?v=hNLCa6isqJA
No idea how far between concept and reality that is and obviously this is a whole different class of vehicle than a tank.
Spring4Shell is entirely a flaw in Spring, however is somewhat understandable because it was only exploitable due to a new feature in Java (modules) that added new methods to java.lang.Class, which is a very significant change. You could argue the very existence and nature of Java object serialization deserves blame as well, but that gets nuanced quickly.
Modules are also part of the reason why so many folks got "stuck" on java 8.
It is definitely an interesting study in the challenges of trying to make advances in a platform when a lot of the ecosystem is very much in maintenance mode and may not have a lot of eyes on the combination of existing libraries vs new versions of Java.
Ahh, your comment is the first one that made it clear why this is only in 9 and later, because it was actually "introduced" by the introduction of modules in Java 9. That added https://docs.oracle.com/javase/9/docs/api/java/lang/Class.ht... to java.lang.Class.
It looks like the Spring code, when written, did properly filter out existing unsafe methods in java.lang.Class deliberately. Obviously not in a defensive enough way to avoid this, but adding methods to java.lang.Class is a very rare event.
I'm not sure what they are using right now, but they currently have the "AWS-LC Cryptographic Module" listed as being in process for validation which may be sufficient for s2n.
I know there are other AWS features/services that are lined up behind that validation for FIPS support.
For even more fun, try "SELECT pg_cancel_backend(pid) from pg_stat_activity".
(DON'T ACTUALLY DO THIS on anything other than a personal test db as it will kill all the connections it has permission to kill)
Related, postgres has a number of different volatility options for functions so you can declare if there are side effects: https://www.postgresql.org/docs/14/xfunc-volatility.html These can become very important in some cases to let the optimizer have the freedom to shine.
...and almost every time I end up on a mobile link to a tweet in a web browser I have to refresh the page to get anything but an error. Which has been going on for years, or at least seems like it.
This is very true, the costs and performance impacts can be significant if your architecture isn't designed to account for it. And sometimes even if it is.
In addition, unless you can cleanly survive an AZ going down, which can take a bunch more work in some cases, then being multi-AZ can actually reduce your availability by giving more things to fail.
AZs are a powerful tool but are not a no-brainer for applications at scale that are not designed for them, it is literally spreading your workload across multiple nearby data centers with a bit (or a lot) more tooling and services to help than if you were doing it in your own data centers.
One other thing to note is that by default lastpass allows reverting to your previous password for 30(?) days. The option is in account settings -> advanced -> "Allow master password changes to be reverted".
To be safe you would probably want to disable that then change your password again. Just don't lose your new password as you then can't revert.
Note the classes aren't at fault or doing anything wrong (even though you could imagine other mitigations they could use), they are just conveniently there to use if you have a vulnerability that lets you de-serialize untrusted data.
While the specific exploit may not be possible in 8u191 and later, I am not convinced they are safe from all RCEs using this vulnerability. It does make it harder to exploit, and hit or miss depending on what is available in the classpath.