Dom Delnano

There was a recent report of this in the Pixie slack. For this problematic case, the Go application in question was built with the following configuration: ``` ELF 64-bit LSB...

This upgrade requires using Go 1.22 ``` (dependabot/go_modules/github.com/opencontainers/runc-1.2.0) $ bazel cquery --keep_going --noshow_progress --config=clang --notool_deps '//... except(kind(test, //...)) except(kind(container_image, //...)) except attr('\''tags'\'', '\''manual|disabled_flaky_test'\'', //...) except //third_party/... except attr('\''tags'\'', '\''requires_bpf'\'', //...)'...

After updating the `go_sdk`, it seems there is still a dependency cycle: dependency cyle logs ``` ddelnano@dev-vm:~/code/pixie (dependabot/go_modules/github.com/opencontainers/runc-1.2.0) $ bazel cquery --keep_going --noshow_progress --config=clang --notool_deps '//... except(kind(test, //...)) except(kind(container_image, //...))...

> There may be one or more tests that never ran, so the list of test failures is not reliable. Re-running the ones that failed up to that point makes...

This is blocked on removing go 1.23 from our build. I'm planning to cover this as part of the bazel 7 upgrade changes (#2282 ).

Hi @lucascicco, thanks for starting this discussion. You're right that Pixie's golang services have a hard coded log level. The C++ embedded within the query broker, kelvin and PEM Vizier...

@pixie-io/third-party-reviewers this is ready for review. I'll make sure to test all of the oauth flows in the next cloud release. I am planning a hydra and kratos upgrade, so...

Hey @gzwxh, thanks for the bug report. There seems to be a situation where the database migrations run on service start up don't run cleanly. I've seen reports of this...

The first batch of the upgrade was started in #2242. We will need to get to a more recent version than that, but it resolves the security vulnerabilities for now.

While I lost the logs, the `proc_exit` source connector also has the same unaligned memory access.