Re: [Tails-project] Questions about the GitLab migration[W…

Hi,

u:
> On 28.11.19 10:56, intrigeri wrote:
>> u:
>>> - What will happen to our encrypted repositories?
>>
>> Formally speaking, wrt. Git repositories, the scope of this GitLab
>> migration project is restricted to public ones, so private
>> repositories (be them encrypted or not) are not supposed to be
>> migrated initially.
>>
>> The way I see it, migrating private repositories would require
>> a dedicated discussion (even if we leave them end-to-end encrypted),
>> which personally I'd rather postpone, in order to focus for the time
>> being on the various other — potentially complicated — discussions
>> this GitLab migration will require.

> I guess my question relies on an unknown: Would that work technically,
> to leave them end-to-end encrypted and migrate them to one of the three
> Gitlab instances that you started discussing with?

As I understand how git-remote-gcrypt works, it's a proper end-to-end
encryption thing that does not require anything special from the Git
server. This being said, I did not try that git-remote-gcrypt works on
GitLab in practice. And I don't know if git-remote-gcrypt has ever
been audited, which is one of the reasons why I'd rather not dive into
the "can/should we migrate encrypted repos to GitLab?" topic as part
of this migration.

>>> - Will the Gitlab instance only be used for tickets related to encrypted
>>> repositories? How do we guaruantee confidentiality for those? What
>>> other solutions might there be?
>>
>> I don't understand your first question as-is, but I can make sense of
>> it if I ignore "only" in this sentence. Should I?

> I think this relates to the question above.

> I'll give you an example, to clarify. At some point you had the idea to
> migrate the fundraising repository to a Gitlab instance. This repository
> is currently end-to-end encrypted. If we would migrate this repository,
> would the Gitlab instance then only be used for handling tickets related
> to fundraising.git as Gitlab would not be able to read the contents of
> this repository?

Thanks, now I understand! :)

*If* we decided to migrate the Fundraising team repository to GitLab,
while keeping it end-to-end encrypted, then indeed, GitLab would not
have access to the content of that Git repo, as long as the
encryption works.

Does this clarify things for you?


Now, as part of this migration, GitLab will have access to
confidential issues, including the Fundraising ones, as this project
is about migrating all our issues to GitLab. So, about issues:

> And if we have tickets containing confidential information on
> a Gitlab instance, how do we guarantee their contents stays
> confidential? (There might be payment information in it, or similar
> quite personal details.)

I don't think it's realistic to _guarantee_ any such thing for content
stored in a web application exposed on the Internet and whose job is
to intensively handle untrusted input data. Less theoretically:
I don't think such a promise would be realistic with GitLab, and
I don't think it would be realistic to promise any such thing with our
current Redmine setup either.

The best we can do is to mitigate risks.

Are we in agreement so far?

For example, IMO we must:

- Have this concern in mind when choosing the GitLab instance
we'll use.

Quite a few of the criteria that came out of the brainstorming on
this thread are about trust in people and in infrastructure.
So it's clear to me that it matters a lot to us.

- Ensure teams who handle confidential data are aware of the risks.

I'm afraid the status quo is sub-optimal in this respect.
Regardless of the migration to GitLab, it would be smart if these
teams did better. Still, AFAICT, even perhaps without an accurate
understanding of the risks, it seems to me that these teams do
a rather good job already at not putting super sensitive info into
web apps (Redmine).

I think it's the responsibility of our sysadmins (for Redmine) and
of the folks who are doing the migration to GitLab to communicate
about these risks, and then it's the responsibility of the teams
who handle confidential data to take this information into account
and equip themselves with adequate habits, policies, and if needed,
tooling. Ideally, the people whose personal data is handled by
these teams would have the possibility to exercise some oversight
over such policies, which they could do unless they are happy to
keep blindly trusting those teams to act sensibly.

Does this make sense to you?

While we're at it, any other ideas, or different approaches anyone
thinks we should consider?

>> Do you have specific desires, concerns, or fears about this relation?

> My only concern is to clearly document the changes and new expectations
> somewhere. ?eople who currently use the repositories could receive an
> email pointing them specifically to this documentation, in order to
> guarantee that everyone is aware of the changes of habit this might imply.

I can only agree on this (and I'm under the impression that we've done
this quite consistently when rolling out such big changes to
production in the past).

Additionally, on top of documenting how one would clone a repo from
scratch, it's nice to also explain in that email how to adjust the
configuration of an existing repo.

Cheers,
--
intrigeri