It seems like we haven't had a non-robot status update on the status page in days since this what seems like daily occurrence. I figure at this point we'd get something of why this is happening.
I also don't appreciate our builds freezing, unable to be cancelled and then eating up hundreds of minutes.
Billing should always be built on a "ping" IMO and not start/stop hooks. The latter is shockingly bad for customers during times of unreliability. The former sounds stupid and requires more infrastructure from the one offering the service, but I think it's more fair.
I haven't used GA in a way where it actually costed me anything, but having minutes just tick away while you can't do anything is really stupid if that's the case.
Edit: Another sane solution would probably be to record outage periods and have Billing automatically reconcile for every customer when invoicing. This would require them to admit the outage durations however, so it may be flawed from a human perspective.
The "ping" solution is an interesting one that I haven't seen proposed before.
At what rate would you do these pings? I don't know how upgrading/downgrading works at GitHub but if they do any sort of refund/credit when you downgrade, it seems like there's some interesting implications for abusing the system (e.g. upgrading/downgrading between pings for "free" service if the time between them is too long) versus performance (e.g. how do you update all users per ping in a timely manner if the time between them is too short?).
Would love to read up more on this approach; seems interesting!
I suggest you add the timeout-minute property on the job/step, so even if the web interface isn't responsive the job times out eventually. Saves you from spending time emailing support about consumed minutes.
Of course, assuming that a future bug won't affect the timeout-minute itself.
This is totally unsurprising and also totally unacceptable IMO. They should automatically wipe out all build minute usage during outages for every account if they insist on architecting their system in this way.
Initial release sure, but if you are looking at the website linked that was released in 2018 and the last major release (2.6.0) was released in 2021. So don't think 2010 is accurate.
Submitter linked to the main page, which is known since 2010. Nothing much changed since.
If he would have linked to the latest news instead, it would be 2021.
When I moved the project from Google Code to GitHub, GitHub did not allow binary downloads. So I used Bitbucket, changing the download location again after moving did not seem right. So it has just been maintained since the switch. Now in present day they are also uploaded to GitHub and another mirror I host.
This was an interesting security patch that marked the first time in my memory that updating Apache led to an immediate regression. A few hours after taking this upgrade many systems experienced such strange timeout errors. Connections were low and couldn't pinpoint the misleading behavior that looked like a slowloris attack, with no connections.
Half a day later with no resolution in research a new patch [1] was available and problem resolved.
It might be because they had patch cycle commitments. Ideally you want this stuff to be tucked into the regular release cycle. It costs companies a shit load of money to release and out of band update, esp when security related
I’m replying to you because the parent is flagged.
I’m not a security guy, but I am a serious generalist and I’ll try my hand at anything.
Except security.
As finely as I try to hone my craft, as much discipline as I bring to it, and as many great results as I’ve produced: computer security is a completely different ballgame.
The guys and gals who are as sophisticated, and diligent, and dedicated, and ultimately humble enough to be serious security pros are a breed apart, and my hat is off to them.
In our case, we use a mac mini solely for building mobile applications via fastlane with a self-runner. Doing that with the GitHub runner on Mac would be mega expensive. The rest of the CI/test process runs on GitHub runners.
GitHub right now only has their self-hosted Mac runner released as an Intel Build, but it works fine through Rosetta, though running Apple Silicon Xcode might require some additional wrapping of commands with `arch` which might or might not be built into the pre-built action you're using.
We're currently using an Intel Mac we've used from before we migrated from Jenkins to GitHub actions, so your mileage may vary.
I wonder if the signed features of GitHub would have helped here. Probably can't ask all the 3rd party contributors to setup signing commits, but it would help to spot commits not signed.
If the attackers would have used their own name/email linked to a GitHub account and signed the backdoor commits, GitHub would display a green "Signed" label, and everything would look OK to an outsider.
That's why it's just a gimmick. Signing only works as protection against hosting compromise if the signing/verification is separate from the hosting itself.
Someone responsible for release would have to manually keep a list of keys of authorized comiters and check the repository against this list at the very least prior to a release.
The number of people with direct commit access is almost certainly less than the number of commits in a release though. Without signatures you have to verify every commit.
Well that was a sad article to read on a Monday morning. If this is what we've just scratched the surface on - I'm nervous to what we don't know in terms of ocean dumping.
Greenpeace did a lot of work in the 80s and 90s against the dumping of nuclear waste, including direct action against the ships doing the dumping. This led to the London Dumping Convention.
More seriously, there is the SS Richard Montgomery, not dumped but sank during the war, carrying a thousand tons of explosives ... right next to London. https://en.wikipedia.org/wiki/SS_Richard_Montgomery
This is really cool. Just clicking around to various blogs and scanning for articles that perk my interest. It would be pretty cool for blog authors to pick like a top 3 articles or something to help me quickly gauge on top of their description.
* We get a non-machine message that migrations to GitHub are temporarily disabled.
* We get an exact message that the delivery of webhooks and action kickoff is delayed.
So while there are no 500s - I just have to wait a few more minutes for builds to kick off. So at least I can still review code in the meantime.