Project

General

Profile

Feature #15523

Feature #14468: Add VeraCrypt support to Tails

Feature #15214: Iteration 1: Support unlocking VeraCrypt partitions in GNOME

Feature #15521: Iteration 1: Create Debian packages to ship our VeraCrypt patches in Tails 3.9

Iteration 1: Create custom Debian package for Disks

Added by segfault over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
-
Target version:
Start date:
04/11/2018
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

I backported our Disks patches to the Disks version in Stretch (#15515).
Now we have to create a Debian package out of this, which we can ship in the beta release (planned for June 1) and Tails 3.9.

The dependencies are listed here: https://packages.debian.org/stretch/gnome-disk-utility.

Repository: https://gitlab.com/segfault3/debian-gnome-disk-utility.git
Branch: 3.22.1-1-support-tcrypt


Related issues

Blocked by Tails - Feature #15515: Iteration 1: Backport our VeraCrypt patches to Disks in Stretch Resolved 04/09/2018

History

#2 Updated by u over 1 year ago

@segfault: I assume you will want to get this patch upstream? If yes, may you please create a ticket for that or link one that you created already?

If we have to build this package for every Tails release, we will also need a release process documentation, similar to this one: http://tails.boum.org/contribute/release_process/tails-installer

#3 Updated by segfault over 1 year ago

u wrote:

@segfault: I assume you will want to get this patch upstream?

The changes in Disks will be upstreamed (to Disks, see #15221), but the Debian package will not be upstreamed (to Debian) - we only need it to ship our changes in Tails before the end of the contract. They will land in Debian Buster anyway, so we don't need to take the effort of upstreaming the Stretch packages.

If we have to build this package for every Tails release, we will also need a release process documentation, similar to this one: http://tails.boum.org/contribute/release_process/tails-installer

Right. I don't expect that we will have to change the package, but we should include a step in the release process to check whether there are security updates we should merge. I now created #15524 for that.

#4 Updated by u over 1 year ago

segfault wrote:

I backported our Disks patches to the Disks version in Stretch (#15515).
Now we have to create a Debian package out of this, which we can ship in the beta release (planned for June 1) and Tails 3.9.

The code lives in https://github.com/segfault3/gnome-disk-utility branch 3.22.1-support-tcrypt.

The dependencies are listed here: https://packages.debian.org/stretch/gnome-disk-utility.

So basically : you patched gnome-disk-utility?
i.e. we can take that package from Debian, add your patch, build and upload?
If you confirm, this is much easier (read: faster!) than what I thought.

#5 Updated by u over 1 year ago

You might want to learn how to create patches for Debian packages :)

To start with:

debcheckout gnome-disk-utility
cd gnome-disk-utility

Now use quilt: https://wiki.debian.org/UsingQuilt

quilt push -a
quilt new bla.diff
quilt add file_to_patch
quilt edit file_to_patch
quilt refresh
quilt pop -a

This should create bla.diff in debian/patches/ and update debian/patches/series

You can also create that patch manually from your code and put it into debian/patches/mypatch.diff and then add it to debian/patches/series.

Actually.. I think intrigeri uses http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html to handle patches. But i never tried this -> although I think it is particularly intended for the kind of case we're facing here :)

From here we can build the package using

gbp buildpackage

.. assuming you've already created a build environment with pbuilder or cowbuilder for example.

Depending on the codebase and language, building can take quite some time though.

Do you want to give it a try or should I +/- anonym do it?

Also, I guess we might want to use a Git repository that other people than you can write to? Could you ask sysadmins to set this up?

#6 Updated by segfault over 1 year ago

Yay, I succeeded in building custom packages for both udisks2 and gnome-disk-utility! Thanks for your help!

u wrote:

You might want to learn how to create patches for Debian packages :)

To start with:

debcheckout gnome-disk-utility
cd gnome-disk-utility

Wow, debcheckout is awesome, I wish I knew about that earlier (I always used apt source to get the sources, but getting the git repository is much better).

Now use quilt: https://wiki.debian.org/UsingQuilt

[...]

This should create bla.diff in debian/patches/ and update debian/patches/series

You can also create that patch manually from your code and put it into debian/patches/mypatch.diff and then add it to debian/patches/series.

Actually.. I think intrigeri uses http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html to handle patches. But i never tried this -> although I think it is particularly intended for the kind of case we're facing here :)

I tried both quilt and gbp now and found that gbp does indeed do exactly what I needed.

From here we can build the package using
[...]
.. assuming you've already created a build environment with pbuilder or cowbuilder for example.

I did not use pbuilder or cowbuilder, but found that gbp buildpackage still does build a package - at least up to the point where it fails with

Now signing changes and any dsc files...
 signfile dsc gnome-disk-utility_3.22.1-1.dsc Michael Biebl <biebl@debian.org>
gpg: skipped "Michael Biebl <biebl@debian.org>": No secret key
gpg: /tmp/debsign.xptmR9ZM/gnome-disk-utility_3.22.1-1.dsc: clear-sign failed: No secret key

I spent quite some time trying to fix this, without success. But then I noticed that there were already .deb files created in the parent directory, which I was able to successfully install in Tails. And it all seems to work now, I could successfully unlock VeraCrypt volumes in Disks on Tails! :)

Also, I guess we might want to use a Git repository that other people than you can write to? Could you ask sysadmins to set this up?

I'm not sure if this is required anymore now.

#7 Updated by segfault over 1 year ago

  • Description updated (diff)
  • Assignee changed from segfault to anonym
  • QA Check set to Ready for QA

#8 Updated by intrigeri over 1 year ago

  • Blocked by Feature #15515: Iteration 1: Backport our VeraCrypt patches to Disks in Stretch added

#9 Updated by intrigeri over 1 year ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 30

#10 Updated by u over 1 year ago

segfault wrote:

Yay, I succeeded in building custom packages for both udisks2 and gnome-disk-utility! Thanks for your help!

You're welcome.

u wrote:

You might want to learn how to create patches for Debian packages :)

To start with:

debcheckout gnome-disk-utility
cd gnome-disk-utility

Wow, debcheckout is awesome, I wish I knew about that earlier (I always used apt source to get the sources, but getting the git repository is much better).

Indeed :) There are too many secret things in Debian :)

Now use quilt: https://wiki.debian.org/UsingQuilt

[...]

This should create bla.diff in debian/patches/ and update debian/patches/series

You can also create that patch manually from your code and put it into debian/patches/mypatch.diff and then add it to debian/patches/series.

Actually.. I think intrigeri uses http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html to handle patches. But i never tried this -> although I think it is particularly intended for the kind of case we're facing here :)

I tried both quilt and gbp now and found that gbp does indeed do exactly what I needed.

Cool, that's what I suspected.

From here we can build the package using
[...]
.. assuming you've already created a build environment with pbuilder or cowbuilder for example.

I did not use pbuilder or cowbuilder, but found that gbp buildpackage still does build a package - at least up to the point where it fails with

I don't know what gbp does by default - but I use it with pbuilder in order to build packages in a clean sid or stretch chroot - whatever I build the package for.

[...]

I spent quite some time trying to fix this, without success. But then I noticed that there were already .deb files created in the parent directory, which I was able to successfully install in Tails. And it all seems to work now, I could successfully unlock VeraCrypt volumes in Disks on Tails! :)

See my other comment about incrementing the version number and using your own email address to be able to sign the package. Still, as I don't think you have the right to upload this yourself, one of us will do the signing I guess.

Also, I guess we might want to use a Git repository that other people than you can write to? Could you ask sysadmins to set this up?

I'm not sure if this is required anymore now.

Well, if you want us to be able to "sponsor" and upload your package to the Tails repository - I guess it's required. Unless you have access to that which I doubt for some reason.

#11 Updated by intrigeri over 1 year ago

  • Target version changed from Tails_3.7 to Tails_3.8

#12 Updated by intrigeri about 1 year ago

  • Assignee changed from anonym to segfault

I think you should not block on anonym for this. If you need help / uploads, ask me (or possibly u if she's fine with that).

#13 Updated by intrigeri about 1 year ago

  • QA Check changed from Ready for QA to Dev Needed

I did a first review on #14481.

#14 Updated by intrigeri about 1 year ago

See my upcoming review on #15521 for required changes. Other than that: libudisks2-dev (= 2.1.8-1tails1) feels needlessly strict and will force us to rebuild + upload this package every time we update src:udisks2. Assuming ABI is compatible, I suspect libudisks2-dev (>= 2.1.8-1tails1) would be enough to ensure we have the required API available.

#15 Updated by intrigeri about 1 year ago

Also, that version is wrong in the source package you've uploaded so the package FTFBS. I've replaced it with 2.1.8-1.0tails1 and did the s/=/>=/ while I was at it.

#16 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_3.8 to Tails_3.9

This can (and should) wait post-3.8.

#17 Updated by intrigeri about 1 year ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (segfault)
  • % Done changed from 30 to 100
  • QA Check changed from Dev Needed to Pass

Please correct me if I'm wrong, but I think we're done here.

If #14480 or #15589 bring more needed changes, we'll track this on the parent ticket (#15521).

#18 Updated by segfault about 1 year ago

intrigeri wrote:

Please correct me if I'm wrong, but I think we're done here.

If #14480 or #15589 bring more needed changes, we'll track this on the parent ticket (#15521).

ack

#19 Updated by intrigeri about 1 year ago

  • Priority changed from Normal to High

Also available in: Atom PDF