12:14 <sima> www.x.org wiki down or an issue on my end?

12:14 <sima> traceroute/ping seems to work

12:14 <sima> oh it works again, sorry for the noise

15:49 <zxrom> Hello! Any libinput experts here?

15:50 <MrCooper> libinput discussion usually happens on #wayland

15:52 <zxrom> My two different old Microsoft IntelliPoint 3 and 4 mice are behaving strangely. More than a year ago, the scroll wheel started working spontaneously. Perhaps the new mouse input processing module has removed protection against this behavior of these mice? I have already disassembled and cleaned everything from dust. It did not help. Who has a similar problem? Anyone have any ideas?

15:53 <zxrom> MrCooper, Thanks.

21:09 <pinchartl> from my limited experience with gitlab CI on fd.o, it seems that gitlab has at least a saner default configuration than github from the point of view of supply chain attacks (https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/). does that also extend to the runners, or can a malicious pipeline start persistent background processes that

21:09 <pinchartl> easily on the runner (assuming, of course, that the malicious pipeline can't escape from the container) ?

21:55 <kode54> pinchartl: from what I've observed, fd.o at least requires being granted permission to even use runners on your forks of existing projects, let alone your own projects to begin with

21:56 <kode54> so you'd have to ask to be granted runners first

21:56 <kode54> not sure how the bare metal runners handle processes persisting, they probably terminate all processes owned by the runner after the timeout if they don't end on their own

21:57 <kode54> but yeah, it's already gated behind proving you're a trustworthy enough user to have CI turned on for your project, I think

22:43 <alanc> though the permissions on gitlab.fd.o were orignally much looser - they were tightened to stop scammers from running crypto miners & such on the runners

23:15 <kode54> oh

23:15 <kode54> well, you have to be careful anyway

23:15 <kode54> heck, Arch's gitlab even requires manual approval to activate new accounts