#spring4shell — Public Fediverse posts

JUnit 6 broke 50 repos. I’m delighted.

If a dependency bump can shatter your stack, you don't need fewer updates. You need better tests.

I maintain 50+ OSS repos as one human. I don't babysit them. I automated everything, including updates and minor releases. Many repos haven't been touched in 6 years. AS now JUnit 6 rolled in, a chunk failed. Perfect.

Why perfect? Because failure is a signal, not a disaster. Good tests mean breakage never escapes. I've had repos fail on a Java date parser change. Beautiful. I saw it before release, fixed it, moved on. During Log4Shell and Spring4Shell I didn't panic. I just waited for the next update. That's what behaviour tests are for. And no, they are not slow. If your tests crawl, your design does too.

I trust code I write. I do not trust magic. I remove convenience glue that silently rots:

I don't need MultiValueMap when Map<List> is clearer.
I don't need StringUtils.isEmpty when a simple null or empty check is obvious.
I don't need annotations that smuggle in half a framework.

Every extra library is a future liability: CVEs, Licences, Security, Data Privacy, Performance, breaking changes, mental overhead. Use them to start, then delete them to last. Fewer moving parts mean fewer ways to die.

After 6 years my micro systems still boot in micro seconds, still read clean, still behave. CI pipelines aged, sure, but the code stayed boring. Boring is freedom. Quiet, peaceful, done.

If your stack cannot auto-update without heart palpitations, the problem isn't updates. It's architecture.

Principles I ship by

Automate updates and everything else I can. Let tests be the gate, not fear.
Push behaviour tests to the edges. If it's slow, refactor until it isn't.
Prefer primitives and standard libs. Delete decorative wrappers.
Design for micro systems, not micro monoliths. Start fast, stay fast.
Fewer tools, fewer surprises, fewer nights on fire.

Congratulations. The system failed safely. After fix, you may proceed to do literally anything else with your life.

#java #junit #testing #oss #automation #developerexperience #simplicity #minimalism #microservices #security #log4shell #spring4shell #cleanarchitecture

@gossithedog same for me and #Spring4Shell or #SpringShell. My team did a bunch of work (including teaching devs how to do dependency checks 🙄​) and all I did was send emails twice a day after a 15 minute meeting!

#Log4Shell and #Spring4Shell explained

https://www.ibexa.co/blog/log4shell-and-spring4shell

The #Spring4Shell vulnerabilities in the Java Spring Framework put numerous products at risk, which are also already under attack.

https://borncity.com/win/2022/04/09/spring4shell-sicherheitslcken-in-java-spring-framework/

Die #Spring4Shell Schwachstellen im Java Spring Framework gefährden zahlreiche Produkte, die auch bereits angegriffen werden.

https://www.borncity.com/blog/2022/04/09/spring4shell-sicherheitslcken-in-java-spring-framework/

VMware patcht #Spring4Shell Schwachstelle CVE-2022-22965 teilweise - Exploit wird bereits ausgenutzt

https://www.borncity.com/blog/2022/04/06/vmware-reagiert-auf-die-spring4shell-rce-schwachstelle-cve-2022-22965/

Innerhalb eines helben Arbeitstages 46 Mails zu #Spring4Shell im Ticketsystem aufgetaucht

Explaining Spring4Shell: The Internet security disaster that wasn’t - Enlarge (credit: Getty Images)

Hype and hyperbole were on full... - https://arstechnica.com/?p=1845362 #vulnerabilities #spring4shell #springshell #exploits #biz&it

This Week in Security: More State-Sponsored Activity, Spring4Shell - [Editor’s note: There is a second, fake iteration of this column out today. This i... - https://hackaday.com/2022/04/01/this-week-in-security-more-state-sponsored-activity-spring4shell/ #thisweekinsecurity #hackadaycolumns #securityhacks #spring4shell #briankrebs #cisco #news