ctf-collab VS dear-github

GitHub - jstrieb/ctf-collab: Collaborative programming environment inside GitHub Actions – like Google Docs for hacking

https://github.com/jstrieb/ctf-collab/blob/9300c57364f71fe29...

I have used Apache Guacamole to use running GitHub Actions workflows as remote desktops. It worked super well for testing GUI apps on other operating systems that I didn't want to deal with setting up.

https://github.com/jstrieb/ctf-collab/blob/9300c57364f71fe29...

One of my own projects sits in a related grey area: it automates running a reverse shell inside an Action for collaborating on programming and competitive hacking challenges/CTF problems.[0] It lets anyone log into a shared session from the terminal or the browser.

My project doesn't use anywhere near the resources of cryptomining, but I still sometimes feel guilty when I fire it up. I wonder how different it is from regular GitHub Actions usage patterns, and whether it is noticeable to those maintaining the infrastructure. My hope is that the load it incurs is comparatively insignificant, and that if noticed, it will be viewed as a good-faith attempt to use resources in a creative way.

0: https://github.com/jstrieb/ctf-collab

GitHub makes this unnecessarily worse by refusing to let you disable Pull Requests like one can disable the other social features (Wiki etc) of a repository: https://github.com/dear-github/dear-github/issues/84

The workaround is to use GH Actions to auto-close PRs: https://github.com/marketplace/actions/repo-lockdown

There is no way to disable pull requests on GitHub. Only some weird work-arounds for auto-closing them with Actions

> don't let people waste their time creating issues in the first place

But then you don't get to use issues to track things that you personally care about. It would be nice if there were a way to enable issue creation by the repo owner / maintainers, but disallow it for the public at large. Especially now that "discussions" are a thing, which gives a place for people to comment without implicitly requesting work from the maintainer.

Apparently this is sort of possible[1] by setting `blank_issues_enabled: false`, so that you can only create issues from the Project page.

[1]: https://github.com/dear-github/dear-github/issues/293#issuec...

last I've seen the Oauth permissions for the Heroku Dashboard given by Github are excessive and include write access to all public repos - as read-only is not an option if I recall correctly, see https://github.com/dear-github/dear-github/issues/113#issuec...

Newer integrations like Github Apps are more granular and can restrict the scope , also ssh deploy keys are an option for other purposes, but specifically the tokens issued for the Heroku Dashboard can write to the public repos of a user or org.

Without active triage and maintenance, such a list would quickly become useless. Let's look at just one example that's not even for an open source project: https://github.com/dear-github/dear-github/issues/214

Found these ways to submit bug to github: https://support.github.com/contact/feedback https://support.github.com/request https://github.com/isaacs/github#if-you-have-an-issue-or-feature-request-for-github https://github.com/dear-github/dear-github [email protected] Submitting tickets using an enterprise account

You're right, likely the OP thought PRs were included in settings where you can disable issues or wikis

Discussion: https://github.com/dear-github/dear-github/issues/84