Page MenuHomePureOS Tracker
Create Task
Maniphest T421

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

Description

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 https://example.com, 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.

Event Timeline

d3vid created this task.May 10 2018, 08:03
d3vid renamed this task from Packages with hardcoded references to external download sources to Need a reference document for packages with external sources.May 16 2018, 05:06
d3vid updated 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 https://example.com

    $ 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

Notes:

  • 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).
sean.obrien added a subscriber: sean.obrien.Oct 11 2018, 16:27

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.Aug 1 2019, 09:09
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.

d3vid added a comment.Sep 11 2019, 04:40

@jeremiah.foster There was a time when we were concerned about including tools like pip [1] in PureOS. My understanding is that we have since decided this is not a grave or urgent concern, but we would still prefer to issue a warning when the user installs a tool like this.

$ sudo apt install python-pip
... # installation details
After this operation, 58.3 MB of additional disk space will be used.

WARNING: This tool can be used to install software from outside PureOS. Use at your own risk. Do you want to continue? [Y/n]

...a warning is also much easier to implement than convincing multiple upstreams to adopt a foreign design pattern. ;)

[1] https://pypi.org/project/pip/

jonas.smedegaard added a comment.Sep 12 2019, 11:43

@d3vid Interesting idea. We might use a similar approach as Debian package debian-security-support.

jonas.smedegaard added a comment.Sep 12 2019, 11:44

To test, try install debian-security-support and afterwards binutils.

d3vid added a comment.Sep 16 2019, 09:06

@jonas.smedegaard I'm sure it was your idea :D

I already have binutils, so I got a friendly warning when I installed debian-security-support from the command line. Great!

I did not get any warning when I tried again from the Packages GUI. Not so great, but low priority since it will probably by pre-installed.

I don't want to / can't uninstall binutils to test the first-time UX from the command line and Software GUI. How can I find out what other packages are on the warning list?

But the principle looks sound to me :)

jonas.smedegaard added a comment.Sep 16 2019, 10:23

It might be documented, but since I am lousy at reading documentation here's how I'd figure it out:

First, check what was included in the package: dpkg -L debian-security-support

Skimming through those files, one sticks out to me as potentially essential: /usr/share/debian-security-support/security-support-ended - so check that: less /usr/share/debian-security-support/security-support-ended
Hmm, possibly it was a good guess but we are too early in this release to have anything there.

...so how about this: less /usr/share/debian-security-support/security-support-limited
Bingo! Looks like you got a list of packages to toy with there.

jonas.smedegaard added a comment.Sep 16 2019, 10:31

As for user notification, I suggest borrowing from how needrestart does it: Provide a purpose-specific GUI as a separate binary package, and have core package suggest either that or libnotify-bin, where the latter spews simpler notifications.