For example, debug/pe ImportedLibraries(), which is supposed to return all the libraries that a module imports, was stubbed out to return "nil, nil" in a minor release [1]
I just looked at the Git history and this is plain false. It already looked that way when the big source tree move (src/pkg/ -> src/) was done in 2014. Tracing it back further (to before Go 1.0 times, when there wasn't even a builtin error interface yet and the function returned os.Error), ImportedLibraries was *never* implemented in debug/pe.
No longer true. Podman nowadays ships with an optional daemon that serves a Docker-compatible interface, so you can use docker-compose directly if that's what you want.
This was never an intended feature. If I understand the article correctly, they were using an undocumented ("private") API which happened to stop working.
I don't like it either but it's not as bad as it sounds: the ban almost certainly isn't enforced mindlessly and with no recourse for the affected.
I'm pretty sure that if someone from the University of Minnesota would like to contribute something of value to the Linux kernel, dropping a mail to GregKH will result in that being possible.
Getting a hold of someone's secrets is not possible just by doing a pull request. It's really only about resource usage, at least when the runners in question provide sufficient isolation (true at least for the Github-hosted ones, or we're all in big trouble).
Unfortunately, using self-hosted runners to provide additional capabilities not supported by Github-hosted ones is basically impossible (for public repos at least) as you can't restrict a runner to an organization or project. Set up a bare-metal runner and it will receive jobs from random forks.
Seems reasonable to me: this way, you don't have to duplicate the BOM stripping in the decoders of every single format you want to support.
It's also more general as there are other commonly-needed transformations that have an even weaker case for explicit support in the CSV library (charset conversion, dropping other bogus bytes, ...).
No. QUIC is a transport protocol. Its purpose is roughly equivalent to TCP: provide a reliable byte stream transport over an unreliable datagram service (IP, though QUIC prepends a small UDP header mostly for compatibility with existing infrastructure).
You might be thinking of the HTTP server push functionality. That was introduced with HTTP/2 and has been deployed for years already over TCP transports (i.e. totally unrelated to QUIC).
Due to how advertising networks work, I'd be surprised if anyone used server push in the way you fear.
Not libc. The stack probe was inserted by the compiler when compiling the vDSO (part of the kernel, but mapped into user processes) with certain ricer^Whardening flags enabled.
People sometimes use it for type conversions but that's in line with usage elsewhere, no?