GitLab

dkg's key currently has 10 self-signatures so without this change,
this check would always pass even though Seahorse has not synchronized
the keys yet, and as a result that step would sometimes erroneously pass:

  I synchronize keys in Seahorse

… which in turn sometimes causes the next one to fail:

  the key "0EE5BE979282D80B9F7540F1CCD2ED94D21739E9" has more than 42 signatures

… because it was run too early.

Test suite: make the "Syncing OpenPGP keys using Seahorse" tests more robust wrt. new subkeys and other kinds of self-certification (refs: #15771).

Otherwise it will break next time dkg adds a subkey to his key.

This does not fully fix #15116 but it improves things at least on some recent
NVIDIA graphics cards.

Merge remote-tracking branch 'kibi/bugfix/15695-avoid-breaking-automatic-upgrades-to-tails-3-9' into devel (Fix-committed: #15695, #15407, #15419)

Only order changes, which does not matter.

Fixup on top of commit:3682fde3: we should not
"assign a number of groups, fresh, unreserved group IDs" because then these
groups would have a different GID than in Tails 3.8, which is precisely
what we're trying to avoid here :)

As outlined in a774ba2a, since the
virtualbox 5.2.8-dfsg-7 upload the virtualbox-guest-utils package depends
on virtualbox-guest-dkms which in-turn creates a "vboxsf" group later than
before.

This results in the resulting debian-tor group ID being assigned a
different number due to change of relative ordering and, accordingly,
breaks automatic upgrades.

We therefore assign a number of groups, fresh, unreserved group IDs to
avoid collisions.

v2 by Cyril Brulebois:
 - Use the correct command to adjust group ID.
Signed-off-by: Cyril Brulebois <cyril@debamax.com>

Merge branch 'feature/15720-drop-custom-doc-viewer+force-all-tests' into devel (Fix-committed: #15720)

Such changes can break automatic upgrades, as seen on #13426 and more
recently during the 3.6 release.

The /usr/share/tails/build/{passwd,group} added here come straight from the
Tails 3.8 ISO.

The project was renamed, what, 8 years ago?

… at commit e9f9a441a6a6e9366bd7ab59255fb482276d4e64.

We've always disabled this feature because it calls home and generates
network traffic every time one starts Tails and then Tor Browser.
But 106a5129 did not port our settings
customization to the new uBlock settings storage format.

Implementation-wise, I've found no better way of changing the default
value of this setting than patching the extension code: it's not managed
as a regular Firefox pref and the only other option would be to include
a hard-coded
/etc/tor-browser/profile/browser-extension-data/uBlock0@raymondhill.net/storage.js,
which feels more bothersome to maintain than this patch.

This reverts commit 3cbb9d4e.

We now install uBlock from sid, that has a newer version than the one
we had uploaded to this APT overlay.

First, since the transition to webext (commit
106a5129) we actually did not store these lists:
we merely shipped custom settings, which include the list of enabled
filter lists.

Second, even if one manually refreshes these lists, Tor Browser's "avoid disk"
feature prevents the uBlock webext from actually saving the updated lists
on "disk". So extracting them and adding them to our Git repo is not easy.

Third, given the lifetime of our ISO, any list we ship in there will always be
only marginally more up-to-date than the ones included in the Debian package.

Finally, one reason why we needed to include these lists in the ISO is that we
were enabling a couple non-default, regional ones. It makes little sense in 2018
to special-case German and French in Tails so I think this reason does not
work anymore.

So we'll now rely purely on the set of filter lists shipped in the
Debian package.