Anelok: revisiting the migration from gitorious

Werner Almesberger werner at
Sun Mar 29 15:13:43 UTC 2015

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

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.


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.


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

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. gives an "A+"
rating while gets "A-". Interestingly, 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
- AND you don't have an easier way to get at the precious, or the

(*) 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

More information about the discussion mailing list