Arnout Engelen

> By design they usually hold pretty tight to their secrets and don't expose them Oh I thought `-Djavax.net.debug=ssl` also already dumped the key material - but TBH I haven't...

I can confirm [jsslkeylog](https://github.com/jsslkeylog/jsslkeylog) actually works (at least with Pekko gRPC on sbt on Java 21.0.7) - so it would be cool to document that ;)

The NixOS community is currently heavily targeted with invite spam (invite mentioning CSAM but I haven't joined the rooms obv), to the point that we've (temporarily?) made our main chat/support...

> I wonder if we could try ordering the resolvers in sbt. > > I've seen failures where we get issues loading 3rd party jars because our sbt setup seems...

We haven't seen GitHub Actions runners get blocked anymore by the "too many 404's on repository.apache.org" rule since https://github.com/apache/ranger/pull/435 was merged. I now (ack'ed by infra) removed all those bans....

looks like this might be bingbot, filed https://issues.apache.org/jira/browse/INFRA-26405 to get a robots.txt in place

(I didn't keep numbers to tell if the lifting of the '404' blocks helped, but at least they haven't reappeared yet. We're still affected by the other blocks, e.g. https://github.com/apache/pekko-persistence-jdbc/actions/runs/12663831987/job/35291029035...

Does that mean we can close this PR?

> I would prefer not to use this because I think trying to support Akka before v2.6.5 almost certainly will lead to us having to add extra fixes. Sounds reasonable...

This is indeed an unfortunate puzzle. We have public API's that accept `org.apache.pekko.japi.Function` as a parameter. I don't think we should mark `org.apache.pekko.japi.Function` as deprecated when we still have non-deprecated...