GitLab

Currently translated at 17.7% (11 of 62 strings)

Translation: Tails/wiki/src/news/version_3.14.1.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_3141po/pt/

Currently translated at 39.0% (16 of 41 strings)

Translation: Tails/wiki/src/news/version_3.11.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_311po/it/

To be consistent with other Tails apps (e.g. additional-software).

commit:7dc8f638 introduced usage
of $TBB_EXT.

ibus-pinying is deprecated and in Tails 3.12.1, it segfaults when enabling
Bopomofo support. Let's replace it with ibus-libpinying — which supports
both Chinese Pinyin and Chinese ZhuYin (Bopomofo) — and also install
ibus-chewing, that according to some sources has better Bopomofo support:

  https://wiki.archlinux.org/index.php/IBus
  https://www.pinyinjoe.com/linux/ubuntu-18-gnome-chinese-setup.htm

This way tails-additional-software-notify will open a browser with
propoer "GNOME" environment no matter who calls it.

Regression introduced when migrating to Tor Browser 8.x in Tails
3.9~rc1 (Tails 3.8 with the last Tor Browser 7.5.x release is fine).

We lacked sufficient environment for AT-SPI to work for the browser
child processes started for browsing the docs.

At this point it's unclear whether there's a problem to solve
(https://redmine.tails.boum.org/code/issues/16299#note-20)
and if there's one, whether this is the best way to solve it
(https://redmine.tails.boum.org/code/issues/16299#note-19).

This reverts commit a2bb3bf0.

We shipped thunderbird with Autocrypt enabled by default. As Tails we do
not recommend to use Autocrypt by default at the moment. Ask the user,
what they want to do abut Autocrypt.

It's called tailslib.adminpassword now that it's been moved to the
tailslib module.

- Appropriate changes in 'tails-screen-locker' and 'replace-su-with-sudo'
made.
- URL to 'pythonlib' submodule updated.
- PYTHON_PROGS sorted.

Mount a dedicated tmpfs on /run/initramfs instead of trying to remount /run with the "exec" option (refs: #16097).

My previous approach, i.e. "let's remount /run with the exec option via a unit
file started as part of the shutdown procedure", worked just fine for clean
shutdown. But it does not work for emergency shutdown, i.e. when the boot medium
is physically removed: for some reason (possibly missing bits in the memlockd
configuration), this service is not started, and then systemd-shutdown won't
return to the initramfs because /run/initramfs/shutdown is not executable.

So let's instead disregard /run and extract the initramfs into a dedicated
tmpfs, that we mount on /run/initramfs (where systemd-shutdown will look for
it), and that we mount without the "noexec" option.

Also, remove manual calls to eject(1):

 - They increase chances that the shutdown process breaks due to missing
   files locked in memory by memlockd.

 - Their sole benefit is to ensure we physically eject the DVD. It's unclear if
   this code is still needed nowadays. Regardless, starting with Tails 3.12, the
   only supported use case for ISO and DVD is virtual machines, which are not
   targeted by the emergency shutdown feature, which is about removing the
   *physical* boot medium.

Remounting /run with the "exec" option in /lib/systemd/system-shutdown/tails
does not work anymore with systemd v239, while it worked at least until systemd
v237. I could not find out why by reading systemd's NEWS file.

So let's instead do this there:

 - For clean shutdown: in a new, dedicated service, started immediately before
   final.target, which itself is a synchronization point that ensures this
   service is started before the transition to systemd-shutdown and in turn to
   the initramfs, where we finish the unmounting and other clean ups needed to
   erase the memory.

 - For emergency shutdown: in the udev watchdog script, before calling the
   unclean shutdown code, which bypasses final.target and thus won't run
   tails-remount-run-exec.service. Too bad we have to duplicate this mount
   command but it seems that both instances will become unnecessary quickly
   enough, once systemd DTRT™. Another way would be to manually start
   tails-remount-run-exec.service from the udev watchdog script but I'm
   concerned it will be unreliable when the boot medium has been unplugged.

1. 'tails.py':
- Renamed from 'tails_is_password_set.py'
- Added comment specifying the source and purpose of this file.
- Updated references in 'replace-su-with-sudo' and
'tails-screen-locker'.

2. 'replace-su-with-sudo':
- Added comment to describe its source and role.
- Edited 'print(_('"..."'))' to avoid double quotes printed by using
 'su'.
- Replaced 'exit' with 'sys.exit'.

1. 51-update-bash.bashrc:
- Add comment to '/etc/bashrc' ('The following code is added by XYZ
script').
- Removal of OPTS_FILE variable.

2. replace-su-with-sudo.sh:
- Updated comment to better describe the role of this script.
- Moved output stuff to '/usr/local/bin/replace-su-with-sudo'.
- Moved translation stuff to '/usr/local/bin/replace-su-with-sudo'.
- 'su' function will now simply call the 'replace-su-with-sudo' script.

3. replace-su-with-sudo:
- Created new script
- It handles the logic and output (with translation) of 'Please use sudo
instead' message.

4. tails_is_password_set.py
- Moved from /usr/local/bin/ to /usr/local/lib/python3/dist-packages/
- Removed main() function. This file is now just a library; not meant to
be executed as a standalone script.

5. 'POTFILES.in' and 'refresh-translations':
- Modified to accommodate the changes made in 'replace-su-with-sudo.sh'
and 'replace-su-with-sudo'.

1. Created a helper script 'tails_is_password_set.py'. It contains a
single function at this time, 'is_password_set', which returns a boolean
depending on whether the current user's password is set or not.

2. Modified tails-screen-locker to use the new helper script.

3. Deleted '51-replace_su_with_sudo' hook. An alternative solution was
recommended by intrigeri to resolve bug#15583. The new solution will be
implemented in future commits.

Will-fix: #16110

For example, people using VirtualBox on Windows should also be told that
only free software can be trustworthy.

It is not safe in its current state (refs: #15923).

Will-fix: #16186

We've seen users that use a persistent Thunderbird configuration being
stuck with English even if their session is in another locale.

Will-fix: #16113

People get confused by the use of pal/neutral/foe: they think we need
to particularly trust members of the "pal" pool, which is incorrect
and can lead to useless controversy.

So let's fix this by renaming the pools and clarifying our design doc.

Will-fix: #15983

Convert packages names to set as map objects sometimes don't
behave as expected.

Will-fix: #15983

fix custom auth cookie authentication path

Previously the following line in Tor config...

```
HashedControlPassword
16:88A1B9F6EBD74C6960E1E60CC725B6C94A990C65223358EFF0DF41E8BA
```

Was leading the the following error:

```
Sep 13 22:02:08 host onion-grater[10460]: Exception happened during
processing of request from ('10.137.0.45', 48828)
Sep 13 22:02:08 host onion-grater[10460]: Traceback (most recent call last):
Sep 13 22:02:08 host onion-grater[10460]:   File
"/usr/lib/python3.5/socketserver.py", line 625, in process_request_thread
Sep 13 22:02:08 host onion-grater[10460]:
self.finish_request(request, client_address)
Sep 13 22:02:08 host onion-grater[10460]:   File
"/usr/lib/python3.5/socketserver.py", line 354, in finish_request
Sep 13 22:02:08 host onion-grater[10460]:
self.RequestHandlerClass(request, client_address, self)
Sep 13 22:02:08 host onion-grater[10460]:   File
"/usr/lib/python3.5/socketserver.py", line 681, in __init__
Sep 13 22:02:08 host onion-grater[10460]:     self.handle()
Sep 13 22:02:08 host onion-grater[10460]:   File
"/usr/lib/onion-grater", line 651, in handle
Sep 13 22:02:08 host onion-grater[10460]:     self.controller =
self.connect_to_real_control_port()
Sep 13 22:02:08 host onion-grater[10460]:   File
"/usr/lib/onion-grater", line 592, in connect_to_real_control_port
Sep 13 22:02:08 host onion-grater[10460]:
controller.authenticate(cookie)
Sep 13 22:02:08 host onion-grater[10460]:   File
"/usr/lib/python3/dist-packages/stem/control.py", line 1071, in authenticate
Sep 13 22:02:08 host onion-grater[10460]:
stem.connection.authenticate(self, *args, **kwargs)
Sep 13 22:02:08 host onion-grater[10460]:   File
"/usr/lib/python3/dist-packages/stem/connection.py", line 575, in
authenticate
Sep 13 22:02:08 host onion-grater[10460]:
authenticate_password(controller, password, False)
Sep 13 22:02:08 host onion-grater[10460]:   File
"/usr/lib/python3/dist-packages/stem/connection.py", line 711, in
authenticate_password
Sep 13 22:02:08 host onion-grater[10460]:     password =
password.replace('"', '\\"')
Sep 13 22:02:08 host onion-grater[10460]: TypeError: a bytes-like object
is required, not 'str'
```

```
ls -la /var/run/tor/
```
```
total 148
drwxr-sr-x  2 debian-tor debian-tor    140 Sep 13 22:15 .
drwxr-xr-x 28 root       root          760 Sep 13 22:00 ..
srw-rw----  1 debian-tor debian-tor      0 Sep 13 22:15 control
-rw-r-----  1 debian-tor debian-tor     32 Sep 13 22:15 control.authcookie
-rw-r-----  1 debian-tor debian-tor 143123 Sep 13 22:15 log
srw-rw-rw-  1 debian-tor debian-tor      0 Sep 13 22:15 socks
-rw-r--r--  1 debian-tor debian-tor      6 Sep 13 22:15 tor.pid
```
```
DataDirectory /var/lib/tor
PidFile /var/run/tor/tor.pid
RunAsDaemon 1
User debian-tor

ControlSocket /var/run/tor/control GroupWritable RelaxDirModeCheck
ControlSocketsGroupWritable 1
SocksPort unix:/var/run/tor/socks WorldWritable
SocksPort 9050

CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /var/run/tor/control.authcookie

Log notice file /var/log/tor/log
```

The HashedControlPassword confused python-stem even
though cookie authentication was functional without that HashedControlPassword.

There is no need to manually read Tor authentication cookie file.

        with open(global_args.control_cookie_path, "rb") as f:
            cookie = f.read()

python-stem can do that for us.

Line

```
controller.authenticate(cookie)
```

was wrong. `controller.authenticate` does not take

Syntax from manual:

https://stem.torproject.org/api/connection.html#stem.connection.authenticate

```
stem.connection.authenticate(controller, password=None, chroot_path=None, protocolinfo_response=None)
```

... and remove now obsolete scripts which we used to update the config file