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

Conflicts:
	features/torified_browsing.feature

config/chroot_local-includes/usr/local/bin/tor-browser

@@ -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

config/chroot_local-includes/usr/share/tails/torbrowser-AppArmor-profile.patch

 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,
+ }

features/step_definitions/common_steps.rb

@@ -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

features/step_definitions/pidgin.rb

@@ -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

features/step_definitions/torified_gnupg.rb

@@ -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

features/step_definitions/torified_misc.rb

+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|

features/torified_browsing.feature

@@ -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

run_test_suite

@@ -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

wiki/src/about.fr.po

@@ -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]]."

wiki/src/blueprint/UEFI/32-bit.mdwn

@@ -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`

wiki/src/blueprint/automated_builds_and_tests/automated_tests_specs.mdwn

@@ -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

wiki/src/blueprint/bootstrapping/extension.mdwn

@@ -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]].

wiki/src/blueprint/monthly_meeting.mdwn

@@ -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"]]

wiki/src/blueprint/report_2015_06.mdwn

 [[!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.