On Thu, Mar 26, 2020 at 5:26 AM Jordan Petridis via desktop-devel-list < desktop-devel-list@gnome.org> wrote:
> On Sunday, March 22, 2020 12:56 AM, Michael Catanzaro < > mcatanz...@gnome.org> wrote: > > > On Sat, Mar 21, 2020 at 1:21 pm, Christian Hergert > > christ...@hergert.me wrote: > > > > > > Those words sound incompatible to me in the same way that if you have > > > access to Linux's perf, you can sniff pretty much any data you want on > > > the system. > > > > > We're talking about CI runners... we only need privileged access inside > > the container running our CI, not outside it. Yes? > > It doesn't take much effort to get access outside a privilledged contianer > sadly. But maybe we can have a shared 'privilledged' runner that's setup in > a VM and gets wiped daily or such for the jobs outside the GNOME group that > need it, such as forked repos. > Hi, Has anyone thought any more about allowing CAP_SYS_PTRACE for unprivileged runners or somehow setting up a disposable privileged runner? This has continued to be a large inconvenience for me during the last three months. Almost all contributions to GJS are from people without a GNOME developer account, and so happen on forks, or even from people with a developer account who prefer to use a fork (like myself until this change happened.) This means as the maintainer I cannot use the GitLab website to merge these contributions. I have to check out the branch on my machine, compile it myself with sanitizers enabled since GitLab won't do it, and then merge it myself and push it back up to the repo. Many times I also have to field confused questions from these contributors. It seems like not a lot of work, but it's getting old very fast. Is GJS really the only project that tests merge requests using ASan and LSan? If not, please speak up so we can have a better idea of how many projects are affected. (And if so, you should really consider it, it's a very low-friction way to detect memory leaks, trivial to set up with Meson, faster than Valgrind, and fewer false positives than Valgrind! On the downside, it sometimes pinpoints the source of the memory leak less accurately than Valgrind.) Cheers, -- Philip C
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
