[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tails-dev
Subject:    [Tails-dev] Tails report for April, 2013
From:       intrigeri () boum ! org (intrigeri)
Date:       2013-05-12 12:36:55
Message-ID: 85a9o0qsrc.fsf () boum ! org
[Download RAW message or body]

Hi Jacob,

Jacob Appelbaum wrote (11 May 2013 19:40:04 GMT) :
> Tails folks:

>> - 71 reports were received through WhisperBack.

> Is there a common complaint or are most of these automated?

All of these are bug reports manually submitted by Tails users.
I believe that most of these Tails users are human.

>> - 1515 comments were posted on the forum, with 76 signed by Tails. This
>>   means there has been much more activity on the forum, and that we are
>>   having a hard time coping with it, but also that anonymous
>>   contributors are providing more and more good answers without our
>>   help.

> Quite nice. Is English the primary language?

English is the only supported language on this forum.

>> - The persistence feature to remember installed packages (has matured a
>>   lot) and should be ready for Tails 0.18.
>> 
>>   https://tails.boum.org/todo/remember_installed_packages/

> Will it be possible to ensure that this isn't abused for persistent
> rootkits?

I don't think so: APT/dpkg have no way to know if a given .deb
contains a rootkit or not.

On the other hand, in current Tails, a targeted rootkit installed
after having gained root privileges can probably already implant
itself in a persistent way, so I don't think that this feature changes
much on this side. Especially given the package checking done by APT
(technical side) and by the organizations that run the configured APT
repositories (social side).

> Also, I wonder if there is a way to verify the packages as
> being both up to date and actually valid packages from a valid repo?

This feature updates these packages once networking is up.

The packages are installed with APT, so they must be referenced in
a configured repository to be installed. APT takes care of the
packages validity wrt. the signed indices distributed by the
configured repositories.

>> - IPv6 is not disabled anymore. It turns out that the IPv6 leaks we
>>   wanted to fix actually don't exist.
>> 
>> 
>> http://git.immerda.ch/?p=amnesia.git;a=shortlog;h=refs/heads/feature%2Fenable%2DIPv6
>> 

> Unless I'm mistaken, without a random MAC address, IPv6 has some pretty
> bad privacy concerns, no?

Tails firewall blocks both incoming and outgoing IPv6 traffic,
so I don't think this is a problem in practice in current Tails.

In the future, when we want to enable some IPv6 traffic, initially
it's likely to be onioncat traffic (limited to the onioncat
interface), and on the long run, the worst parts should be covered by
the IPv6 Privacy Extensions (enabled by default for new connections
NetworkManager 0.9.4+).

We've not researched these long term plans yet anyway, and you're
warmly welcome to elaborate on the privacy concerns you were thinking
of :)

>> - "secure and simple network time (hack)", about tlsdate, a possible
>>   segmentation fault and its future in Tails
>> 
>>   https://mailman.boum.org/pipermail/tails-dev/2013-April/002843.html

> I'm interested in moving this forward - what more needs to be discussed
> after I upload version 0.0.7? If there are specific changes, I'd like to
> know soon as I'd like to put out the release soon.

I have to admit I've not been able to process this long thread yet.
Sorry about that, and thanks for having the discussion!

>> - The grant application we did with OpenITP (Sponsor Echo) was rejected.
>>   But our proposal made it to their finalist set.

> What? That is really sad. Did they explain why?

No, they did not elaborate further than something like "your project
is good, but unfortunately we can't fund everybody".

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

[prev in list] [next in list] [prev in thread] [next in thread]