Re: [Tails-dev] Why Tails partition is non-deterministic?

[Random User]

On Mon, Aug 8, 2016, at 03:32 PM, Joanna Rutkowska wrote:
> Hello,
> 
> Is there any special reason why the partition where Tails installs itself
> is
> non-deterministic? It is thanks to differing timestamps on the
> filesystem.

What you have asked about sounds at least similar to an issue I had
reported on this list a while back. I had reported that the checksums
(sha256, sha1, md5, etc.) of the Tails partition (on USB, created by dd)
no longer matched that of the Tails ISO from which said partition was
written. I say "no longer" because there had been a time when these
values did match. That changed at some point with one of the releases
and the change remained for an extended period, through a number of
releases. Then, I believe with the latest release, Tails 2.5, the hashes
for the ISO and the partition of the installation written from the ISO
(via dd, on USB) once again were the same.

The cause of these changes remains a mystery to me.

> This posses a problem for a prudent user who would like to be able to
> verify
> Tails integrity, e.g. by typing:
> 
> dd if=/dev/sda1 | sha1sum

How is that different from "sha1sum /dev/sdX*"?

Isn't your version just a lengthier and less simple means of achieving
the identical end: obtaining the checksum of a given partition (in this
case, the sha1 of the partition that Tails installed itself on). Perhaps
I am missing something?

*X for the specific device value, which will obviously change

> This might be especially useful if one uses the stick on various
> computers and
> would like to verify if her USB stick holding Tails installs hasn't been
> modified (e.g. by a malicious BIOS). 

Or (and this is obviously applicable even when one always uses his Tails
device on the same computer) that the Tails partition itself was not
altered by a remote attacker (such as while one was online using Tails)
or even a local attacker (such as while one's Tails stick was left
unattended-- even if within a secured space, unless one can somehow be
sure that no one unauthorized entered said space). 

Now, of course, this means of verification is still possible even when
the hash of the (verified) ISO does /not/ match that of the partition
created from same ISO-- providing that one made sure to record the hash
of the Tails partition right after creating it (before using it for the
first time and before leaving the device it is contained-on unattended).
But when the checksums of the Tails partition match those of the ISO
that said partition was created from, then one has the additional
advantage of knowing that the actual writing/installation itself was
completed without error or corruption.   

>Yes, I'm aware that the first sector
> of the
> disk (/dev/sda) would still differ thanks to different partition sizes.

Right, meaning that an attacker in whatever form (including a
compromised BIOS or other hardware component) could leave the Tails
partition itself untouched, yet alter another section of the device.
 
What I therefore do, in addition to recording the checksum of the Tails
partition that I created from the ISO (/dev/sdX), is to /also/ record
the checksum of the /entire device/ (USB stick). In this way, I can
presumably be reasonably certain that my stick has not been tampered
with by verifying, at any given time (such as after using it or after
leaving it unattended) that the checksum for the full-device (/dev/sdX)
still matches the one I recorded just after installing Tails on it.

/Persistence/, of course, presents an exception to this; obviously, one
cannot expect the checksum for the persistence partition not to change
with each and every change, no matter how small and insignificant, that
the user makes to said partition. 

Having noted that, however, I must /also/ mention an experience I recall
with a USB stick that I had created, with a persistence partition, using
Tails Installer. If I recall correctly, I had found that after each use
of this USB stick to boot and run Tails, the hash for the persistence
partition would change-- /even when I had NOT enabled persistence (or
otherwise consciously accessed the persistence partition) for that
session. Although I do not know the reason for this behavior, I suspect
that it somehow may be very much related to the topic that Ms. Rutkowska
created this thread about.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Changelog: "Unstable" Huh?!

[Random User]

https://git-tails.immerda.ch/tails/plain/debian/changelog 
lists each Tails release as "unstable".  Why? These are the final
releases; not betas or release candidates.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [review'n'merge] small typo

[emmapeel]

ey there:

here a patch for a typo on the website.

please review and merge.
From c5f370cb5c61d81aa370046a4377d29a4426420b Mon Sep 17 00:00:00 2001
From: emma peel 
Date: Thu, 25 Aug 2016 01:08:11 +
Subject: [PATCH] small typo

---
 wiki/src/doc/first_steps/startup_options.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wiki/src/doc/first_steps/startup_options.mdwn b/wiki/src/doc/first_steps/startup_options.mdwn
index 83f20b5..615ae6e 100644
--- a/wiki/src/doc/first_steps/startup_options.mdwn
+++ b/wiki/src/doc/first_steps/startup_options.mdwn
@@ -10,7 +10,7 @@ functioning. The two ways of specifying startup options are the following:
 Using the boot menu
 
 
-The boot menu is the first screen to appears
+The boot menu is the first screen to appear
 when Tails starts.
 
 
-- 
2.1.4



signature.asc
Description: OpenPGP digital signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] New Tor releases: 0.2.8.7 and 0.2.9.2-alpha

[Nick Mathewson]

Hello!

There are two new source releases available on dist.torproject.org.
Please remember to check the signatures.


Changes in version 0.2.8.7 - 2016-08-24
  Tor 0.2.8.7 fixes an important bug related to the ReachableAddresses
  option in 0.2.8.6, and replaces a retiring bridge authority. Everyone
  who sets the ReachableAddresses option, and all bridges, are strongly
  encouraged to upgrade.

  o Directory authority changes:
- The "Tonga" bridge authority has been retired; the new bridge
  authority is "Bifroest". Closes tickets 19728 and 19690.

  o Major bugfixes (client, security):
- Only use the ReachableAddresses option to restrict the first hop
  in a path. In earlier versions of 0.2.8.x, it would apply to
  every hop in the path, with a possible degradation in anonymity
  for anyone using an uncommon ReachableAddress setting. Fixes bug
  19973; bugfix on 0.2.8.2-alpha.

  o Minor features (geoip):
- Update geoip and geoip6 to the August 2 2016 Maxmind GeoLite2
  Country database.

  o Minor bugfixes (compilation):
- Remove an inappropriate "inline" in tortls.c that was causing
  warnings on older versions of GCC. Fixes bug 19903; bugfix
  on 0.2.8.1-alpha.

  o Minor bugfixes (fallback directories):
- Avoid logging a NULL string pointer when loading fallback
  directory information. Fixes bug 19947; bugfix on 0.2.4.7-alpha
  and 0.2.8.1-alpha. Report and patch by "rubiate".




Changes in version 0.2.9.2-alpha - 2016-08-24
  Tor 0.2.9.2-alpha continues development of the 0.2.9 series with
  several new features and bugfixes. It also includes an important
  authority update and an important bugfix from 0.2.8.7. Everyone who
  sets the ReachableAddresses option, and all bridges, are strongly
  encouraged to upgrade to 0.2.8.7, or to 0.2.9.2-alpha.

  o Directory authority changes (also in 0.2.8.7):
- The "Tonga" bridge authority has been retired; the new bridge
  authority is "Bifroest". Closes tickets 19728 and 19690.

  o Major bugfixes (client, security, also in 0.2.8.7):
- Only use the ReachableAddresses option to restrict the first hop
  in a path. In earlier versions of 0.2.8.x, it would apply to
  every hop in the path, with a possible degradation in anonymity
  for anyone using an uncommon ReachableAddress setting. Fixes bug
  19973; bugfix on 0.2.8.2-alpha.

  o Major features (user interface):
- Tor now supports the ability to declare options deprecated, so
  that we can recommend that people stop using them. Previously,
  this was done in an ad-hoc way. Closes ticket 19820.

  o Major bugfixes (directory downloads):
- Avoid resetting download status for consensuses hourly, since we
  already have another, smarter retry mechanism. Fixes bug 8625;
  bugfix on 0.2.0.9-alpha.

  o Minor features (config):
- Warn users when descriptor and port addresses are inconsistent.
  Mitigates bug 13953; patch by teor.

  o Minor features (geoip):
- Update geoip and geoip6 to the August 2 2016 Maxmind GeoLite2
  Country database.

  o Minor features (user interface):
- There is a new --list-deprecated-options command-line option to
  list all of the deprecated options. Implemented as part of
  ticket 19820.

  o Minor bugfixes (code style):
- Fix an integer signedness conversion issue in the case conversion
  tables. Fixes bug 19168; bugfix on 0.2.1.11-alpha.

  o Minor bugfixes (compilation):
- Build correctly on versions of libevent2 without support for
  evutil_secure_rng_add_bytes(). Fixes bug 19904; bugfix
  on 0.2.5.4-alpha.
- Fix a compilation warning on GCC versions before 4.6. Our
  ENABLE_GCC_WARNING macro used the word "warning" as an argument,
  when it is also required as an argument to the compiler pragma.
  Fixes bug 19901; bugfix on 0.2.9.1-alpha.

  o Minor bugfixes (compilation, also in 0.2.8.7):
- Remove an inappropriate "inline" in tortls.c that was causing
  warnings on older versions of GCC. Fixes bug 19903; bugfix
  on 0.2.8.1-alpha.

  o Minor bugfixes (fallback directories, also in 0.2.8.7):
- Avoid logging a NULL string pointer when loading fallback
  directory information. Fixes bug 19947; bugfix on 0.2.4.7-alpha
  and 0.2.8.1-alpha. Report and patch by "rubiate".

  o Minor bugfixes (logging):
- Log a more accurate message when we fail to dump a microdescriptor.
  Fixes bug 17758; bugfix on 0.2.2.8-alpha. Patch from Daniel Pinto.

  o Minor bugfixes (memory leak):
- Fix a series of slow memory leaks related to parsing torrc files
  and options. Fixes bug 19466; bugfix on 0.2.1.6-alpha.

  o Deprecated features:
- A number of DNS-cache-related sub-options for client ports are now
  deprecated for security reasons, and may be removed in a future
  version of Tor. (We believe that client-side DNS cacheing is a bad
  idea for anonymity, and you 

Re: [Tails-dev] Changing default order in Nautilus

[ghostlands]

Awesome explanation. Thanks heaps. Looks like the dotfiles option is the 
most straightforward.


Re: upgrade hazards, maybe dconf locks could help: 
https://help.gnome.org/admin/system-admin-guide/stable/dconf-lockdown.html


ghostlands


On 2016-08-24 14:18, intrigeri wrote:

ghostla...@autistici.org:
Why is it not already possible for the persistence feature to 
save/reference the
.config directory and everything in it (and whatever other config 
directories in the

home directory)? And of course load these saved settings at startup?


This would persist not only the settings that the user really meant to
change in a persistent way, but it will also freeze all the other
settings stored in ~/.config/ to the value that we set in Tails at the
time when they made this directory persistent. In other words, a part
of their Tails system will never be upgraded anymore, and the user has
little knowledge and control over what's in this part. This is not
something that I want to even try supporting.

For ~/.config/ I would suggest using the Dotfiles feature instead,
since it allows adding a custom persistent overlay *on top* of the
defaults that one did not mean to modify nor persist.

For dconf one "should just" implement dumping/loading a list of
user-specified keys to/from persistence. It should be simple to solve
that for technical users (who can already workaround this easily so
it's not worth it), and non-trivial to solve in a way that is easy &
safe to use for everyone else. Which probably explains why nobody has
implemented it yet.

Cheers,

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Changing default order in Nautilus

[intrigeri]

ghostla...@autistici.org:
> Why is it not already possible for the persistence feature to save/reference 
> the
> .config directory and everything in it (and whatever other config directories 
> in the
> home directory)? And of course load these saved settings at startup?

This would persist not only the settings that the user really meant to
change in a persistent way, but it will also freeze all the other
settings stored in ~/.config/ to the value that we set in Tails at the
time when they made this directory persistent. In other words, a part
of their Tails system will never be upgraded anymore, and the user has
little knowledge and control over what's in this part. This is not
something that I want to even try supporting.

For ~/.config/ I would suggest using the Dotfiles feature instead,
since it allows adding a custom persistent overlay *on top* of the
defaults that one did not mean to modify nor persist.

For dconf one "should just" implement dumping/loading a list of
user-specified keys to/from persistence. It should be simple to solve
that for technical users (who can already workaround this easily so
it's not worth it), and non-trivial to solve in a way that is easy &
safe to use for everyone else. Which probably explains why nobody has
implemented it yet.

Cheers,
-- 
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Changing default order in Nautilus

[ghostlands]

I'd like to butt in with a question here, with apologies for whatever 
obvious things I may be missing (that I hope someone is also willing 
point out):


Why is it not already possible for the persistence feature to 
save/reference the .config directory and everything in it (and whatever 
other config directories in the home directory)? And of course load 
these saved settings at startup?


There's always the threat of a user changing a config file in a way that 
breaks security; however I'm not sure what the best thing to do to would 
be in order to command the more sensitive programs to store their 
settings separately. It might just be correct to leave the 
responsibility for those kinds of fumbles up to the user anyway.


Am I totally wrong that this is the simplest way for any user to save 
settings?


ghostlands


On 2016-07-27 18:58, Ulrich Viefhaus wrote:
I didn't test using ~/.dconf as you are suggesting, but only by 
reading

your documentation, it's not clear to me how it works. Dotfiles only
work for *files* (and not for *folders*). So which file should be
included in the Dotfiles? Also, will this file store all changes made 
to

the GNOME configuration without allowing the user to choose which
changes are made persistent and which not? Would these be binaries 
files

or would it be possible for the user to review what's being changed?


ALL changes to the gnome settings would be persistent,
if the folder is made persistent. Thats because the newer dconf system
saves all settings in a binary file, thats optimized for reading. The
older gconf system used a xml file for each program.
That makes it a little bit harder for the user.


For example, on my own setup, I made the ~/.xsessionrc file persistent
using Dotfiles and added lines of gsettings commands to it. This way I
can opt-in for which changes I want to make persistent and also review
the sum of my changes.

If feel like these are two very important properties (opt-in +
reviewable). But I'm not very knowledgeable about GNOME internals so
maybe there's a better option than .xsessionrc.


I agree with you. I'm going to brainstorm a little bit in the following
parts, but I think I have an

It is possible to watch all changes by calling "dconf watch / > 
logfile"

at the beginning of a session. This way you can directly see, then
something changes. But evolution and other programs produce some noise
there. I don't think this can be used for opt-in or review.

An other possibility is to use the command "dconf dump / > dump.dconf".
It shows all changes made by the user and saves them to the dumpfile.
This file could be made persistent. You can load it at the beginning of
a new session with "dconf load / < dump.dconf".
But it also contains a lot of noise like this:
[apps/seahorse/windows/key-manager]
width=1366
height=702
It would be quite troublesome to figure out which lines to keep.

But you could save changes directly to a dotfile. The structure is 
quite

simple, if you already know the command for gsettings.
For example, you could save the following as a dotfile and load it with
dconf load, to change the folder view of nautilus:
[org/gnome/nautilus/preferences]
default-folder-viewer='list-view'
The gsettings command would be "gsettings set
org.gnome.nautilus.preferences default-folder-viewer list-view". There
exists documentation about writing such "schemes". Or you can dump
single settings with the dump command and append it to your config 
file.


You can then save all your settings in a dotfile and load that with
dconf, then the persistent memory is loaded at the beginning of a
session.

I admit that it is not easier than your .xsessionrc method. But I think
it makes it a little bit more clear to the average user, if he/she has 
a

configuration file with a clear syntax dedicated to such changes.


Kind regards,
 Ulrich


___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [tor-dev] [GSoC] Tails Server - Final status report

[sajolida]

segfault:
> Hi everone,
> 
> the GSoC ends this week. My goal was to implement the basis of the Tails
> Server, which should include a GUI and a CLI to install, configure and
> start onion services in Tails. I implemented a prototype which meets
> this goal. There are nightly images [1] of Tails including this
> prototype and the code is available here [2]. This is not yet a call for
> testing, but there will be one at some point.

Your GSoC went really well and the results are excellent!

Just to get people more excited, it's now possible to do group call over
Tails only (server + client) using Mumble. We'll definitely be using
this a lot internally at least.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [review'n'merge] Remove useless alt in documentation

[xin]

> I did not look at the branch but it should not completely remove the
> alt, just its contents when necessary.

Sorry for my misspelling, when I say "remove alt" I talk about the
content, not the tag itself.

xin



signature.asc
Description: OpenPGP digital signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.