Commit 33102f9f authored by anonym's avatar anonym
Browse files

Merge remote-tracking branch 'origin/master' into devel

parents 5d7b901d 5d841e36
......@@ -30,6 +30,8 @@ in a better organized, team-based and focused way.
Additionally, we would like to use this process as an opportunity to
evaluate the idea of basing Tails on snapshots of Debian testing.
<a id="schedule"></a>
# Schedule
* 2016Q1 — Tails 2.0 is out
......@@ -55,9 +57,12 @@ evaluate the idea of basing Tails on snapshots of Debian testing.
* November 14-18th: second sprint (in-person, organized by intrigeri)
* December 20-23: third sprint (remotely attended for everybody except
a couple of us)
* January 30 - Febuary 3: fourth sprint (remotely attended)
* January 30 - Febuary 3: fourth sprint (remotely attended); release
Tails 3.0~beta1
* February 2017 to Tails 3.0 release: keep 3.0~beta as up-to-date,
wrt. security vulnerabilities, as our 2.x channel is
* February 5 2017 — Debian Stretch freeze starts
* March 13-17th: fifth sprint (in-person, organized by sajolida)
* March 17-19th: fifth sprint (in-person, organized by intrigeri)
* June 2017 (???) — Debian Stretch is released
* June-August 2017 — Tails 3.0 is released
......@@ -77,8 +77,8 @@ and a set of third parties tools listed here:
There are other tools that would be possible to explore like:
There are other tools that would be possible to explore like
[[!tails_ticket 10984]].
# Analysis regarding operations on storage devices
We would like to have one :)
# Social contract
Issue number: [[!tails_ticket 11669]]
## Introduction
The Tails Social Contract is a set of commitments that we as contributors to the Tails project stand by. This work is derived from the Debian Social Contract and Tor Project's Social Contract. If you have any questions or comments, feel free to email: <>.
This is a promise from our developer community to the rest of the world, affirming a commitment to our beliefs.
## 1. By developing Tails and publishing related documentation we try to provide usable tools for anonymity and privacy.
We believe that privacy, the free exchange of ideas, and equal access to information are essential to free and open societies. Through our community standards and the code we write and deploy, we provide tools that empower all people to protect and advance these rights.
## 2. Tails and the related documentation is and will remain free software
Equal access to information includes the free availability of our code and documentation as well as the transparency of our decision making processes. Tails will always be free to use, remix, adapt and distribute.
When we write new components of the Tails system, we will license them in a manner consistent with the [Debian Free Software Guidelines](
##3. We will give back to the Free Software community
Tails is a privacy-oriented [Debian Derivative](
We want usable security and privacy-oriented tools to become a standard for the Free Software community as a whole.
Bugfixes, code improvements, Debian packaging, as well as work on usability issues which we include in Tails will be upstreamed whenever possible. This way, our modifications will benefit others and can be improved upon further by a wider audience of people.
## 4. We will never harm our users intentionally
We will always do our best to write secure code and make the right decisions. We will never willingly include backdoors or malicious software nor will we cooperate with any entity wanting us to harm our users.
As Tails is created in a transparent manner, anyone is encouraged to participate, review it and point out problems. Mistakes sometimes happen. We will be honest about them and fix them when they are reported to us.
## 5. We will not hide problems
Our entire bug report database is and will stay open for public view at all times. Reports that are filed here will promptly become visible to others.
Whenever severe security issues are reported to us in private, we will test them and ensure we promptly fix these issues. We will notify our users whenever such an issue has been reported to us. However, for the security of our users, we might not disclose such a severe issue immediately, before releasing a fix.
## 6. We are honest about the capabilities and limits of Tails and related technologies
We encourage users to inform themselves and decide if Tails is suitable for their use case, fits their security needs and whether it can and should be trusted. We work diligently to keep our community up-to-date through our various communication channels about the current state of our software and its limitations. We encourage users to read our documentation as well as third-party documentation in order to make an informed decision and engage in a learning process about the tools we ship.
We provide and explain methods of verification so that anyone can ensure that they downloaded a genuine copy of Tails.
......@@ -157,6 +157,7 @@ Mumble
- supports IPv6
- Tor project's (mttp and Phoul) [guide on using Mumble with
- [Plumble]( is a Mumble client for Android
See the
[[reproducible builds blueprint|blueprint/reproducible_builds#custom-Debian-packages]],
that documents why we want to build our Debian packages automatically,
and raises a number of questions about it.
- <> (uploaded to Debian on 2015-08-22)
- [debile](
is used by Tanglu
......@@ -211,6 +211,8 @@ well as incremental backups.
Borg is the perfect backup back end. It supports increments, encryption,
data deduplication, local and remote backups, and mounting backups as
FUSE file systems. And it way faster than obnam which advertises similar
......@@ -244,7 +246,7 @@ partition if the destination USB is already a Tails USB stick.
Other solutions
- `[sbackup](`, Simple Backup:
- [sbackup](, Simple Backup:
unmaintained since 2008.
- [Lucky Backup]( seems
......@@ -3,8 +3,8 @@
We are running a contest for designers to create a new logo for Tails. See the
full description of the content in our [[blog post|news/logo_contest]].
Some more brainstorming and ideas can also be found in our [Redmine
Some more brainstorming and ideas can also be found in our [[!tails_ticket
5797 desc="Redmine ticket"]].
Here are the proposals we received so far, and their status regarding our
......@@ -16,3 +16,8 @@ Availability and plans for the next weeks
- [[!tails_ticket 6972 desc="Create a 'Sponsors' page"]]
- [[!tails_ticket 12098 desc="Spurious screensaver activation while synchronizing the system clock"]]
- [[!tails_ticket 11882 desc="disable recent usage and history in privacy settings by default"]]
- [[!tails_ticket 12076 desc="Have a sponsor per release"]]
- [[!tails_ticket 12104 desc="Can we drop DKMS modules support?"]]
......@@ -63,6 +63,7 @@ Template
\[[!meta title="Tails report for MONTH, YEAR"]]
\[[!meta date="XXX"]]
[[!meta title="Tails report for December, 2016"]]
[[!meta date="January 10 12:34:56 2017"]]
[[!toc ]]
* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|minor] release).
* Tails 2.9 was cancelled due to CVE-2016-1252.
* [[Tails 2.9.1 was released on 12 14|news/version_2.9.1]] (minor release).
* Tails VERSION+1 is [[scheduled for MONTH DAY|contribute/calendar]].
* Tails 2.10 is [[scheduled for 01 24|contribute/calendar]].
The following changes were introduced in Tails VERSION:
The following changes were introduced in Tails 2.9.1:
XXX: Copy the "Changes" section of the release notes, and compact a bit:
- Remove lines about software upgrade (that's not Tails itself).
- Remove screenshots.
- Remove "New features" and "Upgrades and changes" headlines.
- Remove line about Changelog.
* Switch to *DuckDuckGo* as the default search engine in *Tor Browser*.
The previous default search engine, **, has already been
redirecting to *Duck Duck Go* for some time.
XXX: List important code work that is not covered already by the Release
section (for example, the changes being worked on for the next version).
We've had a great sprint about porting Tails to Debian Stretch.
Most of our time was spent integrating the new Greeter as well as bug fixing,
polishing, and updating the test suite.
[](Report from the sprint)
Documentation and website
......@@ -47,11 +48,17 @@ XXX: Report only if more scenarios have been written and add the diff from the p
XXX: The fundraising team should look at the fundraising Git.
- We continued our donation campaign which will likely bring us more
than 100000 € in donations.
- The [[independent French investigative journal Mediapart has decided
to support|news/mediapart]] Tails financially every year. Thank you
very much!
git log --patch --since='1 December' --until='1 January' origin/master
- We submitted a concept note to OTF for 2017-2018.
XXX: The fundraising and accounting teams should look at the archives of <> and <>.
- We were contacted by private sponsors interested in donating and being
recognized as Tails patrons.
......@@ -59,21 +66,13 @@ Outreach
Past events
Upcoming events
From December 27th to December 30th, we were at 33C3 in Hamburg/Germany.
On-going discussions
XXX: Link to the thread on <>.
Press and testimonials
XXX: Copy content from press/media_appearances_2016.mdwn
This page is continuously updated by, so if
it's empty there might be nothing special to report.
......@@ -92,3 +92,6 @@ no IRC. Tickets were created and rejected some time ago
reconsidering after updating this blueprint ([[!tails_ticket 11686]]).
People from Security-in-a-Box have used it successfully in Tails.
Gajim ships with a plugin called "plugin installer" which allows a user to download new plugins. This sounds suspicious for security, because plugins are pieces of code running with full privilege. The implementation in Debian use unverified TLS connection, which is very very open to MITM. The development version has switched to verified HTTPS connection and is trying to make it more robust.
However, I think that Tails should not ship this plugin at all: it allows a user to download code without needing sudo. We could work debian-side to separate gajim-plugininstaller in a separate package so that Tails can choose not to install it?
......@@ -2,6 +2,8 @@ This is about [[!tails_ticket 5630]].
[[!toc levels=2]]
<a id="why"></a>
# Why we want reproducible builds
## List of reasons why
......@@ -501,3 +503,94 @@ It also raises technical questions:
- ask Chris Lamb <> (keywords: libisofs,
libisoburn, xorriso)
- [[!debbug 831379]] / [[!debbug 832689]]
# Progress
See [[our November report|news/report_2016_11]].
# Future work
<a id="recreate-build-environment"></a>
## Make it easy to recreate a given build environment
It would be great if one didn't have to trust a given Vagrant basebox
we published, and could instead build their own. Their resulting basebox
doesn't have to be identical to ours, but it must be similar enough to
produce ISO images that are identical to ours.
<a id="custom-Debian-packages"></a>
## Integrate custom Debian package builds in the automated ISO builds
In our first iteration of reproducible ISO builds, we treat the
content of the Debian package repositories used during the build
process as trusted input. These repositories are of two kinds:
* snapshots of the Debian archive, hosted on our own infrastructure,
and signed server-side by our own key; Tails system administrators have the
power to modify the content of these snapshots; an attacker who
takes control of the relevant server can do the same; this will be
improved later, and is outside of the scope of the work described
in this section;
* our [[custom APT repository|contribute/APT_repository/custom]],
that stores our custom Debian packages; in addition to the people
listed above (system administrators, successful attackers), Tails
developers with commit rights can modify the content of this
repository. The current standard process is that a developer builds
a package locally, and uploads it to our custom APT repository.
This entails a number of problems that we are going to discuss now.
Here are some problems that come with our current handling of custom
Debian packages:
* Each developer needs to set up and maintain a local build
environment for Debian packages. Such error-prone busywork is
best avoided.
* Our custom Debian packages may not build reproducibly across
different developers' systems. So, one can't reproduce the build of
a given ISO unless they use the exact packages that were uploaded
to our custom APT repository. This brings the same
[[set of problems|reproducible_builds#why]] that lead us to make
our ISO image build reproducibly. For example, the state of our Git
tree does not fully define what an ISO built from it will be, which
makes reviewing and auditing harder than it should be.
* Preparing a Tails release requires to build and upload a few
packages by hand. This work is tedious and error-prone, and
increases our time to mitigation for security issues.
* Preparing a Tails release requires special credentials on our
infrastructure, while we are moving towards Git access
being enough.
The way we have chosen to address these problems in the future is to
have our custom Debian packages built automatically, in a reproducible
manner, as part of building a Tails ISO image.
There are a number of open questions:
* Is it better to apply this build process change to _all_ ISO
builds, or only to selected ones, e.g. actual releases?
* Shall the Debian packages built as part of the ISO build be
uploaded, stored and published somewhere? Or should they be
considered as intermediate results we can just throw away after
installing them?
* If we upload these packages, how will they be verified by future
builds using them?
* How exactly shall these custom Debian packages be built? Can we do
this inside the Vagrant build virtual machine?
* What kind of quality assurance process will the built packages go
through? Should it be done as part of the ISO build process, or
instead on our continuous integration platform where the packages
could be re-built (or uploaded) and checked?
Part of this project will therefore be to research and discuss these
topics with the affected parties, and come up with user stories and
with a fitting design.
- Be non-commercial, open source, and privacy respectful
- Be possible to integrate in ikiwiki (to avoid people having to go elsewhere to answer questions)
- <>
- WordPress plugin: <>
- Drupal plugin: <>
Quick Survey
- <>
- Sandstorm app
- <>
- NodeJS + MySQL
- <>
- Python + PostgreSQL
- <>
- Drupal plugin
- Framaforms: <>
- <>
- NodeJS
- <>
......@@ -221,7 +221,7 @@ a distribution, keeping references to the packages it contains.
Compared to the "snapshots as full-blown distributions + `reprepro
pull`" option we
[used in our initial experiments](,
[[!tails_ticket 6295#note-14 desc="used in our initial experiments"]],
we are saving _a lot_ on database size, and thus in performance,
because reprepro does less tracking on snapshots, than what it does
for real distributions.
......@@ -244,10 +244,9 @@ uncommitted changes. This behaviour can be controlled by:
The fastest build you could pretend to get can be done by setting:
export TAILS_BUILD_OPTIONS="ram cache extproxy gzipcomp"
export TAILS_BUILD_OPTIONS="ram extproxy gzipcomp"
This will force the build to happen in RAM and allow skipping the
boostrap stage if one is cached, and will use use an HTTP proxy
This will force the build to happen in RAM, and will use use an HTTP proxy
external to the virtual machine, and SquashFS compression will be done
using *gzip*.
[[!meta title="Calendar"]]
* 2016-12-13: Release 2.9 (Firefox 45.6) - anonym is the RM
* 2017-01-24: Release 2.10 (Firefox 45.7) - anonym is the RM
* 2017-01-12:
- Feature Freeze: All feature branches targeting Tails 2.10 *must*
be merged into the `devel` branch by noon, CET.
- Build and upload Tails 2.10~rc1.
- Start testing Tails 2.10~rc1 during late CET if building the image
went smoothly.
* 2017-01-13:
- Finish testing Tails 2.10~rc1 by the end of the afternoon, CET.
- Release Tails 2.10~rc1.
* 2017-01-23:
- All branches targeting Tails 2.10 *must* be merged into the
`testing` branch by noon, CET.
- The upcoming Tor Browser is hopefully out so we can import it.
- Build and upload Tails 2.10 ISO image and IUKs.
- Hopefully start testing Tails 2.10.
* 2017-01-24:
- Finish testing Tails 2.10 by the end of the afternoon, CET.
- Release Tails 2.10 during late CET.
* 2017-03-07: Release 2.11 (Firefox 45.8, 52.0) - bertagaz is the RM
* 2017-04-18: Release 2.12 (Firefox 45.9, 52.1) - anonym is the RM
* 2017-06-13: Release 3.0? (Firefox 52.2) - anonym is the RM
* 2017-06-13: Release 3.0? (Firefox 52.2) - intrigeri is the RM
* 2017-08-08: Release 3.1? (Firefox 52.3)
- bertagaz is the RM?
......@@ -4,11 +4,11 @@ Agenda
1. Decide if we care about the Pidgin CTCP replies
[[!tails_ticket 6283]]
2. Decide on throw keyids
[[!tails_ticket 6152]]
3. Test suite: retry when tor fails
[[!tails_ticket 5770]]
4. Broken window week
5. Monthly low-hanging fruits meeting?
......@@ -17,8 +17,8 @@ Decide if we care about the Pidgin CTCP replies
### Introduction
* Parent ticket
* [[!tails_ticket 6283]]
* Parent ticket [[!tails_ticket 5823]]
Pidgin responds to PING returning a time duration and VERSION returning
'Purple IRC'.
......@@ -34,8 +34,8 @@ Decide on throw keyids
### Introduction
* Parent ticket
* [[!tails_ticket 6152]]
* Parent ticket [[!tails_ticket 6153]]
--throw-keyids is a GnuPG option that hides the receiver of the encrypted
data as a countermeasure against traffic analysis.
......@@ -56,7 +56,7 @@ Test suite: retry when tor fails
### Introduction
[[!tails_ticket 5770]]
Some scenarios uses the live Tor network, which is not entirely reliable,
so we may get failing scenarios when in fact we just happened to pick a
......@@ -3,7 +3,7 @@
6245: MD5 Reborned Hasher is incompatible with Firefox 20
[[!tails_ticket 6245]]
This ticket should be in Wait state instead of Discuss state. Another ticket has
been created as parent of this one:
......@@ -15,7 +15,7 @@ been created as parent of this one:
6679: Do not auto-connect to the #tor IRC channel
[[!tails_ticket 6679]]
This ticket has been renamed "Remove the preconfigured #tor IRC channel": we
don't auto-join the #tor channel, so the only way to have less people from Tails
......@@ -68,7 +68,7 @@ Press enquiries
- Three people (sajolida, jvoisin, and intrigeri) were convinced by anonym's
[comment #2]( and agreed
[[!tails_ticket 7380#note-2 desc="comment 2"]] and agreed
with rejecting.
- Furthermore as anonym said, we might not want to change how Tails behaves
when opting-out of MAC spoofing, so it would turn the MAC option into a
......@@ -26,12 +26,12 @@
# [[!tails_ticket 8447 desc="Persistent data is not erased when persistence features are disabled"]]
- We acknowledged the proposal from [comment 4](
- We acknowledged the proposal from [[!tails_ticket 8447#note-4 desc="comment 4"]].
- We can't really say "securely delete" on flash media. So that needs rephrasing.
# [[!tails_ticket 8443 desc="Adding a new printer requires administration password"]]
- We acknowledged the proposal from [comment 9](
- We acknowledged the proposal from [[!tails_ticket 8443#note-9 desc="comment 9"]].
- DrWhax will try to do it for 1.3.
# [[!tails_ticket 8510 desc="Reconsider distributing a hybrid ISO image"]]
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment