nscur0

@fribbledom@mastodon.social Just hoping this hypothetical spec language doesn't involve XML or YAML in any shape or form.

Getting really fucking tired of obscenely verbose Claude output being dumped verbatim into GitHub issues. If you can't be arsed to even write a comment yourself, why should I spend time interacting with it?

implementing workload identity federation. how hard can it be? i'm sure the token exchange will be super straightforward because IdPs all provide a small set of uniform claims, and it won't be necessary to use an expression language to deal with them, right?

RE: https://infosec.exchange/@nscur0/117254750212873843 Anyway, the upcoming version of @DependencyTrack@infosec.exchange will support workload identity federation, making long-lived API keys entirely obsolete for deployments where OIDC (e.g. through GitHub Actions) or SPIFFE is available. Long live short-lived credentials! Ergh, I mean...

With Error Prone, NullAway, and Spotless, you can get a JVM project quite far to what you'd have in Go with its fantastic linter and formatter ecosystem. Obviously it'd be better if all that would ship with the JDK, but the tooling is mature and works well, and that's all that counts in the end. Error Prone being a compiler plugin means you pay the linting price on every build though. Most other ecosystems separate compilation from linting, which ofc makes builds faster but also linting entirely optional and easy to forget. Torn on what approach I like better.

@elmuerte@idlethumbs.social Yep, although to my understanding it's necessary for some checks that would otherwise not be possible. It's more of a failure of the JDK for not offering a public API that alternative compilers can implement. Go has a fairly clean API for this (notably separate from the compiler entirely), but tbf Go is also a much simpler language. https://pkg.go.dev/golang.org/x/tools/go/analysis