I'm still trying to make up my mind whether Anelok's new home shall be GitHub or GitLab. I looked for side-by-side comparisons, and they all suggest that there's virtually no difference in terms of functionality.
Those who chose GitLab over GitHub usually did so because they needed private (i.e., without public access) repos and GitHub (where you have to pay for any private repos) was getting too expensive. Virtually all who mention GitLab are running a local version, be it for the cost issue or be it just because they don't want to depend on a third party for the service. Examples: http://www.quora.com/How-much-of-threat-is-Gitlab-to-GitHub-Enterprise http://www.quora.com/What-are-some-major-differences-between-GitHub-and-GitLab-when-comparing-each-others-features-for-private-repositories http://thenextweb.com/apps/2011/10/13/ship-it-faster-and-cheaper-gitlab-is-github-for-your-own-servers/ Those who chose GitHub over GitLab usually did so because they found that running their local installation and keeping up with the frequent updates was too much of an effort. Example: http://www.boxuk.com/blog/a-tale-of-three-git-systems/ For Anelok, running a local copy is not on the radar at the moment. Instead, a reliable - both in terms of day to day operation as in the longer-term viability - "cloud" service is important. I'm still uncertain which of the two is the safer choice there. Risks would include them folding, stopping the free service, in other ways radically changing their business model, or doing something else we'd consider unbearable. GitHub would certainly have sheer inertia on its side. The Anelok project doesn't need any private repos at the moment but once a company is created for it, it is likely to require a place for keeping confidential material (could be code, but there is also financial and other operational data, customer information, contracts, etc.) The prying eyes such repos should be hidden from would almost certainly include those of GitHub or GitLab, or the spies who watch over them. In that situation, a solution that can be installed locally would be necessary, and the operational overhead this causes would have to be accepted. However, even if Anelok has a public and a private side one day, the two don't have to use the same infrastructure. E.g., one can set up a bare-bones private repo just with git and SSH. Such simplicity may even be desirable for security reasons. But should we wish for a more lavish environment, it can't hurt if it is already familiar. So having this option would be a point in favour of GitLab. Would there be a difference for occasional users, such as Anelok owners who for some reason want to access material in a repo ? Things to consider include malicious content provided by the cloud site, tampering the commits, tracking of users. Both services are ad-free, so that channel for uncontrolled nasty content doesn't exist. Another way would be infiltrate their site and place malicious content. I have no idea how their site security history compares. Git itself should help defend again such tampering, at least unless the enemy has the ability to create a file B with malicious content, given a non-malicious (but possibly conditioned for the attack, e.g., by contributing innocuous-looking code) file A, such that sha1(A) == sha1(B). Not sure what criteria to apply regarding tracking. GitLab and GitHub both use HTTPS, so fine-grained tracking requires access to the keys. https://www.ssllabs.com/ssltest/ gives github.com an "A+" rating while gitlab.com gets "A-". Interestingly, gitlab.com seems to run on Amazon AWS ("A" rating), which probably means that GitLab is vulnerable to governmental arm-twisting from more sides. But does this even make a practical difference ? I could imagine some targeted attacks based on such tracking information, but they all seem a bit far-fetched, as in: - you are after someone's precious (secrets, acces, ...), the keys to which are stored in Anelok, - AND you find out about an exploitable vulnerability in some version of the Anelok firmware, - AND you know (from the tracking) whether that person has pulled this version, - AND you know that this person is therefore (*) likely to be running said version on an Anelok containing the keys, - AND your prospective victim either doesn't know about the vulnerability, or at least hasn't taken corrective actions (yet), - AND you can execute a suitable hit (steal the device or whatever it takes to exploit the vulnerability) on the victim within that window of opportunity, - AND the hit is of a nature that doesn't allow it to be easily repeated (other wise you wouldn't have to time the attack), - AND the victim isn't able to deny you the benefits of your elaborate attack, - AND you don't have an easier way to get at the precious, or the keys. (*) The "therefore" is important. If you'd already know without tracking that the device in question probably has the vulnerability, you don't need the tracking. So all this is inconclusive. "Da steh ich nun, ich armer Tor, und bin so klug als wie zuvor." -- Goethe (Faust) "To Hub or to Lab, that is the question." -- with apologies to Shakespeare and Hamlet Any suggestions for criteria that I have overlooked, that could tip the scale ? - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
