Commit d263896b authored by intrigeri's avatar intrigeri
Browse files

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

parents 222f23fc 5fe135ce
......@@ -225,7 +225,7 @@ po_slave_languages:
- fr|Français
- pt|Português
# PageSpec controlling which pages are translatable
po_translatable_pages: '!security/audits and !security/audits/* and (about or bugs or chat or contribute or contribute/how/donate or doc or doc/* or download or getting_started or inc/stable_i386_date or index or news or news/* or press or press/* or security or security/* or sidebar or support or support/* or todo or torrents or wishlist or misc or misc/*)'
po_translatable_pages: '!security/audits and !security/audits/* and (about or bugs or chat or contribute or contribute/how/donate or doc or doc/* or download or getting_started or inc/release_notes/* or inc/stable_i386_date or inc/stable_i386_release_notes or index or news or news/* or press or press/* or security or security/* or sidebar or support or support/* or todo or torrents or wishlist or misc or misc/*)'
# internal linking behavior (default/current/negotiated)
po_link_to: current
......
......@@ -202,7 +202,7 @@ po_slave_languages:
- fr|Français
- pt|Português
# PageSpec controlling which pages are translatable
po_translatable_pages: '!security/audits and !security/audits/* and (about or bugs or chat or contribute or contribute/how/donate or doc or doc/* or download or getting_started or inc/stable_i386_date or inc/stable_i386_release_notes or index or news or news/* or press or press/* or security or security/* or sidebar or support or support/* or todo or torrents or wishlist or misc or misc/*)'
po_translatable_pages: '!security/audits and !security/audits/* and (about or bugs or chat or contribute or contribute/how/donate or doc or doc/* or download or getting_started or inc/release_notes/* or inc/stable_i386_date or inc/stable_i386_release_notes or index or news or news/* or press or press/* or security or security/* or sidebar or support or support/* or todo or torrents or wishlist or misc or misc/*)'
# internal linking behavior (default/current/negotiated)
po_link_to: current
......
......@@ -3465,7 +3465,30 @@
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
<cc:license
rdf:resource="http://creativecommons.org/licenses/by-sa/3.0/" />
<dc:description></dc:description>
<dc:contributor>
<cc:Agent>
<dc:title>using parts of Weather-storm.svg of the tango project and Gnome-network-server.svg as well as Gnome-computer.svg by the GNOME icon artists</dc:title>
</cc:Agent>
</dc:contributor>
</cc:Work>
<cc:License
rdf:about="http://creativecommons.org/licenses/by-sa/3.0/">
<cc:permits
rdf:resource="http://creativecommons.org/ns#Reproduction" />
<cc:permits
rdf:resource="http://creativecommons.org/ns#Distribution" />
<cc:requires
rdf:resource="http://creativecommons.org/ns#Notice" />
<cc:requires
rdf:resource="http://creativecommons.org/ns#Attribution" />
<cc:permits
rdf:resource="http://creativecommons.org/ns#DerivativeWorks" />
<cc:requires
rdf:resource="http://creativecommons.org/ns#ShareAlike" />
</cc:License>
</rdf:RDF>
</metadata>
<g
......
......@@ -76,10 +76,10 @@ msgstr ""
"de son, etc."
#. type: Plain text
#, fuzzy, no-wrap
#, no-wrap
#| msgid "[[!toc levels=1]]\n"
msgid "[[!toc levels=2]]\n"
msgstr "[[!toc levels=1]]\n"
msgstr "[[!toc levels=2]]\n"
#. type: Plain text
#, no-wrap
......@@ -87,10 +87,10 @@ msgid "<a id=\"tor\"></a>\n"
msgstr "<a id=\"tor\"></a>\n"
#. type: Title =
#, fuzzy, no-wrap
#, no-wrap
#| msgid "Online anonymity and censorship circumvention with Tor\n"
msgid "Online anonymity and censorship circumvention\n"
msgstr "Anonymat en ligne et contournement de la censure avec Tor\n"
msgstr "Anonymat en ligne et contournement de la censure\n"
#. type: Plain text
#, no-wrap
......@@ -98,6 +98,8 @@ msgid ""
"Tor\n"
"---\n"
msgstr ""
"Tor\n"
"---\n"
#. type: Plain text
msgid ""
......@@ -219,27 +221,27 @@ msgid ""
"I2P\n"
"---\n"
msgstr ""
"I2P\n"
"---\n"
#. type: Plain text
msgid ""
"You can also use Tails to access [I2P](https://geti2p.net) which is an "
"anonymity network different from Tor."
msgstr ""
"Vous pouvez aussi utiliser Tails pour accéder au réseau [I2P](https://geti2p."
"net), qui est un réseau d'anonymisation différent de Tor."
#. type: Plain text
#, fuzzy
#| msgid ""
#| "[[Read more about those tools in the documentation.|doc/"
#| "encryption_and_privacy]]"
msgid ""
"[[Learn how to use I2P in Tails in the documentation.|doc/anonymous_internet/"
"i2p]]"
msgstr ""
"[[En savoir plus sur ces outils en lisant la documentation.|doc/"
"encryption_and_privacy]]"
msgstr "[[En savoir plus sur I2P dans Tails.|doc/anonymous_internet/i2p]]"
#. type: Plain text
#, fuzzy
#| msgid ""
#| "To learn more about how the usage of Tor is enforced, see our [[design "
#| "document|contribute/design/Tor_enforcement]]."
......@@ -247,8 +249,8 @@ msgid ""
"To know how I2P is implemented in Tails, see our [[design document|"
"contribute/design/I2P]]."
msgstr ""
"Pour en savoir plus sur comment l'utilisation de Tor est imposée, voir la\n"
"[[documentation de conception|contribute/design/Tor_enforcement]]."
"Pour en savoir plus sur l'implémentation d'I2P dans Tails, consultez la\n"
"[[documentation de conception|contribute/design/I2P]]."
#. type: Plain text
#, no-wrap
......
......@@ -200,3 +200,19 @@ For this to work and to be flexible, mirrors need to respond to \*.amnesia.boum.
Using this approach, giving one mirror more weight than others is very easy: Simply add it's name multiple times to the array of mirrors. :D
# PHP: first draft
// http://stackoverflow.com/questions/4233407/get-random-item-from-array
$mirrors = Array("alice.amnesia.boum.org","bob.amnesia.boum.org","clark.amnesia.boum.org","deborah.amnesia.boum.org","eric.amnesia.boum.org","freiwuppertal.amnesia.boum.org");
$mirror = $mirrors[array_rand($mirrors)];
echo "<p><a href=\"http://{$mirror}/tails/stable/tails-i386-1.4/tails-i386-1.4.iso\">Download Tails!</a></p>\n";
echo "<p>Selected mirror: {$mirror}</p>";
Try it here:
http://sandbox.onlinephpfunctions.com/code/54ffcc18e5dbbafc6c7d3c81e0c26f94ce7946fc
Note: I am a horrible coder and basically copied this from the linked StackOverflow page. This page also helped me: http://php.net/manual/de/function.echo.php
...and that's all. There might be security flaws in this extremely simple concept, so please have a close look at it. :)
Having absolute catenary ashes during Sebring additionally, the after consecutive an term abominable needs very adequately. But these loans are admired will absolutely even back by depositing the X in your bank. ,
......@@ -2,122 +2,27 @@ Corresponding ticket: [[!tails_ticket 8007]]
[[!toc levels=2]]
Things to check
Remaining to do
===============
* the kludges needed to make them work with aufs
* access to files via alternate paths specific to Debian Live systems,
e.g.
- check `private-files` and `private-files-strict` abstractions, in
particular wrt. whatever can be accessed via the following paths
- is there any alternate path to `/live/persistence`?
- `/lib/live/mount/overlay/` -- until Tails 1.4~rc1, we have _two_
`tmpfs` mounted there, including an empty one that hides the
other's content (but we should not rely on this for security).
Fixed on the `bugfix/8007-AppArmor-hardening` branch with
[[!tails_gitweb_commit bc491c9]], and then:
* test that this doesn't break persistence in read-write mode
* test that this doesn't break persistence in read-only mode
* test that this doesn't break booting an upgraded Tails with
more that one SquashFS
* test how AppArmor confinement behaves wrt. `/live/overlay`
(that's a symlink to `/lib/live/mount/overlay`, created in
[[!tails_gitweb_commit 3233da6]]; maybe it's not needed
anymore?)
* test how AppArmor confinement behaves wrt.
`/lib/live/mount/overlay` (at least it blocks access for Evince
to `/lib/live/mount/overlay/home/amnesia/.gnupg/default.pdf`)
* we add `/lib/live/mount/overlay/home/` to `HOMEDIRS`, so at
least `$HOME` is OK -- isn't it?
- recheck all these things with persistence in read-only mode
* wide-open access to `/lib/**` or similar, that might grant access to
persistent files -- everything checked, potential issues and
remaining todo items follow:
- the `base` abstraction (used e.g. by Pidgin and Evince) has things
like `/lib{,32,64}/** r`
- the `launchpad-integration` abstraction has
`/{,usr/}lib*/{,**/}*.so{,.*} m`
- the `ubuntu-helpers` abstraction has
`/{,usr/,usr/local/}lib{,32,64}/{,**/}*.so{,.*} m`
* access to microphone (can we easily block that while still allowing
sound output?)
- `abstractions/audio` gives full access to PulseAudio, which
no doubt gives access to the microphone; we use that abstraction
for Totem, Tor Browser, Evince and Pidgin. The Ubuntu phone
mediates access to PulseAudio at the D-Bus level. As of
2015-05-04:
* this is only done at the AppArmor level. There is WIP to [make
PulseAudio a trusted helper for microphone
access](https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1224756).
The "trust-store" is a library (external to AppArmor) that
services can use. it can prompt, remember the answer, etc.
It's currently limited to mir. It can also be preseeded.
jdstrand is not sure if there is a CLI for that, but that could
be another option. The broader picture is described in
<https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement>
and in the phone-specific bits at
<https://wiki.ubuntu.com/AccountPrivileges>.
* AppArmor support for D-Bus mediation has made it into D-Bus
upstream, but the kernel bits have not been upstreamed yet.
- regarding Alsa:
* `/dev/snd/pcmC[0-9]D[0-9]c` raw audio devices seem to be capture,
while `/dev/snd/pcmC[0-9]D[0-9]p` devices seem to be playback
devices
* do `/dev/snd/hwC[0-9]D[0-9]` give access to the microphone?
* do `/dev/controlC[0-9]` give access to the microphone?
* does `/dev/snd/seq` give access to the microphone?
* does `/dev/snd/timer` give access to the microphone?
* wide-open access to `$HOME` except blacklist -- everything checked,
potential issues and remaining todo items follow:
- Evince, Totem and their previewers have read-write access to
`@{HOME}/**`: perhaps we can make it a bit tighter, e.g.
using a regexp that doesn't include dotfiles (see `user-write`),
and read-only everywhere except for specific directories? Or is
the blacklist used by these profiles tight enough?
- What else uses `private-files` and
`private-files-strict` abstractions?
- Shall we add stuff to these blacklist?
* jvoisin's profile hardening
- Pidgin
* drop `bash` abstraction: has been here since the first version
of the profile; that abstraction is not too scary, but... what
is it useful for?
* disable video and audio visualization capabilities: if it
doesn't break e.g. accessibility or sound notifications, why not
- `/usr/bin/evince`
* drop `bash` abstraction: same as Pidgin
* drop `audio` and `ubuntu-media-players` abstraction: note that
PDF can embed videos; do we care?
* drop `ubuntu-console-browsers`, `ubuntu-console-email` and
`ubuntu-gnome-terminal` abstractions: I doubt it's useful to
anyone in Tails, indeed
* disallow `/usr/bin/yelp`: if it breaks displaying Evince help,
we don't want that
* disallow `/usr/bin/bug-buddy`: Ubuntu-specific, we don't care
* disallow `/usr/bin/exo-open` and a bunch of file managers that
are not shipped in Tails: not worth maintaining a delta
* disallow `/usr/bin/gedit`: a comment in the profile says it's
useful "for text attachments", and given it's inheriting the
current profile it's not scary enough to be worth potentially
breaking things
- `/usr/bin/evince-previewer`
* same changes as in `/usr/bin/evince` profile, same comments
* drop `ubuntu-browsers` abstraction: it doesn't cover Tor Browser
anyway, so why not
* drop `ubuntu-email` abstraction: do we care about Evince
previewer being able to start Claws Mail? What is it useful for?
* disallow networking access: the Debian kernel doesn't support
such rules anyway, so that would be a no-op
* `config/chroot_local-includes/usr/share/tails/torbrowser-AppArmor-profile.patch`
Things to keep in mind
======================
* Beware not to break assistive technologies (accessibility).
See [[blueprint/harden_AppArmor_profiles]].
Checked already
===============
Could be improved later
-----------------------
See [[blueprint/harden_AppArmor_profiles]].
Currently OK
------------
As of 20150604, some of those are OK in
`bugfix/8007-AppArmor-hardening`, but not in current `stable`.
Unless they're worth special treatment, all changes made as a result
of this audit should land together into Tails 1.5.
* Ux rules don't sanitize `$PATH`
(<https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1045986>) =>
they must only be used to run software that does *not* rely on
......@@ -128,7 +33,7 @@ Checked already
- the Tor Browser one: **OK**, the only `Ux` rule it has is about an
ELF executable
- Pidgin profile: was vulnerable via `/usr/local/bin/tor-browser`,
fixed in `bugfix/8007-AppArmor-hardening`
fixed in Tails 1.4
- `abstractions/tor`: only `Ux` rules are about ELF executables
- no other relevant `Ux` rule are present in the profiles we ship
* use of `sanitized_helper` [isn't very
......@@ -176,3 +81,52 @@ Checked already
- `/lib/live/mount/rootfs/` and `/lib/live/mount/medium/` should be
OK: they only contain stuff that's publicly available in our ISO
anyway, and DAC still applies.
- there's no alternate path to `/live/persistence`
- `/lib/live/mount/overlay/` -- until Tails 1.4, we have _two_
`tmpfs` mounted there, including an empty one that hides the
other's content (but we should not rely on this for security).
Fixed on the `bugfix/8007-AppArmor-hardening` branch with
[[!tails_gitweb_commit bc491c9]]. Note that there's also
`/live/overlay` (that's a symlink to `/lib/live/mount/overlay`,
created in [[!tails_gitweb_commit 3233da6]]). Follow-up fixes and
corresponding new automatic tests (in `torified_browsing.feature`,
`pidgin.feature`, `evince.feature` and `totem.feature`) were added
on `bugfix/8007-AppArmor-hardening`; the full test suite passes,
and the new bits were validated by manual testing.
- persistence in read-only mode doesn't bring any additional
alternate path
- `private-files` and `private-files-strict` abstractions do the
right thing wrt. `/lib/live/mount/overlay/home/`, since we add it
to @{HOMEDIRS}
* wide-open access to `/lib/**` or similar, that might grant access to
files via alternate paths -- everything checked, potential issues were:
- the `base` and `ubuntu-helpers` abstraction have things
like `/lib{,32,64}/** r`: this was patched when introducing
aliases ([[!tails_gitweb_commit 6e48b6d]])
- the `launchpad-integration` abstraction has things like `/** rwlk`
and `/{,usr/}lib*/{,**/}*.so{,.*} m`; it's harmless since it only
gives such rights to an executable we don't ship, and it's
included by the Pidgin profile only, which for good measure we
disabled with [[!tails_gitweb_commit 551d372]] on
`bugfix/8007-AppArmor-hardening`
* the kludges needed to make them work with aufs: everything replaced
with aliases (and other kludges) in [[!tails_gitweb_commit 6e48b6d]]
* wide-open access to `$HOME` except blacklist -- everything checked,
in particular:
- Apart of Evince and Totem profiles (discussed elsewhere), only
Pidgin uses one of the `private-files` and `private-files-strict`
abstractions, but it doesn't have any wide-open access rules like
Evince or Totem have.
* `config/chroot_local-includes/usr/share/tails/torbrowser-AppArmor-profile.patch`
- can tell that it's running in Tails: unavoidable in the current
state of things
- quite some avenues for fingerprinting of the hardware being used:
unavoidable without adding virtualization to the mix
- gives access to `machine-id`: in the current state of things, that
tells what exact version of Tails is running; depending on how
[[!tails_ticket 7100]] is addressed, this may become worse; such
access was allowed so that the browser can play sound with
PulseAudio (commit 371ba40 in our torbrowser-launcher Git repo);
if such access is denied, then Tor Browser plays sound directly
with Alsa, which makes UX worse... and breaks our automated tests.
We'll deal with that as part of [[!tails_ticket 7100]].
......@@ -9,9 +9,8 @@ branches").
Some metrics about the number of branches merged per releases are
available on the [[dedicated statistics page|autobuild_stats]].
Our Jenkins now has the Global Build Stats plugin live, Tails developers
[[have access to the metrics|
https://jenkins.tails.boum.org/plugin/global-build-stats/]]
Our Jenkins now has the Global Build Stats plugin live, Tails core developers
[have access to the metrics](https://jenkins.tails.boum.org/plugin/global-build-stats/).
[[!toc levels=2]]
......@@ -84,7 +83,7 @@ This locally-merge-before-building process requires [[!tails_ticket
## When to build it
Define the regularity we want to build topic branches, apart from being build
Define the regularity we want to build topic branches, apart from being built
on Git push or new Debian package upload.
Note that we will have to plug that in automatic tests when they will be
......@@ -105,7 +104,12 @@ Email will be the main interface.
* For topic branches, notify the author of the last commit.
Note that this proposal doesn't take into consideration how to notify
when the branch is build because of a Debian package upload.
when the branch is built because of a Debian package upload.
An alternative for topic branches we might want to use in the future is to
notify all authors of the topic branch since it deviated from the base branch:
git log --pretty="format:%an <%ae>" ${BASE_BRANCH}.. | sort -u
# Scenarios
......@@ -223,7 +227,7 @@ might want to consider it in the future.
# Statistics
As of 2015-02-02, there are 26 branches that would be automatically
build as part of the next 1.3 release, following the for now defined
built as part of the next 1.3 release, following the for now defined
criterias (above in this blueprint):
* feature/7779-revisit-touchpad-settings
......
[[!meta title="Automated tests specification"]]
*Ticket*: [[!tails_ticket 8667]]
This blueprint helps to keep track of the discussions and decisions
about the specification of automated tests ran in Tails' Jenkins on
the [[automatically build ISOs|autobuild_specs]] ([[!tails_ticket 5288]]).
[[!toc levels=2]]
# Facts
Running the full test suite on 1 isotester hosted on Lizard takes
around 8 hours.
We intend to run __4 isotesters__, so at the moment we would be able
to run __16 full test suites__ per day.
We have 2 isobuilders on Lizard, that build a total of a bit less than
__400 ISOs/month__ (that's __an average of 13 ISOs/day__).
At the moment, we build __from 6 ISOs to 30-40 ISOs a day__, depending
on the activity.
We usually build the _stable_, _devel_, _experimental_,
_feature/jessie_ (+ _testing_ sometimes) and a bunch of other
branches
This numbers are expected to grow when the automated builds will be
put in production. It's difficult to guess what would the maximum
number of builds per day be, but the minimum should be expected to
raise to in between __10/20 ISOs/day__.
# Things to keep in mind
There will probably be new hardware at the end of the year to deploy
more isotesters. If a machine is dedicated to that usage, we can throw
in faster CPUs and run the test suite on bare metal, which would
speed up the test process. That's [[!tails_ticket 9264]].
So in the discussion, we have to think to a deployment that might
have two iterations with different computational powers (those
different amounts of tests/day possible), and the defined
implementation should be modular enough to handle both of them without
too much changes.
# Questions
<a id="when-to-test-the-builds"></a>
## When to test the builds
It doesn't sound reasonable to run the full test suite on every ISO
automatically built by Jenkins, at least in the first iteration.
We __need to lessen the number of tests per day__. Probably even in
the second iteration, with the expected growth of the number of
automated builds.
Some ideas that could help:
We can maybe split the design between the type of branches being built
and tested:
* for base branches, we could envisage to run the full test suite on
every automatically built ISO (every git push and daily builds) if
we think that is relevant.
* for feature branches, we could run the full test suite only on the
daily builds, and either only the automated tests related to the
branch on every git push, and/or a subset of the whole test suite.
We can also consider testing only the feature branch that are marked
as ReadyforQA as a beginning, even if that doesn't cover Scenario 2
(developers).
We can also maybe find more ways to split the automated test suite in
faster subsets of feature depending on the context, define priorities
for built ISO and/or tests.
<a id="how-to-run-the-tests"></a>
## How to run the tests
This section heavily depends on the discussion about the previous one.
The automated test suite MUST have access to the artifacts of a given
automated build corresponding to a given commit, as well as to the
ISOs of the previous Tails releases.
The automated test suite MUST be run in a clean environment.
The automated test suite MUST be run on a freshly built ISO,
corresponding to the commit it tests.
The automated test suite MUST be able to run features in parallel
for a single automated build ISO. This way, if more than one isotester
are idle, it can use several of them to test an ISO faster.
The automated suite SHOULD be able when there are more than one ISO
queued for testing to fairly distribute the parallelizing of their
features.
The automated test suite MUST not allocate all the isotesters for one
ISO when others are waiting to be tested.
The automated test suite MUST be able to accept a treshold of failures
for some features before sending notifications. This can help if a
scenario fails because of a network congestion, but other use cases
will probably raise.
## Notifications
Email will be the main interface. Use the same settings than for
automated builds:
* For base branches, notify the RM.
* For topic branches, notify the author of the last commit.
# Scenarios
In the following scenario:
0. topic branches are named branch F
0. base branches are named branch B
We also assume that the following scenarios expectations only cover
the test suite artifacts, the ISO one being covered in the automated
builds specification.
## Scenario 1 : reviewer
As a reviewer
When I'm asked to review branch F into branch B
Then I need to know if branch F passes the automated tests
once locally merged into branch B and built (fresh results!)
And if all the automated tests scenarios suceeded
The resulting test logs must be made available to me
The Redmine ticket should be notified
Otherwise the developer who proposed the merge must be notified
And the developer *needs* to see the test logs and screenshots
And the ticket should be reassigned to the branch submitter
And QA check should be set to "Dev needed"
## Scenario 2 : developer
As a developer who has the commit bit
When I'm working on branch F
Then I need to know if my branch passes the automated tests suite
once locally merged in base branch B
And I need to know if my branch fails to pass the automated test
suite because of an external change possibly weeks after my
last commit (by e.g Debian changes, changes in branch B, ...)
And if my branch passes the automates test suite
The resulting test logs must be made available to me
The Redmine ticket should be notified
Otherwise I *need* to see the build logs and screenshots
And the developer who proposed the merge must be notified
And the ticket should be reassigned to the branch submitter
And QA check should be set to "Dev needed"
## Scenario 3 : RM
As the current RM
When working the full dev release cycle
Then I need to know if a base branch does not pass the automated
test suite
And when this happens the build logs and screenshots must be made
available to me.
# Future ideas
This list other scenarios that we have also envisaged for the second
iteration of the automated builds deployment, as they are really
tightened.
## Scenario 10
As a Tails developer working on branch B
When I upload a package to APT suite B
Then I want to know if the automated test suite passes
(same responsiveness as when pushing to git)
(acceptable workaround: being able to manually trigger a test suite.)
## Scenario 11
As the current RM
When I push new tag T on branch B
Then I want the APT suite for tag T to be created
And I want the APT suite B to be copied into the APT suite T
And once this is done, I want the automated test suite to be run
on the ISO build from the checkout of tag T
## Scenario 12
As a Tails developer
When the test suite is ran on the ISO build from my last commit
I want to watch TV and see the test video in HTML5 from the Tor Browser
## Scenario 14
As a Tails developer
When I push a new commit or a new Debian package to a base branch
I want the affected feature branches ISO to be tested with that change
......@@ -140,3 +140,24 @@ Jenkins for Perl projects
* [another tutorial](http://alexandre-masselot.blogspot.com/2011/12/perl-hudson-continuous-testing.html)
* use [[!cpan TAP::Formatter::JUnit]] (in Wheezy) rather than the Jenkins TAP plugin
* use `prove --timer` to know how long each test takes
Restarting slave VMs between jobs
---------------------------------
When we tackle [[!tails_ticket 5288]], if the test suite doesn't
_always_ clean between itself properly (e.g. when tests simply hang
and timeout), we might want to restart `isotesterN.lizard` between
each each ISO testing job.