Need a reference document for packages with external sources
Open, NormalPublic


Problem statement

User story: I am an everyday user of libre software. I want to control which sources I download software from, so that I only install software from trusted sources (and don't unwittingly rely on external sources that I have not verified).

User story: I am a package maintainer for an FSDG distribution. I only provide packages that I can vouch for, so I do not want to provide packages that actively download software from external sources.

User story: I am an upstream developer, my packages relies on an external source and I have limited concern for the problem (I trust the source and expect others to do the same). I need a straightforward, high-level solution, so that I can write/review a patch that does not compromise the technical integrity of my package.

Typical problem scenario

The user is running PureOS and installs package foo from the PureOS repository:

sudo apt install foo

The foo package has its own installation function, which the user uses to install package bar:

foo install bar

However, bar is not downloaded from the PureOS repo, it is downloaded from, a hardcoded external source.

The user is now relying on an external source that they have not verified, and that the PureOS package maintainers cannot vouch for.

Prior art

  • PureOS includes apt for package installation, and points only to the trusted PureOS repository. The user is free to add additional apt sources that they trust.
  • When flatpak is first installed, you cannot install any flatpak packages. You need to add at least one source first.

Suggested solution

Provide a reference document with a high-level design pattern that resolves this problem. We can then direct upstream developers to it and/or use it ourselves to implement fixes on upstream packages.

d3vid created this task.May 10 2018, 3:03 PM
d3vid changed the title from "Packages with hardcoded references to external download sources" to "Need a reference document for packages with external sources".May 16 2018, 12:06 PM
d3vid edited the task description. (Show Details)

Rough starting point (comments welcome)

  1. Give foo one or more CRUD-like functions:
    • "add source" + "remove source"
    • "set source" (single source only, replace rather than remove)
  1. Patch foo so that there are no hardcoded external sources by default. The procedure will then become:

    $ sudo apt install foo

    $ foo install bar

    - Package "bar" not found

    $ foo addsource

    $ foo install bar

    - Package "bar" installed
  1. (Optional) Create packages for maintainer-vouched sources

    $ sudo apt install foo

    $ sudo apt install foo-vouched-source

    $ foo install bar

    - Package "bar" installed


  • It is now the user's responsibility to verify external sources before adding them.
  • Full CRUD support is not required (a minimal implementation would be a single "set source" function).
  • Support for multiple simultaneous sources is not required.
  • Adding a source could be implemented as a new command, as in the examples above, or foo could read a list of user-defined sources in a well-known location (this is the approach taken by apt).

The problem here is very nicely explained, and I agree that a reference document with a high-level design pattern we can refer to is the best solution. Let me know if there's anything I can do to move this along.

jeremiah.foster triaged this task as "Normal" priority.Thu, Aug 1, 4:09 PM
jeremiah.foster added a project: Restricted Project.
jeremiah.foster removed a subscriber: sean.obrien.
jeremiah.foster added a subscriber: jeremiah.foster.

My feeling is that we ought not permit packages or apps to download code from external sources, at least not at install time. This seems like security risk.

Add Comment