Michael Catanzaro commented: > I find it hard to believe you don't know security implications of granting > `SYS_PTRACE` to CI which runs completely arbitrary loads, not to mention > runners no longer run with `--privileged` after it was reported it breaks > glib test suite as well. Honestly, I don't tbh. I know that in Fedora, ptrace of your *own* processes works by default, whereas ptrace of *other users'* processes requires sudo (for CAP_SYS_PTRACE). asan only wants to ptrace its *own* processes, which seems like it should be safe to do without any special capabilities, but doesn't work on our CI (I assume because it uses docker)? I don't know why docker blocks it, though. Are there special considerations inside containers? I do know this used to work fine until a couple months ago. > We likely can provide a burner VM with odd CAPs applied but I wish your > request wasn't written in such a disheartening way in the first place. So my plan is to propose a GNOME initiative to add asan CI to every core module that uses C or C++, since asan is important to be confident in the security of our code. That's hard to propose when it means no more CI for external contributors, though. Honestly, I don't understand your concern with the tone of my issue report, but I didn't intend it to be mean. I think everyone really appreciates your work. :) -- Reply to this email directly or view it on GitLab: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/370#note_865754 You're receiving this email because of your account on gitlab.gnome.org.
_______________________________________________ gnome-infrastructure mailing list gnome-infrastructure@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-infrastructure
