Security (defense-in-depth) concern about stack-traces

It's generally a bad practice to return stack traces on catastrophic failures - to the client - as evidenced in https://github.com/apache/tooling-releases-client/issues/33

Generally speaking best practice is to never reveal any detail to the client, otherwise attacker might use stack traces to figure out new attack vectors.

A good practice is to only store stack traces in server logs - not accessible by the client - and to pass a y unique correlation ID in the error message:

Unexpected error happened: 12310hoedauew4444

And also store that correlation id in the same log in the server, so that the support team can find the log when reported by the user.

While ATR is now in tests - this is one of the classic issues reported (rightfully) by security reporters, so it might be worth to implement it now - especially that the announcements about ATR - including the URLs to our test instance have been posted today in the Alpha-Omega blog posts https://alpha-omega.dev/blog/case-study-from-friction-to-flow-how-investment-in-apache-software-foundation-asf-tooling-is-lowering-barriers-for-open-source-maintainers/

Alpha-Imega is a very much security-drawing-attention thing, so we can expect security scans and reporters hammering ATR after such announcements.