Evgeny Vereshchagin

Results 849 comments of Evgeny Vereshchagin

Looking at ``` headers: { accept: 'application/vnd.github.v3+json', 'user-agent': 'CodeQL-Action/1.0.2 octokit-core.js/3.1.2 Node.js/12.13.1 (linux; x64)', authorization: 'token [REDACTED]', 'content-type': 'application/json; charset=utf-8' }, ``` I think either `codeql` replaces tokens with `[REDACTED]` itself...

> For this reason I believe the CodeQL Action itself is never actually logging write tokens As long as the CodeQL Action uses the library it's probably safe to say...

> We're currently on clang-14. @jonathanmetzman as far as I can see https://github.com/llvm/llvm-project/commit/bc56097817bec3446edd9f06e2d78eab95033027 hasn't been included in the base-builder image yet so it seems clang is pinned somewhere between clang-13...

That commit is older than https://github.com/llvm/llvm-project/commit/bc56097817bec3446edd9f06e2d78eab95033027. The problem is that distributions ship clang-14 with both those commits included and there it's kind of safe to assume that `-fno-semantic-interposition` doesn't work...

With this patch applied I managed to run the fuzzers built with clang/rustc along with the C fuzzers: https://github.com/systemd/systemd/actions/runs/861509391. I decided not to create a new GHAction and just merged...

I somehow thought I had already replied here. Sorry! The idea of the "user_env_var" variable sounds good to me but I'm not sure it should be allowed to pass random...

I'm not sure if it was rolled out or not but judging by https://oss-fuzz-build-logs.storage.googleapis.com/log-640610d8-c435-4843-9585-7605ae64bb9c.txt `systemd` appears to have failed to build on aarch64 with ```sh Starting Step #43 - "compile-libfuzzer-address-aarch64"...

@jonathanmetzman thanks! I didn't know `aarch64` was turned on there. Generally `systemd` along with its fuzz targets is built regularly on all sorts of architectures by the CI so it...

@jonathanmetzman thanks! I think the commit message should point to https://github.com/google/clusterfuzzlite/issues/77 instead of https://github.com/google/oss-fuzz/pull/77. FWIW Not that it matters but I think it would be better if CIFUZZ wasn't set...

systemd has started using both CIFuzz and CFLite so issues like that are no longer theoretical :-)