Commit 29bb31bf authored by intrigeri's avatar intrigeri
Browse files

Merge branch 'devel' into bugfix/15116-newer-nouveau-xorg-driver

parents 43a8cb37 4625f031
......@@ -647,7 +647,7 @@ namespace :basebox do
boxes.sort! { |a, b| basebox_date(a) <=> basebox_date(b) }
boxes.pop
boxes.each do |box|
if basebox_date(box) < Date.today - 365.0/3.0
if basebox_date(box) < Date.today - 365.0/2.0
clean_up_basebox(box)
end
end
......
......@@ -84,10 +84,6 @@ Package: systemd systemd-sysv systemd-container systemd-journal-remote systemd-c
Pin: release o=Debian,n=stretch-backports
Pin-Priority: 999
Package: onionshare
Pin: release o=Debian,n=sid
Pin-Priority: 999
Package: openpgp-applet
Pin: release o=Debian,n=sid
Pin-Priority: 999
......
#! /bin/sh
set -e
set -u
echo "Configure Enigmail's version"
# Import set_mozilla_pref()
. /usr/local/lib/tails-shell-library/tor-browser.sh
# Rationale: the only way to suppress Enigmail's "first run" wizard is
# to have *some* version configured. But too old versions might
# trigger work-around code to run unnecessarily.
version="$(dpkg-query --show \
--showformat='${source:Upstream-Version}' \
enigmail)"
set_mozilla_pref /etc/xul-ext/enigmail.js \
extensions.enigmail.configuredVersion \
"\"${version}\""
---
- exe-paths:
- apparmor-profiles:
- '/usr/bin/onioncircuits'
users:
- 'amnesia'
......
---
- exe-paths:
- apparmor-profiles:
- '/usr/bin/onionshare'
- '/usr/bin/onionshare-gui'
users:
......
---
- exe-paths:
- apparmor-profiles:
- 'torbrowser_firefox'
users:
- 'amnesia'
......
---
- exe-paths:
- apparmor-profiles:
- '/usr/local/lib/tor-browser/firefox-unconfined'
users:
- 'tor-launcher'
......
......@@ -34,21 +34,6 @@ start_thunderbird() {
configure_default_incoming_protocol
# Apply only the relevant parts of Debian's Icedove → Thunderbird
# migration procedure.
TB_PROFILE_FOLDER="${THUNDERBIRD_CONFIG_DIR}"
if [ ! -f "${TB_PROFILE_FOLDER}/.migrated" ]; then
# Debian's migration helpers are not designed to have set -e
# or -u enabled.
set +e
set +u
. /usr/lib/thunderbird/thunderbird-wrapper-helper.sh
do_fix_mimetypes_rdf
do_create_migrated_mark_file
set -e
set -u
fi
exec /usr/bin/thunderbird --class "Thunderbird" -profile "${PROFILE}" "${@}"
}
......
......@@ -12,8 +12,10 @@
# dictionary looking something like this:
#
# - name: blabla
# exe-paths:
# - path_to_executable
# apparmor-profiles:
# - path_to_executable_if_that_is_the_name_of_the_apparmor_profile
# # or
# - explicit_apparmor_profile_name
# ...
# users:
# - user
......@@ -47,10 +49,10 @@
# least one of the elements match the client. For local (loopback)
# clients the following qualifiers are relevant:
#
# * `exe-paths`: a list of strings, each describing the path to
# the binary or script of the client with `*` matching
# anything. While this matcher always works for binaries, it only
# works for scripts with an enabled AppArmor profile (not
# * `apparmor-profiles`: a list of strings, each being the name
# of the AppArmor profile applied to the binary or script of the client,
# with `*` matching anything. While this matcher always works for binaries,
# it only works for scripts with an enabled AppArmor profile (not
# necessarily enforced, complain mode is good enough).
#
# * `users`: a list of strings, each describing the user of the
......@@ -163,7 +165,7 @@ def pid_of_laddr(address):
return None
def exe_path_of_pid(pid):
def apparmor_profile_of_pid(pid):
# Here we leverage AppArmor's in-kernel solution for determining
# the exact executable invoked. Looking at /proc/pid/exe when an
# interpreted script is running will just point to the
......@@ -175,9 +177,9 @@ def exe_path_of_pid(pid):
enabled_aa_profile_re = r'^(.+) \((?:complain|enforce)\)$'
with open('/proc/{}/attr/current'.format(str(pid)), "rb") as fh:
aa_profile_status = str(fh.read().strip(), 'UTF-8')
exe_path_match = re.match(enabled_aa_profile_re, aa_profile_status)
if exe_path_match:
return exe_path_match.group(1)
apparmor_profile_match = re.match(enabled_aa_profile_re, aa_profile_status)
if apparmor_profile_match:
return apparmor_profile_match.group(1)
else:
return psutil.Process(pid).exe()
......@@ -580,11 +582,11 @@ class FilteredControlPortProxyHandler(socketserver.StreamRequestHandler):
# client being killed before we find the PID.
if not self.client_pid:
return
client_exe_path = exe_path_of_pid(self.client_pid)
client_apparmor_profile = apparmor_profile_of_pid(self.client_pid)
client_user = psutil.Process(self.client_pid).username()
matchers = [
('exe-paths', client_exe_path),
('users', client_user),
('apparmor-profiles', client_apparmor_profile),
('users', client_user),
]
else:
self.client_pid = None
......@@ -593,9 +595,9 @@ class FilteredControlPortProxyHandler(socketserver.StreamRequestHandler):
]
self.match_and_parse_filter(matchers)
if local_connection:
self.client_desc = '{exe} (pid: {pid}, user: {user}, ' \
self.client_desc = '{aa_profile} (pid: {pid}, user: {user}, ' \
'port: {port}, filter: {filter_name})'.format(
exe=client_exe_path,
aa_profile=client_apparmor_profile,
pid=self.client_pid,
user=client_user,
port=self.client_address[1],
......
......@@ -128,21 +128,6 @@ migrate_persistence_preset()
fi
}
migrate_icedove_to_thunderbird() {
local CONFIG="${1}"
local PERSISTENCE_DIR="$(dirname "${CONFIG}")"
if [ -d "${PERSISTENCE_DIR}/thunderbird" ] || \
! [ -d "${PERSISTENCE_DIR}/icedove" ]
then
return
fi
mv "${PERSISTENCE_DIR}/icedove" "${PERSISTENCE_DIR}/thunderbird"
add_persistence_preset /home/amnesia/.thunderbird thunderbird "${conf}"
remove_persistence_preset /home/amnesia/.icedove "${conf}"
# The script /usr/local/bin/thunderbird takes care of the rest of
# the migration when starting Thunderbird.
}
# We override live-boot's logging facilities to get more useful error messages
log_warning_msg ()
{
......@@ -384,21 +369,6 @@ activate_volumes ()
fi
done
# Migrate persistence settings
for conf in $(ls /live/persistence/*_unlocked/persistence.conf || true)
do
migrate_icedove_to_thunderbird "${conf}"
# Let's make sure to get rid of any Enigmail configuredVersion
# that we previously used to set in a way that would become
# persistent in these files (see #12680).
tb_profile="$(dirname "${conf}")/thunderbird/profile.default"
rm -f "${tb_profile}/preferences/0000tails.js"
sed -i --regexp-extended \
'/^(user_)?pref\("extensions\.enigmail\.configuredVersion",/d' \
"${tb_profile}/prefs.js"
done
# Fix permissions on persistent directories that were created
# with unsafe permissions.
for persistent_fs in $(ls -d /live/persistence/*_unlocked || true)
......
deb http://deb.torproject.org/torproject.org stretch main
deb http://deb.torproject.org/torproject.org sid main
[[!meta title="Request tracker (RT) for help desk"]]
[[!meta title="Request tracker for help desk"]]
We want a tool that allows our help desk to
===========================================
Having a request tracker powering our help desk will be key to fulfilling their
[[updated mission|contribute/working_together/roles/help_desk]]:
**Gather qualitative and quantitative data to understand better our users and
prioritize our work.**
Requirements
============
MUST
----
- Track easily what's been done and what's left from previous shifts:
- Track easily what's been done and what's left from previous help desk shifts:
- Make it easy to ensure everything is answered
- Be able to follow an issue from the beginning to the end
- Allow a single person to follow an issue from the beginning to the end
- Statistics:
- Know how many users encountered the same issue. Spot the "Top bug".
- Know how many users encountered the same issue. Spot the "Top bugs"
- Be able to have stats on common issues
- Security of the platform:
- Allow secure deletion of information over time. Not keep a database forever (how long? what to keep?)
- Handle incoming OpenPGP emails
- Handle outgoing OpenPGP emails
- Be able to search into emails archive
- Better interaction between user support and devs:
- Provide logs to devs
- Make it easy to drop more dev-related issues to devs
- Be able to categorize issues ("tags")
- Allow building a responsible data retention policy
- The platform will handle sensitive information (email addresses of
users, their hardware, their problems, etc.). We'll have to do some
threat modeling to figure out how to store each piece of
information and for how long. The platform might have built-in
capacity for this...
- Handle incoming and outgoing OpenPGP emails
- Allow searching in the archive of tickets
- Plain text search
- Search on metadata (eg. filter by the version of Tails)
- Make it easy to forward logs to devs (who might not have a direct
access to the platform)
- Provide a separate queue of tickets per language [[!tails_ticket 9080]]
- Make it easy to get new mates on board
- Make it easy to onboard new help desk members
- Keep a database of template answers
- Allow cross-referencing Redmine tickets and help desk tickets
- For example, in order to know when a particular issue will be fixed
- Make it easy to contact the user back when there is a solution
- Parse automatically at least some metadata from WhisperBack reports
- We might want to parse automatically all kind of data from
WhisperBack reports but that might be hard to do (eg. hardware
information) but the platform should at least parse automatically the
WhisperBack headers (email address, version number, etc.)
SHOULD
------
- Make it easy to contact the user back when there is a solution
- Hardware information
- Parse cleverly WhisperBack data (hardware, gpg, etc)
- Keep track of hardware compatibility (Tails works on XYZ, Wi-Fi card XYZ doesn't work)
- Shift management:
- Replace the calendar of shifts and do something smart about that (send notifications to the person on duty)
- Automatically clock user support time
- Replace the list of bad users. Flag them as nasty automatically
- Allow forwarding issues from and to other user support projects (Tor, Access Now)
- Keep track of hardware compatibility (Tails works on XYZ, Wi-Fi card XYZ doesn't work)
- Replace the list of bad users and flag them automatically as nasty
- Allow users to express whether they were satisfied with our answers
- Be configurable using Puppet
- Allow for easy extraction, archiving, and metrics on hardware
compatibility. For example to update our list of known issues easily
or to know whether Tails (and which version) worked on this same
hardware based on other WhisperBack reports. Hardware that would be
interesting to track:
- Laptop model (for boot issues)
- USB stick (to clean up known issues)
- Graphic cards
- Wi-Fi cards
MAY
---
- As a start we'll aim at creating a tool that's only accessible to
help desk members (and maybe a few other core contributors) but not
to members of the Foundations and UX team in general.
But for the future, the platform might have built-in capacity to
handle different type of accesses to the data in terms of privacy.
- Shift management:
- Replace the calendar of shifts and do something smart about that (send notifications to the person on duty)
- Automatically clock user support time
- Allow forwarding issues from and to other user support projects (Tor, Access Now)
- Have a disposable chat system for tricky cases (Tor does that)
Resources
Budgeting
=========
- [[!wikipedia Comparison_of_help_desk_issue_tracking_software]] (Wikipedia)
This work is directly related to the work of four of our core team:
- [[Help Desk|contribute/working_together/roles/help_desk]]: they will
use the platform to do their work.
- [[Foundations
Team|contribute/working_together/roles/foundations_teams]]: they will
use the data of the platform to investigate for example hardware
compatibility issues.
- [[UX Designes|contribute/working_together/roles/ux]]: they will use
the data of the platform to investigate usability issues and help
prioritizing our work.
- [[Sysadmins|contribute/working_together/roles/sysadmins]]: they will
administer the platform.
Making sure that the platform will work for them is part of the core
work of these teams (eg. building the requirements).
But researching implementation options doesn't fit in their scope of
work and should be budgeted apart. This work could either be:
- Clocked and paid only once we'll find a grant or a budget to build the
platform.
- Paid after requesting an exceptional budget line to tails@boum.org.
For example, if we decide to get the help from external contractors
for the research phase.
If we decide to work with external contractors, we'll have to be
careful about not spending more time being the point of contact than
doing the work ourselves (for example, this might not work for
intrigeri).
It might be good if the researcher and the implementer are the same
person. This might be groente but not before the end of the year.
Options
=======
- [[!wikipedia Comparison_of_help_desk_issue_tracking_software]] (Wikipedia)
### OTRS
- http://www.otrs.com/
- https://otrs.github.io/doc/manual/admin/3.1/en/html/configure-pgp.html
- <http://www.otrs.com/>
- <https://otrs.github.io/doc/manual/admin/3.1/en/html/configure-pgp.html>
### RT
- http://bestpractical.com/rt/
- https://bestpractical.com/rtir/
- <http://bestpractical.com/rt/>
- <https://bestpractical.com/rtir/>
- AccessNow have a RT behind their help desk. It's run by Gustaf
Björksten <gustaf@accessnow.org>.
- https://www.bestpractical.com/docs/rt/4.2/RT/Crypt/GnuPG.html
- https://forge.puppetlabs.com/darin/rt
- <https://www.bestpractical.com/docs/rt/4.2/RT/Crypt/GnuPG.html>
- <https://forge.puppetlabs.com/darin/rt>
- Koumbit is using RT and told us about their experience in <ead91b4d-8a87-5855-de55-2c4ffcb40377@koumbit.org>
### Faveo
- <https://www.faveohelpdesk.com/>
- Online demo: <https://www.faveohelpdesk.com/online-demo/>
### Helpy
- <https://helpy.io/>
......@@ -25,7 +25,9 @@ and add your topic here:
### Strategic planning
We'll discuss XXX
We'll discuss "Oppressed people can safely use Tails (e.g. without being detected) [B, +5-3]".
See [[blueprint/strategic_planning]] for the terminology.
### Gather comments on our draft personas
......
......@@ -27,6 +27,26 @@ XXX: If you feel like it and developers don't do it themselves,
Release section (for example, the changes being worked on for
the next version).
- We have worked on improving support for recent graphics cards and in
particular those produced by NVIDIA. We've sent
a [call for testing](https://mailman.boum.org/pipermail/tails-testers/2018-June/001018.html)
and
[updated](https://mailman.boum.org/pipermail/tails-testers/2018-June/001029.html)
it. If the feedback is good, we will probably include these changes
in Tails 3.9.
- We have kept working on fixing the EFAIL attacks against
encrypted email ([[!tails_ticket 15602]]). Tails 3.8 fixed most of
them and Tails 3.9 should fix the remaining ones.
- We have worked on detecting earlier changes that would break
automatic upgrades ([[!tails_ticket 15419]])… and already identified
one we need to fix in time for Tails 3.9 ([[!tails_ticket 15695]]).
- Chris Lamb prepared a fix for the most infamous rendering issue (raw PO
content being inserted in some page) that affects our website
([[!tails_ticket 6907]]).
Documentation and website
=========================
......
......@@ -13,6 +13,7 @@ Similar surveys
- <https://matomo.org/blog/2011/06/piwik-community-survey-here-are-the-results/>
- <https://survey.piwik.org/index.php/151125>
- <https://matomo.org/blog/2017/11/community-survey-revealed-discover-the-profile-of-a-piwik-user/>
- <https://www.limesurvey.org/about-us/blog/2100-must-have-survey>
Possible research questions
---------------------------
......
......@@ -2,13 +2,11 @@
All times are referenced to Berlin and Paris time.
## 2018Q2
* 2018-06-01: Beta release of VeraCrypt
## 2018Q3
* 2018-06-28, 16:00: Foundations Team meeting
* 2018-07-01: Beta release of VeraCrypt
## 2018Q3
* 2018-07-02, 15:00: VeraCrypt meeting
* 2018-07-03, 19:00: [[Contributors meeting|contribute/meetings]]
......
......@@ -247,7 +247,7 @@ tracked by tickets prefixed with `todo/test_suite:`.
To synchronize your local copy:
torsocks rsync -rt --progress --delete rsync.torproject.org::amnesia-archive/tails/stable/iuk/ /var/www/tails/stable/iuk/
torsocks rsync -rt --progress --delete mirrors.rsync.tails.boum.org::amnesia-archive/tails/stable/iuk/ /var/www/tails/stable/iuk/
* Patch `/etc/hosts` in Tails to point to your web server:
......
......@@ -7,7 +7,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2018-06-26 16:29+0200\n"
"POT-Creation-Date: 2018-06-26 19:09+0200\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"
......@@ -33,9 +33,9 @@ msgstr ""
#. type: Plain text
msgid ""
"This release fixes [[many security "
"issues|security/Numerous_security_holes_in_3.7.1]] and users should upgrade "
"as soon as possible."
"This release fixes [[many security issues|security/"
"Numerous_security_holes_in_3.7.1]] and users should upgrade as soon as "
"possible."
msgstr ""
#. type: Plain text
......@@ -55,9 +55,37 @@ msgstr ""
#. type: Bullet: '- '
msgid ""
"Upgrade *Enigmail* from 1.9.9 to "
"[2.0.7](https://enigmail.net/index.php/en/download/changelog#enig2.0.7) "
"which fixes some of the [EFAIL](https://efail.de/) attacks on OpenPGP."
"Upgrade *Enigmail* from 1.9.9 to [2.0.7](https://enigmail.net/index.php/en/"
"download/changelog#enig2.0.7) which fixes some of the [EFAIL](https://efail."
"de/) attacks on OpenPGP."
msgstr ""
#. type: Plain text
#, no-wrap
msgid "<div class=\"note\">\n"
msgstr ""
#. type: Plain text
#, no-wrap
msgid ""
"<p>When starting <span class=\"application\">Thunderbird</span> for the first\n"
"time after upgrading to Tails 3.8, you have to go through the\n"
"<span class=\"application\">Enigmail Setup Wizard</span> again.</p>\n"
msgstr ""
#. type: Plain text
#, no-wrap
msgid "<p>Your OpenPGP keys and your per-recipient rules are preserved.</p>\n"
msgstr ""
#. type: Plain text
#, no-wrap
msgid "<p>[[!img enigmail-setup.png link=\"no\" alt=\"\"]]</p>\n"
msgstr ""
#. type: Plain text
#, no-wrap
msgid "</div>\n"
msgstr ""
#. type: Title ##
......@@ -73,14 +101,14 @@ msgstr ""
#. type: Plain text
msgid ""
"- Fix the translations of the homepage of the *Unsafe "
"Browser*. ([[!tails_ticket 15461]])"
"- Fix the translations of the homepage of the *Unsafe Browser*. ([[!"
"tails_ticket 15461]])"
msgstr ""
#. type: Plain text
msgid ""
"For more details, read our [[!tails_gitweb debian/changelog "
"desc=\"changelog\"]]."
"For more details, read our [[!tails_gitweb debian/changelog desc=\"changelog"
"\"]]."
msgstr ""
#. type: Plain text
......@@ -119,8 +147,7 @@ msgstr ""
#. type: Plain text
#, no-wrap
msgid ""
" If you cannot do an automatic upgrade or if Tails fails to start after "
"an\n"
" If you cannot do an automatic upgrade or if Tails fails to start after an\n"
" automatic upgrade, please try to do a [[manual upgrade|upgrade]].\n"
msgstr ""
......@@ -145,7 +172,6 @@ msgstr ""
#, no-wrap
msgid ""
"We need your help and there are many ways to [[contribute to\n"
"Tails|contribute]] (<a "
"href=\"https://tails.boum.org/donate?r=3.8\">donating</a> is only one of\n"
"Tails|contribute]] (<a href=\"https://tails.boum.org/donate?r=3.8\">donating</a> is only one of\n"
"them). Come [[talk to us|about/contact#tails-dev]]!\n"
msgstr ""
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment