[prev in list] [next in list] [prev in thread] [next in thread]
List: nix-dev
Subject: [Nix-dev] Proposal: adding fetchapt support to nixpkgs
From: Chuan-kai Lin <chklin () gmail ! com>
Date: 2016-10-25 4:42:28
Message-ID: CAJjFYLbwN3ecrbwNFGu8zeEyFwhdWJ5=EsU9SEA0TdN-PB=YWw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<div dir="ltr">I have been thinking about adding Debian-package-fetching \
functionality (tentatively named fetchapt) into nixpkgs, and I'd like to hear \
your thoughts.<div><br></div><div>First, why would anyone want such a \
thing?</div><div><br></div><div>Nixpkgs retrieves some unfree software (e.g., \
google-chrome) through binary packages in Debian packaging format, through vendor \
repositories (e.g., <a href="http://dl.google.com">dl.google.com</a>). 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.</div><div><br></div><div>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.</div><div><br></div><div>Adding support for fetching binary packages in \
Debian format from an APT repository would solve this problem. I envision that a \
nixpkg would specify:</div><div>- the APT repository base URL</div><div>- the release \
name (e.g., stable, testing, or unstable),</div><div>- the binary package \
name,</div><div>- repository signing key (for repositories that implement secure APT, \
<a href="https://wiki.debian.org/SecureApt">https://wiki.debian.org/SecureApt</a>).</div><div><br></div><div>And \
the fetchapt derivation would:</div><div>- Fetch Release and Release.gpg files from \
the repository</div><div>- Verify digital signature</div><div>- Fetch Packages \
file</div><div>- Check hash value of Packages file against the hash value listed in \
Release file</div><div>- Extract binary package path that correspond to the given \
package name from Packages file</div><div>- Fetch the binary package</div><div>- \
Check hash value of binary package against the hash value listed in Packages \
file</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Thanks, \
and looking forward to hear your \
thoughts.</div><div><br></div><div>Chuan-kai</div><div><br></div></div>
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic