There have been ideas to move to a self-hosted platform to manage issues and pull requests, motivated by concerns that GitHub might not be a suitable platform in the long term. For example, there were issues reviewing pull requests for several weeks due to failures to load the site.
This is a tracking issue of past discussions, so the same discussions don’t have to happen over again:
Personally I really like GitHub. The security track record of GitHub has been much better than the self-hosted solutions I’ve seen used by various other open-source projects.
Usually due to a combination of recurring security flaws in the self-hosted alternative used and a slow patching routine by the volunteer team handling the installation. This combination leads to long periods of exposure also for publicly known vulnerabilities.
I think it would be very costly to achieve a self-hosted solution with a security level equivalent to what is provided by GitHub. The combination of near immediate roll-out of security patches, a skilled security team operating around the clock and a big bug bounty budget (incentives matter!) is hard to beat :-)
I don’t know if it makes sense for the project to switch to a self-hosted platform either, but if it helps tip the scales in any way I’d be happy to offer my assistance on the infrastructure side of things, should you want to pursue it.
I have a background in operating reliable and secure large-scale systems (at Google and elsewhere), building monitoring / alerting etc., and I’d be up for providing advice, technical work, or actually help set up / operate infrastructure, assuming at minimum the raw costs for the machines were covered somehow. (Agreed with @practicalswift that incentives as well as removing single points of failure in terms of human operators also would need to be tackled for a long term solution.) For the last several months I’ve been spending all my time on learning about the Bitcoin project and related tech, and trying to find where I can help the most. If this might be such a place I’d be happy to contribute.
E.g if the project ran a self-hosted platform like GitLab on top of a CoreOS cluster, OS-level patches would be applied automatically and atomically to the entire filesystem as soon as new versions were available. Usually new CoreOS images holding fixes to critical security issues are available, and automatically deployed to all CoreOS deployments, within < 24 hrs of the patches themselves become available. Some historical data on time-to-patch, e.g for Heartbleed and Shellshock, can be seen here.
CoreOS itself is very minimal (by design, to limit the attack surface), so anything beyond statically compiled binaries normally needs to be run inside a Docker or rkt container. The app-level services would also need to be patched in case of vulnerabilities, and of course those would not (or at least should not) be updated automatically. On a self-hosted platform we could pick whatever service level indicators (SLIs) that make most sense for monitoring the health of the service, as well response time to bring out new versions, etc, and from there define reasonable service level objectives (SLOs) that can be used for alerting.
(There’s also even crazier stuff possible with CoreOS like boot-to-application cryptographically verified chain using TPMs, but I don’t want to create even more of a wall-of-text in this issue..)
um Github sanctions now in effect? This is concerning. See link below.
The feature request didn’t seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.
Closing due to lack of interest. Pull requests with improvements are always welcome.
