I've observed that typically only Daffodil committers who already have write access to the daffodil-site repo create pull requests to make changes to the website. We did get a drive-by contribution once from a developer outside the Daffodil community using a bot that offered to fix misspelled words on the website for us (https://github.com/apache/daffodil-site/pull/5). Just saying that we probably could pick the more restrictive categories "Limit to prior contributors" or "Limit to repository collaborators" if the "Limit to existing users" isn't restrictive enough due to miners/bots waiting more than 24 hours.
-----Original Message----- From: Steve Lawrence <slawre...@apache.org> Sent: Wednesday, April 21, 2021 11:25 AM To: dev@daffodil.apache.org Subject: EXT: Re: all this github spam ? Cool, I didn't know about this. That seems like the right solution to deal with this spam temporarily. Seems most of these spam PR's are coming from new accounts, so maybe "Limit to existing users" for "1 week" might be enough to discourage spammers from using our repo? Anyone have thoughts on a different setting? I think INFRA will have to make this change though. It's not something that's configurable in .asf.yml. We can open a bug once there's a consensus on a reasonable restriction. On 4/21/21 11:16 AM, Adam Rosien wrote: > There's a way to limit the incoming activity for various categories of > participants: > https://docs.github.com/en/communities/moderating-comments-and-convers > ations/limiting-interactions-in-your-repository > : > >> Enabling an interaction limit for a repository restricts certain >> users > from commenting, opening issues, creating pull requests, reacting with > emojis, editing existing comments, and editing titles of issues and > pull requests. >> >> When you enable an interaction limit, you can choose a duration for >> the > limit: 24 hours, 3 days, 1 week, 1 month, or 6 months. After the > duration of your limit passes, users can resume normal activity in your > repository. >> >> There are three types of interaction limits. >> >> Limit to existing users: Limits activity for users with accounts that >> are > less than 24 hours old who do not have prior contributions and are not > collaborators. >> Limit to prior contributors: Limits activity for users who have not > previously contributed to the default branch of the repository and are > not collaborators. >> Limit to repository collaborators: Limits activity for users who do >> not > have write access to the repository. > > On Wed, Apr 21, 2021 at 7:14 AM Steve Lawrence <slawre...@apache.org> wrote: > >> Unfortunately, doesn't look like the .asf.yml will help. There isn't >> really anything related to controling pull requests. It does allow >> changing where PR emails go to, so we could send them to /dev/null, >> but then we'd miss legit emails which is probably worse. >> >> On 4/21/21 9:47 AM, Dave Fisher wrote: >>> Infra has setup some controls which may be useful. There is support >>> for >> an .asf.yaml file. >>> >>> See >> https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId= >> 127405038#content/view/127405038 >>> >>> Regards, >>> Dave >>> >>> Sent from my iPhone >>> >>>> On Apr 21, 2021, at 5:59 AM, Beckerle, Mike < >> mbecke...@owlcyberdefense.com> wrote: >>>> >>>> >>>> We seem to be fending off maybe 10 a day github spam attacks where >> people open/close pull requests. >>>> >>>> Is there something systematic we can do to avoid this? >>>> >>>> This pollutes our mailing lists. I know we can manually purge the >>>> PRs >> from github, but these things will live forever in the mail archives, >> adding a bunch of random emails/account names to them, and generally >> making them less useful. >>>> >>>> Mike Beckerle | Principal Engineer >>>> >>>> mbecke...@owlcyberdefense.com >>>> P +1-781-330-0412 >>>> Connect with us! >>>> >>>> >>>> >>>> The information contained in this transmission is for the personal >>>> and >> confidential use of the individual or entity to which it is >> addressed. If the reader is not the intended recipient, you are >> hereby notified that any review, dissemination, or copying of this >> communication is strictly prohibited. If you have received this >> transmission in error, please notify the sender immediately >>> >> >> >
