Commit 002f71af authored by sajolida's avatar sajolida

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

Conflicts:
	wiki/src/contribute.de.po
	wiki/src/contribute.fa.po
	wiki/src/contribute.fr.po
	wiki/src/contribute.it.po
	wiki/src/contribute.pt.po
	wiki/src/news/version_2.3.de.po
parents 404165b7 60de553a
......@@ -937,7 +937,7 @@ RewriteRule ^todo/think_about_tordate_htpdate_changes https://labs.riseup.net/co
RewriteRule ^todo/include_arm https://labs.riseup.net/code/issues/5884 [R]
RewriteRule ^todo/add_virtualbox_host_software https://labs.riseup.net/code/issues/5606 [R]
<FilesMatch "^(latest|upgrade)\.yml(\.pgp)?$">
<FilesMatch "^((latest|upgrade)\.yml(\.pgp)?|mirrors\.json)$">
ExpiresActive On
ExpiresDefault "access plus 2 hours"
Header append Cache-Control must-revalidate
......
......@@ -41,12 +41,12 @@ This only include steps for which ordering is critical. There are a few
other auxiliary tasks, tracked as sub-tasks of [[!tails_ticket 7161]],
that can be dealt with independently.
1. Have the mirror pool dispatcher library audited [[!tails_ticket 8640]]
2. Make (almost) all downloads use the new mirror pool:
1. Make (almost) all downloads use the new mirror pool:
* website: [[!tails_ticket 8642]]
* Dave: [[!tails_ticket 11109]]
* Upgrader: [[!tails_ticket 11123]]
3. Shrink our DNS pool into a small, fallback one: [[!tails_ticket 11284]]
* ~~Upgrader: [[!tails_ticket 11123]]~~
2. Shrink our DNS pool into a small, fallback one: [[!tails_ticket 11284]]
3. Have the second audit of our mirror pool dispatcher library completed: [[!tails_ticket 8640]]
<a id="configuration"></a>
......
......@@ -32,11 +32,160 @@ Everything in this report is public.
# B. Improve our quality assurance process
## B.4. Freezable APT repository
The work we have done has been reviewed, merged into the main Tails
development branch, and successfully used while preparing Tails
2.4~rc1. Unsurprisingly, we had to fix a couple small bugs that
earlier testing had not discovered, but all in all we're very
satisfied by how the whole thing work: it has been very solid and
performed pretty well so far. We are proud to point to the first ever
tagged snapshot, that contains only the set of packages needed for
building Tails 2.4~rc1, and the corresponding source code:
<http://tagged.snapshots.deb.tails.boum.org/2.4-rc1/>.
Now, let's dive into the details:
- B.4.3. Centralize and merge the list of needed packages
As [[explained previously|contribute/reports/SponsorS/2015/2016_03#index4h2]],
the original definition of this deliverable doesn't make sense
anymore, so here we are reporting about what now replaces it:
* Allow storing APT snapshots longer than the default when needed:
the code was reviewed, merged, and successfully used in production
while preparing Tails 2.4~rc1, so this is completed.
* Freeze and unfreeze the APT snapshots used by a branch when
needed: the code and corresponding documentation were reviewed,
merged, and used in production, so this is completed.
So we're happy to report that deliverable B.4.3 has been completed
in May.
- B.4.5. Implement processes and tools for importing and freezing those packages ([[!tails_ticket 6299]], [[!tails_ticket 6296]])
As [[said last month|contribute/reports/SponsorS/2015/2016_04]], the
last remaining bits here are about handling some consequences on
this system:
* Garbage collection of APT repository snapshots: this was deployed
in production and works fine.
* Manage a very custom configuration for `apt-cacher-ng`: this was
reviewed, merged, and used in production since then.
* Manage `reprepro`'s database growth: we checked the actual data
in our production environment and realized that there is actually
no problem to be solved here; since we have enabled garbage
collection, the database has not grown at all.
- Miscellaneous follow-ups
We have submitted upstream three branches that improve the Puppet
module we use to manage `reprepro` in ways that made it compatible
with the needs of our freezable APT repository.
By the end of July, we will also do some polishing in various areas:
* Polish a bit the design documentation for the entire setup
([[!tails_ticket 11447]]).
* If needed, write helper tools for freeze exceptions
([[!tails_ticket 11448]]).
* Investigate a weird issue we have identified, when a package is
not removed from our time-based APT snapshots, while it should be
([[!tails_ticket 11496]]).
# C. Scale our infrastructure
## C.1. Change in depth the infrastructure of our pool of mirrors
XXX: u, please review
The new mirror pool is now used by Tails Upgrader, by users who
download Tails without using our Download And Verification Extension
for Firefox (aka. DAVE), for any download that is not supported by
DAVE (e.g. release candidates), and for downloads started from a web
browser that has JavaScript disabled. So, in summary two of the use
cases of this work are covered already, and only the "downloading with
DAVE" use case is left to complete.
- C.1.2. Write & audit the code that makes the redirection decision from our website ([[!tails_ticket 8639]], [[!tails_ticket 8640]], [[!tails_ticket 11109]])
* `mirror-dispatcher.js`: we are still waiting for the auditor to do
a final security review.
* Download And Verification Extension for Firefox: we have made some
progress on the implementation, and coordinated with the person
who will do the code review to ensure he will be available when we
need it. XXX: u, please update/complete this part.
- C.1.4. Communicate with each mirror operator to adapt their configuration ([[!tails_ticket 8635]], [[!tails_ticket 11079]])
This deliverable is completed:
* All mirrors have now implemented the changes we requested.
* We have sent a call for mirrors to a number of fast mirror
operators, and we already have 7 more mirrors. We will pursue this
effort in June, even though we have already reached the goals we
had set: we expected to have at least 30 mirrors in the pool once
the new infrastructure was ready, and 35 mirrors 3 months later,
and we already have 36 active mirrors as of May 31.
- C.1.6. Adjust download documentation to point to the mirror pool dispatcher's URL ([[!tails_ticket 8642]], [[!tails_ticket 11329]], [[!tails_ticket 10295]])
This was deployed to production: all links pointing to our mirror
pool now use the new redirection system.
So, this deliverable is now completed.
- C.1.7. Adjust update-description files for incremental upgrades ([[!tails_ticket 11123]])
We have adjusted the code of Tails Upgrader to use the new mirror
pool. This code has been merged, and is now used by Tails Upgrader
in production (starting with Tails 2.4~rc1), so this deliverable is
completed as well.
- C.1.8. Clean up the remainers of the old mirror pool setup ([[!tails_ticket 8643]], [[!tails_ticket 11284]])
This is now only blocked by the work that is in progress on DAVE
(C.1.2).
## C.4. Maintain our already existing services
XXX: bertagaz, please review/complete
- C.4.6. Administer our services upto milestone VI
We kept on answering the requests from the community and taking care
of security updates.
We noticed that old Puppet reports were not cleaned up as they
should on our infrastructure, so we fixed this and submitted a merge
request to the Puppet module we use to manage… Puppet itself
([[!tails_ticket 11468]]).
We noticed that our four newest virtual machines used to
continuously run our automated test suite on all ISO images built by
our Jenkins instance (B.2) did not reboot as intended between test
suite runs. We investigated the root cause of the problem, and fixed
it ([[!tails_ticket 11467]]).
We ported everything that made sense to, in our Puppet
infrastructure, to use [Hiera](https://github.com/puppetlabs/hiera).
Not only this simplified a lot how we manage systems, but more
importantly, this allowed us to release quite a bit more of our
Puppet code. This is part of our strategy to treat infrastructure as
code, and to enable more people to contribute to it without needing
any special credentials.
# D. Migration to Debian Jessie
We streamlined email reporting from failed cronjobs across our
infrastructure, to ensure we don't miss problems.
We did lots of refactoring and miscellaneous clean ups in our Puppet
code. Sprint cleaning!
# E. Release management
......@@ -8,13 +8,18 @@ This is about [[!tails_ticket 5926]].
1. design documentation: [[!tails_ticket 11447]]
2. [[!tails_ticket 11445]]: handle ever-growing `references.db`, aka.
[[!debbug 823629]]: if
`references.db` doesn't fit in the memory disk cache, then at
least our GC process gets very slow); the visible consequence
would be: long periods of heavy disk read, and much slower
snapshots expiration process; so we added an Icinga2 check on
the file size itself. When this problem occurs, our options are:
2. misc: see subtasks of [[!tails_ticket 5926]]
# Bonus for later
## Handle handle ever-growing `references.db`
This is about [[!debbug 823629]]:: if `references.db` doesn't fit in
the memory disk cache, then at least our GC process gets very slow);
the visible consequence would be: long periods of heavy disk read, and
much slower snapshots expiration process; so we added an Icinga2 check
on the file size itself. When this problem occurs, our options are:
* add more RAM to the VM if that's still feasible and reasonable
(likely not)
* reset the whole `debian` repository to an empty state (simple
......@@ -30,10 +35,6 @@ This is about [[!tails_ticket 5926]].
works on small databases, but on our big `debian` the file
doesn't shrink
3. misc: see subtasks of [[!tails_ticket 5926]]
# Bonus for later
## Miscellaneous
If the chosen mirroring/snapshoting tool supported re-using the Debian
......
......@@ -8,20 +8,59 @@ Releases
Code
====
- segfault sent his
[first](https://mailman.boum.org/pipermail/tails-dev/2016-May/010637.html) and
[second](https://mailman.boum.org/pipermail/tails-dev/2016-May/010663.html)
report on his GSoC on *Tails Server*.
Documentation and website
=========================
- sajolida finished replacing the old installation instructions we had before
the installation assistant. This implied rewriting our instructions for
[[OpenPGP verification|install/download/openpgp]] which now include a direct
download link. We are [[!tails_ticket 11024 desc="still discussing"]] how to
better link this page to make it easier to find.
- emmapeel documented how to [[exchange files with I2P
Browser|doc/anonymous_internet/i2p#index2h1]].
- sajolida sent some [statistics on the hits on our
website](https://mailman.boum.org/pipermail/tails-project/2016-May/000508.html).
User experience
===============
- We discussed the design of [segfault's second prototype for *Tails
Server*](https://mailman.boum.org/pipermail/tails-ux/2016-May/000953.html).
- We discussed the design of the [**Unlock** and **Relock** widgets of the
new *Tails Greeter*](https://mailman.boum.org/pipermail/tails-ux/2016-May/000952.html).
- kurono wrote a [simplified interface for *Tails
Installer*](https://mailman.boum.org/pipermail/tails-ux/2016-May/000990.html)
that would allow removing the splash screen and asked for reviews of
his design.
Infrastructure
==============
- XXX: Move #tails to XMPP
Funding
=======
- [Mediapart](https://www.mediapart.fr/), a French online investigative journal
that uses Tails for their work, is the first media organization to answered
positively our call to support Tails financially. The terms of our
partnership are still being discussed.
- We submitted a proposal to fund reproducible builds to the [Mozilla Open
Source Support|https://blog.mozilla.org/blog/2016/05/11/mozilla-open-source-support-moss-now-open-to-all-projects/]].
Outreach
========
Past Events
-----------
......@@ -34,8 +73,11 @@ Press and testimonials
Translation
===========
- XXX: Added Italian
Metrics
=======
* Tails has been started more than XXXtimes this month. This makes XXX boots a day on average.
* Tails has been started more than XXX times this month. This makes XXX boots a day on average.
* XXX downloads of the OpenPGP signature of Tails ISO from our website.
* XXX bug reports were received through WhisperBack.
* 112 bug reports were received through WhisperBack.
# /dev/random and /dev/urandom radomness seeding in Tails
/dev/random and /dev/urandom are especial Linux devices that provide access from user land
to the Linux kernel Pseudo Random Number Generator (PRNG). This generator is used for almost
every security protocol, like TLS/SSL key generation, choosing TCP sequence and file system and email
encryption [1]. Such PRNG requires a a "good" source of randomness on initialization,
that is a seed. In order to this seed to be secure, a source of entropy should be used. The
Linux kernel collects entropy from several sources, for example keyboard typing, mouse movement,
among others.
## Problem
Because of the Tails nature of being amnesic, and run from a live device,
the seed file is public and the same each boot for a given Tails release,
this may make the output of /dev/urandom predictable.
The urandom initscript makes it clear that the assumption for this file is that its content
is "unique to this machine and not known to attackers"... which is not the case when we
ship that file in our ISO images. If that file doesn't exist, the initscript seeds urandom
with the output of date +%s.%N only. The same initscript says that "re-using a seed compromises
security". Only /dev/urandom is at risk here. /dev/random is not.
Read [2],[3],[4],[5],[6],[7] and [8] for more information.
## Proposed solutions
### Persist entropy pool seeds [[!tails_ticket 7675]]
Generating entropy on a live distribution is a tough problem. And this has impact to securely
generate cryptographic keys, like for example for Pidgin-OTR, using SSH or generating a PGP key.
We hope to improve this situation for users who enable the persistence storage option using some
randomness from the previous session to help bootstrap with some "well" generated randomness.
However this option is only useful for users with persistence enabled, and does not solve the
problem for the first time Tails is booted.
### Use a stronger entropy collector library [[!tails_ticket 5650]]
We could try haveged as well as other entropy collection daemons. It would be nice to
have study (read: a survey of packages, etc) of all the useful entropy gathering daemons
that might be of use on a Tails system.
### Use the Tails installer to create a better seed
Tails installer can be used on Debian and Ubuntu, and in the future on
Windows and OSX, we could use their PRNG to generate a presumably better
seed file on every new Tails installation. Of course this should be a post installation
mechanism, after verifying the ISO/disk image hash/signature.
This would at least provide a better escenario than the one with the same known
and constant seed file, which provides entropy zero.
This solution is partial since it only works for Tails Installer+USB stick, and doesn't
provide persistence by itself, but might be a complementary solution for [[!tails_ticket 7675]].
## Current workaround
Tails has stopped shipping /var/lib/urandom/random-seed, since it is a fixed known value
for every Tails installation which means its entropy contribution is zero.
On Tails 2.x we ship /var/lib/urandom/random-seed, that would be used by the urandom initscript...
except that initscript is masked by urandom.service, so what matters now is how
/lib/systemd/systemd-random-seed load behaves in the absence of any /var/lib/systemd/random-seed
(Tails 2.0.1 ships no such file).
Systemd-random-seed load won't write anything to /dev/urandom (so we rely purely on the kernel and
current system entropy to get /dev/urandom). This new behavior can't be much worse, and the fact it's
the new debootstrap and systemd default behavior tends to reassure me somewhat.
## Related tickets
This is about [[!tails_ticket 7642]], [[!tails_ticket 7675]],
[[!tails_ticket 6116]], and friends.
# Resources
## References
* <http://wiki.qubes-os.org/trac/ticket/673>
* <https://github.com/QubesOS/qubes-issues/issues/1311>
* <https://groups.google.com/forum/#!msg/qubes-devel/Q65boPAbqbE/9ZOZUInQCgAJ>
* <https://groups.google.com/forum/#!topic/qubes-devel/5wI8ygbaohk>
* <https://www.av8n.com/computer/htm/secure-random.htm>
* <http://www.av8n.com/computer/htm/fixup-live-cd.htm>
* [1] <https://eprint.iacr.org/2006/086.pdf>
* [2] <https://eprint.iacr.org/2013/338.pdf>
* [3] <http://wiki.qubes-os.org/trac/ticket/673>
* [4] <https://github.com/QubesOS/qubes-issues/issues/1311>
* [5] <https://groups.google.com/forum/#!msg/qubes-devel/Q65boPAbqbE/9ZOZUInQCgAJ>
* [6] <https://groups.google.com/forum/#!topic/qubes-devel/5wI8ygbaohk>
* [7] <https://www.av8n.com/computer/htm/secure-random.htm>
* [8] <http://www.av8n.com/computer/htm/fixup-live-cd.htm>
......@@ -384,6 +384,72 @@ be that a new VM is created, because we do not want to have to deal
with re-installing the correct versions when switching between
branches.
## Debian (or nothing!) as trust anchor when building Tails
Note: this goal should probably not be part of our first iteration of
making Tails reproducible unless it turns out to be truly easy. But it
can be good to keep this potential future goal in mind so we don't
make decisions making it harder.
A possible goal for us could be that, when building Tails, delegate
the trust of the authenticity (here this means that a binary was built
from the claimed source code) of the binaries used, from the Tails
project (incl. infra) to the Debian project (incl. infra). This
includes both binaries used when building Tails, and the binaries that
end up inside the final Tails image. After all, the goal here is that
looking at the source and building it should be enough to authenticate
the images we ship.
In our custom APT repo we ship packages that we build ourselves, so we
need to make all of them build reproducibly for this goal to give any
real confidence. That includes both packages installed inside the
final Tails image (e.g. `tails-greeter`) and those used in the build
process (e.g. our patched `live-build`). Note that this would also be
nice to have in our QA process as a safe guard against contributors
uploading a (knowingly or not) compromised package, i.e. the reviewer
must be able to reproducibly build the same package.
In our frozen APT suites we allegedly ship tons of packages imported
straight from Debian. We should provide scripts that make it easy to
verify that that is the case, perhaps by downloading the needed signed
indexes/manifests etc from `snapshot.debian.org` and doing the
necessary checks. Or possibly even better: in each APT suite we can
include a package containing all the proofs needed to verify the
sources of all packages in the same suite, i.e. all
`dists/.../Packages`, `dists/.../Release{,.pgp}` and APT repo signing
keys used. That will make it easier to deal with non-Debian sources we
use (e.g. `deb.torproject.org`) that don't necessarily archive
historical APT repo state like `snapshot.debian.org` does. Users would
*only* need to authenticate all APT repo keys shipped in that package,
or similar. Hopefully Debian provides a way to authenticate obsolete
APT repo signing keys (e.g. by signing the old one with the new one)
so at least that part can be scripted/automated.
We also need to make it possible for users to generate the "static
build environment" (see above) themselves so they do not have to rely
on whatever binary blob (e.g. VM config + disk image) we
distribute. As already mentioned above, it should be possible to to do
this by leveraging our APT infrastructure's ability to freeze APT
state, which then can be verified as described above. Whatever the
users manage to produce does not need to be bit-by-bit identical with
binary blob we distribute; it just must have the same properties for
building Tails in a reproducible manner, which it should have provided
the frozen APT state used during generation.
(FWIW: given the experience we'll gather making Tails itself
reproducible, making the generation of the "static build environment"
reproducible is likely trivial in comparison. Having that would be
nice, but, as pointed out above, not necessary for this goal.)
Given all the above, users should be able to build Tails reproducibly
while only having had to trust Debian for any binaries used in the
process. Combine this with all Debian packages being reproducible at
some point and we're basically down to the "Reflections on Trusting
Trust" level when it comes to the "trust anchor", and close to reach
reproducability nirvana. I guess the next step would be to rely less
on a "static build environment" to support something like "Diverse
Double-Compiling" to counter the "Trusting Trust" problem. :)
## Jenkins
XXX: see "Adjust our infrastructure accordingly" above, that has some
......
......@@ -105,10 +105,10 @@ For each service included in Tails Server a single executable file (using this t
## CLI options
### info [--details]
#### info [--details]
Print a mapping of attributes of the service to their current values. With *--details*, additional attributes will be printed.
#### Example 1
##### Example 1
$ mumble.py info
description: A low-latency, high quality voice chat server
......@@ -126,7 +126,7 @@ Print a mapping of attributes of the service to their current values. With *--de
server-password: PmEi9uVNH7oXMuppB7Hd
welcome-message: '"<br />Welcome to this server Enjoy your stay!<br />"'
#### Example 2
##### Example 2
$ mumble.py info --details
name: mumble
......@@ -182,19 +182,19 @@ Print a mapping of attributes of the service to their current values. With *--de
systemd-service: mumble-server.service
icon-name: mumble
### status
#### status
Print the mapping of the *enabled* attribute to its value.
### enable
#### enable
Enables the service, which involves installing the packages, starting the service, creating the hidden service directory and reloading Tor.
### disable
#### disable
Stops the service.
### get-option OPTION
#### get-option OPTION
Prints the mapping of the provided option to its value.
### set-option OPTION VALUE
#### set-option OPTION VALUE
Sets the provided option to the provided value.
## Service Template Module
......
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2016-05-25 22:08+0200\n"
"POT-Creation-Date: 2016-05-31 15:54+0300\n"
"PO-Revision-Date: 2014-04-18 23:25+0100\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -527,6 +527,7 @@ msgstr ""
#| " - [[Ticket gardener|contribute/working_together/roles/ticket_gardener]]\n"
msgid ""
" - Roles\n"
" - [[Foundations team|contribute/working_together/roles/foundations_team]]\n"
" - [[Front desk|contribute/working_together/roles/front_desk]]\n"
" - [[Release manager|contribute/working_together/roles/release_manager]]\n"
" - [[Ticket gardener|contribute/working_together/roles/ticket_gardener]]\n"
......
......@@ -7,7 +7,7 @@ msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: tails-l10n@boum.org\n"
"POT-Creation-Date: 2016-05-25 22:08+0200\n"
"POT-Creation-Date: 2016-05-31 15:54+0300\n"
"PO-Revision-Date: 2015-10-15 15:23+0000\n"
"Last-Translator: sprint5 <translation5@451f.org>\n"
"Language-Team: Persian <http://weblate.451f.org:8889/projects/tails/"
......@@ -511,6 +511,7 @@ msgstr "[[پیشرفت اسناد|contribute/working_together/document_progress]
#| " - [[Sysadmins|contribute/working_together/roles/sysadmins]]\n"
msgid ""
" - Roles\n"
" - [[Foundations team|contribute/working_together/roles/foundations_team]]\n"
" - [[Front desk|contribute/working_together/roles/front_desk]]\n"
" - [[Release manager|contribute/working_together/roles/release_manager]]\n"
" - [[Ticket gardener|contribute/working_together/roles/ticket_gardener]]\n"
......
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: \n"
"POT-Creation-Date: 2016-05-25 22:08+0200\n"
"POT-Creation-Date: 2016-05-31 15:54+0300\n"
"PO-Revision-Date: 2014-03-26 10:50+0100\n"
"Last-Translator: MR\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -473,6 +473,7 @@ msgstr ""
#, no-wrap
msgid ""
" - Roles\n"
" - [[Foundations team|contribute/working_together/roles/foundations_team]]\n"
" - [[Front desk|contribute/working_together/roles/front_desk]]\n"
" - [[Release manager|contribute/working_together/roles/release_manager]]\n"
" - [[Ticket gardener|contribute/working_together/roles/ticket_gardener]]\n"
......
......@@ -7,7 +7,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2016-05-25 22:08+0200\n"
"POT-Creation-Date: 2016-05-31 15:54+0300\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -387,6 +387,7 @@ msgstr ""
#, no-wrap
msgid ""
" - Roles\n"
" - [[Foundations team|contribute/working_together/roles/foundations_team]]\n"
" - [[Front desk|contribute/working_together/roles/front_desk]]\n"
" - [[Release manager|contribute/working_together/roles/release_manager]]\n"
" - [[Ticket gardener|contribute/working_together/roles/ticket_gardener]]\n"
......
......@@ -172,6 +172,7 @@ Collective process
- [[Marking a task as easy|contribute/working_together/criteria_for_easy_tasks]]
- [[Document progress|contribute/working_together/document_progress]]
- Roles
- [[Foundations team|contribute/working_together/roles/foundations_team]]
- [[Front desk|contribute/working_together/roles/front_desk]]
- [[Release manager|contribute/working_together/roles/release_manager]]
- [[Ticket gardener|contribute/working_together/roles/ticket_gardener]]
......
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: \n"
"POT-Creation-Date: 2016-05-25 22:08+0200\n"
"POT-Creation-Date: 2016-05-31 15:54+0300\n"
"PO-Revision-Date: 2016-04-30 11:31-0300\n"
"Last-Translator: Tails Developers <amnesia@boum.org>\n"
"Language-Team: Portuguese <LL@li.org>\n"
......@@ -507,9 +507,19 @@ msgstr ""
"[[Documentação de progresso|contribute/working_together/document_progress]]"
#. type: Plain text
#, no-wrap
#, fuzzy, no-wrap
#| msgid ""
#| " - Roles\n"
#| " - [[Front desk|contribute/working_together/roles/front_desk]]\n"
#| " - [[Release manager|contribute/working_together/roles/release_manager]]\n"
#| " - [[Ticket gardener|contribute/working_together/roles/ticket_gardener]]\n"
#| " - [[Sysadmins|contribute/working_together/roles/sysadmins]]\n"
#| " - [[Technical writer|contribute/working_together/roles/technical_writer]]\n"
#| " - [[Test suite maintainers|contribute/working_together/roles/test_suite]]\n"
#| " - [[Reports sent to sponsors|contribute/reports]]\n"
msgid ""
" - Roles\n"
" - [[Foundations team|contribute/working_together/roles/foundations_team]]\n"
" - [[Front desk|contribute/working_together/roles/front_desk]]\n"
" - [[Release manager|contribute/working_together/roles/release_manager]]\n"
" - [[Ticket gardener|contribute/working_together/roles/ticket_gardener]]\n"
......
......@@ -4,6 +4,11 @@
* 2016-08-02: Release 2.5 (Firefox 45.3; intrigeri is the RM)
- 2016-07-30: all branches for 2.5 must be merged by 6pm CEST
- 2016-07-31: build and upload the ISO image
- 2016-08-01: test suite
- 2016-08-02: release
* 2016-09-13: Release 2.6 (Firefox 45.4)
* 2016-11-08: Release 2.7 (Firefox 45.5)
......
......@@ -9,6 +9,8 @@ The choice between possible destination
devices or partitions is proposed amongst the
available removable storage devices.
[[!toc]]
Upgrades
========
......
......@@ -38,6 +38,7 @@ on Redmine.
Some minimal amount of [[advertising material|promote/material]] is available already:
* [[Logo|promote/material/logo]]
* [[Press and media information|press]]
* [[DVD label|promote/material/cd_label.pdf.gz]]
* [[Slides|promote/material/slides]]
......
[[!meta title="Foundations Team"]]
[[!toc levels=2]]
The Tails Foundations Team is responsible for:
* maintaining the core Tails system, which includes e.g.
- porting Tails to the new version of its upstream foundations, such
as a new Debian, Tor or Tor Browser;
- keeping our core code base up-to-date and maintainable, e.g.
refactor or clean up stuff that has bit-rotted, migrate code that
would otherwise rely on obsolete technologies;
- maintaining the ISO build system;
- doing the _extra_ peer-review and
[[release management|release manager]] work that corresponds to
the above bullet points;
* welcoming new code contributors, e.g. when enough mentoring is
required to put it outside of the scope of the [[release manager]]'s
duty to review code contributions;
* reviewing code contributions that are on nobody else's plate, e.g.
those submitted by the [[release manager]], and the translation
merge requests sent to <tails-l10n@boum.org>;
* ensuring that development discussions started on
<tails-dev@boum.org> are followed-up;
* if time allows, do whatever code task the project sees as
top-priority, such as fixing Holes in the Roof, important bugs, or
implementing a feature that is needed to keep Tails relevant.
......@@ -6,15 +6,15 @@
msgid ""
msgstr ""
"Project-Id-Version: \n"
"POT-Creation-Date: 2015-07-05 17:57+0200\n"
"POT-Creation-Date: 2016-05-26 20:17+0200\n"
"PO-Revision-Date: 2016-05-16 11:35+0200\n"
"Last-Translator: \n"
"Language-Team: \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.8.7.1\n"
"Last-Translator: \n"
"Language-Team: \n"
#. type: Plain text
#, no-wrap
......
......@@ -6,15 +6,15 @@
msgid ""
msgstr ""
"Project-Id-Version: \n"
"POT-Creation-Date: 2015-11-08 09:16+0100\n"
"POT-Creation-Date: 2016-05-26 20:17+0200\n"
"PO-Revision-Date: 2016-05-21 12:29-0000\n"
"Last-Translator: \n"
"Language-Team: \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.6.10\n"
"Last-Translator: \n"
"Language-Team: \n"