Re: The future of the daffodil DFDL schema debugger?

[John Wass]

Thanks Adam, the DAP variable angle is interesting.  So are you thinking
all aspects are covered without defining any new DAP interfaces?

What about the backend, do you think a Daffodil debug server implementation
is needed?

When looking at the Java Debug server, for both Scala and Java, it looked
very much tied to JDI and debugging a virtual machine.  Did you see
anything at all that could be reused there?

It seemed to me that whether we extend DAP or not custom backend server
components need to be implemented to provide Daffodil debug sessions rather
than the JDI JVM sessions.




On Wed, Apr 21, 2021 at 7:52 PM Adam Rosien  wrote:

> I've been reading up on DAP and wanted to share...
>
> > There are many areas though that are unique to Daffodil that have no
> representation in the spec.  These things (like InputStream, Infoset, PoU,
> different variable types, backtracking, etc) will need an extension to
> DAP.  This really boils down to defining these things to fit under the DAP
> BaseProtocol and enabling handling of those objects on both the front and
> back ends.
>
> To me, much of the current state exposed by the (Daffodil) Debugger
> translates directly to a DAP Variable[1]. DAP Variables can be
> nested/hierarchical, so they could (potentially) model larger data like the
> infoset. I can imagine shoving all the current state into Variables as a
> proof-of-concept.
>
> It also seems like the processing stack maintained by the Daffodil PState,
> where each item references the relevant schema element, could translate to
> the DAP StackFrame type [2]. That is, the path from the schema root to the
> currently processing schema element becomes the "call stack". (Apologies if
> I don't have all the Daffodil terms lined up correctly.)
>
> For displaying the input data and processing progress, I looked at a few
> existing VS Code extensions that provided non-builtin views, some of which
> interact with their DAP debugger code [3] [4] [5] [6].
>
> Finally, I took a cursory look at scala-debug-adapter [7], which, for
> reference, wraps Microsoft's java-debug implementation of DAP. I was
> curious about the set of request/response and event types. Additionally,
> the Typescript API to VS Code offers custom DAP requests and responses, but
> I couldn't find the equivalent notion in the java-debug project.
>
> .. Adam
>
> [1]
>
> https://microsoft.github.io/debug-adapter-protocol/specification#Types_Variable
> [2]
>
> https://microsoft.github.io/debug-adapter-protocol/specification#Types_StackFrame
> [3] https://github.com/scalameta/metals-vscode (provides a debugger and
> non-debugger custom UI)
> [4] https://github.com/microsoft/vscode-cpptools (debugger + memory view)
> [5]
> https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug
> (debugger + memory view,
>
> https://github.com/Marus/cortex-debug/blob/master/src/frontend/memory_content_provider.ts
> )
> [6]
>
> https://marketplace.visualstudio.com/items?itemName=slevesque.vscode-hexdump
> (extension for hexdumps that could be controlled by other extensions)
> [7] https://github.com/scalacenter/scala-debug-adapter
> [8] https://github.com/microsoft/java-debug
>
> On Tue, Apr 20, 2021 at 7:08 AM John Wass  wrote:
>
> > > Going to look deeper into how DAP might fit with Daffodil
> >
> > Have been looking over DAP and getting a good feeling about it. The
> > specification [1] seems general enough that it could be applied to
> Daffodil
> > and cover a swath of common operations (like start, stop, break,
> continue,
> > code locations, variables, etc).
> >
> > There are many areas though that are unique to Daffodil that have no
> > representation in the spec.  These things (like InputStream, Infoset,
> PoU,
> > different variable types, backtracking, etc) will need an extension to
> > DAP.  This really boils down to defining these things to fit under the
> DAP
> > BaseProtocol and enabling handling of those objects on both the front and
> > back ends.
> >
> > On the backend we need a Daffodil DAP protocol server.  Existing JVM
> > implementations (like Java [2], Scala [3]) are tied closely to JDI and
> > would bring a lot of extra baggage to work around that.  Developing a
> > Daffodil specific implementation is no small task, but feasible.  There
> are
> > a several existing implementations on the JVM that are close and can be
> > looked at for reference.
> >
> > The backend implementation would look similar to what was described in an
> > earlier post.  We could use ZIO/Akka/etc to implement the backend
> Protocol
> > Server to enable the IO between the Daffodil process and the DAP clients.
> > This implementation would now be guided by the DAP specification.
> >
> > With the protocol and backend extended to fit Daffodil that leaves the
> > frontend.  In theory an existing IDE plugin should get pretty close to
> > being able to perform the common debug operations mentioned above.  To
> > support the Daffodil extensions there will need to 

Re: The future of the daffodil DFDL schema debugger?

[Adam Rosien]

I've been reading up on DAP and wanted to share...

> There are many areas though that are unique to Daffodil that have no
representation in the spec.  These things (like InputStream, Infoset, PoU,
different variable types, backtracking, etc) will need an extension to
DAP.  This really boils down to defining these things to fit under the DAP
BaseProtocol and enabling handling of those objects on both the front and
back ends.

To me, much of the current state exposed by the (Daffodil) Debugger
translates directly to a DAP Variable[1]. DAP Variables can be
nested/hierarchical, so they could (potentially) model larger data like the
infoset. I can imagine shoving all the current state into Variables as a
proof-of-concept.

It also seems like the processing stack maintained by the Daffodil PState,
where each item references the relevant schema element, could translate to
the DAP StackFrame type [2]. That is, the path from the schema root to the
currently processing schema element becomes the "call stack". (Apologies if
I don't have all the Daffodil terms lined up correctly.)

For displaying the input data and processing progress, I looked at a few
existing VS Code extensions that provided non-builtin views, some of which
interact with their DAP debugger code [3] [4] [5] [6].

Finally, I took a cursory look at scala-debug-adapter [7], which, for
reference, wraps Microsoft's java-debug implementation of DAP. I was
curious about the set of request/response and event types. Additionally,
the Typescript API to VS Code offers custom DAP requests and responses, but
I couldn't find the equivalent notion in the java-debug project.

.. Adam

[1]
https://microsoft.github.io/debug-adapter-protocol/specification#Types_Variable
[2]
https://microsoft.github.io/debug-adapter-protocol/specification#Types_StackFrame
[3] https://github.com/scalameta/metals-vscode (provides a debugger and
non-debugger custom UI)
[4] https://github.com/microsoft/vscode-cpptools (debugger + memory view)
[5] https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug
(debugger + memory view,
https://github.com/Marus/cortex-debug/blob/master/src/frontend/memory_content_provider.ts
)
[6]
https://marketplace.visualstudio.com/items?itemName=slevesque.vscode-hexdump
(extension for hexdumps that could be controlled by other extensions)
[7] https://github.com/scalacenter/scala-debug-adapter
[8] https://github.com/microsoft/java-debug

On Tue, Apr 20, 2021 at 7:08 AM John Wass  wrote:

> > Going to look deeper into how DAP might fit with Daffodil
>
> Have been looking over DAP and getting a good feeling about it. The
> specification [1] seems general enough that it could be applied to Daffodil
> and cover a swath of common operations (like start, stop, break, continue,
> code locations, variables, etc).
>
> There are many areas though that are unique to Daffodil that have no
> representation in the spec.  These things (like InputStream, Infoset, PoU,
> different variable types, backtracking, etc) will need an extension to
> DAP.  This really boils down to defining these things to fit under the DAP
> BaseProtocol and enabling handling of those objects on both the front and
> back ends.
>
> On the backend we need a Daffodil DAP protocol server.  Existing JVM
> implementations (like Java [2], Scala [3]) are tied closely to JDI and
> would bring a lot of extra baggage to work around that.  Developing a
> Daffodil specific implementation is no small task, but feasible.  There are
> a several existing implementations on the JVM that are close and can be
> looked at for reference.
>
> The backend implementation would look similar to what was described in an
> earlier post.  We could use ZIO/Akka/etc to implement the backend Protocol
> Server to enable the IO between the Daffodil process and the DAP clients.
> This implementation would now be guided by the DAP specification.
>
> With the protocol and backend extended to fit Daffodil that leaves the
> frontend.  In theory an existing IDE plugin should get pretty close to
> being able to perform the common debug operations mentioned above.  To
> support the Daffodil extensions there will need to be handling of the
> extended protocol into whatever views are desired/applicable.
>
> > Also looking into the Java Debug Interface (JDI) for comparison.
>
> JDI appears to be the wrong level of abstraction for what we are talking
> about in debugging Daffodil for schema development.  While DAP does do JVM
> debugging (through a JDI DAP impl) it also generalizes to many other
> debugging scenarios.  JDI on the other hand is very tied to the JVM.
>
> Extending the JDI appears to be more complex than dealing with DAP, and
> even though the JDI API is mostly defined with interfaces, there are choke
> points that limit to JVM concepts.  For example jdi.Value has a finite set
> of JVM types that it works with, its not clear where Daffodil types would
> plugin if even possible.
>
> The final note is that unique 

Re: Forgot to squash commits

[John Wass]

Might want to note that new commit in the PR.

On Wed, Apr 21, 2021 at 4:53 PM Interrante, John A (GE Research, US) <
john.interra...@ge.com> wrote:

> Yep.  My pull request had no conflicts and I just merged it (after all the
> checks passed) without any problem.
>
> -Original Message-
> From: Beckerle, Mike 
> Sent: Wednesday, April 21, 2021 4:34 PM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: Forgot to squash commits
>
> I decided to force-push them, but just in case I do have the branch with
> the other 3 commits saved and we could recreate the other 3-commit scenario
> if necessary.
>
> So the master is now what it is supposed to be. The bug fix (which was
> just adding test cases) having been squashed from 3 commits into 1 (our
> usual workflow practice.)
>
> Outstanding pull requests still have to rebase on top, and conflict
> detection should still do the right thing. I checked a couple PRs and they
> still show no-conflicts with the base.
>
> 
> From: John Wass 
> Sent: Wednesday, April 21, 2021 4:26 PM
> To: dev@daffodil.apache.org 
> Subject: Re: Forgot to squash commits
>
> I'd let them be.
>
> On Wed, Apr 21, 2021 at 4:13 PM Beckerle, Mike <
> mbecke...@owlcyberdefense.com> wrote:
>
> > I ended up committing 3 tiny commits to master, forgot to squash them.
> >
> > Should I fix this by force push?
> >
> > 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
> >
>

RE: Forgot to squash commits

[Interrante, John A (GE Research, US)]

Yep.  My pull request had no conflicts and I just merged it (after all the 
checks passed) without any problem.  

-Original Message-
From: Beckerle, Mike  
Sent: Wednesday, April 21, 2021 4:34 PM
To: dev@daffodil.apache.org
Subject: EXT: Re: Forgot to squash commits

I decided to force-push them, but just in case I do have the branch with the 
other 3 commits saved and we could recreate the other 3-commit scenario if 
necessary.

So the master is now what it is supposed to be. The bug fix (which was just 
adding test cases) having been squashed from 3 commits into 1 (our usual 
workflow practice.)

Outstanding pull requests still have to rebase on top, and conflict detection 
should still do the right thing. I checked a couple PRs and they still show 
no-conflicts with the base.


From: John Wass 
Sent: Wednesday, April 21, 2021 4:26 PM
To: dev@daffodil.apache.org 
Subject: Re: Forgot to squash commits

I'd let them be.

On Wed, Apr 21, 2021 at 4:13 PM Beckerle, Mike < mbecke...@owlcyberdefense.com> 
wrote:

> I ended up committing 3 tiny commits to master, forgot to squash them.
>
> Should I fix this by force push?
>
> 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
>

Re: Forgot to squash commits

[Beckerle, Mike]

I decided to force-push them, but just in case I do have the branch with the 
other 3 commits saved and we could recreate the other 3-commit scenario if 
necessary.

So the master is now what it is supposed to be. The bug fix (which was just 
adding test cases) having been squashed from 3 commits into 1 (our usual 
workflow practice.)

Outstanding pull requests still have to rebase on top, and conflict detection 
should still do the right thing. I checked a couple PRs and they still show 
no-conflicts with the base.


From: John Wass 
Sent: Wednesday, April 21, 2021 4:26 PM
To: dev@daffodil.apache.org 
Subject: Re: Forgot to squash commits

I'd let them be.

On Wed, Apr 21, 2021 at 4:13 PM Beckerle, Mike <
mbecke...@owlcyberdefense.com> wrote:

> I ended up committing 3 tiny commits to master, forgot to squash them.
>
> Should I fix this by force push?
>
> 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
>

RE: Forgot to squash commits

[Interrante, John A (GE Research, US)]

My pull request (runtime2, #532) has been approved and I'm just waiting for the 
checks to finish before merging it.  I'm not sure how a force push to the 
master branch would affect any outstanding pull requests.  But I'm willing to 
wait for the force-push before merging my pull request if you decide to go 
ahead.

From: Beckerle, Mike 
Sent: Wednesday, April 21, 2021 4:13 PM
To: dev@daffodil.apache.org
Subject: EXT: Forgot to squash commits

I ended up committing 3 tiny commits to master, forgot to squash them.

Should I fix this by force push?

Mike Beckerle | Principal Engineer

[cid:7cdf72d7-2aa7-4d28-b9d3-bc7fa7c525a1]

mbecke...@owlcyberdefense.com
P +1-781-330-0412

Connect with us!

[cid:30d2c816-c306-4257-867b-9c6395fea667][cid:153579d6-aa11-448c-ab90-fec19584e663]

[cid:d267645d-3247-4fab-97fe-fd60a4dd0301]



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

Re: Forgot to squash commits

[Steve Lawrence]

Fine with me. It was merged recently and not much activity right now so
no concern for lost commits.

On 4/21/21 4:13 PM, Beckerle, Mike wrote:
> I ended up committing 3 tiny commits to master, forgot to squash them.
> 
> Should I fix this by force push?
> 
> 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
> 

Forgot to squash commits

[Beckerle, Mike]

I ended up committing 3 tiny commits to master, forgot to squash them.

Should I fix this by force push?

Mike Beckerle | Principal Engineer

[cid:7cdf72d7-2aa7-4d28-b9d3-bc7fa7c525a1]

mbecke...@owlcyberdefense.com

P +1-781-330-0412

Connect with us!

[cid:30d2c816-c306-4257-867b-9c6395fea667][cid:153579d6-aa11-448c-ab90-fec19584e663]

[cid:d267645d-3247-4fab-97fe-fd60a4dd0301]



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

New JIRA component "Back End C-Generator". Also Issue Types.

[Beckerle, Mike]

I added this component as we're going to be merging this stuff onto master soon 
enough.

JIRA tickets associated with this new back end should use this component.

I also wanted to mention that JIRA offers us a huge list of issue types.

I'd like to recommend we stick with exactly 3: Bug, Improvement, New Feature.


Mike Beckerle | Principal Engineer

[cid:8c0ba067-d17a-42e0-bba0-62142ad43964]

mbecke...@owlcyberdefense.com

P +1-781-330-0412

Connect with us!

[cid:de89acb0-0c26-4e83-8b68-4e66ceb7dcea][cid:ab3efb76-6e11-45e0-9665-d23ed421ee87]

[cid:53f2062f-398b-437a-be33-e9bdcf7b2b07]



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

Re: editconfig

[Beckerle, Mike]

Also, did we decide on the autocrlf or force just LF thing?

I think I am in the force LF-only camp now. I got prompted the other day by 
IntellJ that I was commiting files that contained CRLFs.

Developers on windows just must configure tools to always use just LF line 
endings for the Daffodil project.

From: John Wass 
Sent: Wednesday, April 21, 2021 11:46 AM
To: dev@daffodil.apache.org 
Subject: Re: editconfig

> As a Scala project, however, how about using Scalafmt?

I'm in favor of scalafmt also.

> But I assume scalafmt won't cover other files like XML/schema/tdml/text
files.

Take a look at https://github.com/diffplug/spotless

Spotless says it could support all of those, and a quick search says the
SBT plugin is backed by scalafmt.

(I haven't used Spotless, just saw it today and thought of this thread)



On Mon, Apr 19, 2021 at 3:17 PM Interrante, John A (GE Research, US) <
john.interra...@ge.com> wrote:

> I concur with Steve; we're going to need both a scalafmt configuration
> file and an .editorconfig file to cover all source code files unless the
> day comes when scalafmt understands .editorconfig and we're happy with
> scalafmt's default formatting options.
>
> Daffodil's existing code style is supposed to be very close to
> scalariform's default formatting options.  Does anyone know how different
> scalafmt's default formatting options are from scalariform's?  If they're
> not that different, eventually we might end up with just .editorconfig.
>
> -Original Message-
> From: Adam Rosien 
> Sent: Monday, April 19, 2021 12:16 PM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: editconfig
>
> Ah, thanks for the extra context. I'll check out the JIRA issue.
>
> FYI there's an editorconfig integration issue open for scalafmt:
> https://github.com/scalameta/scalafmt/issues/1458.
>
> .. Adam
>
> On Mon, Apr 19, 2021 at 8:51 AM Steve Lawrence 
> wrote:
>
> > As long as scalafmt covers everything editconfig supports and the
> > popular IDE's support it, we'd probably get better results for our
> > scala files. But I assume scalafmt won't cover other files like
> > XML/schema/tdml/text files. We might need a combination of the two to
> > cover all files?
> >
> > See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related
> issue.
> >
> > - Steve
> >
> > On 4/19/21 11:37 AM, Adam Rosien wrote:
> > > As a Scala project, however, how about using Scalafmt? [1] It's
> > > become standard in all the projects I've been involved with; it's
> > > supported by
> > the
> > > language creators and matches the previously mentioned features.
> > >
> > > .. Adam
> > >
> > > [1] https://scalameta.org/scalafmt/
> > >
> > > On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US)
> > > < john.interra...@ge.com> wrote:
> > >
> > >> I agree, an .editorconfig file at the root of daffodil coupled with
> > >> IDE plugins (some IDEs such as IDEA already support .editorconfig
> > >> without
> > any
> > >> plugin needed) could autoconfigure the following IDE settings
> > automatically
> > >> (if we felt we needed to specify all of these settings):
> > >>
> > >> root = true
> > >> # All files (risky - could change bin/dat files inadvertently) [*]
> > >> end_of_line = lf charset = utf-8 trim_trailing_whitespace = true
> > >> insert_final_newline = true indent_style = space indent_size = 2 #
> > >> Can narrow scope to only source code files [*.{java,scala,xml}]
> > >> indent_style = space indent_size = 2
> > >>
> > >> EditorConfig plugins format only newly typed lines with these
> > >> settings; they do not reformat existing files, meaning only files
> > >> actually
> > changed by
> > >> one's commit will be affected by these settings.  There are
> > >> separate command-line tools that can check, infer, or fix
> > >> EditorConfig rules
> > across
> > >> one or more directories/files in a repository manually.  I think
> > >> using
> > one
> > >> of these tools such as eclint would be essential for writing a
> > >> proper .editorconfig that narrows its scope as much as possible
> > >> (e.g., we don't want to change existing bin or dat or tdml files
> > >> inadvertently when
> > editing
> > >> a single character within them in Emacs or IDEA because many of
> > >> them use other charsets and are not source code).
> > >>
> > >> There's a nice long list of projects already using EditorConfig
> > >> with
> > links
> > >> to their .editorconfig files.  We also can look for similar
> > >> projects to Daffodil to see how they scope their .editorconfig
> > >> rules for their own files, but again, using "eclint infer" and
> > >> "eclint check" seems the
> > safest
> > >> way to me.
> > >>
> > >> John
> > >>
> > >> -Original Message-
> > >> From: Beckerle, Mike 
> > >> Sent: Monday, April 19, 2021 9:56 AM
> > >> To: dev@daffodil.apache.org
> > >> Subject: EXT: editconfig
> > >>
> > >> https://editorconfig.org/
> > >>
> > >> This is interesting and we should consider adding 

all this github spam ?

[Interrante, John A (GE Research, US)]

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  
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  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
>>>
>>
>>
> 

Re: editconfig

[John Wass]

> As a Scala project, however, how about using Scalafmt?

I'm in favor of scalafmt also.

> But I assume scalafmt won't cover other files like XML/schema/tdml/text
files.

Take a look at https://github.com/diffplug/spotless

Spotless says it could support all of those, and a quick search says the
SBT plugin is backed by scalafmt.

(I haven't used Spotless, just saw it today and thought of this thread)



On Mon, Apr 19, 2021 at 3:17 PM Interrante, John A (GE Research, US) <
john.interra...@ge.com> wrote:

> I concur with Steve; we're going to need both a scalafmt configuration
> file and an .editorconfig file to cover all source code files unless the
> day comes when scalafmt understands .editorconfig and we're happy with
> scalafmt's default formatting options.
>
> Daffodil's existing code style is supposed to be very close to
> scalariform's default formatting options.  Does anyone know how different
> scalafmt's default formatting options are from scalariform's?  If they're
> not that different, eventually we might end up with just .editorconfig.
>
> -Original Message-
> From: Adam Rosien 
> Sent: Monday, April 19, 2021 12:16 PM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: editconfig
>
> Ah, thanks for the extra context. I'll check out the JIRA issue.
>
> FYI there's an editorconfig integration issue open for scalafmt:
> https://github.com/scalameta/scalafmt/issues/1458.
>
> .. Adam
>
> On Mon, Apr 19, 2021 at 8:51 AM Steve Lawrence 
> wrote:
>
> > As long as scalafmt covers everything editconfig supports and the
> > popular IDE's support it, we'd probably get better results for our
> > scala files. But I assume scalafmt won't cover other files like
> > XML/schema/tdml/text files. We might need a combination of the two to
> > cover all files?
> >
> > See https://issues.apache.org/jira/browse/DAFFODIL-2133 for related
> issue.
> >
> > - Steve
> >
> > On 4/19/21 11:37 AM, Adam Rosien wrote:
> > > As a Scala project, however, how about using Scalafmt? [1] It's
> > > become standard in all the projects I've been involved with; it's
> > > supported by
> > the
> > > language creators and matches the previously mentioned features.
> > >
> > > .. Adam
> > >
> > > [1] https://scalameta.org/scalafmt/
> > >
> > > On Mon, Apr 19, 2021 at 8:20 AM Interrante, John A (GE Research, US)
> > > < john.interra...@ge.com> wrote:
> > >
> > >> I agree, an .editorconfig file at the root of daffodil coupled with
> > >> IDE plugins (some IDEs such as IDEA already support .editorconfig
> > >> without
> > any
> > >> plugin needed) could autoconfigure the following IDE settings
> > automatically
> > >> (if we felt we needed to specify all of these settings):
> > >>
> > >> root = true
> > >> # All files (risky - could change bin/dat files inadvertently) [*]
> > >> end_of_line = lf charset = utf-8 trim_trailing_whitespace = true
> > >> insert_final_newline = true indent_style = space indent_size = 2 #
> > >> Can narrow scope to only source code files [*.{java,scala,xml}]
> > >> indent_style = space indent_size = 2
> > >>
> > >> EditorConfig plugins format only newly typed lines with these
> > >> settings; they do not reformat existing files, meaning only files
> > >> actually
> > changed by
> > >> one's commit will be affected by these settings.  There are
> > >> separate command-line tools that can check, infer, or fix
> > >> EditorConfig rules
> > across
> > >> one or more directories/files in a repository manually.  I think
> > >> using
> > one
> > >> of these tools such as eclint would be essential for writing a
> > >> proper .editorconfig that narrows its scope as much as possible
> > >> (e.g., we don't want to change existing bin or dat or tdml files
> > >> inadvertently when
> > editing
> > >> a single character within them in Emacs or IDEA because many of
> > >> them use other charsets and are not source code).
> > >>
> > >> There's a nice long list of projects already using EditorConfig
> > >> with
> > links
> > >> to their .editorconfig files.  We also can look for similar
> > >> projects to Daffodil to see how they scope their .editorconfig
> > >> rules for their own files, but again, using "eclint infer" and
> > >> "eclint check" seems the
> > safest
> > >> way to me.
> > >>
> > >> John
> > >>
> > >> -Original Message-
> > >> From: Beckerle, Mike 
> > >> Sent: Monday, April 19, 2021 9:56 AM
> > >> To: dev@daffodil.apache.org
> > >> Subject: EXT: editconfig
> > >>
> > >> https://editorconfig.org/
> > >>
> > >> This is interesting and we should consider adding these files to
> > >> the
> > root
> > >> of daffodil both as a declaration of the code-style, and a way that
> > >> auto-configures many IDEs and tools (like github).
> > >>
> > >> This does not appear to be sophisticated enough to really cover
> > code-style
> > >> issues at all, but at least basic whitespace stuff like spaces not
> > >> tabs, 2-space indenting, etc. would be covered.
> > >>
> > >>
> > >>
> > >
> >
> >
>

Re: all this github spam ?

[Steve Lawrence]

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-conversations/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  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
>>>
>>
>>
> 

Re: all this github spam ?

[Adam Rosien]

There's a way to limit the incoming activity for various categories of
participants:
https://docs.github.com/en/communities/moderating-comments-and-conversations/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  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
> >
>
>

Re: all this github spam ?

[Steve Lawrence]

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  
>> 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
> 

Re: all this github spam ?

[Steve Lawrence]

I'm don't think github has a feature to require captcha's on PRs. But
these PR's come from brand new accounts, so if they're bots, they've
figured out how to get around the new account captcha.

But actually, I'm not sure they're bots. I see one account that create a
a spam PR also created 70 of the same pull requests to other
repositories. They also opened an issue in the crypto mining source code
repo that looks like a human wrote it, so I think these might actually
be real people.

On 4/21/21 9:38 AM, Attila Horvath wrote:
> does github support (re)captcha on email submit?
> 
> On Wed, Apr 21, 2021 at 9:22 AM Steve Lawrence  wrote:
> 
>> Unfortunately, I'm not sure there's anything we can do about it.
>>
>> GitHub doesn't give any controls over who can/can't open a PR. We can't
>> even temporarily close PR's completely.
>>
>> We could maybe make it so GitHub actions on PRs must be manually
>> triggered so the spammers cryptocurrency mining stuff would never run.
>> But that's a bit of a pain, and it relies on the spammers to realize
>> their stuff isn't being run anymore and take us off their list. My guess
>> is we're stuck on their list forever now.
>>
>> These crypto mining attacks are a known issue for GitHub, hopefully
>> they're working on a solution. Tough, GitHub is eventually detecting
>> these are spam and closing the accounts and deleting the PRS, but not
>> until after the PR is created.
>>
>> As to the archive issue, we could maybe ask infra to remove archives
>> that are clearly spam (all of them so far say "Demo titles Add
>> files...", so unique and consistent). But it doesn't solve the
>> underlying issue.
>>
>>
>> On 4/21/21 8:59 AM, Beckerle, Mike 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!
>>>
>>> <
>> https://twitter.com/owlcyberdefense>
>>>
>>> 
>>>
>>> **
>>>
>>> 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
>>>
>>
>>
> 

Re: all this github spam ?

[Dave Fisher]

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  
> 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

Re: all this github spam ?

[John Wass]

The trick is being able to modify the CI workflow in the PR to inject new
behavior.  If there was a limit of some type on that it would decrease the
usefulness of this.

On Wed, Apr 21, 2021 at 9:33 AM Beckerle, Mike <
mbecke...@owlcyberdefense.com> wrote:

> This has to do with crypto mining?  Gaaak.
>
> So their PR contains crypto mining code, and they are doing this to get
> the CI to run it as part of the way CI checks any PR?
>
> Sounds like submitting a PR has to require a Capcha or 2-FA.
>
>
> 
> From: Steve Lawrence 
> Sent: Wednesday, April 21, 2021 9:22 AM
> To: dev@daffodil.apache.org 
> Subject: Re: all this github spam ?
>
> Unfortunately, I'm not sure there's anything we can do about it.
>
> GitHub doesn't give any controls over who can/can't open a PR. We can't
> even temporarily close PR's completely.
>
> We could maybe make it so GitHub actions on PRs must be manually
> triggered so the spammers cryptocurrency mining stuff would never run.
> But that's a bit of a pain, and it relies on the spammers to realize
> their stuff isn't being run anymore and take us off their list. My guess
> is we're stuck on their list forever now.
>
> These crypto mining attacks are a known issue for GitHub, hopefully
> they're working on a solution. Tough, GitHub is eventually detecting
> these are spam and closing the accounts and deleting the PRS, but not
> until after the PR is created.
>
> As to the archive issue, we could maybe ask infra to remove archives
> that are clearly spam (all of them so far say "Demo titles Add
> files...", so unique and consistent). But it doesn't solve the
> underlying issue.
>
>
> On 4/21/21 8:59 AM, Beckerle, Mike 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!
> >
> > <
> https://twitter.com/owlcyberdefense>
> >
> > 
> >
> > **
> >
> > 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
> >
>
>

Re: all this github spam ?

[Attila Horvath]

does github support (re)captcha on email submit?

On Wed, Apr 21, 2021 at 9:22 AM Steve Lawrence  wrote:

> Unfortunately, I'm not sure there's anything we can do about it.
>
> GitHub doesn't give any controls over who can/can't open a PR. We can't
> even temporarily close PR's completely.
>
> We could maybe make it so GitHub actions on PRs must be manually
> triggered so the spammers cryptocurrency mining stuff would never run.
> But that's a bit of a pain, and it relies on the spammers to realize
> their stuff isn't being run anymore and take us off their list. My guess
> is we're stuck on their list forever now.
>
> These crypto mining attacks are a known issue for GitHub, hopefully
> they're working on a solution. Tough, GitHub is eventually detecting
> these are spam and closing the accounts and deleting the PRS, but not
> until after the PR is created.
>
> As to the archive issue, we could maybe ask infra to remove archives
> that are clearly spam (all of them so far say "Demo titles Add
> files...", so unique and consistent). But it doesn't solve the
> underlying issue.
>
>
> On 4/21/21 8:59 AM, Beckerle, Mike 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!
> >
> > <
> https://twitter.com/owlcyberdefense>
> >
> > 
> >
> > **
> >
> > 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
> >
>
>

Re: all this github spam ?

[Beckerle, Mike]

This has to do with crypto mining?  Gaaak.

So their PR contains crypto mining code, and they are doing this to get the CI 
to run it as part of the way CI checks any PR?

Sounds like submitting a PR has to require a Capcha or 2-FA.



From: Steve Lawrence 
Sent: Wednesday, April 21, 2021 9:22 AM
To: dev@daffodil.apache.org 
Subject: Re: all this github spam ?

Unfortunately, I'm not sure there's anything we can do about it.

GitHub doesn't give any controls over who can/can't open a PR. We can't
even temporarily close PR's completely.

We could maybe make it so GitHub actions on PRs must be manually
triggered so the spammers cryptocurrency mining stuff would never run.
But that's a bit of a pain, and it relies on the spammers to realize
their stuff isn't being run anymore and take us off their list. My guess
is we're stuck on their list forever now.

These crypto mining attacks are a known issue for GitHub, hopefully
they're working on a solution. Tough, GitHub is eventually detecting
these are spam and closing the accounts and deleting the PRS, but not
until after the PR is created.

As to the archive issue, we could maybe ask infra to remove archives
that are clearly spam (all of them so far say "Demo titles Add
files...", so unique and consistent). But it doesn't solve the
underlying issue.


On 4/21/21 8:59 AM, Beckerle, Mike 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
>

Re: all this github spam ?

[Steve Lawrence]

Unfortunately, I'm not sure there's anything we can do about it.

GitHub doesn't give any controls over who can/can't open a PR. We can't
even temporarily close PR's completely.

We could maybe make it so GitHub actions on PRs must be manually
triggered so the spammers cryptocurrency mining stuff would never run.
But that's a bit of a pain, and it relies on the spammers to realize
their stuff isn't being run anymore and take us off their list. My guess
is we're stuck on their list forever now.

These crypto mining attacks are a known issue for GitHub, hopefully
they're working on a solution. Tough, GitHub is eventually detecting
these are spam and closing the accounts and deleting the PRS, but not
until after the PR is created.

As to the archive issue, we could maybe ask infra to remove archives
that are clearly spam (all of them so far say "Demo titles Add
files...", so unique and consistent). But it doesn't solve the
underlying issue.


On 4/21/21 8:59 AM, Beckerle, Mike 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
> 

all this github spam ?

[Beckerle, Mike]

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

[cid:dad50db4-6031-4eb8-bba5-24881987583e]

mbecke...@owlcyberdefense.com

P +1-781-330-0412

Connect with us!

[cid:c5dd57f6-59b7-42a8-8f72-3b5aec87ae58][cid:ce6f9108-6d36-4815-b1f6-8201448e03b5]

[cid:034fa20d-6e10-4ed7-8818-91fb58a12136]



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