Builds for public repositories initialized by applications are not supported.

[kolyshkin]

Noticed a problem today for the first time, with the following PR opencontainers/runc#3366 (created by dependabot to bump a Go package dependency).

The cirrus ci job status is not reported back to github. If I go to cirrus website and look for this job (https://cirrus-ci.com/build/6140273406246912), I see

Builds for public repositories initialized by applications are not supported.

(which is also a tad misleading -- did you mean "initiated" rather than "initalized"?)

I looked this message up, and haven't found any explanations. Google search for the phrase shows nothing; searching this repo issues and discussions shows nothing either.

In particular, I am seeing this in runc repo with this PR:

A job/build that refused to run is here: https://cirrus-ci.com/build/6140273406246912

Expected Behavior

CI jobs are run for opened PRs.

Real Behavior

https://cirrus-ci.com/build/6140273406246912

Related Info

This is a (tick one of the following):

• Task issue

[asomers]

This is affecting Nix too. Nix uses the bors merge bot, but since sometime between 29-Jan and 3-Feb, we can no longer merge any PRs. Is this some kind of new Cirrus policy?

[fkorotkov]

I'm sorry for the inconveniences this change brought this week. It's not now been reverted/workarounded. Let me give you a little background for those who interested.

Last Sunday we identified a new vector of crypto miners attack on Cirrus CI where instead of using fake users to initialize builds that mine crypto currencies, applications like Dependabot were used instead. To stop the bleeding we made this temporarily change.

Historically, GitHub tried to fit this new functionality for "GitHub Apps being able to commit/comment/etc." into the existing model. For example, for the Dependabot there is a "fake" user with dependabot[bot] username which authors the commits and PRs. Unfortunately, just making "a GitHub App === a GitHub user" assumption introduced some issues including permissions checking for such fake users and a few more.

Long story short, back in 2019 when these capabilities were introduced without much support in GitHub API, on Cirrus CI side we had to workaround things for such *[bot] users. We basically just started always trust such users. And now it's been exploited by the miners.

We reworked how Cirrus CI is treating such fake users overall and specifically in a situation of crypto mining activity.

[asomers]

Damn, crypto miners suck. So what is the recommended procedure for Cirrus users to use bots? In the case of Bors, unlike Dependabot, Bors will never initiate a build unless it's been requested to do so by a human with permission for that repository. Is there any way to modify Bors so that Cirrus will see the real human user? Or could Cirrus just trust Bors, knowing that it can't be triggered anonymously?

[fkorotkov]

Everything should be working as before. You should be able to use Dependabot or Bors like before. I won't go too deep into details publicly but now Cirrus will associate activity of such bots with the corresponding user or organization and block them instead in case of a crypto mining activity.

[asomers]

Indeed it works now. Thanks! I misunderstood your previous comment. Was "not" perhaps a typo for "now"?

[fkorotkov]

😅 yeah, fixed the typo! Thanks for noting!

[kolyshkin]

@fkorotkov naive question -- how do I re-run the jobs that were rejected earlier? E.g. opencontainers/runc#3366

[fkorotkov]

@kolyshkin you should be able now to click "Re-Trigger" on your build:

[pathunstrom]

Sorry for the noise, but I want to explicitly express appreciation for all of this. It was jarring to learn our build system stopped working, but the reason for it (and the swift resolution) were great. Thanks for all the work that went into this.