HN user

znep

222 karma
Posts1
Comments71
View on HN

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.

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.

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.

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.

That is concerning and directly contradicts the docs:

"You can revert to your previous master password only if the change had taken place within the last 30 days."

I guess it is possible it is another UX issue and would fail if you tried, but that still isn't very reassuring.

Interesting example given you can no longer do that with the latest (v2) version of the AWS CLI, since it isn't published to PyPI due to how big of a nightmare AWS found supporting that to be.

There is a very nice comment talking through some of the reasoning here that is worth a read: https://github.com/aws/aws-cli/issues/4947#issuecomment-5860...

I am quite annoyed v2 isn't in PyPI as it makes updating to v2 a sizable project in some cases and v1 does not support all services, but also quite understand their reasoning.

Granted the tradeoffs may be weigh out differently for an internal tool as the post describes, or if distributing the tool to a more constrained audience.

That isn't due to a missing timeout, that is due to not properly communicating aborted requests down the stack which, admittedly, isn't always easy and some clients/languages/etc. are very bad at. A hardcoded timeout, while a fine workaround in some applications, is not a good default and not the proper fix for that.

Default timeouts in the database layers are hidden time bombs that turn operations that just legitimately take a bit longer than some value the library author set that you didn't even know existed into failures that get retried over and over causing even more load than just doing the thing once. Don't get me wrong there are lots of uses for setting strict timeouts and being able to do so is very important, but as a default no thanks.

I might be wrong, it was a long time ago, but IIRC a different DNS rebinding attack was actually part of the reason this behavior was introduced to the URL class, to help protect against such attacks in Java Applets.

TL;DR - "Here is a lot of boilerplate code that doesn't seem necessary for what you are doing in this case..."

...

"Hey look another tool that can generate a lot of boilerplate code you then have to deal with and makes the easy stuff easier and the hard stuff almost impossible!"