Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Restrict apt to specific Jessie distro

36 views
Skip to first unread message

Brendan Simon

unread,
Feb 13, 2016, 6:20:05 AM2/13/16
to
Hi,

Is there a way to restrict apt to a **specific release** of Jessie.  e.g. 8.1, 8.2, 8.3, ... ??

I build root filesystems for embedded systems.  The sources.list is set to Jessie, but the contents of the generated rootfs can change from one day to the next if there have been updates.  I want to lock into a specific release and be sure that the packages wont change if I build now and 6 or 12 months later.

What's the best way to do this?

Thanks,
Brendan.

Christian Seiler

unread,
Feb 13, 2016, 9:00:05 AM2/13/16
to
Hi,
So first of all: you shouldn't do this. Updates happen for a reason
and you should note that point releases not only contain bugfixes
but also security updates that are folded into them. If you
construct images in that way, this will be problematic.

Note that Debian's release team is very strict about what kind of
updates are allowed in stable releases [1] and each non-security
change is reviewed by them - and sometimes changes are rejected.
Some people (myself included) have -proposed-updates in their
sources.list to get these updates early and report any potential
problems. Security updates (which are also folded into point
releases) are checked by the security team before releasing them.

If you *really*, *really* want to do that against better judgment,
you can use the http://snapshot.debian.org/ service. See the
instructions there, just pick the current date. And realize that
you are using old versions of software with potential security
problems. (Even worse, since at least for me snapshot.d.o doesn't
support https, and you have to disable Valid-Until in APT to make
it work, an attacker in your network with man-in-the-middle
capabilities could serve you versions of Jessie that are even
older than the ones you want, which have more security problems
and you wouldn't really notice it, especially if you automate your
process.)

Regards,
Christian

[1] There are very few exceptions here. I don't think you're using
e.g. Chromium on your embedded system, right? ;-)

signature.asc

Richard Hector

unread,
Feb 13, 2016, 3:10:07 PM2/13/16
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 14/02/16 00:12, Brendan Simon wrote:
> Hi,
>
> Is there a way to restrict apt to a **specific release** of Jessie.
> e.g. 8.1, 8.2, 8.3, ... ??
>
> I build root filesystems for embedded systems. The sources.list is
> set to Jessie, but the contents of the generated rootfs can change
> from one day to the next if there have been updates. I want to
> lock into a specific release and be sure that the packages wont
> change if I build now and 6 or 12 months later.

If I wanted guaranteed repeatability, I'd be tempted to maintain my
own mirror, that was only updated manually. But as Christian says, you
need to be careful about what updates you're missing.

Richard


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWv4l1AAoJELSi8I/scBaNbokH/2NjZFte+rUy2OMFhUNqAyKr
4T2jWfmICQMzjJNGp7Pk75kZbIDmjbjyaTuyCFXV6vhoax9Q8leP0U1j6mnQKffq
8MqEhMNKCSWKi/Rmg+wwBrLYvCclrGvYq9kJAxQl49bphQHdfXsaGjRUn+rYvduA
YPSaaZPSFLpCkvzMUpgKExzdCRQZgOUmIag3fB9EwzrCxBmDvFC0FYRC54GSVLmp
ieOQlyVuzogw70eGSzmvYXe9lGTGofRq9BSfXAQmBu76IdD4A1fkerdubiJ0GHfM
ST9QALK0jrqOo5ConauGFk1Pb73826KtNjOwawlZhLx/7/YvwXJMXZ8YyFBS+8k=
=WLG8
-----END PGP SIGNATURE-----

Brendan Simon (eTRIX)

unread,
Feb 14, 2016, 6:30:07 AM2/14/16
to
On 14/02/2016 12:07 AM, Andrew M.A. Cater wrote:
Short answer: No, if you ever want security updates / other fixes.

Longer answer: not by design. Mirror 8.4 on the day of release, get the DVDs / build a Blu-Ray .iso using jigdo
and use these for hoever long.

Jessie is Debian 8 - so all changes to Debian 8 apply through the lifetimme of the release. 

Point releases are snapshots rolling up security fixes etc. to that point. You don't _need_ them if you keep
systems up to date.

In general, locking to a specific point in time / a "golden image" and using it for a period would be a bad
move because of the fact that the release receives fixes.

Sizes shouldn't change that drastically - in general, packages replace their predecesors precisely so net
change is of the order of kB.

Hope this helps

AndyC

Thanks Andy.  I guess the DVDs might be the way to go.

The thing is when you are deploying something to lots of sites (e.g. an embedded data logger in many remote locations), it's important to know exactly what versions you have created and installed, and more importantly be able to rebuild the exact same system sometime down the track.  e.g. 6-12 months later, when bug is reported and you need to be able to replicate the build and make changes based on that build.  Often a patch release will be deployed based on the a build from that point in time, so as to not introduce any "new features" or unknown changes in behaviour.

Thanks, Brendan.

Brendan Simon (eTRIX)

unread,
Feb 14, 2016, 6:40:05 AM2/14/16
to
On 14/02/2016 12:49 AM, Christian Seiler wrote:
On 02/13/2016 12:12 PM, Brendan Simon wrote:
Is there a way to restrict apt to a **specific release** of Jessie. 
e.g. 8.1, 8.2, 8.3, ... ??

I build root filesystems for embedded systems.  The sources.list is set
to Jessie, but the contents of the generated rootfs can change from one
day to the next if there have been updates.  I want to lock into a
specific release and be sure that the packages wont change if I build
now and 6 or 12 months later.

What's the best way to do this?
If you *really*, *really* want to do that against better judgment,
you can use the http://snapshot.debian.org/ service. See the
instructions there, just pick the current date. And realize that
you are using old versions of software with potential security
problems. (Even worse, since at least for me snapshot.d.o doesn't
support https, and you have to disable Valid-Until in APT to make
it work, an attacker in your network with man-in-the-middle
capabilities could serve you versions of Jessie that are even 
older than the ones you want, which have more security problems
and you wouldn't really notice it, especially if you automate your
process.)

Regards,
Christian

Thanks Christian.  I've had a quick look at snapshot.debian.org and it might be worth considering.


The thing is when you are deploying something to lots of sites (e.g. an embedded data logger in many remote locations), it's important to know exactly what versions you have created and installed, and more importantly be able to rebuild the exact same system sometime down the track.  e.g. 6-12 months later, when bug is reported and you need to be able to replicate the build and make changes based on that build.  Often a patch release will be deployed based on the a build from that point in time, so as to not introduce any "new features" or unknown changes in behaviour.

Specifying a date in the apt sources.list may achieve that, but locking in the versions to that date or earlier.  Subsequent security release based updates can be achieved by updating the date at a controlled time, doing a build, testing thoroughly and then releasing.

Does apt not use keyrings or some kind of certificates for authenticating versions?

Thanks, Brendan.


Christian Seiler

unread,
Feb 14, 2016, 8:20:06 AM2/14/16
to
On 02/14/2016 12:16 PM, Brendan Simon (eTRIX) wrote:
> The thing is when you are deploying something to lots of sites (e.g. an
> embedded data logger in many remote locations), it's important to know
> exactly what versions you have created and installed, and more
> importantly be able to rebuild the exact same system sometime down the
> track. e.g. 6-12 months later, when bug is reported and you need to be
> able to replicate the build and make changes based on that build.

So if you just want to exactly reproduce something, then using
snapshot.d.o is actually the right thing to do. The Debian
reproducible builds effort [1] actually uses that service to be
able to reproduce the same build environment for a given package.

If you want to make sure that you exactly get the right package
versions, you could do the following:

- Use snapshot.d.o in your sources.list and put in the current
date
- Once you created a system you later want to reproduce, do the
following:
printf "Depends: "
dpkg-query -f 'ST<${db:Status-Abbrev}>${binary:Package} (= ${Version}), ' -W | \
sed 's%ST<[^i][^>]*>[^,]*, %%g;s%ST<[^>]*>%%g;s%, $%%'
printf '\n'
That will record all installed packages with their version in
the format Debian packages use for their dependencies.
- Create a fake binary package with that dependency information
(see [1])

To reproduce the image:

- Use the same date for snapshot.d.o
- debootstrap a minimal system
- install aptitude in there
- force-install the package via
dpkg --force-depends --force-conflicts \
-i force-package-versions-dummy.deb
- tell aptitude to resolve dependencies while keeping the dummy
package:
aptitude -y -o APT::Install-Recommends=false \
-o Aptitude::ProblemResolver::StepScore=100 \
-o "Aptitude::ProblemResolver::Hints::KeepDummy=reject force-package-versions-dummy :UNINST" \
-o Aptitude::ProblemResolver::Keep-All-Level=55000 \
-o Aptitude::ProblemResolver::Remove-Essential-Level=maximum \
install force-package-versions-dummy
(This is stolen from pbuilder how they satisfy Build-Depends)
- if everything works out, purge the dummy package again
dpkg -P force-package-versions-dummy
- remove aptitude in case your setup doesn't include it in the
image

Then you can be sure that you have exactly the same versions installed
as the reference.

Note that after image creation you should automate trying to reproduce
them, because if you notice an issue with the method I described here
to reproduce a certain image only once you need to find a bug.

Also note that if you really use snapshot.d.o a lot, you should be a
nice citizen and have a caching proxy in front of it (you could e.g.
configure apt-cacher-ng for that [2]) so that you don't cause the
snapshot.d.o unnecessary traffic - it's not part of Debian's mirror
network.

> Does apt not use keyrings or some kind of certificates for
> authenticating versions?

APT uses GnuPG cryptographic signatures of certain aggregate files that
contain hashes of the packages. The trusted keyring can be found under
/etc/apt/trusted.gpg - and additional keyrings may be installed under
/etc/apt/trusted.gpg.d. (The latter only in recent Debian versions,
starting with Wheezy IIRC.)

For Jessie you want to look at:

gpg --no-default-keyring \
--keyring /etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg \
--keyring /etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg \
--keyring /etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg \
--list-keys

Typically, the Release files are signed:
wget http://httpredir.debian.org/debian/dists/jessie/Release
wget -O Release.asc http://httpredir.debian.org/debian/dists/jessie/Release.gpg
gpg --no-default-keyring \
--keyring /etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg \
--keyring /etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg \
--keyring /etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg \
--verify Release.asc

The 'Release' file then contains a list of MD5 and SHA256 sums of the
Packages files. For example, on amd64 there is
main/binary-amd64/Packages.gz. (The non-compressed files typically don't exist
on mirrors). So you can download that file and verify it's correct:

wget http://httpredir.debian.org/debian/dists/jessie/main/binary-amd64/Packages.gz
# Compare the output of the following two commands
# (size of the file, should be equal)
stat -c '%s' Packages.gz
grep ' main/binary-amd64/Packages.gz' Release | tail -n 1 | awk '{print $2}'
# Check the SHA256 sum:
grep ' main/binary-amd64/Packages.gz' Release | tail -n 1 | awk '{printf "%s %s\n", $1, $3}' | sed 's%main/binary-amd64/%%' > sums
sha256sum -c sums

The Packages files then contains a list of all packages with the hashes
of the .deb files.

And that's how APT verifies the authenticity of the archive.

(For things that change more often, such as security updates, there's
also a Valid-Until field, see <https://bugs.debian.org/499897>.)

Anyway, hope that helps.

Regards,
Christian

[1] e.g.
(with the output of the commands I gave you stored in a file
called /path/to/depends-line):

mkdir fpv/DEBIAN -p
cd fpv/DEBIAN
cat > control <<EOF
Package: force-package-versions-dummy
Version: 0.invalid.0
Maintainer: Your Name <your@email>
Description: Dummy package to ensure consistent package state
Architecture: all
Section: admin
Priority: required
EOF
cat /path/to/depends-line >> control
cd ../..
dpkg-deb -b fpv force-package-versions-dummy,deb

[2] e.g. add
Remap-snapshot: /snapshot ; http://snapshot.debian.org/archive/debian
Remap-snapshotsec: /snapshot-security ; http://snapshot.debian.org/archive/debian-security
to /etc/apt-cacher-ng/acng.conf
and use
http://$SERVER:3142/snapshot/20160124T041729Z/ jessie main
http://$SERVER:3142/snapshot-security/20160124T041729Z/ jessie/updates main
as the sources.list entries.

signature.asc
0 new messages