ChanServ changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
gtristan has quit [Remote host closed the connection]
gtristan has joined #freedesktop
gtristan has quit [Remote host closed the connection]
gtristan has joined #freedesktop
gtristan has quit [Remote host closed the connection]
gtristan has joined #freedesktop
gtristan has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
agd5f_ has joined #freedesktop
gtristan has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
ximion has quit []
agd5f_ has quit [Remote host closed the connection]
agd5f_ has joined #freedesktop
gtristan has quit [Remote host closed the connection]
gtristan has joined #freedesktop
gtristan has quit [Remote host closed the connection]
gtristan has joined #freedesktop
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
Leopold__ has quit [Remote host closed the connection]
Leopold has joined #freedesktop
Haaninjo has joined #freedesktop
ppascher has joined #freedesktop
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
gtristan has quit [Ping timeout: 480 seconds]
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
hir0pro has joined #freedesktop
gtristan has joined #freedesktop
hir0pro has quit [Ping timeout: 480 seconds]
hir0pro has joined #freedesktop
MajorBiscuit has joined #freedesktop
<bentiss>
sigh, it was supposed to be a day off for me, but I realized a new kind of spam: people are creating 1 or 2 project and then immediately create tons of issues in those projects
<bentiss>
one had 12000 issues in less than a few hours
<bentiss>
so... I am thinking at changing the policy: all new users will be external: they can only create issues on existing projects. This way spammers will be detected by everybody and can be nuked more easily
<bentiss>
then we add a new signup banner, telling people to create an issue in one dedicated freedesktop project, which will be monitored by a bot and everytime someone creates an issue there, the account will be marked as internal and the user will be able to create projects/forks/snippets
<bentiss>
of course, we should be able to have a regex for bypassing external users for well known companies in opensource (amd, nvidia, red hat, collabora, igalia, debian.org, kernel.org, etc...)
<bentiss>
daniels, mupuf, emersion: any thoughts on the above? ^^
<mupuf>
bentiss: that sounds like an acceptable solution for me
<bentiss>
the bonus point is that there will be no more delay in accepting new accounts
<mupuf>
bentiss: do you have stats as to how many accounts were rejected by the bot?
<mupuf>
because I may prefer keeping both
<bentiss>
mupuf: not really. but looking at the recent stats of new users, we were having a steady ~600 new users per month, and in Jan 1400, and in feb 1700
<mupuf>
yeah, sounds very fishy
<bentiss>
mupuf: now gitlab can enforce the email verification by itself that I am doing manually
<mupuf>
even 600 per month sound fishy
<mupuf>
oh, then yeah, let's use the upstream solution then
<bentiss>
so basically the admin verification just adds delay (which is valid to kill some spam bots)
<mupuf>
yeah... I wonder if gitlab could ratelimit users
<bentiss>
and honestly, having a spam account that just have a link to a website is almost better than having a spam that creates a repo and 12000 issues in that same repo
<mupuf>
let me check
<mupuf>
the default rate limiting is 300 comments per minute
<bentiss>
side note registry-mirror.freedesktop.org has been dead for the past 2 weeks and nobody complained, so I think we can just delete it :)
<bentiss>
we should lower that nb of comments per minute
<bentiss>
sure
<bentiss>
something like 2 would be ok :)
<mupuf>
I would set 5
<bentiss>
fair enough
<mupuf>
that's like 12 seconds to write an issue
<mupuf>
As for how many comments per minutes, I would say 10?
<mupuf>
Still muuuuuuch better than 300
<bentiss>
+1 :)
<alatiera>
bentiss fyi, the spam wave has hit all the public gitlab instances so you could ask around what the kde and gnome sysadmins are doing
<bentiss>
alatiera: good to know :)
<mupuf>
bentiss: Rate limits applied
<bentiss>
mupuf: thanks
<bentiss>
mupuf: over the past 7 days: 446 rejected accounts that were not validated
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alatiera>
I think in gnome we've clsoed registrations for now completely
<emersion>
:/
<mupuf>
bentiss: so, these accounts managed to go through the gitlab creation process including email verification?
<emersion>
i find it important that users can contribute without jumping through hooks
<mupuf>
and yet they failed at our custom verification?
<bentiss>
mupuf: they can bypass it by using google authentication
<bentiss>
emersion: with "external" they can contribute by opening issues
<mupuf>
emersion: agreed, but this is what `external` means: they can create issues and comment on them. Just can't create new projects
<emersion>
can they fork?
<bentiss>
it's just creating a repo/snippet which is prevented
<bentiss>
emersion: no
<emersion>
that's not great
<emersion>
people can contribute to the kernel by sending an email
<bentiss>
fighting spam email is a known process
<emersion>
and then for mesa they need to wait multiple days, fill captchas, contact admins, etc
<bentiss>
the nice point with that is that they will be able to ask why they can not create project
<bentiss>
emersion: I agree, but this spam is definitely not good for freedesktop: disk wasted, bad reputation from search engines, etc...
<emersion>
i think these are less important than having contributors
<bentiss>
emersion: and with external, now users will have to validate their email (or use google/github/etc...), and they can immediately open an issue
<bentiss>
emersion: when you can not send emails because of such bad reputation, this gets a problem for everyone
<emersion>
the whole point of migrating to gitlab was to lower the barrier to entry when submitting patches
<emersion>
but the barrier is actually much higher now
<bentiss>
emersion: this statement is wrong: if people log in currently with gmail/github/twitter, there is no remediuaation and then they can do whatever they want
<emersion>
ah yes, if they want to use their $bigcorp account, everything is fine
<bentiss>
the problem I was fighting was for manual registration which allowed you to create an account without a valid email address
agd5f_ has quit [Ping timeout: 480 seconds]
<emersion>
do i need to tell people to register an elon musk account to contribute to mesa now?
<bentiss>
but I agree that now, I want to also prevent those $bicorp users to spam us, and for that I think marking new accounts as external is a sensible way to do it
<mupuf>
emersion: I understand the frustration, and I think everyone here shares it to different degrees. Do you have other ideas that could address this spam issue?
<bentiss>
emersion: and as much as I agree lowering the barrier is nice, I think gitlab can not be reduced to that and the beenfits we are seeing now are definitely bigger than allowing new users to easily contribute
<emersion>
i'm trying to think about other ways
<bentiss>
the spam problem is also an issue to our sponsors: the IP they own is going to be tagged as a spam center, and this is bad reputation for them too
* mupuf
would rather not have people decide to move away from gl.fd.o because of spam just keep the barrier of entry to newcomers untainably low
<bentiss>
anyway, I'll let you think a little bit more. bbl
<emersion>
moving away from fdo is definitely something i'm considering :/
<mupuf>
sad to hear... may I ask why?
<emersion>
gitlab being slow, captchas, policy to not host some projects, and now this
<emersion>
oh well
<mupuf>
I think the hosting policy is in need of an update
<pq>
emersion, why would that help you specifically? Are small enough servers somehow not spam targets? Would they not become spam targets if you keep equally low barrier to entry? Saved by obscurity maybe?
<emersion>
anyways, it's unlikely i have time to invest into helping with this, so maybe take my opinion with a grain of salt, as if i were a mere user of the service and nothing more
<mupuf>
As for the current issue, I think we can find an acceptable way
<emersion>
pq, we don't have this kind of issue with sourcehut
<emersion>
we do have spam, but some daily banning is enough
<pq>
emersion, why is that?
<pq>
not famous enough site, or?
<mupuf>
emersion: Would it be OK if users were to receive an email after subscribing explaining what are theor current access rights, then provide a link to apply for more right. The link would pre-fill an issue on the right project, and people would just need to press "Save".
<emersion>
pq, maybe more bots targeted specifically at spamming gitlab instances
<mupuf>
As far as joining a community, it certainly would be muuuuch easier than what we had before where users had to submit their ssh/gpg keys, and send emails to a mailing list to get access
<mupuf>
yeah, for sure.
<emersion>
pq, we do have bots targeting sourcehut specifically, but maybe less
<emersion>
(in terms of size only, sourcehut is bigger than fdo fwiw)
<pq>
oh, what do you count in size?
<mupuf>
emersion: you mean, in terms of hosted projects and amount of users? Wow!
<emersion>
mupuf, yeah, i think good documentation can help a lot
<emersion>
pq, more users, more projects
<emersion>
(even when counting all of fdo spam accounts)
<mupuf>
hats off to you guys :)
<emersion>
thanks!
* mupuf
will mark one of his gitlab users as external to see how it would look
<emersion>
hm i wonder if bots are clever enough to click around links and submit forms
<mupuf>
there is a way to add text when creating new projects. I wonder how this will work
<emersion>
you mean add a banner?
<emersion>
is it displayed when forking too?
<emersion>
i'm mostly worried about this workflow fwiw:
<emersion>
- user creates account
<mupuf>
that's what I would like to check, indeed :)
<emersion>
- user clicks confirmation email
<emersion>
- user clciks "fork" button
<mupuf>
as for the banner, I would rather use that as a last resort
<emersion>
ah, okay, text and not banner. still sounds good
<mupuf>
External users cannot click the "fork" button (tooltip is "You have reached your project limits"), and they do not see the "New project" button either
<mupuf>
let's have a look at the banners now: Can we conditionally have banners?
<emersion>
it may be possible to send a notification to a single user
<emersion>
(so the bot could do this)
<emersion>
there is also "Target roles" for broadcast messages
<emersion>
ehh, "Target roles" doesn't show up
<emersion>
> Target roles introduced in GitLab 14.8 with a flag named role_targeted_broadcast_messages. Disabled by default.
<mupuf>
yeah, the target role may have worked.. but gone it is
<mupuf>
oh, not gone, but not enabled
<mupuf>
but is "role" here external/internal?
<emersion>
hm, i don't think it would work even if enabled
<mupuf>
I guess we could look for "Guest" users on paths /*
<mupuf>
but yeah, still doesn't sound good
<mupuf>
I guess the best gitlab has to offer is a dismissable banner
<mupuf>
new users will have it at the top, while returning users would likely just dismiss it and forget the message even existed
<mupuf>
it's just annoying that we'll show it to existing users...
<mupuf>
OK, so my suggestion would be to have a bot that sends an email to new users telling them about their current access rights, and how to get more (just create an issue somewhere). Additionally, we should add a banner for all users that says something like: "To fight off spam, new users are limited to filing issues and commenting on existing projects. See our [newcomer guide](...) to apply for full access".
<mupuf>
^ the banner should be dismissable
<emersion>
yeah
<mupuf>
and this is knowledge every user should have, so noone should complain about seeing this message
<emersion>
+1
<mupuf>
and the new contributor guide is anyway good to have to document our code of conducts, the do's and don't...
<emersion>
where is the existing bot source code btw?
<mupuf>
bentiss, daniels: thoughts on my last 4 messages?
<mupuf>
I don't know
hir0pro has joined #freedesktop
thaller has joined #freedesktop
gtristan has quit [Ping timeout: 480 seconds]
Guest5484 has quit [Ping timeout: 480 seconds]
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ximion has joined #freedesktop
<bentiss>
mupuf: works for me. Though if there is a benner, there is no need for a bot
<emersion>
hm, how so?
<emersion>
we still need a bot to promote users to internal no?
<bentiss>
oh, yeah, but we don't need to send emails to people I mean
<mupuf>
I would also still prefer sending an email, on top of the banner, since users may miss it. Of course, they may also miss that, but at this point, we can't do toooooo much :D
<mupuf>
as in, 2 means of communicating the links to the newcomer guide
<bentiss>
mupuf: there are 2 messages we could use: "After sign-up text" and "Sign-in text"
<bentiss>
FTR, I'm supposed to be off today, so I won't work on the bot now. I can disable the current one that adds the delay, but not develop a new one
<mupuf>
Of course you shouldn't work on that now!
<bentiss>
Heh "Make new users' profiles private by default" :)
<mupuf>
"Admin Mode" sounds great! Any reason why it is not enabled?
<mupuf>
yeah, there are plenty of places where we can link to the newcomer guide
<mupuf>
so... I guess it is time to start writing it
<bentiss>
mupuf: nobody enabled it when it was introduced
<mupuf>
I guess we can have an informal vote on that after we address this issue
<bentiss>
so: pending approval removed, new users are external by default now
<bentiss>
for this week end, if new users want to create a repository, they'll have to contact an admin through gitlab
<bentiss>
actually, now that pending_users is empty, the bot will not do anything for new accounts, just delete spams
ximion has quit []
* bentiss
just realized that this move will also fight all script kiddies trying to use our runners for building android or crypto mining
hir0pro has joined #freedesktop
<mupuf>
bentiss: where would you like users to request access?
<__tim>
I wonder if there are ways to restrict use of the API (if that's a problem, I don't know if it is), like "shouldnt' be able to create issues/MRs/comments via the API)
<mupuf>
freedesktop/freedesktop?
<bentiss>
mupuf: ideally a new project under freedesktop so we don't get spammed by this
<bentiss>
mupuf: freedesktop/newcomers? and we can also host the code for the newcomers wiki/pages?
<mupuf>
Need to update the signup text too, to remove the part about the validation email
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hir0pro has joined #freedesktop
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
miracolix has joined #freedesktop
hir0pro has joined #freedesktop
hir0pro has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
hir0pro has joined #freedesktop
jarthur has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
ximion has joined #freedesktop
miracolix has quit [Read error: Connection reset by peer]
<alanc>
today's spammer seems to be trying to claim control of the site in google's tools by submitting MR's to a bunch of projects to add his key for google-site-verification
miracolix has joined #freedesktop
miracolix has quit [Read error: Connection reset by peer]
miracolix has joined #freedesktop
miracolix has quit [Read error: Connection reset by peer]
<alanc>
I guess I should say the first spammer I spotted today, since there seems to be a network of connected accounts there
miracolix has joined #freedesktop
miracolix has quit [Read error: Connection reset by peer]
<alanc>
I knew the spam had gotten bad lately, but I hadn't realized how bad
miracolix has quit []
agd5f_ has quit [Ping timeout: 480 seconds]
miracolix has joined #freedesktop
miracolix has quit []
miracolix has joined #freedesktop
<mupuf>
Yeah, it came pretty fast
<alanc>
Just need to ban any bugs containing "720p", "1080p", or "HD" - not that any of the legitimate projects want to see bugs mentioning those things
miracolix has quit []
<alanc>
and automatic instant account ban for any gitlab posting containing the phrase "Fast X"
<pixelcluster>
wonder if "movie", "free" and "download" (in one bugreport) might be better keywords
<pixelcluster>
for graphics-related things like mesa drivers I can see people mentioning their resolution as 720p or things like that
<alanc>
movie or sports it seems - lots of posts for sports live streams too
<alanc>
there was a bit of sarcasm in suggesting the resolutions, knowing that Xorg, mesa, & gstreamer bugs could legitimately mention them, but there was also a kernel of seriousness, since a lot of this spam is in a wide range of languages, but the resolutions are listed the same in all of them
<daniels>
as a massive fan of the F&F series, I'll have to watch myself on GitLab
<daniels>
but yeah, we can't ban 720p or 1080p or 4K or HD or movie or anything really, because GStreamer exists
<daniels>
bentiss, mupuf: I like your solution, I think that's the best solution for now
<daniels>
I mean we were already starting to get various nastygrams from Google, and DMCAs from other automated services
miracolix has joined #freedesktop
<mupuf>
daniels: great! Can you review my changes to the freedesktop/freedesktop wiki?
<mupuf>
Then add a banner linking to it to inform our users?
<mupuf>
Then we need to brace ourselves for tons of requests for accounts
<bentiss>
daniels: the nice thing also with marking new accounts as external is that we can just remove them and they will just come back as external, so without possibility to create accounts
<bentiss>
well, hopefully they won't be able to do more harm :)
<daniels>
alanc: nuked all the accounts you reported, thanks!
<daniels>
bentiss: heh, yeah
<alanc>
you're welcome
<bentiss>
alanc: yeah thanks
<bentiss>
I was planning on writing a script to gather all of those, but maybe we can do a mnual pass after all
<bentiss>
at noon, we were having 150 external accounts. Now it's 300 :(
<daniels>
heh, I flipped the targeted-announcements FF on, and it doesn't help us
<bentiss>
FWIW, the following in the gitlab-rails console seems to be able to find quite some spam:
<bentiss>
User.active.where('id NOT IN (select distinct(author_id) from merge_requests)').where("created_at >= ?", 60.days.ago).each() { |user| if (user.projects.length == 1) then project = user.projects[0]; if (project.repository.commit_c
<bentiss>
ount == 1 and project.users.count <= 1 and project.fork_source == nil and project.issues.count >= 1 ) then p project.issues.each() { | issue| p issue.title } ; p user end end }
<bentiss>
alanc: yeah, they click on both add readme and enable SAST checking
<alanc>
so increasing the commit count in your above query might catch some more
<bentiss>
well, I'm already trying to delete the last one from this query, and it's taking forever
<bentiss>
I have a feeling we just DoS-ed the background jobs by nuking that many users :)
<alanc>
I did notice spam disappearing on reloads
Leopold has quit [Ping timeout: 480 seconds]
<bentiss>
alright, done with my query above, killed a few accounts. Now to check with 2 commits :)
<bentiss>
18 more to nuke :)
Leopold_ has joined #freedesktop
Leopold_ has quit [Remote host closed the connection]
<bentiss>
it's a very recent trend: I ran the query above with projects with less or equal than 2 commits, and I nuke quite a few in the past 60 days, but in the past 90 days, I only have 4 new hits
Leopold_ has joined #freedesktop
miracolix has quit [Remote host closed the connection]
<bentiss>
FWIW, I think I pruned all users in the past 90 days with less than 5 projects with at least one with spam (when doing the full query I had to manually select the targets, I did no blindly shoot down users)
<bentiss>
daniels: not sure if it was intended or not, but the banner you set up is not displayed
<bentiss>
heh, looking at the user admin panel, I wonder if we could not also mark as internal users with 2FA setup
<bentiss>
anyway, going to bed now. see you all later