Merge ~pappacena/launchpad:create-mp-refs into launchpad:master

How does this interact with privacy?

wgrant, good point.

When a user opens a MP#1 targeting RepositoryX's master, for example, RepositoryX itself will have a read-only ref called `refs/merge/1/head`. The idea is that whomever is responsible for RepositoryX will have an easier way to pull locally the changes introduced by MP#1.

Let's assume a RepositoryX is private. In theory, nothing changes for the user opening the MP#1: the privacy checks and requirements to actually open a new MP targeting RepositoryX are still the same.

The only extra security check introduced on RepositoryX will be on Turnip side, to block pushes to `refs/merge/...` namespace: https://code.launchpad.net/~pappacena/turnip/+git/turnip/+merge/390620.

Do you see any specific privacy problem with this scenario?

On 12/9/20 12:38 am, Thiago F. Pappacena wrote:
> wgrant, good point.
>
> When a user opens a MP#1 targeting RepositoryX's master, for example, RepositoryX itself will have a read-only ref called `refs/merge/1/head`. The idea is that whomever is responsible for RepositoryX will have an easier way to pull locally the changes introduced by MP#1.
>
> Let's assume a RepositoryX is private. In theory, nothing changes for the user opening the MP#1: the privacy checks and requirements to actually open a new MP targeting RepositoryX are still the same.
>
> The only extra security check introduced on RepositoryX will be on Turnip side, to block pushes to `refs/merge/...` namespace: https://code.launchpad.net/~pappacena/turnip/+git/turnip/+merge/390620.
>
> Do you see any specific privacy problem with this scenario?

The problem arises when the *source* repository is private. Consider,
for example, a security fix MP: a user can only view an MP if they can
see both the source and target branches. But this will let anyone who
can see the target repository examine the code in the MP from a
potentially invisible private branch.

wgrant, got it.

I guess we have 2 options in this case:

1- We don't add at all the the `refs/merge/<xxx>` if the source repository is private; or
2- We do extra permission checks on refs on Turnip on every operation, and not only pushes as it seems to be implemented today.

The first option brings some complexity in terms of changing a repository to/from private after the virtual ref is already created, but is simple to implement.

I prefer the second option, as it seems cleaner and better for the long term IMHO, although it might require (a small) extra implementation effort now.

Any thoughts on this?

Just to keep the record, it turn out that filtering git fetches is not that trivial, since there is no hook for that anymore (http://git.661346.n2.nabble.com/Removal-of-post-upload-hook-td4394312.html).

We will handle private repositories the following way:

1- When opening the MP, if the source is a different private repository, the virtual ref will not be created;
2- When opening the MP, if the source is the same repository (regardless of being private or not), we will create the virtual ref;
3- When opening the MP, if the owner of the source repository is the same as the owner of the target repository, we will creat ethe virtual ref
4- When privacy or the owner of a repository changes, we need to run a job to check again the above conditions and make sure that the virtual ref is created/deleted accordingly

I'll split in some MPs just to make the review easier (this MP is already a bit too big), but I guess all of these rules should be landed at once.

The MP with the job that should re-sync the virtual refs is here: https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/390940.

As said before, they are splitted just to make the review process easier, but the functionality should only be landed once both MPs are ready to be landed together.

Also please set a commit message.

Strange that the commit message is empty. I'm adding it now.

Pushed the requested changes. There are a few comments that may worth checking, cjwatson.