[Tails-dev] [tails-dev] Fwd: [Tails - Feature #10972] Port Tails to arm platforms

[Tails]

Hi developers,

intrigeri asked:
> I don't understand: why are you rebuilding all packages, instead of
> just the Tails -specific ones (that are not in Debian)?
I tried to build only the packages from repository
http://deb.tails.boum.org/.

Am I on the wrong route (or repository)? Or could anybody provide a more
reduced/specific list of tails specific packages? I absolutely agree
with intrigeri and the tails way not to re-invent a prooven wheel ...

-- 
Best Regards!
n9iu7pk

PGP pool.sks-keyservers.net 0x4D12FFCB
7426 4598 B5AD 4D12 1699 C710 D602 E331 4D12 FFCB

 Forwarded Message 
Subject: [Tails - Feature #10972] Port Tails to arm platforms
Date: Wed, 10 Feb 2016 17:11:53 +
From: redm...@labs.riseup.net

Issue #10972 has been updated by intrigeri.


I don't understand: why are you rebuilding all packages, instead of just
the Tails -specific ones (that are not in Debian)?

Do we have Tor Browser for arm?


Feature #10972: Port Tails to arm platforms
https://labs.riseup.net/code/issues/10972#change-53852

* Author: N9iu7pk
* Status: New
* Priority: Normal
* Assignee: N9iu7pk
* Category: Hardware support
* Target version:
* QA Check:
* Feature Branch:
* Type of work: Code
* Blueprint:
* Easy: No
* Affected tool:

Forked from #6064

Step 1:

---Files
statPackages.txt (8.84 KB)
statPackages.txt (25.2 KB)
statPackages.txt (26 KB)


-- 
You have received this notification because you have either subscribed
to it, or are involved in it.
To change your notification preferences, please click here:
https://labs.riseup.net/code/my/account


___
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-dev] Fwd: [Tails - Feature #10972] Port Tails to arm platforms

[intrigeri]

Hi,

Tails wrote (11 Feb 2016 08:04:54 GMT) :
> intrigeri asked:
>> I don't understand: why are you rebuilding all packages, instead of
>> just the Tails -specific ones (that are not in Debian)?
> I tried to build only the packages from repository
> http://deb.tails.boum.org/.

OK, so far, so good :)

> Am I on the wrong route (or repository)? Or could anybody provide a more
> reduced/specific list of tails specific packages?

The attachments you posted on the ticket seem to indicate that you're
trying to build many more packages, including some that we haven't
beeng shipping in Tails for ages.

I think you should focus on packages that are in the "devel" suite of
our APT repository. OK?

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.

[Tails-dev] votre site web peut-il générer plus de business ?

[123PRESTA, comparateur de prestataires internet]

Votre site web peut-il générer plus de business ?

Exploitez-vous toutes les solutions à votre portée pour optimiser les ventes 
sur  votre site ?

Quelle stratégie utilisez-vous pour prospecter de nouveaux clients ?

262 marchands ont été interrogés.
47% des internautes déclarent ne pas avoir un site adapté aux mobiles, Et vous ?


Votre site web peut-il générer encore plus de business ?

"Evaluez-vous ! " : 
http://stats.ems2.123presta.com/l/54515465/v0WkV5EujnaHQrg5sNND22_2bgfAfvNDhP5r9wezganGYxfZfpseyaHTo11T9TRMkg/i.htm

Et identifiez en 3 minutes chrono vos axes d'amélioration pour : 

Générer du trafic
Étendre la visibilité
Améliorer l'ergonomie
 

PS : A la fin de l'évaluation, vous recevrez votre diagnostic détaillé 
personnalisé et vous pourrez juger de l'opportunité (ou pas) d'en parler avec 
nous.

Jennifer Galhaut
Société 123PRESTA
Pour vous désinscrire,  
http://stats.ems2.123presta.com/u/v0WkV5EujnaHQrg5sNND22_2bgfAfvNDhP5r9wezganGYxfZfpseyaHTo11T9TRMkg/i.htm
http://stats.ems2.123presta.com/u/v0WkV5EujnaHQrg5sNND22_2bgfAfvNDhP5r9wezganGYxfZfpseyaHTo11T9TRMkg/i.htm
___
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] Dynamically changing ISO URL in DAVE

[intrigeri]

Hi Giorgio, sajolida and others,

context: we're redesigning how we're handling the pool of HTTP mirrors
used to download Tails ISO images. If you want details, see the "Big
picture" section on https://tails.boum.org/blueprint/HTTP_mirror_pool/

We need to add a feature to DAVE to support our new design. I'd like
to check with Giorgio how possible/difficult it will be, in your
opinion. And I'd like sajolida to sanity-check the plan, in particular
checking compatibility with the IA. Anyone else in the audience is
much welcome to help, of course :)

I'll first explain what we need DAVE to do, and then I have a couple
of questions, mainly for Giorgio.


What we need DAVE to do
===

We need DAVE to retrieve a JSON configuration file from our website,
that describes our pool of HTTP mirrors. The exact content and format
of the config file is not clear yet, but let's assume for now that
it'll be a list of mirrors, with information attached to each of them:
a base URL, and a weight (0 = disabled, and the bigger the number, the
higher the chances to pick it).

And then, whenever DAVE wants to use the ISO URL it found in the ISO
description file (IDF in the new installation process specification,
i.e. what is called a "descriptor" in the DAVE code base), for example
to start a download, we need DAVE to pick one mirrors from this list
(honoring the weight but that's the trivial part I bet), and replace
the "http://dl.amnesia.boum.org/tails/; part of the URL found in the
IDF with the base URL corresponding to the mirror it picked.

I bet it'll be simpler to modify a little bit the IDF format, to
avoid hard-coding this part of the URL in the IDF, and write:

  path: /tails/stable/tails-i386-2.0/tails-i386-2.0.iso

instead of the current:

  url: http://dl.amnesia.boum.org/tails/stable/tails-i386-2.0/tails-i386-2.0.iso

... but this is a detail at this stage, and I think we can ensure
a smooth migration path without having to bump the IDF format to v2.


Questions
=

I assume that doing most of this (retrieving and loading the JSON
config file, picking an element from a list, doing simple string/URL
mangling) in DAVE is pretty basic stuff, that anyone moderately
experienced in JavaScript could do, without expertise that's specific
to Firefox add-on development. Correct?

What I'm more concerned about is the integration of the basic pieces
into the clever stuff that DAVE does. E.g. I see that it is
maintaining a state machine (status.phase), that is used to
retry/continue downloads, display progress, trigger verification etc.,
so for example we need to be careful when exactly we pick a mirror and
build the ISO URL (we have to do it before the download starts, but
shall we re-do it every time we retry?). This is just an example of
the class of issues I expect we will have to solve when implementing
what we need. How hard does it sound?

Any other problems you would expect us to face?

Will you be happy to review our DAVE patch, once we have something
that Works For Me™? Likely we will be working on it on April 6-8, and
ideally we would need the new feature to be on AMO by the end
of April.

Also, it would be awesome if we could ask you one or three questions
when we hit technical difficulties along the way, but if you can't do
it, it's fine, I guess we can ask for help to other add-on developers
we know :)

To end with, can you please give a quick look at our existing JS code,
and tell us if anything can't possibly work in a Firefox add-on such
as DAVE, or really, if anything raises a red light:

  https://git-tails.immerda.ch/mirror-pool-dispatcher/

This draft code implements something very similar to what I'm
describing here, except it's meant to be loaded and run from a web
page that has a download link, instead of from a Firefox extension
(which I think we will need for downloads that are not mediated by
DAVE).

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] Dynamically changing ISO URL in DAVE

[Giorgio Maone]

Hi intrigeri,

I can't see any particular problem (except for some less than idiomatic
EcmaScript style instances, e.g. new Array()) in your code.

The only caveat for integrating it into DAVE is that every time the
extension starts/resume a download or is installed/upgraded/reloaded,
downloader.js loops through all the download jobs already "known" to the
browser's built-in download manager and, if any of them matches the URL
in the IDF, picks the active one, or if none is currently active, the
most advanced one and makes it "current", resuming it if required.

Therefore, rather than just checking for equality with the URL provided
by the IDF, we should check whether these jobs match any of the URLs
produced by combining the mirror host names with the path provided by
the IDF, and force the mirror of the "choosen" download job if any can
be made current.

Beside that, I think the JSON should be fetched every time the UI page
is reloaded (of course obeying to server-side caching directives), just
like we currently do with the IDF.

> Will you be happy to review our DAVE patch, once we have something
> that Works For Me™? Likely we will be working on it on April 6-8, and
> ideally we would need the new feature to be on AMO by the end
> of April.
Of course I will.

> Also, it would be awesome if we could ask you one or three questions
> when we hit technical difficulties along the way,

No problem, just drop me an email and if asked I'm also going to join
the #tails-dev channel ASAP.

Cheers
-- G


On 11/02/2016 14:48, intrigeri wrote:
> Hi Giorgio, sajolida and others,
>
> context: we're redesigning how we're handling the pool of HTTP mirrors
> used to download Tails ISO images. If you want details, see the "Big
> picture" section on https://tails.boum.org/blueprint/HTTP_mirror_pool/
>
> We need to add a feature to DAVE to support our new design. I'd like
> to check with Giorgio how possible/difficult it will be, in your
> opinion. And I'd like sajolida to sanity-check the plan, in particular
> checking compatibility with the IA. Anyone else in the audience is
> much welcome to help, of course :)
>
> I'll first explain what we need DAVE to do, and then I have a couple
> of questions, mainly for Giorgio.
>
>
> What we need DAVE to do
> ===
>
> We need DAVE to retrieve a JSON configuration file from our website,
> that describes our pool of HTTP mirrors. The exact content and format
> of the config file is not clear yet, but let's assume for now that
> it'll be a list of mirrors, with information attached to each of them:
> a base URL, and a weight (0 = disabled, and the bigger the number, the
> higher the chances to pick it).
>
> And then, whenever DAVE wants to use the ISO URL it found in the ISO
> description file (IDF in the new installation process specification,
> i.e. what is called a "descriptor" in the DAVE code base), for example
> to start a download, we need DAVE to pick one mirrors from this list
> (honoring the weight but that's the trivial part I bet), and replace
> the "http://dl.amnesia.boum.org/tails/; part of the URL found in the
> IDF with the base URL corresponding to the mirror it picked.
>
> I bet it'll be simpler to modify a little bit the IDF format, to
> avoid hard-coding this part of the URL in the IDF, and write:
>
>   path: /tails/stable/tails-i386-2.0/tails-i386-2.0.iso
>
> instead of the current:
>
>   url: 
> http://dl.amnesia.boum.org/tails/stable/tails-i386-2.0/tails-i386-2.0.iso
>
> ... but this is a detail at this stage, and I think we can ensure
> a smooth migration path without having to bump the IDF format to v2.
>
>
> Questions
> =
>
> I assume that doing most of this (retrieving and loading the JSON
> config file, picking an element from a list, doing simple string/URL
> mangling) in DAVE is pretty basic stuff, that anyone moderately
> experienced in JavaScript could do, without expertise that's specific
> to Firefox add-on development. Correct?
>
> What I'm more concerned about is the integration of the basic pieces
> into the clever stuff that DAVE does. E.g. I see that it is
> maintaining a state machine (status.phase), that is used to
> retry/continue downloads, display progress, trigger verification etc.,
> so for example we need to be careful when exactly we pick a mirror and
> build the ISO URL (we have to do it before the download starts, but
> shall we re-do it every time we retry?). This is just an example of
> the class of issues I expect we will have to solve when implementing
> what we need. How hard does it sound?
>
> Any other problems you would expect us to face?
>
> Will you be happy to review our DAVE patch, once we have something
> that Works For Me™? Likely we will be working on it on April 6-8, and
> ideally we would need the new feature to be on AMO by the end
> of April.
>
> Also, it would be awesome if we could ask you one or three questions
> when we hit technical difficulties along the way, but if you can't do
> 

[Tails-dev] Hacking Team looking at Tails

[Spencer]

Hi,

> 
> intrigeri:
> https://labs.riseup.net/code/issues/11102
> 
>> 
>> Snip from the ticket:
>> "Tails USB sticks that have "hidden" 
>> files that indicate they have been 
>> plugged into Windows or OSX 
>> machines"
>> 

Are these the typical Thumbs.db & .DS_Store files, or are there others?

Where are they located, in some/all folders, at top of the package directory, 
or somewhere outside of Tails?

Wordlife,
Spencer


___
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] Fwd: Re: Reducing attack surface of kernel and tightening firewall/sysctls

[Jurre van Bergen]

Forwarding e-mail.


 Forwarded Message 
Subject:Re: Fwd: Re: [Tails-dev] Reducing attack surface of kernel and
tightening firewall/sysctls
Date:   Thu, 11 Feb 2016 12:28:35 +0100
From:   Cornelius Diekmann 
To: Jurre van Bergen 



Hi Jurre,

On 11.02.2016 01:24, Jurre van Bergen wrote:
> Hey,
> 
> About the firewall stuff and iptables/ferm we discussed at 32c3. There
> is some movement in this. Could you give us any feedback on what we did?

I looked at the resulting iptables config from the ferm.conf (most
recent version 32e89ef2d7ca2b564990b6758479c47c3713d1e9 in the mentioned
feature branch).

This config will go completely without RELATED. This is really cool.

Summary of the discussion: RELATED handles some ICMP error messages,
which might me necessary.

As discussed, if the kernel handles MTU errors
(net.ipv4.tcp_mtu_probing=1), then everything should be fine. But note
that this was rather intended as a work-around for buggy configurations
which block ICMP. ICMP MTU discovery is also an integral part of IPv6.

A conservative change to the tails config would be to keep an RELATED
rule but limit it to known good ICMP messages.

What I did not see in the discussion is the Destination Unreachable ICMP
error. If a host is unreachable, tails will eventually find out by a
timeout. But with an unreachable message, a user does not have to wait
for a timeout.

Best,
  Cornelius



___
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.