prashantrajan

Financial apps like Coinbase, Venmo, and Cash App require weak 4-digit PINs alongside biometric authentication, creating significant security risks. If Face ID or Touch ID fails, these apps fall back to the weak PIN instead of your username and password. Meanwhile, apps like Fidelity and Schwab get it right by avoiding these pitfalls.

Previous thread: https://news.ycombinator.com/item?id=29644630

It's infuriating that they pushed out this breaking change late on a Friday, screwing over their customers and all our enterprise account managers are now conveniently out on their holiday break.

5 days later and they are still "investigating" instead of rolling back the change.

Lesson: Don't use Amazon Linux. Pick an OS with mature stewardship like Ubuntu/Debian/RedHat

AWS decided it was a good idea to push out a "security" patch late on a Friday (Dec 17) without advance warning that monkey patched running customer owned Java code.

The patch is auto applied on Amazon Linux AMIs at boot time since it's marked as a critical update causing Java web apps to fail. This caused all our auto scaling processes to fail. Note that the code is injected even in customer re-bundled AMIs of Amazon Linux because it attaches itself as a hard dependency of the JDK and gets applied as a JDK upgrade if you opted into "critical" OS security updates.

In their recklessness to rush out this change thinking they know all the ways Java apps have been built over the last 30 years they've likely caused users to now opt out of their automatic security updates (https://aws.amazon.com/amazon-linux-ami/faqs/#:~:text=Q%3A%2...).

Their first and only announcement of this kind was done via https://alas.aws.amazon.com/announcements/2021-001.html (no email or anything) and fails to mention the critical fact that it gets applied to previously baked AMIs.

AWS has long left the customer to manage their own environment within AWS and this approach to security patching in a non standard way (monkey patching user written code) is a betrayal of that trust and policy.

Thanks for pointing that out. Oversight on my part. Originally I thought that permission was required to be able to add a future star/unstar functionality from GitStars but turns out that is not required.

Just released a simple web tool, GitStars (http://www.gitstars.com) to help make the act of starring repositories on GitHub infinitely more useful.

When you log into GitStars, your starred GitHub repositories are fetched and automatically tagged. You can freely edit the tags and help make the system's auto tagging better for everyone.

In this early version, we were focused on helping you re-discover the repositories that you may have starred and lost track of. You can browse or search the repositories by the tags that were automatically generated.

I would love to hear your comment on whether you find GitStars useful.