Re: [Tails-dev] Release schedule for Tails 0.21

2013-10-10 Thread intrigeri
Hi,

intrigeri wrote (24 Sep 2013 13:32:19 GMT) :
> Here's its preliminary release schedule for Tails 0.21, which will be
> a major new release:

Minor changes follow:

>   2013-10-01   enable stable-proposed-updates to bring the Squeeze
>6.0.8 point-release's packages in
>   2013-10-18   freeze, build & upload RC1

This will instead happen on the 17th.

>   2013-10-19   test RC1

This will instead happen mainly on the 18th, and a bit on the 19th
(deadline: 2pm CEST on the 19th).

>   2013-10-20   publish RC1
>   2013-10-20   Squeeze 6.0.8 point-release is out,
>let's disable stable-proposed-updates

>   2013-10-26   package new Firefox ESR
>   2013-10-26   build and upload final ISO
>   2013-10-27   test final ISO
>   2013-10-28   test final ISO (deadline: noon CEST)
>   2013-10-29   release

> Core developers: ASAP, please volunteer for the test day, or make it
> clear that you can't make it, so we can reschedule slightly if
> needed, thanks!

Core developers: we have enough volunteers for testing RC1, but we
still need more for testing the final ISO.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev


Re: [Tails-dev] Web page error

2013-10-10 Thread sajolida
On 12/09/13 12:10, Alan wrote:
>> On your web page "https://tails.boum.org/about/";, you give a
>> definition:
>>
>> amnesiac, noun:
>> forgetfulness; loss of long-term memory.
>>
>> That's the definition of "amnesia". An "amnesiac" is a person who has
>> amnesia.
>>
> 
> Thanks for your attention!
> 
> Do you confirm that the right formulation would be:
> 
> amnesia, noun:
> forgetfulness; loss of long-term memory

Yes, it is. I'm fixing that. Thanks for the comment Mike!

  amnesia, n.
 1. (Med.) Forgetfulness; loss of long-term memory. --Quian.
[1913 Webster + AS]

  amnesiac, n. (Med.)
 A patient suffering from amnesia.
 [AS]




signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev


Re: [Tails-dev] Quarterly tickets gardening: outcome and proposals

2013-10-10 Thread intrigeri
sajol...@pimienta.org wrote (09 Oct 2013 08:15:48 GMT) :
> Then what about having 'Assigned to: "wishlist", and a priority
> "Normal" most of the time, unless we feel a task needs
> something different?

"Assigned to: wishlist" doesn't feel very clear to me, so I'm
unsure. Others?

(Worst case, there's still my proposal of solving this in the
contributors doc.)

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev


Re: [Tails-dev] Fix to #5917 tails-greeter password field : Warn when caps-lock in ON

2013-10-10 Thread Andres Gomez Ramirez
Hi intrigeri,

> If that were the case, then indeed the piece of code that hides the
> caps lock warning would never be run.

> Also, please make sure your commits don't add space errors.
> Git commit warns you about this.

yes I was adding tabs and spaces in indentation, but i doesn't affect the 
expected behavior of the code. It's just that the key event for caps lock (when 
it is on) is not detected or activated at all. If you try with any other key it 
works.

Cheers,
Andres
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev


Re: [Tails-dev] [RFC] Design (and prototype) for MAC spoofing in Tails

2013-10-10 Thread anonym
09/10/13 22:01, irregula...@riseup.net wrote:
> On 10/09/2013 07:32 PM, anonym wrote:
>>
>> ## Using Tails at home
>>
>> First, note that the user's relation (owner, family member's,
>> friend's, work's, borrowed, etc.) to the computer running Tails
>> doesn't matter; the location is already directly related to the user's
>> identity. Similarly, because of this, MAC spoofing is of very limited
>> value for both AvoidTracking and AvoidIdTails value.
>>
>> MAC spoofing could hinder AvoidSuspicion if detected by the ISP's
>> hardware (i.e. no trusted router in the way). Similarly, ISP-provided
>> hardware may employ some sort of MAC address white-listing (e.g. only
>> X unique ones are allowed) that can prevent AvoidConnectionProbs.
>>
>> Summary: MAC spoofing should be avoided but isn't terribly dangerous
>> if enabled.
>>
> 
> That's a very thorough and interesting analysis on changing mac address,
> thanks.
> 
> I want to argue on "MAC spoofing should be avoided but isn't terribly
> dangerous if enabled." when using Tails at home. I wouldn't say that
> AvoidIdTails is negligible.

The real solution for AvoidIdTails would be to hide the use of Tor
completely, e.g. by using obfsproxy. Also, see the "No mention of
AvoidIdTails as motivation?" section. Despite us having this user goal,
the real motivation for MAC spoofing is AvoidTracking.

However, I don't think AvoidIdTails is what you're really talking about
below.

> As you correctly write spoofing MAC could raise suspicion. On the other
> hand, if user is under surveillance for whatever reason, and an
> adversary's goal is to link the user to a certain internet persona, for
> example a nickname in an IRC room. Adversary is monitoring user's local
> router and correlates the following :
> 
> - a MAC address connects to the router
> - that PC starts using Tor
> - a certain nickname shows up in the IRC room
> 
> After a period of time that the adversary monitors the above events and
> seeks for correlation, is able to be certain that user is the one using
> that nickname.

This isn't really what AdvGoalIdTails and the corresponding Tails user
mitigation goal, AvoidIdTails, is about. It's more akin to
AdvGoalTracking, with a twist of traffic-confirmation, which is outside
of Tor's threat model, and hence Tails'. The adversary has used
traffic-confirmation to establish that the traffic of interest
originates from some known location, and what remains is to either prove
that a suspect user is at that location at the time, and also to
identify the user in case s/he is unknown. However, since the "known
location" is the users *home*, we lose.

> All the adversary has to do now, is prove that the MAC address is owned
> from that user.
> 
> Of course if adversary is constantly monitoring user's connections and
> router, will be alarmed when a random MAC will appear. Nevertheless that
> MAC does not provably belong to the user.

This seems like wishful thinking to me (I certainly wish it to be true!
:)). Isn't the connection between a home Internet connection and the
residents of that home too strong to yield that kind of plausible
deniability?

> Interestingly a similar case is described in Hammond Jeremy's complaint,
> page 29 [1], when FBI agents used wireless traffic sniffing, MAC address
> logging to correlate Hammond to a certain persona.

I had a quick look, and I suspect the MAC address stuff was what they
used to single out Hammond's traffic from any other they happen to sniff
over wireless. Could it also have been necessary for their pen/trap
court order? Even if so I imagine there are several other ways they
could have gotten one even if Hammond employed MAC spoofing.

I think we have to assume that no matter what we do, we're screwed if
we're victims of targeted surveillance. What Tails can help with is the
*technical side* of not getting there in the first place. Hammond seems
to have put himself there through due to a weak security culture.

Cheers!
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev