The directories that namespace Pull Request builds are clashing with each other

Original issue: https://pagure.io/copr/copr/issue/767 Opened: 2019-05-28 20:31:31 Opened by: churchyard

Consider one copr that adds 2 SCM packages like this:

$ for pkg in package1 package2; do copr edit-package-scm --clone-url https://src.fedoraproject.org/rpms/ ${pkg}.git --name ${pkg} --webhook-rebuild on --commit master $(whoami)/example; done

Now in Fedora, somebody opens a pull request (possibly malicious) on package1. It's a first pull request, so it is going to be at:

https://src.fedoraproject.org/rpms/package1/pull-request/1

The triggered build will end up in the example: pr:1 "directory" (due to pagure bug, the directory name is not displayed correctly here so I've inserted a space into it, please try to ignore it).

Later, somebody opens a pull request on package2. It's a first pull request, so it is going to be at:

https://src.fedoraproject.org/rpms/package2/pull-request/1

The triggered build will end up in the example: pr:1 "directory" as well ~~seeing the (possibly malicious) build of package1~~. Users installing the repo will get both builds.

This directory now has at last two different packages in it.

This is mostly an UX bug, but if stretched, it can be considered a security issue as well.

praiskup commented at 2019-05-29 07:32:45:

I think we should implement per-package integration (not per project), I claimed this is needed since beginning - so +1.

Reference to thread that triggered this issue: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org/thread/26ZXCMM5BNIFXLUVQ6JVEIAVUCM7VSZX/

The triggered build will end up in the example: pr:1 "directory" seeing the (possibly malicious) build of package1.

Fortunately build of package 2 doesn't see the package 1, because the pr:1 directory is not in list of repositories used for the build of those packages.

This is mostly an UX bug, but if stretched, it can be considered a security issue as well.

At least content of package 1 should not affect content of package 2. But dnf copr enable project:pr:1 would bring both packages, and that is usually not wanted.

churchyard commented at 2019-06-03 15:00:08:

(I don't think this is an RFE.)

praiskup commented at 2019-06-03 15:14:46:

It is a matter of POV; and I need to discuss this on our meeting. We could add opt-in/opt-out per-package copr-dir separation, something like project:pkg:pr:id - that would be RFE. It's not a bug per original design, at least because I know the original decisions..

The issue itself is not security related.

fedora-copr / copr