Commit ec9b75c6 authored by Tails developers's avatar Tails developers

Merge branch 'doc/5636-accessHD' into doc/7143-virtualization

parents 565c14d0 43a37d98
......@@ -61,8 +61,7 @@ In the folowing scenario:
0. topic branches are named branch T
0. base branches are named branch B
0. Builds are ran on merges which don't raise a conflict, and this is the topic
branch's dev to take care of that.
0. builds are ran on merges which don't raise a conflict. If the merge raises a conflict, then the topic branch's developpes should take care of resolving it.
## Scenario 1 : reviewer
......@@ -76,9 +75,9 @@ In the folowing scenario:
I might want to download the resulting ISO
I might want to get the pkg list
I want the redmine ticket to be notified (optional feature)
Otherwise if it fails I _need_ to see the build logs
And the developer who proposed the merge should be notified
And the ticket shouldn't be reassigned to the branch submitter
Otherwise if it fails the developer who proposed the merge should be notified
And the developper _need_ to see the build logs
And the ticket should be reassigned to the branch submitter
And QA check should be set to `Dev needed`
......@@ -88,15 +87,15 @@ In the folowing scenario:
When I'm working on branch T
Then I need to know if my branch builds after I've pushed
And I need to know if my branch build is broken by something else
possibly weeks after my last commit by e.g Debian changes,
changes in branch B...
possibly weeks after my last commit (by e.g Debian changes,
changes in branch B, ...)
And if the build succeeded
I might want to download the resulting ISO
I might want to get the pkg list
I want the redmine ticket to be notified (optional feature)
Otherwise if it fails I _need_ to see the build logs
And the developer who proposed the merge should be notified
And the ticket shouldn't be reassigned to the branch submitter
And the ticket should be reassigned to the branch submitter
And QA check should be set to `Dev needed`
......@@ -115,7 +114,7 @@ might want to consider it in the future.
## Scenario 1
As a tails developer working on branch B
As a Tails developer working on branch B
When I upload a package to APT suite B
Then I want to know if it broke the build ASAP
......@@ -126,7 +125,7 @@ might want to consider it in the future.
## Scenario 2
As the current RM
When I push new tag T on branch
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 a build from the checkout of tag T to be
......@@ -140,3 +139,9 @@ might want to consider it in the future.
When the test suite is ran on the ISO build from my last commit
I want to watch the TV and see the test video in HTML5 from a Torbrowser
## Scenario 4
As a Tails developper
When an ISO is build from my last commit
I want to access it throught remote desktop (VNC/Spice/...) over Tor
......@@ -73,39 +73,40 @@ Grsync is [packaged for debian](https://packages.debian.org/squeeze/grsync).
The documentation for the creation of the encrypted device [[is already written|doc/encryption_and_privacy/encrypted_volumes]].
### Pros
* not that much things to code
* grsync can be easily preconfigurated, eventually with multiple profiles
* this solution separate backup and encryption work
* allows remote backups
### Cons
* seems not really actively developped
* not possible to do incremental backups
* needs a separate encrypted device for backups or reuse the "loopback LUKS"
solution
* does not check if enough space is available on the destination before running
### How to test?
* create an encrypted device.
* install the grsync package.
* paste [those lines](http://dustri.org/p/38e76b) in a .grsync file, then double-click on it.
* paste [those lines](https://paste.debian-facile.org/view/raw/a7a7fe3c) in a `.grsync` file, then double-click on it.
(grsync ask you first to confirm the profile you want to use. Just click on "Open")
* define the destination (i.e your encrypted device)
* test wildly! and please report your results
### Todo
### Pros
* not that much things to code
* grsync can be easily preconfigurated, eventually with multiple profiles
* this solution separates backup and encryption work
* allows remote backups
### Features to request
* grsync should check if enough space is available on the destination before running.
Update: rsync 3.1.0 [introduces](https://rsync.samba.org/ftp/rsync/src/rsync-3.1.0-NEWS) a `--preallocate` option.
(Tails actually ships rsync 3.0.9)
* grsync should ask for confirmation when the option "Delete on the destination" is activated
* when user double-click on a `.grsync` file, a window appears to confirm which file to open. This may be confusing.
### Misc
* some files are normally not readable by rsync (for example persistence.conf, apt/*)
Grsync can bypass that with the option "Run as superuser", we should investigate the consequences of using such an option.
We still have the possibility to ignore those files: we just have then to add `--exclude="apt"` in the preconfiguration file.
* decide if we activate the option `--delete` by default.
* test restoration (see File → Invert source and destination), then at least check files permissions.
* test restoration (see File → Invert source and destination). Then, at least, check files permissions.
* test backup + restoration with symlinks and hardlinks in the Persistent folder.
* eventually test remote backups.
* see the [thread on tails-dev](https://mailman.boum.org/pipermail/tails-dev/2015-January/007931.html)
rdup
----
......
......@@ -23,6 +23,21 @@ Bonus:
* Arch: 1.3.2
* Fedora: 1.3.0 flagged as stable, 1.3.2 in testing
API stability and backwards-compatibility
=========================================
- "all [Docker] containers are backwards compatible, pretty much to
the first version. [...] In general backwards compatibility is a
big deal in the Docker project"
([source](https://news.ycombinator.com/item?id=7985142), shykes
is a Docker developer)
- Apparently the Docker 1.0 release broke older stuff, see e.g. the
0.6 release in
[the jenkins plugin changelog](https://wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin).
- Environment replacement was formalized in Docker 1.3, and the new
behavior ["will be
preserved"](https://docs.docker.com/reference/builder/#environment-replacement).
Random notes
============
......@@ -47,3 +62,55 @@ Random notes
[[dedicated blueprint|blueprint/Linux_containers]].
* [overclockix](https://github.com/mbentley/overclockix) uses
live-build and provides a Dockerfile for easier building.
* overlayfs support was added in Docker 1.4.0; we'll need that when
using Debian Stretch/sid once Linux 3.18 lands in there after
Jessie is released.
Test run
========
(20150120, Debian sid host, `feature/7530-docker` Git branch)
sudo apt --no-install-recommends install docker.io aufs-tools
sudo adduser "$(whoami)" docker
su - "$(whoami)"
make
* `TAILS_BUILD_OPTIONS="noproxy"` => run [apt-cacher-ng in a different
container](https://docs.docker.com/examples/apt-cacher-ng/)
* Even with `--cache false`, some directories (`chroot`, `cache`) are
saved and retrieved from the container upon shutdown; same for
live-config -generated `config/*` files. That's because the current
directory is shared read-write with the container somehow.
This bind-mount should be read-only, but we still need to get the
build artifacts back on the host:
- see [Managing data in
containers](https://docs.docker.com/userguide/dockervolumes/)
- use `VOLUME` to share (read-write) the place where the build
artifacts shall be copied
* We're currently using the `debian:wheezy` template, that likely we
should not trust. How should we build, maintain, publish and use
our own?
* Being in the `docker` group is basically equivalent to having full
root access. Do we want to encourage contributors to do that, or
to run `docker` commands with `sudo`, or to use Docker in
a virtual machine?
* We currently pass `--privileged` to `docker run`. Should we remove
it, and if yes, how?
- According to
<https://docs.docker.com/articles/dockerfile_best-practices/>,
"many of the “essential” packages from the base images will fail
to upgrade inside an unprivileged container". It seems that
the best practice is to publish _and regularly update_ a base
image, so that the most common usecases can avoid the APT upgrade
steps, and then run unprivileged.
* Adding `.git` to the `.dockerignore` file would speed up the build,
but some code in our build process wants to know what branch or
commit we're building from => maybe we could pre-compute this
information, and pass it to the build command in some way?
* What execution environment do we want to support? Only LXC
via libcontainer? Any usecase for e.g. the systemd- or
libvirt-based ones?
* Move more stuff from `Makefile` to `Dockerfile`? E.g. `DOCKER_MOUNT`
could be specified as `VOLUME`. Can we specify the build command as
`CMD`?
......@@ -15,3 +15,4 @@ Discussions
- [[!tails_ticket 6432 desc="WhisperBack launcher in the applications menu should give a hint about its function"]]
- [[!tails_ticket 7076 desc="Warn against plugging a Tails device in untrusted systems"]]
- [[!tails_ticket 8253 desc="a tool to quickly edit (resize...) pictures"]]
- [[!tails_ticket 8796 desc="Consider using the purple of the logo as background color"]]
......@@ -11,9 +11,10 @@ Goals of our Vagrant thing
2. Improve consistency between our various ways of building Tails ISOs
(Tails developers currently use at least 3 different build setups,
and our auto-builder yet another one).
3. Ideally, our "easy build" instructions should work at least on:
3. Our "easy build" instructions must work at least on:
- Debian stable + backports
- Debian testing
4. Ideally, our "easy build" instructions should also work at least on:
- latest Ubuntu LTS
- latest Ubuntu non-LTS
......@@ -38,7 +39,7 @@ What we have
- retrieve the build artifacts from the build VM onto the host system
* Vagrant hasn't been actively maintained in Debian for a while.
It'll likely be part of Jessie, but that's by a very short margin.
It'll be part of Jessie, but that was by a very short margin.
* VirtualBox vs. QEMU/KVM:
- One can't run both VirtualBox and QEMU/KVM on the same system.
......
[[!toc levels=2]]
Related pages
=============
* [[!tails_ticket 5525]]
* [[blueprint/Mandatory_Access_Control]]
* [[contribute/design/application_isolation]]
Status
======
## automated test passes
(needs to be run again with current status of the branch at some point)
* feature/i2p (unconfined)
* feature/torified_browsing
* feature/unsafe_browser (unconfined)
* feature/windows_camouflage
* open `https://` URL from Pidgin
* relevant bits of feature/usb_install
- view persistent bookmarks, in read-only persistence mode ([[!tails_ticket 8787]])
- persistent bookmarks, RW
## manual test OK
(needs to be tested again with current status of the branch at some point)
* add NoScript exception
* change stuff in about:prefs
* manually update AdBlock Plus lists
* add a bookmark, with persistent bookmarks feature enabled, in
read-only persistence mode
## manual test OK, maybe needs automated test
* download to non-persistent ~/Downloads
* YouTube audio and video playback
* non-YouTube HTML5 video playback
* "Tails documentation" link on the Desktop ([[!tails_ticket 8788]])
## broken
## needs testing
* download to persistent ~/Downloads, in read-write persistence mode
* download to persistent ~/Downloads, in read-only persistence mode
* upload from non-persistent ~/Downloads
* upload from persistent ~/Downloads, in read-write persistence mode
* upload from persistent ~/Downloads, in read-only persistence mode
* import OpenPGP key from website (if supported in 1.2.3)
* click email address on a website (if supported in 1.2.3)
* install a Firefox add-on (this does not mean we actively support that, right? :)
User experience matters
=======================
Downloading files
-----------------
Tor Browser will be allowed to save files in
`/home/amnesia/Downloads/` only.
doc++: where to download, how to upload
Usability issue: if not enough space in RAM for hosting ~/Downloads/
* added a persistence setting for Downloads
* added a GNOME bookmark called "Downloads" when the Downloads
persistence feature is enabled; remaining questions:
- Rename this bookmark "Persistent Downloads"? But then users may
lose data by mistake when they use read-only persistence option.
OTOH, we have had a "Persistent" bookmark for years, even in
read-only persistence mode, and nobody complains.
- Rename this persistent directory and the corresponding bookmark to
include the "Uploading files" use case? (see below)
Uploading files
---------------
Basically the same problem as for downloading files. Is it better to
share a common whitelisted directory, or to add a different one to
the whitelist?
Document that one should put files in the `/home/amnesia/Downloads`
folder before uploading them, and make sure that it's the folder
selected by default when clicking a "Browse" upload button on
a website?
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-11-30 02:25+0100\n"
"POT-Creation-Date: 2015-01-25 19:23+0100\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"
......@@ -465,6 +465,13 @@ msgstr ""
"[[Kalender|contribute/calendar]] der Veröffentlichungen, Treffen, "
"Arbeitsbesprechungen etc."
#. type: Bullet: ' - '
#, fuzzy
#| msgid "[[Document progress|contribute/working_together/document_progress]]"
msgid "[[Code of conduct|contribute/working_together/code_of_conduct]]"
msgstr ""
"[[Fortschritte dokumentieren|contribute/working_together/document_progress]]"
#. type: Bullet: ' - '
#, fuzzy
#| msgid "[[Meetings|contribute/meetings]], and minutes from past meetings"
......
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: \n"
"POT-Creation-Date: 2014-11-30 02:25+0100\n"
"POT-Creation-Date: 2015-01-25 19:23+0100\n"
"PO-Revision-Date: 2014-03-26 10:50+0100\n"
"Last-Translator: MR\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
......@@ -437,6 +437,10 @@ msgid ""
"etc."
msgstr ""
#. type: Bullet: ' - '
msgid "[[Code of conduct|contribute/working_together/code_of_conduct]]"
msgstr ""
#. type: Bullet: ' - '
msgid ""
"[[Contributors meetings|contribute/meetings]], and minutes from past meetings"
......
......@@ -164,6 +164,7 @@ Collective process
==================
- [[Calendar|contribute/calendar]] of releases, meetings, working sessions, etc.
- [[Code of conduct|contribute/working_together/code_of_conduct]]
- [[Contributors meetings|contribute/meetings]], and minutes from past meetings
- [[contribute/Low-hanging_fruit_sessions]]
- [[Marking a task as easy|contribute/working_together/criteria_for_easy_tasks]]
......
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-11-30 02:25+0100\n"
"POT-Creation-Date: 2015-01-25 19:23+0100\n"
"PO-Revision-Date: 2014-05-23 14:56-0300\n"
"Last-Translator: Tails Developers <amnesia@boum.org>\n"
"Language-Team: Portuguese <LL@li.org>\n"
......@@ -468,6 +468,13 @@ msgstr ""
"[[Calendário|contribute/calendar]] de lançamentos, reuniões, sessões de "
"trabalho, etc."
#. type: Bullet: ' - '
#, fuzzy
#| msgid "[[Document progress|contribute/working_together/document_progress]]"
msgid "[[Code of conduct|contribute/working_together/code_of_conduct]]"
msgstr ""
"[[Documentação de progresso|contribute/working_together/document_progress]]"
#. type: Bullet: ' - '
#, fuzzy
#| msgid "[[Meetings|contribute/meetings]], and minutes from past meetings"
......
......@@ -2,6 +2,13 @@
[[!toc levels=2]]
Git repository and branches
===========================
You will need to clone the Tails Git repository, and to checkout the
branch that you want to build (most likely, _not_ `master`): learn
more about [[our Git branches layout|contribute/git#main-repo]].
<a id="vagrant"></a>
Using Vagrant
......
......@@ -2,9 +2,28 @@
* 2015-02-03: [[Monthly meeting|contribute/meetings]]
* 2015-03-12: [[Low-hanging fruits session|contribute/low-hanging_fruit_sessions]]
* 2015-02-24: Release 1.3. anonym is [[contribute/working_together/roles/release_manager]]
* 2015-02-11:
- Feature freeze for Tails 1.3.
- Translation window starts for Tails 1.3.
- Build and upload Tails 1.3~rc1 ISO image and IUKs.
- Start testing Tails 1.3~rc1 during late CET?
* 2015-02-12:
- Finish testing Tails 1.3~rc1 by the afternoon, CET.
- Release Tails 1.3~rc1 during late CET.
* 2015-02-12: [[Low-hanging fruits session|contribute/low-hanging_fruit_sessions]]
* 2015-02-23:
- All translations and bug fixes targeting Tails 1.3 must be merged
into the 'testing' branch.
- Tor Browser 4.x, based on Firefox 31.5.0esr is *hopefully* out.
- Build and upload Tails 1.3 ISO image and IUKs.
- Start testing Tails 1.3 during late CET?
* 2015-02-24:
- Finish testing Tails 1.3 by the afternoon, CET.
- Release Tails 1.3 during late CET.
* 2015-03-03: [[Monthly meeting|contribute/meetings]]
......
......@@ -577,6 +577,15 @@ Both with the old and new Tails upgrade systems, mounting such an
attack requires either to take control of the Tails website or to
break the SSL/TLS connection between the client and the server.
This attack is slightly mitigated by the fact that we are announcing
new releases in other ways:
* one that does not rely on our website at all (Twitter);
* one that does not rely on our website to be safe at the time Tails
Upgrader checks for available upgrades, as long as it was safe at
the time the new release was published (<amnesia-news@boum.org>
announce mailing-list).
The move to a secure upgrade system, such as TUF, would make this
stronger, thanks to short-lived signatures on meta-data.
......@@ -599,6 +608,10 @@ The upgrade-description files downloader and verifier could refuse to
download upgrade-description files bigger than some reasonable
constant, but this is not implemented yet.
This attack, when performed against the upgrade-description files
downloader and verifier is slightly mitigated in the same way as
"Indefinite freeze attacks" are.
### Slow retrieval attacks
> An attacker responds to clients with a very slow stream of data that
......
......@@ -78,6 +78,8 @@ Creating a new repository
Repositories
============
<a id="main-repo"></a>
Main repository
---------------
......
......@@ -787,6 +787,15 @@ Tor weekly news
Write a short announcement for the Tor weekly news, or find someone
who's happy to do it.
Amnesia news
------------
The release notes should have been automatically sent to
`amensia-news@` (thanks to the `announce` flag) but it will be stuck
in the moderation
queue. [Log in](https://mailman.boum.org/admindb/amnesia-news) and
accept it.
Prepare for the next release
============================
......
......@@ -574,6 +574,11 @@ Enable Windows camouflage via the Tails Greeter checkbox and:
# Documentation
* The "Tails documentation" desktop launcher should open the
[[getting started]] page (automate: [[!tails_ticket 8788]]):
- in English
- in one language to which the website is translated
- in one language to which the website is not translated (=> English)
* Browse around in the documentation shipped in the image. Internal
links should be fine.
......
[[!meta title="Code of conduct"]]
Like the technical community as a whole, the Tails team and community
is made up of a mixture of people from all over the world, working on
every aspect of the mission &mdash; including mentorship, teaching, and
connecting people.
Diversity is one of our huge strengths, but it can also lead to
communication issues and unhappiness. To that end, we have a few
ground rules that we ask people to adhere to when they’re
participating within this community and project. These rules apply
equally to founders, mentors and those seeking help and guidance.
This isn’t an exhaustive list of things that you can’t do. Rather,
take it in the spirit in which it’s intended &mdash; a guide to make it
easier to enrich all of us and the technical communities in which
we participate.
This policy applies to all spaces used by the Tails project. This
includes IRC, the mailing lists, the issue tracker, the website,
events, and any other forums which the community uses for
communication.
If you believe someone is violating this policy, we ask that you
report it by emailing <tails@boum.org>
* **Be welcoming, friendly, and patient.**
* **Be considerate.** Your work will be used by other people, and you
in turn will depend on the work of others. Any decision you take
will affect users and other contributors, and you should take those
consequences into account when making decisions. Remember that we’re
a world-wide community, so you might not be communicating in someone
else’s primary language.
* **Be respectful.** Not all of us will agree all the time, but
disagreement is no excuse for poor behavior and poor manners.
We might all experience some frustration now and then, but we cannot
allow that frustration to turn into a personal attack. It’s
important to remember that a community where people feel
uncomfortable or threatened is not a productive one. Members of the
Tails community should be respectful when dealing with other members
as well as with people outside the Tails community.
* **Be careful in the words that you choose.** Be kind to others.
Do not insult or put down other participants. Harassment and other
exclusionary behavior aren’t acceptable. This includes, but is not
limited to:
- Violent threats or language directed against another person.
- Sexist, racist, or otherwise discriminatory jokes and language.
- Exhibiting sexually explicit or violent speak or material.
- Publishing (or threatening to publish) other people’s personally
identifying information ("doxing").
- Recording, photographing or filming other persons without their
consent. Seek consent before recording. Also ask people who may be
seen or heard in the background. Similarly, don't publish private
communication without asking first, except if the communication
was unwanted (harrassment, threats etc). In doubt, you can ask us
before publishing something.
- Personal insults, especially those using racist or sexist terms.
- Unwelcome sexual attention.
- Advocating for, or encouraging, any of the above behavior.
- Repeated harassment of others. In general, if someone asks you to
stop, then stop.
* **When we disagree, try to understand why.** Disagreements, both
social and technical, happen all the time and Tails is no exception.
It is important that we resolve disagreements and differing views
constructively. Remember that we’re different. The strength of Tails
comes from its varied community, people from a wide range of
backgrounds. Different people have different perspectives on issues.
Being unable to understand why someone holds a viewpoint doesn’t
mean that they’re wrong. Don’t forget that it is human to err and
blaming each other doesn’t get us anywhere. Instead, please consider
offering your help in order to resolve issues and to help learn
from mistakes.
Adapted from the [Django Code of
Conduct](https://www.djangoproject.com/conduct/), that itself
attributes it to the [Speak Up! project](http://speakup.io/coc.html).
......@@ -22,6 +22,9 @@
* Create a ticket for the release your shift is about, so that we
update the CA bundle that's used by Tails Upgrader and the
security check.
- Check when our OpenPGP signing key expires.
If that's before, or soon after, the scheduled date for the release
_after_ the one your shift is about, then shout.
## Around two weeks before the freeze
......
......@@ -7,7 +7,7 @@ msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-12-11 14:03+0100\n"
"PO-Revision-Date: 2014-11-24 16:47+0100\n"
"PO-Revision-Date: 2015-01-25 10:17+0100\n"
"Last-Translator: amnesia <amnesia@boum.org>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
......@@ -216,7 +216,7 @@ msgstr "[[!img man-in-the-middle.png link=no alt=\"Illustration d'une attaque de
#. type: Plain text
#, no-wrap
msgid "<!-- Source: wiki/lib/man-in-the-middle.svg -->\n"
msgstr ""
msgstr "<!-- Source: wiki/lib/man-in-the-middle.svg -->\n"
#. type: Plain text
msgid ""
......
......@@ -7,7 +7,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2013-05-24 11:31+0300\n"
"POT-Creation-Date: 2015-01-25 19:23+0100\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"
......@@ -22,14 +22,21 @@ msgid "[[!meta title=\"Enable a wireless device\"]]\n"
msgstr ""
<