Commit 071fe5d6 authored by Ulrike Uhlig's avatar Ulrike Uhlig
Browse files

Merge branch 'master' of webmasters.boum.org:wiki

parents 9c446856 c50d29a5
RewriteEngine on
RewriteBase /
RewriteRule ^administration_password/?$ doc/first_steps/startup_options/administration_password [R]
RewriteRule ^blueprint/additional_software_packages_offline_mode/?$ blueprint/additional_software_packages/offline_mode [R]
RewriteRule ^bug_reporting/?$ doc/first_steps/bug_reporting [R]
RewriteRule ^build/?$ contribute/build [R]
......
......@@ -27,3 +27,4 @@ Feel free to add any relevant issue to this list.
* [[!gnome_gitlab yelp/issues/98 desc="Yelp: Clicking a HTML link pointing to an anchor on the page currently viewed opens Nautilus"]]
* [[!gnome_gitlab gdm/issues/251 desc="screensaver doesn't lock with password prompt if password was just set"]]
* [[!gnome_gitlab gtk/issues/1211 desc="Cursor stays in wait status for some seconds after calling `gtk_show_uri_on_window`"]]
* [[!gnome_gitlab seahorse/issues/177 desc="Seahorse: Please support finding remote OpenPGP keys by fingerprint"]]
......@@ -8,7 +8,7 @@ bloat the ISO image.
The current limitations include:
- No user interface. Currently you have to edit a file as root. ([[!tails_ticket 5996 desc="#5996"]])
- No user interface. Currently you have to edit a file as root. ([[!tails_ticket 14568 desc="#14568"]])
- Their Installation locks the opening of the desktop. ([[!tails_ticket 9059 desc="#9059"]])
......
[[!meta title="Explain Tails"]]
Open relationship
-----------------
Tails is not my main operating system: Tails does not make me choose
between itself and other operating systems. With Tails I have an open
relationship. Is not my main operating system, I have other operating
systems for other things.
One in my laptop, one in my school...
Tails is not jealous and does not aim to fulfill all my computer needs:
if I need something Tails cannot give me... I can use another operating
system!
Camping
=======
But I respect our relationship: Tails does not want to be plugged to my
laptop if I am running other operating systems, so I never do that.
And I don't use identities I use on other operating systems from the
same Tails USB stick.
<a id="iff"></a>
Tails as a tent
---------------
From "[Writing good documentation](https://platform.internetfreedomfestival.org/en/IFF2018/public/schedule/custom/426)" at the IFF 2018
---------------------------------------------------------------------------------------------------------------------------------------
### Sheet 1
- [Drawing of an unfolded tent] portable, set up anywhere in the world or your own backyard
- [Drawing of a circus tent]
- [Drawing of a magic hat] make things magically disappear
- [Drawing of two similar tents]
- [Drawing of a tent in a bag] small portable tent fits in backpack, with your belongings.
- [Drawing of a tent city of similar tents]
### Sheet 2
Tents, The everyperson's
### Tents, The everyperson's
- Amnesic
- Empty every time its setup
......@@ -48,18 +26,42 @@ Tents, The everyperson's
- Live
- Can carry around in backpack
- Can set up in backyard (own laptop) or away from home
- Put it away when its finished
### Sheet 3
Leave No Trace
--------------
- clean every time where work (normal is really customized)
- common visual aspect
- decide what keep
- [Drawing of a tent city of similar tents]
"[Leave No Trace](https://lnt.org/)" is an organization and a code of ethics
for outdoor activities.
Open relationship
=================
Tails is not my main operating system: Tails does not make me choose
between itself and other operating systems. With Tails I have an open
relationship. Is not my main operating system, I have other operating
systems for other things.
One in my laptop, one in my school...
Tails is not jealous and does not aim to fulfill all my computer needs:
if I need something Tails cannot give me... I can use another operating
system!
But I respect our relationship: Tails does not want to be plugged to my
laptop if I am running other operating systems, so I never do that.
And I don't use identities I use on other operating systems from the
same Tails USB stick.
<a id="iff"></a>
### Sheet 4
Other output from [IFF 2018](https://platform.internetfreedomfestival.org/en/IFF2018/public/schedule/custom/426)
================================================================================================================
- [Drawing of a circus tent]
- [Drawing of a magic hat] make things magically disappear
- Doesn't leave a trace -- invisibility cloak
- Tent - put it away when its finished
- New wig every morning
- Incognito mode for your computer
- A caravan -- you're the owner, you can move it anywhere
......@@ -70,8 +72,8 @@ Tents, The everyperson's
- Using a bike lock
- Helmet with shades so you're unknown
From the user testing of Additional Software in January 2018 in Berlin
----------------------------------------------------------------------
From the user testing in January 2018 in Berlin
===============================================
- Additional Software P1 talking about how everything we do on the
Internet is tracked: "With Tails I can create that image for myself".
......
......@@ -47,7 +47,7 @@ These will help us for future work like defining a graphical style
guide, defining the tone on our website, the type of visuals to use,
etc.
XXX: Link to resources on brand attributes
- [Mozilla Open Design: Creative Strategy On View](https://blog.mozilla.org/opendesign/creative-strategy-on-view/)
### Deliverable
......
This diff is collapsed.
......@@ -177,9 +177,9 @@ as blocking without notifications would be terrible UX. Also Tails boot time is
a bit long already, and this may grow it quite a bit more again.
XXX: So before going on, we need a bit more data about the state of the entropy when
Tails boot, specially now that we have several entropy collector daemons. It may
very well be that this case do not happen anymore. And if it is, we need to know
on average how much time that blocking would last. [Sycamoreone] [[!tails_ticket
Tails boots, especially now that we have several entropy collector daemons. It may
very well be that this case does not happen anymore. And if it does, we need to know
on average how much time that blocking would last. [[!tails_ticket
11758]]
### Regulary check available entropy and notify if low
......
......@@ -7,7 +7,7 @@ msgid ""
msgstr ""
"Project-Id-Version: Tails\n"
"POT-Creation-Date: 2018-06-03 12:17+0200\n"
"PO-Revision-Date: 2018-07-22 13:34+0000\n"
"PO-Revision-Date: 2018-08-07 13:08+0000\n"
"Last-Translator: \n"
"Language-Team: Tails translators <tails@boum.org>\n"
"Language: fr\n"
......@@ -486,7 +486,7 @@ msgstr "*Tails Upgrader*: intrigeri"
#. type: Bullet: ' - '
msgid "*Tails Verification*: sajolida, anonym"
msgstr ""
msgstr "*Tails Verification*: sajolida, anonym"
#. type: Bullet: ' - '
msgid "Test suite: anonym"
......
......@@ -4,24 +4,15 @@ All times are referenced to Berlin and Paris time.
## 2018Q3
* 2018-08-06, 19:00: [[Contributors meeting|contribute/meetings]]
* 2018-08-16: Build and upload tentative 3.9~rc1 ISO image — intrigeri
* 2018-08-08 to 2018-08-09: port Tails to Tor Browser based on Firefox
60ESR ([[!tails_ticket 15023]]) — intrigeri and segfault
* 2018-08-15: Feature freeze for 3.9. Everything you want to see in
Tails 3.9 must be merged into our devel branch by 17:00 CEST
that day.
* 2018-08-16: Build and upload tentative 3.9~rc1 ISO image — ???
* 2018-08-17: Test and release 3.9~rc1 — ???
* 2018-08-17: Test and release 3.9~rc1 — intrigeri
* 2018-09-03, 19:00: [[Contributors meeting|contribute/meetings]]
* 2018-09-04: Build and upload tentative 3.9 ISO image — ???
* 2018-09-04: Build and upload tentative 3.9 ISO image — intrigeri
* 2018-09-05: Test and **release 3.9** (Firefox 60.2, major release) — ??? is the RM
* 2018-09-05: Test and **release 3.9** (Firefox 60.2, major release) — intrigeri is the RM
- includes VeraCrypt support + major Additional Software Packages improvements
## 2018Q4
......
......@@ -48,6 +48,30 @@
And not *graphics adapters*, *graphics*, *graphical hardware*, or
*video card*.
- **procedures** (a series of steps)
- Keep the number of steps low within a procedure (for example, below
10, ideally 7). For longer procedures, split them and give each
section a title.
- Add a blank line between each step.
- Rely on the automatic numbered of Markdown and number all the steps
with `1.`
See also the *Microsoft Manual of Style: Procedures and technical
content*.
*For example*:
<pre>
1. Make sure that you are connected to the Internet.
1. Start <span class="application">Software Sources</span>.
1. Click on the <span class="guilabel">PPAs</span> button and then choose to <span class="button">Add a new PPA&hellip;</span>.
</pre>
- **network interface**, **Wi-Fi interface**
And not *card*, *device*, or *adapter*.
......
......@@ -4,6 +4,10 @@
See the [[release_schedule]].
<div class="caution">
Read the remainder of this document from the branch used to prepare the release!
</div>
Requirements
============
......@@ -17,6 +21,8 @@ To release Tails you'll need some packages installed:
`debian/control` in the `debian` branch of its repo)
* `tails-perl5lib` dependencies (same trick as `tails-iuk` to get the
list)
* `po4a` _from Stretch_: the version in testing/sid extracts Markdown headings
in a different way, which makes tons of strings fuzzy.
Environment
===========
......@@ -38,15 +44,15 @@ the scripts snippets found on this page:
* `NEXT_PLANNED_MINOR_VERSION`: set to the version number of the next
*minor* Tails release; if the next release is a point-release, use
that one; otherwise, use `${VERSION}.1`
* `MAJOR_RELEASE`: set to 1 if preparing a major release, to 0 else
* `MAJOR_RELEASE`: set to 1 if preparing a major release or a release
candidate for a major release, to 0 otherwise
* `ISOS`: the directory where one stores `tails-amd64-*`
sub-directories like the ones downloaded with BitTorrent.
* `ARTIFACTS`: the directory where build artifacts (e.g.
the `.packages` file) land.
* `MASTER_CHECKOUT`: a checkout of the `master` branch of the main
Tails Git repository.
* `RELEASE_BRANCH`: the name of the branch of the main Tails Git
repository used to prepare the release (`stable` or `testing`).
* `RELEASE_BRANCH=$(if [ "$MAJOR_RELEASE" = 1 ]; then echo -n testing; else echo -n stable; fi)`
* `RELEASE_CHECKOUT`: a checkout of the branch of the main Tails Git
repository used to prepare the release (`stable` or `testing`).
* `TAILS_SIGNATURE_KEY=A490D0F4D311A4153E2BB7CADBB802B258ACD84F`
......@@ -57,7 +63,7 @@ the scripts snippets found on this page:
* `DIST`: either 'alpha' (for RC:s) or 'stable' (for actual releases)
* `export DEBEMAIL='tails@boum.org'`
* `export DEBFULLNAME='Tails developers'`
* `export WEBSITE_RELEASE_BRANCH="web/release-${VERSION:?}"`
* `export WEBSITE_RELEASE_BRANCH="web/release-${TAG:?}"`
Pre-freeze
==========
......@@ -70,16 +76,6 @@ Coordinate with Debian security updates
See [[release_process/Debian_security_updates]].
Select the right branch
=======================
What we refer to as the "release branch" (and `RELEASE_BRANCH`) should
be `testing` for major releases, and `stable` for point-releases.
<div class="caution">
Read the remainder of this document from the branch used to prepare the release!
</div>
Sanity check
============
......@@ -96,7 +92,7 @@ If we are at freeze time for a major release:
1. Merge the `master` Git branch into `devel`:
git checkout devel && git merge --no-ff origin/master
git checkout devel && git fetch origin && git merge --no-ff origin/master
2. [[Merge each APT overlay suite|APT_repository/custom#workflow-merge-overlays]]
listed in the `devel` branch's `config/APT_overlays.d/` into the `devel`
......@@ -179,36 +175,40 @@ The patterns+settings file is stored as a SQLite text dump in
config/chroot_local-includes/usr/share/tails/ublock-origin/ublock0.dump \
&& rm ublock0.sqlite
<a id="upgrade-custom-debs"></a>
Upgrade bundled binary Debian packages
--------------------------------------
Skip this section unless we are at freeze time for a major release
(i.e. we are about to prepare a release candidate).
Skip this section if you are preparing a point-release.
The goal here is to make sure the bundled binary Debian packages contain
up-to-date localization files, so:
That is: make sure the bundled binary Debian packages contain
up-to-date localization files.
- If you are preparing a release candidate, build at least the packages
that change user-visible strings, so that translators can use the RC
to check the status of their work and identify what's left to do.
- If you are preparing a major release, build at least the packages
that got translation updates since the RC: we've sent a call for
translation while releasing the RC so the least we can do is to
incorporate the work that ensued into our final release :)
For each bundled Debian package, `cd` into the package's root
directory (e.g. a checkout of the `whisperback` repository),
and then run the `import-translations` script that is in the
main Tails repository. For example:
import translations from Transifex and sanity-check them:
cd whisperback
"${RELEASE_CHECKOUT:?}"/import-translations
If the `import-translations` script fails to import translations for
the current package, manually copy updated PO files from the
Transifex branches of `git://git.torproject.org/translation.git` (e.g.
`whisperback_completed`) instead. In this case, skip PO files for
[[translation teams that use Git|contribute/how/translate#translate]].
Add and commit.
"${RELEASE_CHECKOUT:?}"/import-translations && \
"${RELEASE_CHECKOUT:?}"/submodules/jenkins-tools/slaves/check_po
Then check the PO files:
Then, `git rm` the PO files that have issues (alternatively, if you
feel like it you can fix them but your changes will be overwritten
next time we import translations from Transifex).
"${RELEASE_CHECKOUT:?}"/submodules/jenkins-tools/slaves/check_po
And finally, commit:
Correct any displayed error, then commit the changes if any.
git add po && git commit \
-m "Update POT and PO files, pull updated translations from Transifex."
Then see the relevant release processes, and upload the packages to
the release branch's custom APT suite:
......@@ -289,19 +289,22 @@ Update other base branches
1. Merge the release branch into `devel` following the instructions for
[[merging base branches|APT_repository/custom#workflow-merge-main-branch]].
2. Merge `devel` into `feature/buster`, *without* following the instructions for
2. [[Thaw|APT_repository/time-based snapshots#thaw]], on the devel
branch, the time-based APT repository snapshots that were used
during the freeze.
3. Merge `devel` into `feature/buster`, *without* following the instructions for
[[merging base branches|APT_repository/custom#workflow-merge-main-branch]].
(For now `feature/buster` is handled as any other topic branch
forked off `devel`: its base branch is set to `devel`.)
If the merge conflicts don't look like something you feel confident
resolving properly, abort this merge and let the Foundations
Team know.
3. Ensure that the release, `devel` and `feature/buster` branches
4. Ensure that the release, `devel` and `feature/buster` branches
have the expected content in `config/APT_overlays.d/`: e.g. it must
not list any overlay APT suite that has been merged already.
4. [[Thaw|APT_repository/time-based snapshots#thaw]], on the devel
branch, the time-based APT repository snapshots that were used
during the freeze.
5. Push the modified branches to Git:
git push origin \
......@@ -518,19 +521,18 @@ SquashFS file order
1. Start *Tor Browser*.
1. A few minutes later, once the `boot-profile` process has been
killed, retrieve the new sort file from `/var/log/boot-profile`.
1. Backup the old sort file: `cp config/binary_rootfs/squashfs.sort{,.old}`
1. Copy the new sort file to `config/binary_rootfs/squashfs.sort`.
1. Cleanup a bit:
- remove `var/log/live/config.pipe`: otherwise the boot is broken
or super-slow
- remove the bits about `kill-boot-profile` at the end: they're
only useful when profiling the boot
1. Inspect the Git diff (including diff stat), apply common sense.
The following command is also helpful but requires that you save a
copy of the old sort file into `/tmp/squashfs.sort.old`:
1. Inspect the Git diff (including diff stat), apply common sense:
diff -NaurB \
<( cut -d' ' -f1 /tmp/squashfs.sort.old | sort ) \
<( cut -d' ' -f1 config/binary_rootfs/squashfs.sort | sort ) \
<( cut -d' ' -f1 config/binary_rootfs/squashfs.sort.old | sort ) \
<( cut -d' ' -f1 config/binary_rootfs/squashfs.sort | sort ) \
| less
1. `git commit -m 'Updating SquashFS sort file' config/binary_rootfs/squashfs.sort`
......@@ -565,10 +567,16 @@ suite should be ready, so it is time to:
1. build the final image!
1. compare the new build manifest with the one from the previous,
almost final build; they should be identical, except that the
`debian-security` serial might be higher. To ensure we publish
the final build's `.build-manifest`, please run:
1. Compare the new build manifest with the one from the previous,
almost final build:
diff -Naur \
"${PACKAGES_MANIFEST:?}" \
"${ARTIFACTS:?}/tails-amd64-${VERSION:?}.iso.build-manifest"
They should be identical, except that the `debian-security` serial might be higher.
1. To ensure we publish the final build's `.build-manifest`, run:
export PACKAGES_MANIFEST="${ARTIFACTS:?}/tails-amd64-${VERSION:?}.iso.build-manifest"
......@@ -794,7 +802,7 @@ Prepare upgrade-description files
or RC), add `--channel alpha`
* If preparing anything but a final release (e.g. an alpha, beta
or RC), drop all `--next-version`
arguments, and instead pass (**untested!**)
arguments, and instead pass
`--next-version $(echo ${VERSION:?} | sed -e 's,~rc.*$,,')`
* Adjust `--next-version "${VERSION:?}.1"` so it matches the next
potential emergency release. E.g. when releasing 3.7.1,
......@@ -832,13 +840,30 @@ Prepare upgrade-description files
)
1. If preparing anything but a final release (e.g. an alpha, beta
or RC), copy the generated or updated files to
`${MASTER_CHECKOUT:?}`, replace `channel: alpha` with `channel:
test`, sign them, commit and push.
or RC), copy the generated UDFs for the previous releases
to the *test* channel in `$MASTER_CHECKOUT`, modify their content
accordingly, sign them, commit and push:
( \
cd ${MASTER_CHECKOUT:?} && \
git fetch && \
for old_version in ${IUK_SOURCE_VERSIONS:?}; do
alpha_udf="wiki/src/upgrade/v1/Tails/${old_version:?}/amd64/alpha/upgrades.yml" && \
test_udf="wiki/src/upgrade/v1/Tails/${old_version:?}/amd64/test/upgrades.yml" && \
mkdir -p "$(dirname "$test_udf")" && \
git show origin/${WEBSITE_RELEASE_BRANCH:?}:${alpha_udf:?} \
| sed -e 's/channel: alpha/channel: test/' > ${test_udf:?} && \
gpg -u "${TAILS_SIGNATURE_KEY:?}" --armor --detach-sign ${test_udf:?} && \
mv ${test_udf:?}.asc ${test_udf:?}.pgp && \
git add ${test_udf:?}* ; \
done && \
git commit -m "Add incremental upgrades on the test channel for Tails ${VERSION:?}" && \
git push origin master:master \
)
1. Else, if preparing a final release, copy the generated UDF for the previous
release to the *test* channel in `$MASTER_CHECKOUT`, modify its content
accordingly, sign it, commit and push:
1. Else, if preparing a final release, copy the generated UDFs for the previous
releases to the *test* channel in `$MASTER_CHECKOUT`, modify their content
accordingly, sign them, commit and push:
( \
cd ${MASTER_CHECKOUT:?} && \
......
......@@ -8,22 +8,18 @@ by delaying a Tails release a bit to wait for a DSA to happen.
Debian security team
====================
RequestTracker
--------------
The Debian security team uses the [Debian RT](https://rt.debian.org/)
to track some of their work. Looking at their RT queues might help us
see if something is being prepared. We, as a Debian derivative, have a
read-only access to these queues.
Security tracker
----------------
The Debian [security tracker][web]'s [SVN repository][svn] is the main
place where we can look at the Debian security team upcoming uploads
and announces. There is also a [mailing list][] that broadcasts
changes to this repository.
The Debian [security tracker][web]'s [GIT repository][git] is the main
place where Debian tracks the status of security issues.
We can look at the [list of upcoming Debian Security Advisories (DSA)][DSA needed].
There is also a [mailing list][] that broadcasts changes to
this repository.
[web]: http://security-tracker.debian.org/tracker/
[svn]: http://svn.debian.org/wsvn/secure-testing
[mailing list]: http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits
[git]: https://salsa.debian.org/security-tracker-team/security-tracker
[mailing list]: https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-security-tracker-commits
[DSA needed]: https://salsa.debian.org/security-tracker-team/security-tracker/blob/master/data/dsa-needed.txt
......@@ -58,8 +58,7 @@ upstream tarball, update `debian/changelog`:
git checkout debian && \
gbp import-orig --upstream-vcs-tag=Tails-perl5lib_$VERSION \
../Tails-perl5lib-$VERSION.tar.gz && \
gbp dch --auto && \
dch -e
gbp dch --auto --spawn-editor=always
(Do not forget to set the appropriate release.)
......@@ -74,7 +73,8 @@ Commit `debian/changelog`:
Git-Dch: Ignore
"
Build a Debian package (use a Stretch/amd64 chroot):
Build a Debian package (use a Stretch/amd64 chroot with `stretch-backports`
enabled):
gbp buildpackage
......
......@@ -7,7 +7,7 @@ Pre-requisites
* a Debian Stretch (or newer) system
* Tails' `devel` APT suite enabled
* the right version of the `tails-perl5lib` package installed
* the latest version of the `tails-perl5lib` package installed
Install build and test dependencies
===================================
......@@ -32,13 +32,11 @@ Export new upstream version number:
export VERSION=XXX
Update version number in `bin/tails-persistence-setup`:
perl -pi -E 's,^Version [0-9.]+,Version $ENV{VERSION},' bin/tails-persistence-setup
perl -pi -E "s,^our \\\$VERSION = '[0-9.]+';\$,our \\\$VERSION = '$VERSION';," bin/tails-persistence-setup
Commit all files that need to be:
Update version number in `bin/tails-persistence-setup` and
commit all files that need to be:
perl -pi -E 's,^Version [0-9.]+,Version $ENV{VERSION},' bin/tails-persistence-setup && \
perl -pi -E "s,^our \\\$VERSION = '[0-9.]+';\$,our \\\$VERSION = '$VERSION';," bin/tails-persistence-setup && \
git commit bin/tails-persistence-setup -m "tails-persistent-setup $VERSION"
Optionally, run the upstream test suite (it is run as part of the
......@@ -70,7 +68,7 @@ Checkout the Debian packaging branch and import the new upstream tarball:
Update `debian/changelog`:
gbp dch && dch -e
gbp dch --auto --spawn-editor=always
(Do not forget to set the appropriate release.)
......@@ -82,9 +80,9 @@ Commit `debian/changelog`:
Git-Dch: Ignore
"
Build a Debian package (use a Stretch/amd64 chroot, that
has either tails-perl5lib installed, or the Tails APT repository
configured):
Build a Debian package (use a Stretch/amd64 chroot, that has
`stretch-backports` enabled and on top of that: either tails-perl5lib
installed or the Tails APT repository configured):
gbp buildpackage
......
......@@ -14,33 +14,17 @@ Update POT and PO files
) && \
git commit po -m 'Update POT and PO files.'
Prepare a release
=================
Run `./scripts/release.sh` and follow the instructions.
git checkout master && ./scripts/release.sh
… then follow the instructions, making sure you set the appropriate
release on the first line of the new changelog entry.
Update the Debian package
=========================
Checkout the correct branch:
git checkout master
Update `debian/changelog`:
gbp dch
(Do not forget to set the appropriate release.)
Commit the changelog:
git commit debian/changelog \
-m "$(dpkg-parsechangelog -SSource) ($(dpkg-parsechangelog -SVersion))
Git-Dch: Ignore
"
Build a new Debian package (use a Stretch/amd64 chroot):
gbp buildpackage
......
......@@ -44,16 +44,11 @@ Export new upstream version number:
Export location of a checkout of the branch of the main Tails Git
repository used to prepare the release (typically `stable` or `testing`):
export TAILS_GIT_CHECKOUT=XXX
export TAILS_GIT_CHECKOUT="$RELEASE_CHECKOUT"
Export source date epoch:
export SOURCE_DATE_EPOCH=$(date \
--utc \
--date="$(dpkg-parsechangelog \
--file "$TAILS_GIT_CHECKOUT/debian/changelog" \
--show-field=Date)" \