Tails

#3 Updated by intrigeri 2014-05-10 04:42:17

I personally see some value in supporting fully-offline designs and usecases (such as Cleanroom), and I trust the Guardian project to have done the research homework right.

The questions I would have are about compatibility with our existing feature-set:

1. How does apt-offline play with someone who has enabled APT lists and cache persistence in Tails?
2. How does apt-offline play with someone who is using the additional software feature of Tails’ persistence (which itself depends on the above)?

If there is any incompatibility, then what is the plan to gently prevent users from shooting themselves in the foot?

Also, does apt-offline play well with changing APT sources? (each Tails release ships with a different APT suite enabled)

To end with, it would be great to know how much installing apt-offline adds to the ISO. A good enough approximation can be found by installing it in a nightly build from the devel branch, and reporting back the total size of .deb’s apt-get downloads.

#5 Updated by hans 2014-05-12 07:45:31

As far as I understand it, apt-offline updates the official apt-get files in their official location, so there is no need for tricks to support it.

1. I started working on figuring this out exactly because of the apt lists/cache persistence in Tails, specifically the issue where the signature expires and the packages can no longer be installed. apt-offline updates the Tails persistent versions of these files just fine.

2. I also needed additional software for signing Android APK files, specifically openjdk-7-jdk to provide jarsigner. That installs fine after updating everything with apt-offline.

On TAILS 1.0, all of apt-offline’s dependencies where already installed. The only additional package needed was apt-offline itself. The apt-offline deb file is ~80kb. apt-offline in wheezy/jessie has one less dependency than in squeeze (python-support is no longer needed).

As for changing APT sources, that is easily handled with apt-offline. The user would just have to run the same command on the offline machine that they would run to install new packages, but they can optionally omit the --install-packages part, i.e.:

sudo apt-offline set /media/USBTHUMB/updates --update --install-packages openjdk-6-jdk

or

sudo apt-offline set /media/USBTHUMB/updates --update

#6 Updated by intrigeri 2014-05-13 02:57:06

JFTR, I won’t be able to read hans’ analysis and reply before late May, so anyone interested, don’t hesitate chiming in :)

#7 Updated by hans 2014-05-13 17:25:01

Turns out the version of apt-offline in wheezy (1.2) has a critical bug, but its fixed in testing. I’m working on an official backport now of 1.3.1 from testing.

For those who want to know the details:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664654

#8 Updated by hans 2014-05-14 06:23:00

Nevermind, the bug was elsewhere, and only affects first time offline installs (i.e. systems where /etc/apt/trusted.gpg has not been setup yet). So no backport needed for TAILS. The 1.3.1 backport would add the very basic GUI. If that is desired, I can still do the backport.

For anyone who wants to know more about the bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748082

#9 Updated by intrigeri 2014-06-06 12:20:16

Re. everything but what follows: looks good!

> 2. I also needed additional software for signing Android APK files, specifically
> openjdk-7-jdk to provide jarsigner. That installs fine after updating everything
> with apt-offline.

Are you having the “Additional software packages” persistence feature (https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html#index13h2) to install openjdk-7-jdk?

If the answer is no, please test how apt-offline works when combined with this feature. I kinda share your intuition that it’ll work just fine, but testing in real settings can’t be replaced :)

To end with, just a minor nitpicking: there are quite good ways in Debian to fix bugs in stable releases (and it’s easier than it used to be nowadays, from what my lurking on -release@ taught me), and the backports archive is explicitly not meant to workaround bugs.

#10 Updated by hans 2014-06-06 12:43:56

Yes, I am using the “Additional software packages” persistence feature to install openjdk-7-jdk and other packages too.

As for fixing bugs in Debian/stable, I agree bugs in stable should be fixed when feasible. I have learned by experience that it seems that the release team is too overwhelmed to deal with anything outside of narrow criteria: security bugs and bugs fixed by tiny patches. This is often in conflict with what is tested and proven to work. I went through this with trying to update olsrd after the wheezy freeze. We had done heavy testing on a specific version of olsrd that was a newer than the one in wheezy. Multiple upstream devs were involved in the process. But the Debian release team would not accept it simply because it was not a tiny patch.

#12 Updated by intrigeri 2014-07-04 07:48:24

Hans, do you intend to submit a Git branch that adds apt-offline, or is it too much overhead for you? If the latter, I guess I can do it, even if I’ll treat it as a low-priority task.

#13 Updated by hans 2014-07-04 18:24:02

As far as I understand it, it should literally just be adding the single apt-offline package. If updates or changes are need to the wheezy package, I’m happy to do any work on apt-offline itself and required backports. I haven’t checked out the tails dev or build process at all at this point, so I’d appreciate it if I didn’t have to dive in to get apt-offline included.

#17 Updated by intrigeri 2016-02-27 15:45:26

@anonym: please skip this branch next time you reset experimental.

Note in passing: some recent discussion about apt-offline on the debian-release list raised serious doubts about the security of the tool: its upstream developper apparently doesn’t know what keyrings APT uses for validating packages, and added the Debian keyring (with all uploading DDs) to the list of allowed ones, which feels scary; it may be an isolated mistake, or something else.

#18 Updated by hans 2016-02-27 20:26:00

I assume you were talking about this thread:
https://lists.debian.org/debian-release/2016/02/msg00271.html

Keep in mind, `apt-offline` just shuffles files around, it does not do the package installing. `apt-get install` does that, and `apt-get install` is what is verifying the packages before installing them.

And yes, it looks like I proposed adding /usr/share/keyrings as part of `apt-offline install` which copies the files from the thumb drive to the offline machine, based on my experience with `debootstrap`, which does use a file in /usr/share/keyring. Glad to see that’s improved, but in terms of apt-offline, this is only related to an added level of verification on top of what `apt-get install` does.

#19 Updated by intrigeri 2016-02-27 21:30:09

> I assume you were talking about this thread: https://lists.debian.org/debian-release/2016/02/msg00271.html

Yes, we’re on the same page.

> Keep in mind, `apt-offline` just shuffles files around, it does not do the package installing. `apt-get install` does that, and `apt-get install` is what is verifying the packages before installing them.

> And yes, it looks like I proposed adding /usr/share/keyrings as part of `apt-offline install` which copies the files from the thumb drive to the offline machine, based on my experience with `debootstrap`, which does use a file in /usr/share/keyring. Glad to see that’s improved, but in terms of apt-offline, this is only related to an added level of verification on top of what `apt-get install` does.

Cool (if whatever is on the thumb drive is seen as fully untrusted by apt-offline, otherwise we’re back to square one and: not so cool).

#20 Updated by hans 2016-02-27 22:03:35

As far as I understand it, apt-offline install copies the apt lists into /var/lib/apt/lists and the .deb files into /var/cache/apt/archives, and leaves the rest to `apt-get install`. I think that’s a sensible design, but it would be nice if there was a way to enforce that. sudo apt-offline install does leave a lot to be desired in terms of least privilege.