Copr security

[fingonfingon (S F)]

Are there some recommended security precautions when installing packages from Copr? Like AUR - it’s recommended to check the PKGBUILD file for the source used or if there is some suspicious bash command. Copr seems more complicated.

[barryascott]

In a secure environment I would never install from copr.

There are few checks on what gets into copr, which is a feature, and I use it all the time.

At work we would maintain the packaging ourselves.

[augenauf (Flo)]

I think the explanation on User Documentation — COPR documentation answers the question.

Is it safe to use Copr? ¶

This is a two-part question.

1. Can we trust Copr as a platform?

Copr is free software with its code publicly available for review by anyone. Internally, it uses the standard Fedora packaging toolset, and resulting repositories are signed. All Copr servers are deployed within Fedora infrastructure, and we work closely with the Fedora Infrastructure team.

2. Can we trust the software available in Copr?

Only people with FAS accounts are allowed to create projects and build packages in Copr. That means that you can find out more information about each project owner and decide for yourself whether you find them trustworthy or not. You can also see how exactly each build was submitted, download its SRPM file, and validate the sources and spec file for yourself.

[jn64 (Justin Koh)]

The main difference from AUR is that packages are built on Copr. With AUR, you only download a PKGBUILD, then build the package locally. With Copr, you not only have to trust the package source, you also have to trust Copr infrastructure (which is Fedora infra). Presumably you already trust it to use Fedora. So I will explain how to check the source, which is indeed a bit more complicated than AUR.

Overview of Copr

• Any Fedora user (foo) can create Copr projects (foo/bar). When end users talk about “a Copr” or “repo” they mean this project. e.g. “the phracek/PyCharm repo”
• Each project technically has separate repos representing each distro/version/architecture (e.g. fedora-38-x86_64, rhel-8-aarch64), since the builds are different
• Each project can have multiple packages
• Packages can be built from various sources e.g. git URLs, URLs to spec files or SRPMs, or direct uploads of spec files or SRPMs.

Checking a build down to the SRPM

Using one of my packages as an example:

• jn64/treesheets is the project.
• This project has only one package, also called treesheets
• On this package, you can see the default build source is pointing to my git repo somewhere. Looking at this is not enough; I can change the source at any time, and of course you don’t know the contents at the specific point in time of any build.
• Now look at the latest build 6167866. Here you can see the actual source at build time, which matches the default source because it’s an automatic build, but this is not always the case; I can easily make a build pointing to another source or from a direct upload. It does give a specific “Committish” which is good, you can cross reference it in my source repo.
• But the real thing you need to check is inside one of the chroots of the build, e.g. the fedora-38-x86_64 chroot of build 6167866. Here you can find the SRPM (source rpm) named *.src.rpm. The SRPM contains the spec file and any sources/patches used. If you trust the Copr/Fedora infrastructure, then this SRPM tells you everything you need to know about the final RPM. You can also find build logs and other misc artefacts here.

Do any end users check this? I wouldn’t bet on 0.1% of users doing this once, much less doing it for every single update of every Copr package they use.

Is this excessive / paranoid? Maybe, but Copr updates have no oversight unlike Fedora updates, where you trust that packagers have some reputation, there are certain update processes to follow, and many more eyeballs on each update (even though a lot of packages are still under-tested! Contribute to testing if you can).

So unless you absolutely trust the Copr owner, and trust that they or their machines will never be compromised, you might want to look at a build once in a while.

Additional points

• Copr owners can do whatever they want. On AUR, you’re collaborating on one PKGBUILD (there is only one bar); if the maintainer tries to add something stupid, you report it, it gets reverted by an Arch Trusted User, or at least you can make a lot of noise in the comments. On Copr, the user “owns” their project (foo/bar), they can add stupid things as long as it doesn’t break the few rules and Fedora legal restrictions. If you don’t like it, don’t use it (or fork it).

• Due to the above, there’s basically 0 guarantee of correctness. Packages can be wrong. They can install the wrong files, install files to the wrong place, with the wrong permissions, have the wrong version. There can be multiple different builds with the same version number, which results in undefined behaviour when you try to install a package. Packages can be deleted and replaced with another package of the same name/version.

  dnf protects you to some extent by preventing you from installing packages with conflicting files.

• Package managers use version/release numbers, they don’t know anything about build numbers which are a Copr detail. If a newer build on Copr has a lower version number, that’s not the package you get when you dnf install ...

• Some owners create 1 project per package. IMO this is better for end users to only install what they want and gives more peace of mind.

  On the other hand, some owners create 1 project with many packages. This does not indicate anything malicious, but you have to be more careful that packages aren’t unintentionally replaced by the repo. e.g. you added the repo because you wanted baz, but they also build qux which is a higher version than Fedora’s qux, and will replace your qux when you update.

  This isn’t a Copr problem. I’ve had to remind a “professional” third-party repo (not RPM Fusion) to make sure they don’t accidentally replace dozens of Fedora packages.

  To mitigate this you can set specific includepkgs or excludepkgs in the Copr’s repo file in /etc/yum.repos.d (e.g. only include baz from that repo). See man dnf.conf.

  dnf does tell you what repo a package is from when you install/update, but it’s easy to develop “banner blindness” or hit y without checking (or worse, I see many users do dnf upgrade -y).

• You can always disable a Copr repo after installing from it. You won’t get updates, but depending on the type of software (some old utility that never gets updated, or a small non-networked game) that might be an acceptable risk compared to leaving the repo enabled and potentially introducing unwanted packages.