Re: [Tails-dev] Consider adding -D_FORTIFY_SOURCE=3 to some applications (e.g., web browser)?

[jvoisin via Tails-dev]

>> Has anyone looked into adding -D_FORTIFY_SOURCE=3 to some
>> It's unclear how much the performance impact is; probably the only way to 
>> know is to try it.

I'd argue that it's also unclear what security benefits it would bring
to a web-browser :P

But having it enabled in Debian by default would indeed by sweet. Do you
have a link to the bug you opened intrigeri?

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

Re: [Tails-dev] [Tails-news] Tails 4.28 is out

[jvoisin via Tails-dev]

I successfully reproduced it: https://rebuilderd.dustri.org/api/v0/pkgs/list

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

Re: [Tails-dev] DEDA - Tracking Dots Extraction, Decoding and Anonymisation toolkit

[jvoisin]

Unfortunately, the way DEDA works is working, from my understanding, is
by calibrating itself on "known bad" documents, meaning that it doesn't
provide a generic solution.

A better solution would be to render the documents in black and white,
since the yellow marks will likely be rounded to white, but this will
make non-textual documents barely usable/readable. Like pdf-redact-tool
( https://github.com/firstlookmedia/pdf-redact-tools ) is doing.

Maybe I should add such option to mat2, behind a `--paranoid` flag?
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Security implications: moving code from Verification Extension to our website

[jvoisin]

> General security implications
> -
> 
> The question we are asking ourselves is: are there any predictable
> downsides to move the verification code from an extension to the website?

I don't see any significant downsides.
I think that having the verification happening on the website will
vastly improve the user experience and is a great idea.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Reproducible Builds sprint #2 report

[jvoisin]

This is really impressive, building a complete Tails image in a
reproducible fashion, congratulation!
___
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] Release schedule for Tails 2.6 [*urgent*]

[jvoisin]

I'll be available the 12-13 of September.

On 01/09/2016 19:35, anonym wrote:
> Hi,
> 
> I'll be the release manager for Tails 2.6, which is a major release
> scheduled on 2016-09-13. The list of tickets targeting Tails 2.6 can be
> found here:
> 
> https://labs.riseup.net/code/projects/tails/issues?query_id=215
> 
> So, yeah, this is a very late date to send the schedule given that the
> freeze will be tomorrow. I blame the distractions of summer and other
> things.
> 
> Here's the preliminary release schedule for Tails 2.6:
> 
> * 2016-09-02:
>- Feature Freeze: All feature branches targeting Tails 2.6 should
>  be merged into the `devel` branch by noon, CEST. I'm open to make
>  exceptions if you can be online and responsive during that
>  afternoon, but ask me first!
>- Build and upload Tails 2.6~rc1.
>- Start testing Tails 2.6~rc1 during late CEST if building the image
>  went smoothly.
> 
> * 2016-09-03:
>- Finish testing Tails 2.6~rc1 by the afternoon, CET.
>- Release Tails 2.6~rc1.
> 
> * 2016-09-12:
>   - All branches targeting Tails 2.6 *must* be merged into the `testing`
> branch by noon, CEST.
>   - The upcoming Tor Browser is hopefully out so we can import it.
>   - Build and upload Tails 2.6 ISO image and IUKs.
>   - Hopefully start testing Tails 2.6.
> 
> * 2016-09-13:
>   - Finish testing Tails 2.6 by the afternoon, CEST.
>   - Release Tails 2.6 during late CEST.
> 
> Testers, please let me know:
> 
> * if you are available on 2016-09-02, late CEST
> 
> * if you are available on 2016-09-03, morning to afternoon, CEST.
> 
> * if you are available on 2016-09-12, late CEST
> 
> * if you are available on 2016-09-13, morning to afternoon, CEST.
> 
> 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.
> 
___
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] Release schedule for Tails 2.5

[jvoisin]

Pong!
Please count me in :)

On 27/07/2016 17:47, intrigeri wrote:
> Hi,
> 
> intrigeri:
>> Usual testers, please let me know (privately) about your availability
>> for testing the ISO on:
> 
>>   - 2016-08-01: all day
>>   - 2016-08-02: until 3pm CEST, in case we did not complete the test
>> suite the day before
> 
> Ping!
> 
> So far I only have one single fellow tester, who will be helping for
> the first time, so additional helping hands would be warmly welcome :)
> 
> Cheers,
> 



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.

Re: [Tails-dev] Potential OpSec issue - Identifying Tails Tor vs "other" Tor

[jvoisin]

Hello Lee,
this is indeed very interesting, feel free to add information on the
relevant ticket about this, here : https://labs.riseup.net/code/issues/5975

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] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails

[jvoisin]

Hello,

I disagree with your analysis;
while the Apparmor profile (♥) will prevent tragic things like gpg key
stealing, please keep in mind that an attacker can access every Firefox
files, like cookies (stealing sessions), stored passwords, changing
preferences (remember http://net.ipcalf.com/ ?), executing code inside
the browser, …

This seems pretty serious to me, since people expect the web-browser to
be reasonably trustworthy.
___
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] Logjam: Tor Browser 4.5.2, and... Tails 1.4.x?

[jvoisin]

On 06/05/2015 06:06 PM, kytv wrote:
> On Thu,  4 Jun 2015 13:55:08 + (UTC)
> intrigeri  wrote:
> 
>> Has anyone here a strong opinion wrt. putting out an emergency Tails
>> 1.4.x release? What are you folks motivation and availability to make
>> it happen?
> 
> No strong opinion but, as always, I'd be willing and available for the
> test sessions.
> 
Neither do I, but I don't think that it's worth an emergency release.

The DH problem has been known for quite some time now, and I think that
we can wait for the next release to get it fixed.
___
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] Release schedule for Tails 1.4.1

[jvoisin]

On 05/15/2015 02:41 PM, sajolida wrote:
> intrigeri:
>> So, testers, please let me know if you are available on:
>> 
>> * 2015-06-29, late evening, CEST.
>> 
>> * 2015-06-30, morning to afternoon, CEST.
> 
Likely  available.

___
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] NoScript 2.6.9.15

[jvoisin]

Hello,

it seems that the latest Tails (1.3) ships with a vulnerable version of
NoScript, that allows to bypass the "Disable Scripts" settings. I know
that this is outside the threat model of Tails, since scripts are
enabled by default, but since some users are manually activating this
setting, I think that it's still relevant.

Anyway, I wrote a quick'n'dirty proof of concept for this vuln, if you
want to play a bit with it:
http://dustri.org/b/noscript-script-disabled-bypass-poc-for-tails-13.html

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] TAILS steganography proposal

[jvoisin]

Hello,
thank you for your interest in Tails.

> I think, there is a way to hide a TAILS into a FAT32/64 USB disk/memory.
In what kind of threat model?
> 
> FAT32 allows some reserved sectors before the first copy of filla
> allocation table.
> There is a way to hide some little assembler/machine code in a
> polimofric form to hide the boot loader.
> 
> Example:
> A "normal" USB partition with FAT32 and TAILS hide.
> 
> The MBR can hide a little sequence to load a disk sector with the real
> boot loader.
> The boot loader can shuffle some code via JMPS instrucions, NOP etc...
> to prevent a pattern recognition.
I'd like to take a look at your polymorphic bootloader implementation.
> 
> Into the FAT32 partitions:
> 1) Crate a file, then delete it with random data and rename some times.
> (The data will create only into de root dir section).
> This can be used to hide an encrypted partition and boot loader.
This will not hide the "encrypted partition" nor the bootloader, since
they have recognizable headers. Also, how can you prove that the file
will not be always written in the same place?
> 
> 2) TAILS and the persistence can sored from in reverse order form end to
> start of USB disk with encryption of boot loader.
Why in reverse order ?

> 3) Free space can be filled to rando data.
"Can", or "must" ?
> This is the similar situation used by truecrypt to hide the outer/inner
> volume.
No, it's not :)

> 
> This steganography cha be used as option to hide TAILS usb.
I don't get how it's hiding Tails, since it will boot Tails when you
plug the usb key in.

I think you may want to read a bit more about cryptography and
steganography/forensic[1][2][3] before suggesting implementations :)

1. http://www.forensicswiki.org/wiki/Main_Page
2. http://forensix.org/
3. https://github.com/volatilityfoundation
___
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] Tails-greeter UI redesign

[jvoisin]

On 06/23/2014 05:02 PM, Alan wrote:
> Hi!
> 
> On Sun, 22 Jun 2014 23:56:49 +0200
> jvoisin  wrote:
>> On 06/22/2014 08:37 PM, Alan wrote:
>>> I integrated the new greeter UI prototype into a working greeter.
>>> Not all options works yet, but anyone interested is welcome to try
>>> and give feedback. Here is the iso:
>>> http://nightly.tails.boum.org/build_Tails_ISO_feature-5464-revamp-ui/
>>
>> Impressive!
>>
> Thanks.
> 
>> Here is my feedback:
>>
>> - The greeter window is not vertically centerer.
> 
> How do you reproduce this? For me it is centered unless I resize the
> (virtual) screen, which doesn't trigger a move of the window.
> Can you reproduce that without changing the size of the screen?
It seems that my virtual machine settings where working against me: It's
indeed centered.
> If not,
> do you (and others) think that the greeter should take screen size
> changes into account?
> 
>> - I think that the text in the two "network configuration" buttons
>> should be centered.
> 
> Please note they are not in the current greeter. What do others think?
> 
>> - What about making possible to use the "Esc" key to go back in the
>> process?
> 
> Yes. I didn't work yet on keyboard navigation but plan to do so if it
> looks like we'll adopt this new greeter.
> 
>> - The "network configuration" documentation is not really browsable,
>> since it's not scrollable. I guess that the window is actually
>> super-long, instead of having a restricted size.
> 
> For me it is scrollable. Please provide a screenshot on not scrollable
> documentation.
Once againt, I'll blame my 9wrong) VM setup. Sorry.
> 
> 
>> - The "mac spoofing" screen doesn't make clear that the button is a
>> toggle-able one, and not the upper part of some exclusives ones. This
>> is likely related to the first point.
> 
> I suggest using a switch (similar to window camouflage) for this one.
> 
>> - "Widows camouflage" ;)
> 
> Please clarify.
I'm quite sure you want a _windows_ camouflage, and not a _widows_ one.
> 
>> - In "administrator password", the cursor is not automatically put in
>> the first field.
>>
> OK.
> 
>> Except those points, it's really nice, congratulations!
> 
> Thanks for the feedback.
> 
> 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.
> 

___
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] Tails-greeter UI redesign

[jvoisin]

On 06/22/2014 08:37 PM, Alan wrote:
> Hi,
> 
> I integrated the new greeter UI prototype into a working greeter. Not
> all options works yet, but anyone interested is welcome to try and give
> feedback. Here is the iso:
> http://nightly.tails.boum.org/build_Tails_ISO_feature-5464-revamp-ui/

Impressive!

Here is my feedback:

- The greeter window is not vertically centerer.
- I think that the text in the two "network configuration" buttons
should be centered.
- What about making possible to use the "Esc" key to go back in the process?
- The "network configuration" documentation is not really browsable,
since it's not scrollable. I guess that the window is actually
super-long, instead of having a restricted size.
- The "mac spoofing" screen doesn't make clear that the button is a
toggle-able one, and not the upper part of some exclusives ones. This is
likely related to the first point.
- "Widows camouflage" ;)
- In "administrator password", the cursor is not automatically put in
the first field.

Except those points, it's really nice, congratulations!
___
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] Setting curl's user-agent to the same as Tor Browser?

[jvoisin]

On 06/22/2014 12:14 PM, intrigeri wrote:
> Hi,
> 
> jvoisin wrote (22 Jun 2014 10:02:50 GMT) :
>> So, the only case where this could be useful is clear-text http, which
>> you shouldn't use over Tor anyway.
> 
> That's a very strong statement, that I won't discuss in the general
> case (cleartext HTTP vs. CA cartel, blah).
You can have https without a certificate signed by a cartel CA ;)
> 
> This is Tails. Everything goes through Tor by default, so what you're
> telling here is basically "don't use Tails for cleartext HTTP". So I'm
> curious: do you really think we should limit the supported Tails
> usecases that far?
I think that people that are techy enough to use curl in Tails are
knowing what they're doing when they use cleartext HTTP, and are
(hopefully) trying to avoid using it.

I don't think it worth reducing the (small) anonymity set for this usage.
> 
> 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] Setting curl's user-agent to the same as Tor Browser?

[jvoisin]

On 06/22/2014 11:32 AM, intrigeri wrote:
> Hi,
> 
> on the one hand, for an attacker that only looks at the user-agent
> header, telling curl to use the same value for it as the Tor Browser
> would make it part of a larger anonymity set.
> 
> On the other hand, the fingerprint of curl probably differs in many
> other ways. So, for an attacker that looks at it more closely, a curl
> HTTP client pretending to be Firefox is part of a very small
> anonymity set.
> 
> Against which one of these attackers do we want to optimize Tails for?
I don't think that tweaking curl is a good idea:

- Making it looking like Firefox for HTTPS won't be an easy task, since
there is a lot of black-magic involved here.

- Against an active attacker, I'm quite sure that she'll find an oracle
anyway.

- A passive attacker on HTTP can most of the time becoming an active one.

So, the only case where this could be useful is clear-text http, which
you shouldn't use over Tor anyway.
___
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] Risks of enabled/disabled TCP timestamps?

[jvoisin]

On 06/21/2014 04:00 PM, intrigeri wrote:
> Hi,
> 
>>> jvoisin started doing it --> now known as #6580.
> 
>> Julien made it clear on IRC that he won't be able to take care of this
>> in time for 0.23. Any taker?
> 
> Julien, do you think you can handle that in time for 1.2 (likely
> freezing in September or October), e.g. during the HackFest?
First, I (we?) need to fix the Vagrant building process ;)
> 
> 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] Goldfish the ephemeral password manager.

[jvoisin]

On 05/13/2014 03:58 PM, Rémi wrote:
> Going over your points:
> 
> - Yes, I should select some other slow hash function. Do you have a
> suggestion for a secure function available in python?
Currently, Python doesn't come with those kind of function.
> 
> - It is less random. That is why it is popped.
Then you should update the comment :)
> 
> - It really doesn't matter if some names have a tiny bit lower
> probability of getting selected. Much more useful would be to add more
> names.
> 
> - Now you're just trolling. The username suffix is indeed not random,
> but derived like the rest of the credentials.
Then it shouldn't be described as random :)
> 
> - Yes, in python you do not have control over memory like you have in C.
This is why those kind of tools should not be written in Python:
- You don't have control over memory
- You can't guarantee that your code can run in constant time.
> 
> Maybe the comments should have been formulated to look less scary? As I
> pointed out in the code, I indeed need another slow hash function. I'm
> on it.
Yes. Sorry for the harsh tone :|

The idea of deriving passwords from a master is not knew.
What about using something like HMAC for this ?
> 
> R.
> 
> 
> On 13/05/14 15:28, jvoisin wrote:
>> On 05/13/2014 03:17 PM, Rémi wrote:
>>> Good suggestion.
>>>
>>> I added the following text to the repository:
>>>
>>> Goldfish is unlocked using 1.000.000 rounds of sha512, which takes ~1.5
>>> seconds in python. The hash rounds are not meant to replace an actual
>>> strong password, so the password should be about as strong as your
>>> truecrypt password.
>>> A danger is that the root password would be guessed. It is also not
>>> obvious how to change a password. If a service provider has the
>>> username/password pair this does not give away anything about other
>>> credentials.
>>>
>>> Obfuscation.
>>> The usernames are designed to 'look real'. They are derived from common
>>> western names with an added suffix. The service passwords and username
>>> suffixes vary in length to further obfuscate that Goldfish is used.
>>> If someone really wants to they could figure out that a set of
>>> credentials was likely generated using Goldfish. This should not
>>> directly be obvious, certainly not by just looking at the username.
>>>
>>> R.
>>
>> A quick glance at your code tells me that I don't want to use this
>> software at all.
>>
>> - "My own implementation of a slow hash function." : Why are you
>> inventing your own crypto ?
>>
>> - "# Pop the first number because it is probably less random." :
>> Probably less random ?!
>>
>> - "# Yes, I know how this affects the name distribution." : Why
>> admitting that your distribution is flawed instead of fixing it ?!
>>
>> - """" Given some information it looks up the correct username and
>> appends some random data """" : This is wrong, the appended data is not
>> random at all.
>>
>> - Your lock/unlock system has no control over the memory of the process.
>>
>> - ...
>>
>> You may want to read some papers about cryptography before creating this
>> kind of softwares.
>>>
>>>
>>> On 13/05/14 12:09, intrigeri wrote:
>>>> Hi Rémi,
>>>>
>>>> Rémi wrote (12 May 2014 09:48:13 GMT) :
>>>>> I wrote an ephemeral password manager, for privacy and anonymity.
>>>>> The idea is that you use a root password to deterministically generate
>>>>> credentials, so no need to store the credentials.
>>>>
>>>> Thanks for this suggestion.
>>>>
>>>> Just curious: is there any threat model description, and security
>>>> analysis of the underlying password generation algorithm, to be
>>>> found somewhere?
>>>>
>>>> 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.
>>>
>>
>> ___
>> 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.
> 

___
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] Goldfish the ephemeral password manager.

[jvoisin]

On 05/13/2014 03:17 PM, Rémi wrote:
> Good suggestion.
> 
> I added the following text to the repository:
> 
> Goldfish is unlocked using 1.000.000 rounds of sha512, which takes ~1.5
> seconds in python. The hash rounds are not meant to replace an actual
> strong password, so the password should be about as strong as your
> truecrypt password.
> A danger is that the root password would be guessed. It is also not
> obvious how to change a password. If a service provider has the
> username/password pair this does not give away anything about other
> credentials.
> 
> Obfuscation.
> The usernames are designed to 'look real'. They are derived from common
> western names with an added suffix. The service passwords and username
> suffixes vary in length to further obfuscate that Goldfish is used.
> If someone really wants to they could figure out that a set of
> credentials was likely generated using Goldfish. This should not
> directly be obvious, certainly not by just looking at the username.
> 
> R.

A quick glance at your code tells me that I don't want to use this
software at all.

- "My own implementation of a slow hash function." : Why are you
inventing your own crypto ?

- "# Pop the first number because it is probably less random." :
Probably less random ?!

- "# Yes, I know how this affects the name distribution." : Why
admitting that your distribution is flawed instead of fixing it ?!

-  Given some information it looks up the correct username and
appends some random data  : This is wrong, the appended data is not
random at all.

- Your lock/unlock system has no control over the memory of the process.

- ...

You may want to read some papers about cryptography before creating this
kind of softwares.
> 
> 
> On 13/05/14 12:09, intrigeri wrote:
>> Hi Rémi,
>>
>> Rémi wrote (12 May 2014 09:48:13 GMT) :
>>> I wrote an ephemeral password manager, for privacy and anonymity.
>>> The idea is that you use a root password to deterministically generate
>>> credentials, so no need to store the credentials.
>>
>> Thanks for this suggestion.
>>
>> Just curious: is there any threat model description, and security
>> analysis of the underlying password generation algorithm, to be
>> found somewhere?
>>
>> 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.
> 

___
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] Risks of enabled/disabled TCP timestamps?

[jvoisin]

On 12/19/2013 10:56 PM, Jacob Appelbaum wrote:
> intrigeri:
>> Hi,
>>
>> it was brought to our attention (thanks Jacob!) that TCP timestamps
>> (net.ipv4.tcp_timestamps) are enabled in Tails, and this might be
>> a problem.
>>
> 
> No problem. Glad to help, if it is actually helpful!
> 
>> In a nutshell, we're said that the risks that go with the current
>> setting are:
>>
>>   1. The system uptime can be inferred from this information.
>>
> 
> That is correct.
> 
>>   2. The system clock can be tracked down to the millisecond.
> 
> That is also correct.
> 
>>
>> As far as I understand it, in the context of Tails, this can be done
>> by an attacker who monitors the network somewhere between the attacked
>> Tails system and the Tor entry nodes being used. Right?
> 
> Yes. And due to a Tor issue (TLS itself), the absolute clock on the
> system is also leaked in the handshake. Nick has been working on fixing
> this - both in the IETF working group on TLS, in patches for OpenSSL and
> in other places, I think. When Nick finishes killing the gmt time leak
> in TLS, we'll still have one left in Tails: the TCP timestamp itself... :(
This can be fixed upstream, in the kernel. The RFC says that the only
requirement is that the timestamps must be incremented, but says nothing
about the initial value. This will prevent the leak of the uptime.
> 
>>
>> I must admit that I did not look closely enough, so in what follows,
>> I'm assuming that this information is not forwarded by the three Tor
>> hops to the other side of the connection. Please correct me if
>> I'm wrong.
>>
>> Given such an attacker anyway knows the public IP used by the attacked
>> system, I don't really get why Jacob calls this a "Major privacy info
>> leak". May you please clarify what exact threat you have in mind?
>>
> 
> I think the inverse issue is important to consider: look for clocks that
> match an expected value to _find_ the public IP used by a user.
> 
>> Off the top of my head, I can think of:
>>
>>   a. Finding out how long a given Tails system has been running: if an
>>  attacker in this position got to watch the network (close enough
>>  to the attacked system) when it was bootstrapping Tor, then they
>>  can learn this too. I'm not overly concerned by this threat.
>>
> 
> There are currently two ways to do this that come to mind - one is by
> watching Tails traffic (first bootstrap, etc), the other is by looking
> at every TCP connection setup. This also ensures that non-Tails clients
> or different Tails clients behind a NAT will be distinguishable. It
> would be nice if a network of Tails machines behind a NAT looked like a
> single Tails machine other than the bootstrapping phase.
> 
>>   b. Distinguishing several Tails systems running behind NAT and using
>>  the same IP address: I would call this a minor issue, and the
>>  same reasoning as in (a) applies.
>>
> 
> If there are four Tails clients behind a NAT, an attacker can probably
> distinguish them by TCP timestamp alone.
> 
>> A very quick web search seems to indicate that disabling TCP
>> timestamps brings its own share of issues: first, disabling TCP
>> timestamps also disables the TCP protection against wrapped sequence
>> numbers mechanism; second, TCP timestamps seem to be a pretty useful
>> performance feature of TCP.
> 
> Do we need those features? I would prefer to not leak anything about the
> system at all. Currently, to recap: we leak the full clock and then
> millisecond offsets. This allows for unique tracking across the internet
> as well as unique host counting behind a NAT or similar networks that
> proxy traffic in various ways.

I agree with Jacob: I don't think Tails needs this features.
TCP timestamps are defined in [RFC
1323](http://www.ietf.org/rfc/rfc1323.txt), entitled "TCP Extensions for
High Performance".
Timestamps are used for:

- "Protection Against Wrapped Sequence Numbers", but in our case, I
don't think that a "normal" Tails user could ever trigger a wrap,
because as said in [RFC 1700](http://www.ietf.org/rfc/rfc1700.txt):
"The current recommended default time to live (TTL) for the Internet
Protocol (IP) [45,105] is 64.". A user would need to send roughly 2^32
packets in one minute.

- "Round-Trip Time Measurement", only useful when the user manage to
saturate the his connection. I don't think that the limiting factor for
transmission speed is the capacity of the user connection when using Tails.

I think timestamps can be safely disabled :)
> 
>> That's why I am reluctant to disable this feature without knowing what
>> exact problem we would solve. I'm all ears :)
> 
> We'll make it harder to count Tails users behind a NAT, we'll make it so
> that Tails users who sleep their machines won't be tracked across
> networks, we'll make Nick's removal of gmt time from TLS complete for
> the Tails picture, and we'll remove a general side channel.

> 
> All the best,
> Jacob
> ___
> tai

Re: [Tails-dev] Support for modern Vagrant

[jvoisin]

On 12/21/2013 04:32 PM, intrigeri wrote:
> Hi,
> 
> David Wolinsky wrote (20 Dec 2013 18:00:49 GMT) :
>> vagrant init tails
> [...]
>> You'll get a package.box that contains the updates
> 
> Thanks a lot. I've upgraded the basebox and it has now reached the web
> mirrors. Hashsum updated in stable, devel and experimental Git
> branches. And also in bugfix/6221-support-newer-vagrant, though in
> a slightly different way since this stuff has moved.
> 
> I'd like to merge bugfix/6221-support-newer-vagrant one of these days,
> and I think we're close. It integrates David's fix for the proxy issue
> (#6514) too, and various minor improvements of mine.
Great!
> 
> @Debian Wheezy users: please try what follows, too. Else, well, too
> bad, we'll only see once this is merged if we broke things for your
> usecase, and if so, then I'm sure you'll be interested :P
> 
> @David and/or Julien, could you please:
> 
> 1. Drop your existing basebox (rm -rf vagrant/.vagrant/).
> 
> 2. You'll want to remove it from VirtualBox and ~/.vagrant.d/ too.
> 
> 3. Checkout the branch that has the latest stuff:
> 
>git checkout bugfix/6221-support-newer-vagrant
> 
> 4. Start a build:
> 
>rake build
> 
>What's expected here is the download of the new basebox. It's easy
>to differentiate, as for whatever reason it's 480MB+ instead of the
>previous 280MB+. Please also check that you don't need to manually
>pass any proxy or noproxy setting. It should download it just fine.
It's downloading here. But it's weird/sad that the seize has doubled :/
> 
> 5. Review the current state of bugfix/6221-support-newer-vagrant.
> 
> ?
> 
> If all goes well, I'll merge this branch into stable and devel :)
> 
> Cheers,
> 
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Support for modern Vagrant

[jvoisin]

On 12/18/2013 05:22 PM, David Wolinsky wrote:
> What's your preferred method? Shall we just hack the keys into the git repo
> for now until the maintainer of the box has a chance to update it?
I think that you can also build a box using the "definitions" folder.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Support for modern Vagrant

[jvoisin]

On 12/17/2013 03:45 PM, David Wolinsky wrote:
> This is an aspect of Tails that's not quite clear to me. Apparently there
> is a proxy running inside a VM we have yet to download? :)
> 
> Use this before rake build
> export TAILS_BUILD_OPTIONS="noproxy"
> then rake build
Tails successfully built from scratch, in less than 2h30.
Your patch is working :)
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Support for modern Vagrant

[jvoisin]

On 12/17/2013 02:52 PM, David Wolinsky wrote:
> The vagrant version checker needs to be tweaked. I figured 1.3 <= would be
> the newer Vagrant style. It seems that perhaps we should reduce that to 1.2
> <= ... Looking at the git repo, it would seem that this was introduced
> during the 1.2.0 development cycle.
> 
> I'll update the patch, but you can also tweak:
> vagrant/lib/vagrant_version.rb and find the number 3 and change it to a 2
Tweaked. Way better:
jvoisin@kaa 15:23 ~/dev/tails rake build
Using HTTP proxy: http://squeeze.vagrantup.com:3142
Bringing machine 'default' up with 'virtualbox' provider...
[default] Box 'tails' was not found. Fetching box from specified URL for
the provider 'virtualbox'. Note that if the URL does not have
a box for this provider, you should interrupt Vagrant now and add
the box yourself. Otherwise Vagrant will attempt to download the
full box prior to discovering this error.
Downloading or copying the box...
rake aborted!(Rate: 0/s, Estimated time remaining: --:--:--)
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.

Could not resolve proxy:
squeeze.vagrantup.com/home/jvoisin/dev/tails/vagrant/lib/vagrant_verified_download.rb:40:in
`download!'
:10:in `synchronize'
Tasks: TOP => build => vm:up
(See full trace by running task with --trace)
zsh: exit 1 rake build
jvoisin@kaa 15:27 ~/dev/tails vagrant --version
Vagrant version 1.2.2
jvoisin@kaa 15:27 ~/dev/tails
> 
> Cheers,
> David
> 
> 
> 
> 
> On Tue, Dec 17, 2013 at 6:49 AM, jvoisin  wrote:
> 
>>
>>
>> On 12/17/2013 10:20 AM, David Wolinsky wrote:
>>> I use ArchLinux that has support for a more modern version of Vagrant.
>> I've
>>> spent a bit of time hacking the source code of Tails to support the newer
>>> version of Vagrant and I think I've maintained support for the older
>> build
>>> environment as well. I'd appreciate feedback (including someone running
>>> this patch against the typical build environment). Note: I have never
>> coded
>>> Ruby before, so any feedback is more than welcome :).
>> Wonderful, I was waiting for this since a long time :)
>>
>> Unfortunately:
>> jvoisin@kaa 11:46 ~/dev/tails rake build
>> Using HTTP proxy: http://squeeze.vagrantup.com:3142
>> rake aborted!
>> There was an error loading a Vagrantfile. The file being loaded
>> and the error message are shown below. This is usually caused by
>> a syntax error.
>>
>> Path: /home/jvoisin/dev/tails/vagrant/Vagrantfile
>> Message: uninitialized constant
>> Vagrant::Action::Box:10:in `synchronize'
>> /home/jvoisin/dev/tails/Rakefile:46:in `new'
>> /home/jvoisin/dev/tails/Rakefile:46:in `primary_vm'
>> /home/jvoisin/dev/tails/Rakefile:231:in `block (2 levels) in > (required)>'
>> Tasks: TOP => build => vm:up
>> (See full trace by running task with --trace)
>> zsh: exit 1 rake build
>> jvoisin@kaa 11:46 ~/dev/tails
>>
>> I'm using Ubuntu 13.10 x64, and was trying to build on `devel` branch.
>>
>>>
>>> Fyi, this should resolve this issue:
>>> https://labs.riseup.net/code/issues/6221
>>>
>>> Many thanks,
>>> David
>>>
>>>
>>>
>>> ___
>>> tails-dev mailing list
>>> tails-dev@boum.org
>>> https://mailman.boum.org/listinfo/tails-dev
>>>
>> ___
>> tails-dev mailing list
>> tails-dev@boum.org
>> https://mailman.boum.org/listinfo/tails-dev
>>
> 
> 
> 
> ___
> tails-dev mailing list
> tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> 
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Support for modern Vagrant

[jvoisin]

On 12/17/2013 10:20 AM, David Wolinsky wrote:
> I use ArchLinux that has support for a more modern version of Vagrant. I've
> spent a bit of time hacking the source code of Tails to support the newer
> version of Vagrant and I think I've maintained support for the older build
> environment as well. I'd appreciate feedback (including someone running
> this patch against the typical build environment). Note: I have never coded
> Ruby before, so any feedback is more than welcome :).
Wonderful, I was waiting for this since a long time :)

Unfortunately:
jvoisin@kaa 11:46 ~/dev/tails rake build
Using HTTP proxy: http://squeeze.vagrantup.com:3142
rake aborted!
There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: /home/jvoisin/dev/tails/vagrant/Vagrantfile
Message: uninitialized constant
Vagrant::Action::Box:10:in `synchronize'
/home/jvoisin/dev/tails/Rakefile:46:in `new'
/home/jvoisin/dev/tails/Rakefile:46:in `primary_vm'
/home/jvoisin/dev/tails/Rakefile:231:in `block (2 levels) in '
Tasks: TOP => build => vm:up
(See full trace by running task with --trace)
zsh: exit 1 rake build
jvoisin@kaa 11:46 ~/dev/tails

I'm using Ubuntu 13.10 x64, and was trying to build on `devel` branch.

> 
> Fyi, this should resolve this issue:
> https://labs.riseup.net/code/issues/6221
> 
> Many thanks,
> David
> 
> 
> 
> ___
> tails-dev mailing list
> tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> 
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] Please review'n'merge feature/default_task_rakefile

[jvoisin]

Hello,
The branch
http://git.tails.boum.org/jvoisin/tails/commit/?h=feature/default_task_rakefile&id=2a76ab567a5f37926d686fb3097c5bb145e10616
provides a default task for rake. Instead of typing "rake build", one
could simply type "rake" now :)

Have a nice day,



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

Re: [Tails-dev] Please review'n'merge feature/linux-3.10-2

[jvoisin]

On 13 August 2013 14:39,   wrote:
> On 12/08/13 15:31, intrigeri wrote:
>> Hi,
>>
>> all Tails builds are broken since Linux was updated in sid, so please
>> review'n'merge feature/linux-3.10-2.
>>
>> I've successfully built experimental with this branch applied, but
>> I have not tested the resulting ISO yet. I'll let the next steps to
>> anyone who wants to fix the builds.
>
> I faced the same issue yesterday and created a similar branch: I built
> an ISO with it and could test feature/tails-bugs successfully with 3.10-2.
>
> Merged and pushed.
>

Successful build here too.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Review of doc/twitter [was: Patches]

[jvoisin]

On 19/07/2013 16:56, sajol...@pimienta.org wrote:
> On 16/07/13 22:08, Alan wrote:
>> Hi,
>>
>> On Mon, 15 Jul 2013 19:53:11 +0200 jvoisin 
>> wrote:
>>> doc/twitter Add a link to the twitter account
>>>
>> sajolida, would you like to take care of this one, or should I?
> 
> Hi Julien, and thanks for the patch.
> 
> The places where we describe our communication channels on the website
> are divided into three sections (more or less):
> 
>   - support/talk, for user support
>   - contribute/talk, for development
>   - news, for news
> 
> I'd say Twitter is not a user support channel, but a news channel, so I
> think this should be mentioned on the news page instead.
Good idea.
> Furthermore, the current patch breaks the three-column layout on support/talk.
I didn't built the wiki with this patch, sorry :/
> 
> I also though we could add another tiny form to help subscribe to
> amnesia-news on the news page as well. Reuse the code from the download
> page.
> 
> I volunteer to do all that, but I didn't want to take over your patch
> without your knowledge and agreement.
I acknowledge and agree :)
> 
> 
> 
> 
> ___
> tails-dev mailing list
> tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> 




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

Re: [Tails-dev] Review of bugfix/wikileaks_irc [was: Patches]

[jvoisin]

> I think so. Next think to do would then be to report an "account
> nickname" to upstream whishlist.
I opened a ticket (https://developer.pidgin.im/ticket/15720)
> 
> Cheers
> ___
> tails-dev mailing list
> tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
> 




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

[Tails-dev] [review] feature/document_the_random_nick_preset

[jvoisin]

Hello,
please review feature/document_the_random_nick_preset in
http://git.tails.boum.org/jvoisin/tails/

Have a nice day,

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

Re: [Tails-dev] Review of bugfix/wikileaks_irc [was: Patches]

[jvoisin]

On 16 July 2013 21:17, Alan  wrote:
> Hi,
>
> Thanks again jvoisin for these patches.
>
> On Mon, 15 Jul 2013 19:53:11 +0200 jvoisin 
> wrote:
>> bugfix/wikileaks_irc : fix wikileaks irc server address
>>
> The patch works well. However, the account is now
> named @isax7s5yooqgelbr.onion in pidgin. I thus fail to see how
> the user is supposed to discover it's the wikileaks account and I
> didn't find how to fix this. Any idea?
I haven't found a way to do anything better. I think that we should
tell upstream about this concern.
>
> Cheers
> ___
> tails-dev mailing list
> tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev



--
-- Julien Voisin
| pgp key : C48815F2
| dustri.org
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] [review] bugfix/better_link_to_the_OTR_homepage

[jvoisin]

Hello,
Please review and merge the bugfix/better_link_to_the_OTR_homepage
branch on https://git.tails.boum.org/jvoisin/tails/

Have a nice day



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

[Tails-dev] Patches

[jvoisin]

Hello,
please review and merge the following branches available here
http://git.tails.boum.org/jvoisin/tails :

feature/better_task_manager : split the "replace truecrypt" bug

bugfix/wikileaks_irc : fix wikileaks irc server address
doc/twitter Add a link to the twitter account

feature/disable_Pidgin_accounts Closes
https://tails.boum.org/todo/disable_Pidgin_accounts/

feature/truecrypt_deprecation_wrapper   Add a deprecation popup wrapper
for TrueCrypt



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

Re: [Tails-dev] [MAT] mat-dev

[jvoisin]

> How about switching the list's default language to English,
>
Done

> and advertising the ML on the website?
>
Done

>
> Thank you :)

-- Julien Voisin
| pgp key : C48815F2


| dustri.org
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] [MAT] mat-dev

[jvoisin]

Hello,
in order to improve the openness of the MAT's development process,
there is now a dedicated mailing list: mat-...@boum.org

Feel free to subscribe if you're interested in metadata-smashing :)



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

Re: [Tails-dev] Attribution mistake in "The Metadata Anonymization Toolkit" paper (arXiv:1212.3648v1)

[jvoisin]

Hello,
I just updated the current version of the article: It'll be soon available
on arxiv.org.

Have a nice day,

-- 

-- Julien Voisin
| pgp key : C48815F2

| dustri.org
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] MAT 0.3.3 ?

[jvoisin]

Hello everyone,
I'm back, and I'm working on the MAT again !

Here is the current changelog since the 0.3.2
* Applied Pabs's patches, which were mostly (nices) bugfixes
* Tried clean and fix for good the setup.py
* Greatly improved the robustness and feedback of the testsuite
* Added the option to degrade the quality of produced PDF to reduce
their size
* Changing options is now effective for added files too

It would be nice if I could get some feeback before making a (possible)
new release.

Has someone requests or comments ?

Have a nice day,

-- jvoisin



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

[Tails-dev] [GSoC] Tails Server

[jvoisin]

Hello everyone.
I am sorry but I won't be able to pursue/achieve my GSoC[1]
for personal reasons that I prefer not disclose on a public mailing
list. I'll donate my current payment to the Tor project.

I am really sorry about this; I hope that I haven't took someone else's
place, and that this project will be achieved.

Take care,

1. https://tails.boum.org/todo/server_edition/

-- jvoisin




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

Re: [Tails-dev] [GSoC] Tails server

[jvoisin]

On 12 June 2012 14:54, intrigeri  wrote:

Hi,

jvoisin wrote (12 Jun 2012 11:29:42 GMT) :
>> I strongly suggest asking on the Debian Live mailing-list how others
>> are doing.
>>
> For now, there are no automatic tests : everything is done "by
> hand".

Well, it's sad there was no positive answer, but FWIW, this does not
really indicate that all Debian Live downstreams do things by hand:
e.g. grml folks did not answer, while they do run automated tests.

>> I also strongly suggest looking at grml's setup (that uses kantan).
>> Pointers and resources there:
>> https://tails.boum.org/todo/automated_builds_and_tests/#index8h2

Did you do so, and if you did, what was the outcome?

I studied every ways proposed by this pages (and other too) yesterday,
and I played with autotest today.

In my opinion, Kantan/grml is interesting, but despite the author's
efforts, still too specific.
OpenSuse has an intresting architecture, but it's not very usable.

Autotest is quite complete and very nice. You where right, the NIH syndrome
influenced me. But still, this project is huge. I'm not sure that
I want to/can spend time to setup it (altough a nice thing like this one
would be amazing for Tails). What do you think ?

(Ho, by the way, too sad that I don't know some ruby :
the RSpec and Autotest combo seems to be truely amazing !)

Another (simpler/quicker) solution would be to use lettuce
and QEMU.

> I was planing to use qemu, but it doesn't seems to be able to boot
from
> an usb stick.

KVM (qemu-kvm package) from testing/sid boots pretty well from a USB
2.0 device passed through the host to the guest. I'm unsure about
regular qemu. I'm using this in libvirt/virt-manager. I hope this
un-stucks you a bit :)

Right, thank you.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [GSoC] Tails server

[jvoisin]

> I strongly suggest asking on the Debian Live mailing-list how others
> are doing.
>
For now, there are no automatic tests : everything is done "by hand".

>
> I also strongly suggest looking at grml's setup (that uses kantan).
> Pointers and resources there:
> https://tails.boum.org/todo/automated_builds_and_tests/#index8h2
>
> > This is why I am currently playing around with lettuce[2], a nice
> > Python-powered BDD tool.
>
> Great. Please:
>  * share your scenarios early (allows better communication, forces
>you to start small and to stay practical :)
>
You can find the scenario for my first iteration here :
http://git.immerda.ch/?p=jvoisin/tails.git;a=summary
(more to follow)

>  * file a RFP bug as soon as you're sure you want to use it -- I want
>your test suite to integrate nicely with our infrastructure, and
>that means using software that is in Debian as much as possible.
>

For now, I'm being stuck :
I have scenarios, but I have no clear ideas about how they can be run,
because most of them are boot-related.
I was planing to use qemu, but it doesn't seems to be able to boot from
an usb stick.

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



-- 

-- Julien Voisin
| pgp key : C48815F2
<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9768FD3CC48815F2>


| dustri.org
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] [GSoC] Tails server

[jvoisin]

Hello,
the "community bonding period" is over for quite some time now,
but as I have previously said in my application,
I (unfortunately) won't be able to start my GSoC until the 8th of June.

So far, I managed to build Tails in a virtual machine,
in a tmpfs, using a proxy (to avoid spamming Debian's mirrors);
but also using vagrant[1]. It takes me only
a couple of minutes to build Tails on my machine, which
is a good news.

About the testing environment now:
It seems like liveCD testing is not something
that interest people very much. The autotesting repo[3]
of debian-live is a 404, and even if it wasn't,
the documentation is lacking.
The "mainstream way" for doing system-wide/vm/liveCD tests is
autotest[4], but it seems completely overkill to me.

This is why I am currently playing around with lettuce[2],
a nice Python-powered BDD tool.

Hopefully, my next status update will be more
consistent/interesting.

Have a nice day

1. https://tails.boum.org/contribute/build/#index1h1
2. http://lettuce.it/
3. http://git.debian.org/?p=debian-live/autotesting.git
4. http://autotest.github.com/

-- jvoisin



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

Re: [Tails-dev] New Vagrant based build system: please test and review!

[jvoisin]

>
>
> In case my hunch is right, I have a feeling this should work:
>
>TAILS_BUILD_OPTIONS="noproxy" rake vm:up
>
> Which you can follow by the usual `rake build`.
>
This solved my issue, but raised another one,
but build-related this time.
See attached logfile.

Cheers,

-- Julien Voisin
| pgp key : C48815F2


| dustri.org


log
Description: Binary data
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] New Vagrant based build system: please test and review!

[jvoisin]

I've got a "Connection timed out - connect(2)" error when I'm trying a
"rake build".
See attached logfile.
Any workaround ?

Cheers,

-- Julien Voisin
| pgp key : C48815F2

| dustri.org


log
Description: Binary data
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] GSoC community bonding period report?

[jvoisin]

On 05/12/2012 11:22 AM, intrigeri wrote:
> Hi Julien,
> 
> time flies, and the GSoC "community bonding period" is almost over.
> 
> Could you please send us a report (Cc'd to tor-dev) about your
> progress so far on the tasks you had picked for tackling during
> this period?
> 
> IIRC this included some research on testing environments that would be
> suitable for Tails server, and I'm especially curious about this part :)
> 
> Cheers,
I didn't even managed to get tails successfully build on my machine (and
it's driving me crazy).

I'm currently in internship, and under _heavy_ load (plus some IRL
concerns/crap). I didn't managed to get significant time for the GSoC
for now, and I'm sorry about this.

But, if everything goes fine, things will slow down after this week
(which ends Thursday here). For now, I only have a draft with some
ideas/reflections, but nothing astounding. As soon as I've got something
more consistent, I'll post it on the mailing list.

Cheers,

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

Re: [Tails-dev] [Electronic Frontier Foundation/The Tor Project] Update by jvoisin to proposal: Tails Server

[jvoisin]

I have just updated (again) my proposal according to intrigeri's feedback.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [GSoC] [tails-server] Ideas and challenges about asking the user's passphrase on boot

[jvoisin]

Hello,
Since anonym answered a large part of tails-server's
passphrase-input-related interrogation,
I'll go with some of the remaining ones:

Dealing with multiples tails-server on the same LAN:
This is not a problem, since the hostname is set during
the setup; it's up to the user to take care to not name multiples
servers with the same name.

What if the screen is broken but the keyboard is still available ?
We must find a way to tell to the user when he should
enter his passphrase, and the result of the operation
(good/bad passphrase).
A good solution could be to communicate thought the
keyboard's capslock LED.
For example:
- Continuous blink : please enter your passphrase
- Two quick-blink : good passphrase
- No more blink until the user can input his passphrase
again, in case of bad passphrase.
Since not every keyboards have a capslock LED,
we could use the system speaker instead;
but since this involve waking up the whole house
when the server is booted up, I prefer the LED solution.

As previously said, in order to authenticate the server,
the user must carry a private key (dropbear approach),
or a certificate fingerprint (webpage approach).
But the server must also have an unencrypted partition,
to carry public keys (dropbear), and certs (webpage).
Since the dropbear approach will require user authentication,
in order to provide a password-less shell access, the webpage one
does not : tails-server does not care about who you are,
the only thing that matter is that you have the right passphrase.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

[Tails-dev] [GSoC] [tails-server] Ideas and challenges about asking the user's passphrase on boot

[jvoisin]

Hello,
I have some questions/ideas about tail-server,
especially about the early boot process; and I'd like
to share them to get advices/options.

Directly after boot, Tails-server need to get the user's passphrase to
decipher the persistence USB stick. But since tails-server's target
are broken laptops, or old servers, we need an alternative way that
direct input with a keyboard with display on a screen (of course
keyboard input will still be available).

I think that a good way to get the passphrase would be to setup a
simple webpage, available on the LAN (for now, I only consider that
the machine has one interface : the LAN).
But this raise (at least) two majors concerns:

1. Disclose the server's presence on the network
In order to be able to type his passphrase on the webpage,
the user must know where is his tails-server on his network.
The first (and easiest) solution would be to hardcode
tails-server's ip during the setup of the persistence USB key;
but this solution require to know on which network will tails-server run.
This is why I think that the "best solution" would be to use avahi,
but this may require some digging into tails firewall.

2. Run a webpage
Setup a php/apache seems a little bit overkill; I think that some
python (or perl) magic
will be sufficient. Using https would of course be nice,
but since this implies using self-signed certs (right ?),
it might scare users. Additionally, since tails-server will only run
the "passphrase-webpage" on LAN, man-in-the-middle is unlikely to happen.

What do you think ?

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

Re: [Tails-dev] Hello Tails, a quick suggestion

[jvoisin]

On 12 February 2012 23:34, Gavin Engel  wrote:

> Hello all on the Tails dev team.  I have been using Tails .10.1, and I'm
> very pleased.
>
> I'd also like to mention a couple of packages you may want to include.
>  First is an eMule client, like aMule.  The second is Tribler.
>
Tor is not designed for massive files exchanges : no.

>
> Additionally, would you ever consider a version which had Adobe Flash
> installed?
>
Since abode flash is non-free, and a big blob full of security holes : no.

>
> thanks for your effort,
>
> -Gavin
>
> ___
> tails-dev mailing list
> tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
>
>


-- 

-- Julien Voisin
| pgp key : C48815F2


| dustri.org
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] MAT packaging

[jvoisin]

I'll work on the setup.py script today.
This is totally new for me.

On 20 July 2011 13:55, intrigeri  wrote:

> Hi Julien,
>
> in order to make it easier for me and others to test the MAT code,
> I'd like to package it for Debian (I mean publishing a Git branch with
> a debian/ directory in it).
>
> I don't see the usual distutils setup.py in your source tree.
> Do you intend to add it / could you please add it?
> This would make my task much easier, and would additionally document
> the program dependencies.
>
> Bye,
> --
>  intrigeri 
>  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
>  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
>  | Did you exchange a walk on part in the war
>  | for a lead role in the cage?
> ___
> tails-dev mailing list
> tails-dev@boum.org
> https://boum.org/mailman/listinfo/tails-dev
>



-- 

VOISIN Julien
| pgp key : C48815F2


| dustri.org
___
tails-dev mailing list
tails-dev@boum.org
https://boum.org/mailman/listinfo/tails-dev