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

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.

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 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).

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, 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.

@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/

Squid added a subscriber: Squid.Sep 11 2019, 7:09 PM

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

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

d3vid added a comment.Mon, Sep 16, 4:06 PM

@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 :)

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.

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.

Add Comment