1. 37
  1.  

  2. 12

    More projects centralising on GitHub, especially after the Microsoft takeover, is disheartening. We’ve made these mistakes before and yet we’ve already forgotten.

    1. 37

      If you were going to advise the PHP team in regards to what to do in order to maintain the security of their source code serving infrastructure (An extremely high value target for everyone from organized crime to nation states), what would you tell them?

      Keeping in mind that as language maintainers they likely do not have the expertise or resources to protect that infrastructure themselves. They’ve already been compromised once. And the risk of not properly protecting that infrastructure is extremely high.

      Complaining about the move while offering no useful alternatives helps no one.

      1. 23

        It’s the same reason people use, Office 365 instead of hosting their own email. Unless it’s a core competency for you, it doesn’t add value beyond personal pride, but it certainly does add liabilities for you.

        1. 2

          I agree with you. Arguably, there is Gitlab, sr.ht, etc. So Github isn’t the only answer, but it certainly is a sane answer to the problem, especially if maintaining infrastructure isn’t on your “YAY I enjoy this” list.

          1. 1

            Wow, I touched a few nerves in this thread! Apologies.

            I was making a rather sweeping statement about us developers putting power and control over how we work in the hands of large companies that we know for a fact don’t have our best interests at heart.

            I can’t fault any individual instance of this - I assume that the PHP maintainers weighed up their options and chose this path as it offers real benefits. But do think that as a group we can focus too much of short term benefits of “just let Microsoft/Google/Amazon deal with it” and not think about how this shifts power about.

            1. 0

              It’s a worthwhile question certainly. But like many collective action problems (What makes sense for the individual may not make sense for the group) it is hard to solve. Do you have suggestions in regards to possible ways forward?

              1. 1

                Distributing repositories using Bittorrent, ala Gittorrent, seemed like a reasonable Idea to me. I wouldn’t endorse all of the blockchain-related addons, but the core idea of grabbing source directly from upstream developers seemed pretty solid. Gittorrent itself seems to be merely a proof of the concept, but I’m sure that it could be made production-worthy.

          2. 8

            There’s no risk here. Microsoft could delete github tomorrow afternoon and all other clones of the repos will still exist. That’s git’s best feature. But until the beancounters inevitably ruin Github in order to get their billion back, the PHP developers no longer have to distract themselves from working on PHP, which they care about, with maintaining git infrastructure, which they almost certainly do not.

            1. 4

              Please expand on the previous iterations of this mistake. It’s not obvious to me this is a mistake.

              1. 3

                I made the mistake of making a very general statement in reply to a specific instance of something, so apologies!

                My reply to zaphar covers it, but in brief: we sacrifice power and control over how we work for short term gain more often than I think we should.

                1. 2

                  It’s a very common problem for open source projects, and it gets worse the bigger you get. On the one hand the main committers usually aren’t interested in or well-versed in administering infra as their first prio, so you need volunteers. If you get volunteers you need to trust them because maintaining the infra is a nice attack vector, which in turn often makes them wary of delegating it.

                  I’m more and more coming to the conclusion that it’s best to use your first funding money to pay for infra if you can’t get it for free (in a managed state, like Github).

                  1. [Comment removed by author]

                    1. 3

                      I think that @lim did read the sentence, but is upset that the PHP project is moving to GitHub instead of (presumably) tightening up security on their own git hosting.

                  2. 2

                    Solution of this problem is using cryptographic signatures (e.g. GPG in Mercurial or Git or built cryptography in Monotone), not changing the hosting.

                    1. 11

                      Is it really a solution? as far as i understand it, signatures confirm that you did the commit, but doesn’t prevent someone else that can bypass server authentication to commit in your name an unsigned commit. they would need to add some sort of extra process to verify the format of the commits to comply with those rules, and then we are back again on the point that resources for maintaining the server infrastructure is what they lack

                      1. 1

                        Yeah, but if everybody signed their commits, it would make it easy to audit. Any commit without GPG would become suspicious.

                        1. 1

                          asking developers to also verify every GPG signature wouldn’t add much I’d say (because if you are going to be suspicious, you also have to verify each signature, not only the presence). in this case people were reviewing and complaining about the suspicious code a couple of hours after commit.

                          if authentication can’t be done automatically, i think it’s better in this case to move it into a trusted third-party (at least until they can provide their own secure server). PHP is a high value target, under limited resources I’d prefer they focus on the source itself (not saying they should disregard this issue, of course)

                    2. 1

                      It is worrying that PHP is having trouble securing their infra (PEAR was compromised a while back too), many users still download from various php.net servers for source tarballs and PECL. I can’t tell if that’s been addressed.

                      1. 2

                        Speaking as a PHP extension developer (I guess I need a hat now), a lot of the PHP infra is home-grown and…. crufty. Sometimes it’s old, but it fits the project fine and it’d be hard to find better alternatives (i.e the bug tracker), sometimes it’s just a bit rickety.