Commit b9da2df8 authored by sajolida's avatar sajolida
Browse files

Merge remote-tracking branch 'origin/master' into doc/10649-boot-menu-animation

parents 81c5c4e6 9628bea2
......@@ -7,7 +7,7 @@ msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2019-06-21 12:40+0000\n"
"PO-Revision-Date: 2019-07-20 09:36+0000\n"
"PO-Revision-Date: 2019-07-29 01:04+0000\n"
"Last-Translator: emmapeel <>\n"
"Language-Team: Spanish <"
......@@ -554,16 +554,12 @@ msgid ""
msgstr ""
#. type: Plain text
#, fuzzy
#| msgid ""
#| "[[OpenPGP key|tails-accounting.key]] ([[details|doc/about/"
#| "openpgp_keys#accounting]])."
msgid ""
"[[OpenPGP key|tails-foundations.key]] ([[details|doc/about/"
msgstr ""
"[[OpenPGP key|tails-accounting.key]] ([[details|doc/about/"
"[[Llave OpenPGP|tails-foundations.key]] ([[details|doc/about/"
#. type: Plain text
#, no-wrap
......@@ -3,18 +3,20 @@
# This file is distributed under the same license as the PACKAGE package.
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2019-06-21 12:40+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"PO-Revision-Date: 2019-07-29 18:40+0000\n"
"Last-Translator: emmapeel <>\n"
"Language-Team: LANGUAGE <>\n"
"Language: \n"
"Language: fa\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 2.20\n"
#. type: Plain text
#, no-wrap
......@@ -56,7 +58,7 @@ msgstr ""
#. type: Plain text
#, no-wrap
msgid "</div>\n"
msgstr ""
msgstr "</div>\n"
#. type: Plain text
#, no-wrap
# Introduction
This is an on-going feasibility on how to port the Tails Installer to the macOS operating system.
## Considerations
This feasibility study was done on a OS X El Capitan system on an early 2011 Macbook. Stock Python2.7 was used.
## Porting
liveusb-creator from Fedora(upstream) only works out of the box for Windows and Linux but no efforts were brought in to support OS X. This is an action point.
## Packaging
This section dives into packaging it all together.
### GTK bundling
* [GTK Mac Bundler ](
* [Micah Lee's attempt at GTK and Onionshare (he switched to QT)](
### Codesigning
We could either:
- Get our software signed and be in the Mac App Store.
- Ask people to download from our website and install doing Ctrl+Click as [instructed for *Tor Browser*|].
* [Apple's Security Overview](
* [Apple's Code Signing introduction](
* [Example of code signing in Onionshare](
# Conclusion
[[!toc levels=1]]
# Linux dependencies
The current Tails Installer version (<>)
has considerable changes when compared with the upstream Fedora liveusb-creator
The current package dependencies for the Tails Installer in Linux are:
* dosfstools
* gdisk
* genisoimage
* gir1.2-glib-2.0
* gir1.2-gtk-3.0
* gir1.2-udisks-2.0
* mtools
* p7zip-full
* policykit-1
* python-configobj
* python-gi
* python-urlgrabber
* syslinux
If we list the set of requirements for each important source file then we have:
### \_\_init\_\
import gettext
if sys.platform == 'win32':
import gettext_windows
if 'linux' in sys.platform:
import gi
gi.require_version('UDisks', '2.0')
from gi.repository import UDisks, GLib
* syslinux
* sgdisk
* dd
* dosfslabel
* e2label
* extlinux
* pkexec
* mkdiskimage
* sync
from gi.repository import Gdk, GLib, Gtk
In general GTK3
from gi.repository import Gtk
if 'linux' in sys.platform:
from gi.repository import GLib
# Alternatives for Windows:
The Windows specific code for the Tails Installer uses mostly
the Python win32 interfaces:
import win32file, win32api, pywintypes
and a set of third parties tools listed here:
There are other tools that would be possible to explore like
[[!tails_ticket 10984]].
# Analysis regarding operations on storage devices
According to <>,
the steps to create a Tails bootable device are:
1. Partition the device as a GPT partition.
2. Create a FAT32 (VFAT) partition with the Tails files and Tails label.
3. (Optionally, not supported yet) Create a persistence partition with LUKS.
Next we analyze the code related to above steps. First we list
the current Linux specific operations carried out in the
target installation device and then we list the current and
proposed Windows alternatives.
## For Linux - LinuxTailsInstallerCreator/
### detect_supported_drives:
partition = obj.props.partition
filesystem = obj.props.filesystem
Add to that a bunch of `drive.props.*` and `block.props.*`.
### mount_device:
mount = filesystem.call_mount_sync(
arg_options = GLib.Variant('a{sv}', None),
cancellable = None)
### unmount_device:
filesystem = self._get_object(udi).props.filesystem
arg_options=GLib.Variant('a{sv}', None),
### partition_device:
arg_options=GLib.Variant('a{sv}', None),
arg_size=self.system_partition_size * 2**20,
arg_options=GLib.Variant('a{sv}', None),
system_partition.call_set_type_sync(ESP_GUID, GLib.Variant('a{sv}', None))
system_partition.call_set_name_sync(self.label, GLib.Variant('a{sv}', None))
self._set_partition_flags(system_partition, SYSTEM_PARTITION_FLAGS)
### update_system_partition_properties:
system_partition.call_set_type_sync(ESP_GUID, GLib.Variant('a{sv}', None))
system_partition.call_set_name_sync(self.label, GLib.Variant('a{sv}', None))
self._set_partition_flags(system_partition, SYSTEM_PARTITION_FLAGS)
### verify_filesystem:
self.popen('/sbin/dosfslabel %s %s' % (['device'], self.label))
self.popen('/sbin/e2label %s %s' % (['device'],
### install_bootloader:
self.popen('/usr/bin/pkexec /usr/bin/syslinux %s -d syslinux %s' % (
' '.join(self.syslinux_options()),['device']))
### initialize_zip_geometry:
self.popen('/usr/lib/syslinux/mkdiskimage -4 %s 0 %d %d' % (
self._drive[:-1], heads, cylinders))
### format_device:
{'label': GLib.Variant('s', self.label),
'update-partition-type': GLib.Variant('s', 'FALSE')}))
self._get_object().props.block.call_rescan_sync(GLib.Variant('a{sv}', None))
## For Windows - WindowsTailsInstallerCreator/
### detect_supported_drives:
win32file, win32api, pywintypes
win32file.GetDriveType(drive) == win32file.DRIVE_REMOVABLE
### mount_device:
XXX: ?
self.dest =['mount']
### unmount_device:
We might use this:
### partition_device:
Not implemented.
Here what we need is to perform a GPT partition on the target device.
The only realistic option we could find was to use the gdisk tools
(<>). This library provides two utilities
to create GPT partitions. The first is `gdisk.exe` a text mode interactive
application and the second is `sgdisk.exe`, which works by command line.
If we want to use `sgdisk.exe` which looks like the best option, we should
compile it by ourselves, because no binary is provided. The compilation
requires gnuwin32 popt library (<>)
which looks old and might only work up to Windows XP. On the other hand,
the only thing popt does is parsing command line parameters,
so in theory it should not be so difficult to run it in other
Windows versions, but I could not find more information.
The only alternative would be to use directly the WinAPI but it could
also require a good amount of work.
### update_system_partition_properties:
cmd = ( [ '/sbin/sgdisk' ]
+ [ '--typecode=1:%s' % ESP_GUID ]
+ [['parent'] ])
self.popen(cmd, shell=False)
Currently it uses sgdisk but we need to decide on using it or not.
### verify_filesystem:
win32api, win32file, pywintypes
win32file.SetVolumeLabel(['device'], self.label)
### install_bootloader:
self.popen('syslinux %s -m -a -d %s %s' % (
' '.join(self.syslinux_options()), 'syslinux', device))
Ref: <>
### initialize_zip_geometry:
self.popen('/usr/lib/syslinux/mkdiskimage -4 %s 0 %d %d' % (
self._drive[:-1], heads, cylinders))
### format_device:
self.popen('format /Q /X /y /V:Fedora /FS:FAT32 %s' %['device'])
Looks broken
## Persistent partition:
This is managed by the persistence-setup <>
so it is beyond the scope of the current research.
# PyGI Windows executable
I managed to create a native windows executable for a test Python/GI program under Windows 8.1
## Downloads
* Python: <>
* PyGI: <>
* cx_freeze: <>
* listdlls: <>
## Prepare
You need a Windows 8 (virtual) machine, with the files downloaded above
* in Windows double-click `python-3.4.3` and accept default choices but select "Install entire feature"
* in Windows double-click `pygi-aio-3.14.0-rev18-setup` and choose to install only
* GNOME libraries: GI, GTK, Pango (needed?)
* non-GNOME libraraies: none
* developpment files: GIR (needed?)
* in Windows double-click `cx_freeze-4.3.4.win32-py34` and accept default choices
## Test Program
import gi
from gi.repository import Gtk
dialog = Gtk.MessageDialog(None, Gtk.DialogFlags.DESTROY_WITH_PARENT, Gtk.MessageType.INFO, Gtk.ButtonsType.CLOSE, "Hello!")
* base: <>
* update the DLL directory to gnome
* update the DLL list in ` with the output of ListDLLs.exe`
* run ``
* run `Listdlls python`
* add all DLLs that are in the gnome directory to the `missing_dll` list in ``
import os, site, sys
from cx_Freeze import setup, Executable
## Get the site-package folder, not everybody will install
## Python into C:\PythonXX
site_dir = site.getsitepackages()[1]
include_dll_path = os.path.join(site_dir, "gnome")
## Collect the list of missing dll when cx_freeze builds the app
## This list should be updated with the output of ListDLLs.exe
missing_dll = ['libffi-6.dll',
## We also need to add the glade folder, cx_freeze will walk
## into it and copy all the necessary files
glade_folder = 'glade'
## We need to add all the libraries too (for themes, etc..)
gtk_libs = ['etc', 'lib', 'share']
## Create the list of includes as cx_freeze likes
include_files = []
for dll in missing_dll:
include_files.append((os.path.join(include_dll_path, dll), dll))
## Let's add glade folder and files
include_files.append((glade_folder, glade_folder))
## Let's add gtk libraries folders and files
for lib in gtk_libs:
include_files.append((os.path.join(include_dll_path, lib), lib))
base = None
## Lets not open the console while running the app
if sys.platform == "win32":
base = "Win32GUI"
executables = [
buildOptions = dict(
compressed = True,
includes = ["gi"],
packages = ["gi"],
include_files = include_files
name = "test_gtk3_app",
author = "Alan",
version = "1.0",
description = "GTK 3 test",
options = dict(build_exe = buildOptions),
executables = executables
## Build
* start "Command Prompt"
* `cd Documents/test/`
* `python bdist`. The resulting ZIP file lives in `dist/`. It is 37M big!
* `python bdist_msi` created a windows installer in `dist/`.
## Test
In another fresh windows 8.1VM
* Install "Microsoft Visual C++ 2010 SP1 Redistributable Package (x86)" (<>).
* extract the ZIP file
* run main.exe
* it works
## Next steps
* make a single executable file: <>
* bundle `msvcr100.dll`: <
* shring the ZIP:
* <>
* <>
## Other tools
* py2exe: <>
# Conclusion
We have outlined the main requirements we should face on fully porting the Tails
Installer to Windows. The major differences in the current Tails version regarding
the former upstream Fedora version, are the usage of the Python interface for GTK3
(PyGI) and the udisks2 library for disk operations.
We have found that there are alternative libraries we could use on Windows, in order
to perform the Linux specific operations. Some of them seem currently maintained and
updated, for instance, PyGI for Windows and extlinux. Other like sgdisk and its dependencies
might need some custom maintenance, which could rise the amount of required effort.
However, even with the extra required work, it seems totally likely that we can successfully
port Tails installer to Windows.
If our objective is to ease Tails adoption for Windows users, especially people that never have
used Linux, then this project may be worth the effort. The question
then becomes: is this the cheapest and/or best way to ease Tails
adoption for Windows users?
[[!map pages="blueprint/SponsorW/*"]]
Potential issues that might or might not have happened already.
From the developers point of view:
- Being told to do stuff without understand exactly why.
- Lack of synchronize between conception and development process. You
end up discovering UX issues too late.
- Cost-benefit ratio.
- Implementation starting too fast (lack of design) or, the other way
around, UX ideas bring in deep technical or security problems.
From the UX point of view:
- Developers are defensive (not important, not acknowledging the
- Lack of input from developers about technical feasibility, security,
maintenance, etc.
Fundraising and management point of view:
- Hard to prepare grant proposals without having input from both
- Hard to evaluate the time needed to implement changes. Sometimes you
know the problem already (sometimes not) but it's hard to know the
precise solution in advance.
- Hard to split responsibilities and for people to feel as working as
a team.
- UX tend to work more with big increments, involving user testing in
between while developers work with small increments and self or
automated testing so it might be hard for them to acknowledge the
need for more increments after their stuff works.
Different mind sets:
- Developer: you want something that works, that's a binary result.
- UX: you want something that is used.
- Difficult to make these two worlds communicate and agree on the
efficiency of a product.
- Improve our contribute section for developers to mention UX and
technical writing [[!tails_ticket 9926]]
- Ask feedback to the "other" side as soon as possible, or actually
better, work together from the beginning.
- Involve all actors in each grant proposal: designers, writers,
coders, sysadmins, etc.
- Find ways of involving developers in the UX process (user testing,
user feedback, etc.)
[[!toc levels=2]]
Design by design
Tails is designed to be an easy-to-use Live operating system as well as a toolkit for privacy and anonymity for the masses.
We organized several workshops at NUMA to improve the usability of Tails. We realized that it is hard for people who are not tech-savvy and/or new to Tails:
- to understand what Tails is;
- to install Tails;
- to boot Tails.
We want to improve this situation.
First-time visitors on the Tails website should be able to enjoy a consistent experience, from understanding if Tails is the right tool for them, to achieving their actual goals by using it.
From the inside, to the outside
We want to go from the inside to the outside, from the skeleton to the surface. E.g. having a rocking website _first_ might lead potential users to think that Tails is easy enough for them, while it is not the case yet, which could be problematic in some cases.
This is why, hereafter you will find a description of the logical order of steps. Of course, we can still work simultaneously on all of these steps, *but* it is useful to keep the whole roadmap in mind along the way.
In 2015, we focused on [[Bootstrapping and upgrading workflow (granted)|blueprint/bootstrapping/]] and going on the the [[Greeter UI revamp|]].
1. Inside
* Change the language selection position in the Greeter [[!tails_ticket 9922]]
* Onion Circuits [[!tails_ticket 6842]]
* Graphical interface for additional packages persistence feature + improve the related boot delay [[!tails_ticket 9050]] & [[!tails_ticket 9059]]
* MAT [[!tails_ticket 7684]]
* Greeter revamp: phase 1 [[!tails_ticket 5464]]