Commit 3a23d73b authored by intrigeri's avatar intrigeri
Browse files

Merge branch 'devel' into bugfix/8007-AppArmor-hardening

Conflicts:
	features/torified_browsing.feature
parents 954815d9 5be4ca90
......@@ -59,6 +59,10 @@ start_browser() {
/usr/local/bin/generate-tor-browser-profile
fi
TMPDIR="${PROFILE}/tmp"
mkdir --mode=0700 -p "$TMPDIR"
export TMPDIR
configure_best_tor_browser_locale "${PROFILE}"
# Workaround bug #8036
......
diff --git a/apparmor/torbrowser.Browser.firefox b/apparmor/torbrowser.Browser.firefox
index 7e68a08..c7db6da 100644
index 7e68a08..2f40271 100644
--- a/apparmor/torbrowser.Browser.firefox
+++ b/apparmor/torbrowser.Browser.firefox
@@ -1,13 +1,15 @@
......@@ -97,7 +97,7 @@ index 7e68a08..c7db6da 100644
/etc/mailcap r,
/etc/mime.types r,
@@ -73,6 +87,31 @@
@@ -73,10 +87,42 @@
/sys/devices/pci[0-9]*/**/uevent r,
owner /{dev,run}/shm/shmfd-* rw,
......@@ -129,3 +129,14 @@ index 7e68a08..c7db6da 100644
# KDE 4
owner @{HOME}/.kde/share/config/* r,
# Xfce4
/etc/xfce4/defaults.list r,
/usr/share/xfce4/applications/ r,
+
+ # Deny access to global tmp directories, that's granted by the user-tmp
+ # abstraction, which is sourced by the gnome abstraction, that we include.
+ deny owner /var/tmp/** rwklx,
+ deny /var/tmp/ rwklx,
+ deny owner /tmp/** rwklx,
+ deny /tmp/ rwklx,
}
......@@ -1075,7 +1075,11 @@ When /^I open a page on the LAN web server in the (.*)$/ do |browser|
step "I open the address \"#{@web_server_url}\" in the #{browser}"
end
Then /^I force Tor to use a new circuit( in Vidalia)?$/ do |with_vidalia|
def force_new_tor_circuit(with_vidalia=nil)
assert(!@new_circuit_tries.nil? && @new_circuit_tries >= 0,
'@new_circuit_tries was not initialized before it was used')
@new_circuit_tries += 1
STDERR.puts "Forcing new Tor circuit... (attempt ##{@new_circuit_tries})" if $config["DEBUG"]
if with_vidalia
assert_equal('gnome', @theme, "Vidalia is not available in the #{@theme} theme.")
begin
......@@ -1106,3 +1110,9 @@ Then /^I force Tor to use a new circuit( in Vidalia)?$/ do |with_vidalia|
@vm.execute_successfully('. /usr/local/lib/tails-shell-library/tor.sh; tor_control_send "signal NEWNYM"')
end
end
Then /^I force Tor to use a new circuit( in Vidalia)?$/ do |with_vidalia|
next if @skip_steps_while_restoring_background
@new_circuit_tries = 1 if @new_circuit_tries.nil?
force_new_tor_circuit(with_vidalia)
end
......@@ -296,8 +296,8 @@ end
Then /^Pidgin successfully connects to the "([^"]+)" account$/ do |account|
next if @skip_steps_while_restoring_background
expected_channel_entry = chan_image(account, default_chan(account), 'roster')
tries = 0
until tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
@new_circuit_tries = 0
until @new_circuit_tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
# Sometimes the OFTC welcome notice window pops up over the buddy list one...
begin
@vm.focus_window('Buddy List')
......@@ -313,9 +313,7 @@ Then /^Pidgin successfully connects to the "([^"]+)" account$/ do |account|
@screen.wait(expected_channel_entry, 60)
break
rescue FindFailed
tries += 1
STDERR.puts "Forcing new Tor circuit... (attempt ##{tries})" if $config["DEBUG"]
step "I force Tor to use a new circuit"
force_new_tor_circuit
@screen.wait_and_click('PidginReconnect.png', 20)
end
end
......
......@@ -50,20 +50,18 @@ When /^I fetch the "([^"]+)" OpenPGP key using the GnuPG CLI( without any signat
else
importopts = ''
end
tries = 0
until tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
@new_circuit_tries = 0
until @new_circuit_tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
begin
@gnupg_recv_key_res = @vm.execute_successfully(
"gpg --batch #{importopts} --recv-key '#{keyid}'",
LIVE_USER)
break
rescue ExecutionFailedInVM
tries += 1
STDERR.puts "Forcing new Tor circuit... (attempt ##{tries})" if $config["DEBUG"]
step 'I force Tor to use a new circuit'
force_new_tor_circuit
end
end
assert(tries <= $config["MAX_NEW_TOR_CIRCUIT_RETRIES"], "Fetching keys with the GnuPG CLI did not succeed after retrying #{tries} times")
assert(@new_circuit_tries < $config["MAX_NEW_TOR_CIRCUIT_RETRIES"], "Fetching keys with the GnuPG CLI did not succeed after retrying #{@new_circuit_tries} times")
end
When /^the GnuPG fetch is successful$/ do
......@@ -112,8 +110,8 @@ end
Then /^I synchronize keys in Seahorse$/ do
next if @skip_steps_while_restoring_background
tries = 0
until tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
@new_circuit_tries = 0
until @new_circuit_tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
begin
step 'process "seahorse" is running'
@screen.wait_and_click("SeahorseWindow.png", 10)
......@@ -124,7 +122,7 @@ Then /^I synchronize keys in Seahorse$/ do
seahorse_wait_helper('SeahorseWindow.png', 5*60)
break
rescue OpenPGPKeyserverCommunicationError
tries += 1
force_new_tor_circuit
@screen.wait_and_click('GnomeCloseButton.png', 20)
if @screen.exists('SeahorseSynchronizing.png')
# Seahorse is likely to segfault if we end up here.
......@@ -132,11 +130,9 @@ Then /^I synchronize keys in Seahorse$/ do
@screen.type(Sikuli::Key.ESC)
end
seahorse_wait_helper('SeahorseWindow.png')
STDERR.puts "Forcing new Tor circuit... (attempt ##{tries})" if $config["DEBUG"]
step 'I force Tor to use a new circuit'
end
end
assert(tries <= $config["MAX_NEW_TOR_CIRCUIT_RETRIES"], "Syncing keys in Seahorse did not succeed after retrying #{tries} times")
assert(@new_circuit_tries < $config["MAX_NEW_TOR_CIRCUIT_RETRIES"], "Syncing keys in Seahorse did not succeed after retrying #{@new_circuit_tries} times")
end
When /^I fetch the "([^"]+)" OpenPGP key using Seahorse( via the Tails OpenPGP Applet)?$/ do |keyid, withgpgapplet|
......@@ -147,8 +143,8 @@ When /^I fetch the "([^"]+)" OpenPGP key using Seahorse( via the Tails OpenPGP A
step "I start Seahorse"
end
step "Seahorse has opened"
tries = 0
until tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
@new_circuit_tries = 0
until @new_circuit_tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
begin
@screen.wait_and_click("SeahorseWindow.png", 10)
seahorse_menu_click_helper('SeahorseRemoteMenu.png', 'SeahorseRemoteMenuFind.png', 'seahorse')
......@@ -169,15 +165,13 @@ When /^I fetch the "([^"]+)" OpenPGP key using Seahorse( via the Tails OpenPGP A
@screen.click("SeahorseImport.png")
break
rescue OpenPGPKeyserverCommunicationError
tries += 1
force_new_tor_circuit
@screen.wait_and_click('GnomeCloseButton.png', 20)
@screen.type(Sikuli::Key.ESC)
@screen.type("w", Sikuli::KeyModifier.CTRL)
STDERR.puts "Forcing new Tor circuit... (attempt ##{tries})" if $config["DEBUG"]
step 'I force Tor to use a new circuit'
end
end
assert(tries <= $config["MAX_NEW_TOR_CIRCUIT_RETRIES"], "Fetching keys in Seahorse did not succeed after retrying #{tries} times")
assert(@new_circuit_tries < $config["MAX_NEW_TOR_CIRCUIT_RETRIES"], "Fetching keys in Seahorse did not succeed after retrying #{@new_circuit_tries} times")
end
Then /^Seahorse is configured to use the correct keyserver$/ do
......
class WhoisLookupFailure < StandardError
end
class WgetFailure < StandardError
end
When /^I query the whois directory service for "([^"]+)"$/ do |domain|
next if @skip_steps_while_restoring_background
@vm_execute_res = @vm.execute(
"whois '#{domain}'",
LIVE_USER)
@new_circuit_tries = 0
until @new_circuit_tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
begin
@vm_execute_res = @vm.execute("whois '#{domain}'", LIVE_USER)
if !@vm_execute_res.success? || @vm_execute_res.stdout['LIMIT EXCEEDED']
raise WhoisLookupFailure
end
break
rescue WhoisLookupFailure
if @vm_execute_res.stderr['Timeout'] || \
@vm_execute_res.stderr['Unable to resolve'] || \
@vm_execute_res.stdout['LIMIT EXCEEDED']
force_new_tor_circuit
end
end
end
assert(@new_circuit_tries < $config["MAX_NEW_TOR_CIRCUIT_RETRIES"],
"Looking up whois info for #{domain} did not succeed after retrying #{@new_circuit_tries} times.\n" +
"The output of the last command contains:\n" +
"#{@vm_execute_res.stdout}\n" + "#{@vm_execute_res.stderr}")
end
When /^I wget "([^"]+)" to stdout(?:| with the '([^']+)' options)$/ do |url, options|
next if @skip_steps_while_restoring_background
arguments = "-O - '#{url}'"
arguments = "#{options} #{arguments}" if options
@vm_execute_res = @vm.execute(
"wget #{arguments}",
LIVE_USER)
@new_circuit_tries = 0
until @new_circuit_tries == $config["MAX_NEW_TOR_CIRCUIT_RETRIES"] do
begin
@vm_execute_res = @vm.execute("wget #{arguments}", LIVE_USER)
raise WgetFailure unless @vm_execute_res.success?
break
rescue WgetFailure
if @vm_execute_res.stderr['Timeout'] || @vm_execute_res.stderr['Unable to resolve']
force_new_tor_circuit
end
end
end
assert(@new_circuit_tries < $config["MAX_NEW_TOR_CIRCUIT_RETRIES"],
"Fetching from #{url} with options #{options} did not succeed after retrying #{@new_circuit_tries} times.\n" +
"The output contains:\n" +
"#{@vm_execute_res.stdout}\n" +
"#{@vm_execute_res.stderr}")
end
Then /^the (wget|whois) command is successful$/ do |command|
......
......@@ -65,9 +65,11 @@ Feature: Browsing the web using the Tor Browser
Scenario: I can view a file stored in "~/Tor Browser" but not in ~/.gnupg
Given I copy "/usr/share/synaptic/html/index.html" to "/home/amnesia/Tor Browser/synaptic.html" as user "amnesia"
And I copy "/usr/share/synaptic/html/index.html" to "/home/amnesia/.gnupg/synaptic.html" as user "amnesia"
And I copy "/usr/share/synaptic/html/index.html" to "/tmp/synaptic.html" as user "amnesia"
Then the file "/home/amnesia/.gnupg/synaptic.html" exists
And the file "/lib/live/mount/overlay/home/amnesia/.gnupg/synaptic.html" exists
And the file "/live/overlay/home/amnesia/.gnupg/synaptic.html" exists
And the file "/tmp/synaptic.html" exists
And I start the Tor Browser
And the Tor Browser has started and loaded the startup page
When I open the address "file:///home/amnesia/Tor Browser/synaptic.html" in the Tor Browser
......@@ -85,6 +87,10 @@ Feature: Browsing the web using the Tor Browser
And I wait between 4 and 5 seconds
Then I don't see "TorBrowserSynapticManual.png"
And I see "TorBrowserUnableToOpen.png" after at most 1 seconds
When I open the address "file:///tmp/synaptic.html" in the Tor Browser
And I wait between 4 and 5 seconds
Then I don't see "TorBrowserSynapticManual.png"
Then I see "TorBrowserUnableToOpen.png" after at most 1 seconds
Scenario: The "Tails documentation" link on the Desktop works
When I double-click on the "Tails documentation" link on the Desktop
......
......@@ -127,10 +127,16 @@ next_free_display() {
echo ":${display_nr}"
}
test_suite_cleanup() {
(kill -0 ${XVFB_PID} 2>/dev/null && kill ${XVFB_PID}) || /bin/true
if [ ! -z $LOG_FILE ]; then
remove_control_chars_from "$LOG_FILE"
fi
}
start_xvfb() {
Xvfb $TARGET_DISPLAY -screen 0 1024x768x24+32 >/dev/null 2>&1 &
XVFB_PID=$!
trap "kill -0 ${XVFB_PID} 2>/dev/null && kill ${XVFB_PID}" EXIT
# Wait for Xvfb to run on TARGET_DISPLAY
until display_in_use $TARGET_DISPLAY; do
sleep 1
......@@ -251,6 +257,8 @@ while [ $# -gt 0 ]; do
shift
done
trap "test_suite_cleanup" EXIT HUP INT QUIT TERM
check_dependencies ${GENERAL_DEPENDENCIES}
TARGET_DISPLAY=$(next_free_display)
......@@ -276,6 +284,5 @@ CUCUMBER_COMMAND="cucumber ${@}"
if [ -z "$LOG_FILE" ]; then
$CUCUMBER_COMMAND
else
trap "remove_control_chars_from '$LOG_FILE'" EXIT HUP INT QUIT TERM
script --quiet --flush --return --command "$CUCUMBER_COMMAND" "$LOG_FILE" | cat
fi
......@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: tails-about-fr\n"
"POT-Creation-Date: 2015-03-13 16:25+0100\n"
"POT-Creation-Date: 2015-07-07 16:34+0300\n"
"PO-Revision-Date: 2013-10-13 17:08-0000\n"
"Last-Translator: \n"
"Language-Team: \n"
......@@ -77,7 +77,6 @@ msgstr ""
#. type: Plain text
#, no-wrap
#| msgid "[[!toc levels=1]]\n"
msgid "[[!toc levels=2]]\n"
msgstr "[[!toc levels=2]]\n"
......@@ -88,7 +87,6 @@ msgstr "<a id=\"tor\"></a>\n"
#. type: Title =
#, 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\n"
......@@ -233,18 +231,12 @@ msgstr ""
"net), qui est un réseau d'anonymisation différent de Tor."
#. type: Plain text
#| 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 I2P dans Tails.|doc/anonymous_internet/i2p]]"
#. type: Plain text
#| msgid ""
#| "To learn more about how the usage of Tor is enforced, see our [[design "
#| "document|contribute/design/Tor_enforcement]]."
msgid ""
"To know how I2P is implemented in Tails, see our [[design document|"
"contribute/design/I2P]]."
......
......@@ -61,7 +61,8 @@ Then, add `nomodeset` if needed, and Tails boots.
Note that:
* Support for `{vesa,}menu.c32` was added in GRUB upstream, but didn't
make it into Debian yet as of 2.02~beta2-22. intrigeri has a
make it into Debian yet as of 2.02~beta2-22.
so `feature/8471-32-bit-UEFI` installs a
2.02~beta2-22tails1~bpo70+1 package with that new code in it,
and indeed it successfully loads our syslinux configuration.
* We'll need to load the `cpuid` module to make our `ifcpu64`
......
......@@ -6,7 +6,7 @@ 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]]
[[!toc levels=3]]
# Facts
......@@ -55,25 +55,19 @@ 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:
### Current proposal
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 branches that are marked
as *Ready for QA* 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 features depending on the context, define priorities
for built ISO and/or tests.
For branch stable:
Must test ISOs built daily and on every Git push;
so that we're always ready to put out an emergency release;
For the next scheduled release branch (either stable, testing, or devel):
Must test ISOs built daily and on every Git push;
so that we always know the state of the next release;
For other branches:
For branches with a `Ready for QA` ticket:
Must test ISO built daily and on every Git push;
Must test ISOs built on every Git push,
with some rate-limiting if necessary;
<a id="how-to-run-the-tests"></a>
......@@ -81,30 +75,25 @@ for built ISO and/or 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.
To test a specific ISO, the automated test suite MUST have access to:
* the corresponding build artifacts;
* the commit ID of that build;
* if applicable, the commit at which the base branch was at, when it
was merged into the branch being built;
* the ISO of the previous Tails release.
The automated test suite MUST be run in a clean environment.
The automated test suite MUST be run in a clean environment, using a
fresh _--tmpdir_ for each run.
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.
When [[!tails_ticket 9515]] and friends will be resolved and a first
deployment of the automated test suite will clarify its need, we'll see
if it should be able to accept a treshold of failures for some features
before sending notifications. This could help if a scenario fails
e.g. because of a network congestion.
## Notifications
......@@ -169,11 +158,34 @@ builds specification.
# 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.
## Cutting the number of run per day
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 maybe find more ways to split the automated test suite in
faster subsets of features depending on the context, define priorities
for built ISO and/or tests.
The automated test suite could 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 then 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 also should not allocate all the isotesters for
one ISO when others are waiting to be tested.
## Scenarios
Folowing is a list of other scenarios that we have also envisaged for
the second iteration of the automated builds deployment, as they are
really tightened.
## Scenario 10
### Scenario 10
As a Tails developer working on branch B
When I upload a package to APT suite B
......@@ -183,7 +195,7 @@ tightened.
(acceptable workaround: being able to manually trigger a test suite.)
## Scenario 11
### Scenario 11
As the current RM
When I push new tag T on branch B
......@@ -193,14 +205,14 @@ tightened.
on the ISO build from the checkout of tag T
## Scenario 12
### 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
### Scenario 14
As a Tails developer
When I push a new commit or a new Debian package to a base branch
......
......@@ -44,8 +44,8 @@ Goals
for years.
- Simplify the installation process by automating *some* verification
of the ISO image inside the browser as part of the download process.
- In case of a bad ISO image, help the user diagnose whether the
download has been interrupted or the ISO has been corrupted.
- Ensure that ISO images are downloaded entirely before trying to
verify them.
- In case of an interrupted download, help the user resume it. This
requires us to have our mirrors stop sending HTTP ETag headers. See
[[!tails_ticket 9022]].
......
......@@ -16,8 +16,3 @@ Availability and plans for the next weeks
Discussions
===========
* [[!tails_ticket 9530 desc="Consider using
hkp://ha.pool.sks-keyservers.net in non-hkps-enabled software"]]
* [[!tails_ticket 9529 desc="Ping PayPal donors regularly?"]]
* [[!tails_ticket 8864 desc="Consider flagging first boot after installing"]]
* [[!tails_ticket 7151 desc="Accept donations via micropayment systems"]]
[[!meta title="Tails report for June, 2015"]]
[[Tails 1.4.1|https://tails.boum.org/contribute/calendar]] has been postponed (because Firefox changed their schedule) and will be released sometime in the beginning of July. So once again, this report will give non-code news :)
Tails 1.4.1 has been postponed (because Mozilla changed their release schedule) and was released in the beginning of July. So once again, this report will give non-code news :)
[[!toc]]
Documentation and Website
Releases
========
* The next release (1.5) is [[planned for August 11|contribute/calendar/]].
* We decided on a new [[version number scheme|contribute/release_schedule#versioning]].
Code
====
FIXME
Documentation and website
=========================
* We added a warning in the [[OpenPGP app documentation|https://tails.boum.org/doc/encryption_and_privacy/gpgapplet]] about non-ASCII characters being badly supported.
* A small note about non-free firmware was added to our [[licence page|doc/about/license]].
* Our [[documentation for reviewers|contribute/merge_policy/review]] now explains how to do a good and nice review.
* A small note about non-free firmware was added to our [[licence page|https://tails.boum.org/doc/about/license]].
* We warn that *Tails OpenPGP Applet* can lead to
[[encoding problems for emails|doc/encryption_and_privacy/gpgapplet/public-key_cryptography#encoding]].
User Experience
User experience
===============
* People are working on the [[Greeter mockups|https://mailman.boum.org/pipermail/tails-ux/2015-June/000437.html]].
- On the [[Installation Assistant|blueprint/bootstrapping/assistant]]:
- We wrote a full synopsis of the [[installation process for
Windows|blueprint/bootstrapping/assistant/windows]], submitted it for
review, and started testing it ([[!tails_ticket 9202 desc="#9202"]]).
- We started writing an ikiwiki and Bootstrap prototype of the Installation
Assistant in [[!tails_gitweb_branch web/assistant]].
FIXME more ?
* People are working on the [Greeter mockups](https://mailman.boum.org/pipermail/tails-ux/2015-June/000437.html).
Infrastructure
==============
* Our test suite covers 185 scenarios, 3 more that in May. We removed outdated scenario again, so there are more than 3 new tests :)
* We decided to archive publicly the tails-support mailing list, since external websites were archiving it anyway.
* We decided to publicly archive the tails-support mailing list, since external websites were archiving it anyway.
* FIXME more?
Funding
=======
* If you want to help us develop and maintain Tails, please [[donate|https://tails.boum.org/contribute/how/donate]] :)
* If you want to help us develop and maintain Tails, please [[donate|contribute/how/donate]] :)
* We sent our final report for the Access Innovation Prize received in
March 2014.
* We submitted our second quarterly report to the
[Digital Defenders Partnership](https://digitaldefenders.org/).
Outreach
========
* [[A workshop about Tails|http://www.lacantine-brest.net/event/atelier-datalove-tails-x-tor/]] happened in Brest, France, June 18th.
* [A workshop about Tails](http://www.lacantine-brest.net/event/atelier-datalove-tails-x-tor/) happened in Brest, France, June 18th.
* Tchou and Fiodor Tonti gave [[a talk about Tails and UX|https://www.passageenseine.org/fr/programme/2015/jeudi-18-juin/grande-salle/atelier-design-tails]] in Pas Sage en Seine 2015 at NUMA in Paris, France on June 18th. [[The video is online|https://www.passageenseine.org/fr/archives-et-videos/]] and good feedback already arrived :)
* Tchou and Fiodor Tonti gave [a talk about Tails and UX](https://www.passageenseine.org/fr/programme/2015/jeudi-18-juin/grande-salle/atelier-design-tails) in Pas Sage en Seine 2015 at NUMA in Paris, France on June 18th. [The video is online](https://www.passageenseine.org/fr/archives-et-videos/) and good feedback already arrived :)
* [[A workshop about Tor and Tails|https://jardin-entropique.eu.org/ateliers]] happened in Rennes, France, during the Jardin entropique event, June 28th.
* [A workshop about Tor and Tails](https://jardin-entropique.eu.org/ateliers) happened in Rennes, France, during the Jardin entropique event, June 28th.
Upcoming events
---------------
* A talk about Tails will take place during [[DebConf15|http://debconf15.debconf.org/]] in Heidelberg, Germany, in August.
* A talk about Tails will take place during [DebConf15](http://debconf15.debconf.org/) in Heidelberg, Germany, in August.
* Please let us know if you organize an event about Tails, we'll be glad to announce it :)
On-going discussions
====================
* [[We discussed our release versioning|https://mailman.boum.org/pipermail/tails-dev/2015-June/009132.html]] and found a new way to do it: always increment the first number with major Debian version, or whenever it makes sense for Tails only (user-visible changes); second number: even for bugfix releases, odd for major ones; add an extra 3rd number for emergency releases.