[Nix-dev] Proposal: adding fetchapt support to nixpkgs

[Chuan-kai Lin]

I have been thinking about adding Debian-package-fetching functionality
(tentatively named fetchapt) into nixpkgs, and I'd like to hear your
thoughts.

First, why would anyone want such a thing?

Nixpkgs retrieves some unfree software (e.g., google-chrome) through binary
packages in Debian packaging format, through vendor repositories (e.g.,
dl.google.com).  Currently, retrieving the binary packages involves
manually specifying package version number and hash value in a nixpkg.
This approach has a few advantages; for example, users can look at nixpkg
and determine exactly which version of the software is being installed.
Also, nixpkg can verify use the hash value to confirm that the binary
package has not been tempered with.

This approach also has a major downside.  Someone needs to update the
version number and hash value manually every time there is a new release.
Which can be a lot of work for software with frequent releases, like
Chrome.  Right now, the stable version for Chrome Linux is 54.0.2840.71,
and nixpkg is still pinned to 53.0.2785.143, which is one major version
(and ~20 security vulnerabilities) behind.  And the ability to pin software
to a specific version is not all that useful here.  Once the vendor makes a
new release, the old version may no longer be available in the vendor
repository.  And users expect to be able to install new versions when they
become available without having to wait one of the (wonderful) Nix devs to
update some strings somewhere.

Adding support for fetching binary packages in Debian format from an APT
repository would solve this problem.  I envision that a nixpkg would
specify:
- the APT repository base URL
- the release name (e.g., stable, testing, or unstable),
- the binary package name,
- repository signing key (for repositories that implement secure APT,
https://wiki.debian.org/SecureApt).

And the fetchapt derivation would:
- Fetch Release and Release.gpg files from the repository
- Verify digital signature
- Fetch Packages file
- Check hash value of Packages file against the hash value listed in
Release file
- Extract binary package path that correspond to the given package name
from Packages file
- Fetch the binary package
- Check hash value of binary package against the hash value listed in
Packages file

So nixpkg will automatically follow upstream vendor releases without any
action from Nix devs.  Even though nixpkg does not directly contain a hash
value of the binary package, secure APT will provide strong assurance that
users are receiving a binary package exactly as provided by the vendor.

Anyway, that is my proposal.  Does that sound like a reasonable thing to
do?  How would such a functionality fit into nixpkgs?  Any advise or
suggestions on design and implementation?

Thanks, and looking forward to hear your thoughts.

Chuan-kai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20161025/24f9b3e8/attachment-0001.html>