Re: [Tails-dev] Claws Mail bug getting (partially) solved

[intrigeri]

sajolida wrote (26 Jun 2015 17:40:51 GMT) :
 What would be the next steps for us to take advantage of it?

Someone should test the patches and confirm they do what we want.
If someone wants to do it, I could maybe prepare patched packages
somewhere (best case, for Wheezy; worst case, for Jessie or
testing/sid).

But personally, I'd rather see us focus our work on the migration
to Icedove.

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] Build failed in Jenkins: build_Tails_ISO_feature-jessie-32-bit-UEFI #2

[tails-sysadmins]

See 
https://jenkins.tails.boum.org/job/build_Tails_ISO_feature-jessie-32-bit-UEFI/2/

--
[...truncated 3837 lines...]
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
100 translated messages, 4 fuzzy translations, 6 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
100 translated messages, 4 fuzzy translations, 6 untranslated messages.
... done.
89 translated messages, 13 fuzzy translations, 8 untranslated messages.
... done.
106 translated messages, 2 fuzzy translations, 2 untranslated messages.
 done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
 done.
100 translated messages, 4 fuzzy translations, 6 untranslated messages.
... done.
89 translated messages, 13 fuzzy translations, 8 untranslated messages.
... done.
100 translated messages, 4 fuzzy translations, 6 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
100 translated messages, 4 fuzzy translations, 6 untranslated messages.
.. done.
0 translated messages, 110 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
... done.
107 translated messages, 1 fuzzy translation, 2 untranslated messages.
ar: .. done.
az: .. done.
ca: .. done.
cs: .. done.
cy: .. done.
da: .. done.
de: .. done.
el: .. done.
en_GB: .. done.
es: .. done.
fa: .. done.
fi: .. done.
fr: .. done.
fr_CA: .. done.
hr_HR: .. done.
hu: .. done.
id: .. done.
it: .. done.
ja: .. done.
km: .. done.
ko: .. done.
lv: .. done.
nb: .. done.
nl: .. done.
pl: .. done.
pt: .. done.
pt_BR: .. done.
ru: .. done.
sk: .. done.
sk_SK: .. done.
sl_SI: .. done.
sq: .. done.
sr: .. done.
sv: .. done.
tr: .. done.
uk: .. done.
zh: .. done.
zh_CN: .. done.
zh_TW: .. done.


 * Current translation support in tails 

ar: 100 translated messages, 4 fuzzy translations, 6 untranslated messages.
az: 100 translated messages, 4 fuzzy translations, 6 untranslated messages.
ca: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
cs: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
cy: 88 translated messages, 14 fuzzy translations, 8 untranslated messages.
da: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
de: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
el: 100 translated messages, 4 fuzzy translations, 6 untranslated messages.
en_GB: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
es: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
fa: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
fi: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
fr: 100 translated messages, 4 fuzzy translations, 6 untranslated messages.
fr_CA: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
hr_HR: 107 translated messages, 1 fuzzy translation, 2 untranslated messages.
hu: 107 

Re: [Tails-dev] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]

[intrigeri]

FYI, the only email dkg answered from this thread was when
I explicitly Cc'd him, so I bet he missed this one:

sajolida wrote (04 Mar 2015 19:44:22 GMT) :
 Daniel Kahn Gillmor:
 thanks for the explicit callout, this thread has been mostly off my
 radar, and i might not have noticed it otherwise.

 Thanks for joining in! As explained to intrigeri earlier on, I planned
 to send you an explicit request about that after a first validity check
 by him (which he did in public and in depth). So let's go!

 I feel the need to explain you more about the whole idea first. As
 explained earlier as well, our plan now is to combine:

 1. A web assistant to lead people through all the process from
landing on our website to having a Tails ready to boot
 2. An ISO verification extension, as discussed here, to do a first
validity check of the ISO image.

 The documentation about OpenPGP would still exist but be presented as
 additional check for careful users.

 The question I'm trying to solve here, is what kind of verification
 shall we do in the extension? Since the whole process is mainly
 targeted at newcomers and will be done through our website and in a web
 browser, my current position is to keep this very minimal. But it still
 makes sense to protect them from a rogue mirror or an interrupted
 download (that's quite noisy on our support channels).

 Later on, I think we should push more careful verification into the
 installer itself. For example, Tails Installer installed from Debian
 would be in a good position to do a reasonably good OpenPGP verification.

 The broad picture is better explained on this blueprint:

 https://tails.boum.org/blueprint/bootstrapping/verification.html

 * ... and then, we could also advise them *not* to import our signing
   key if they've already done it in the past, which gives them TOFU
   done right. For key rollover, this can be handled with a blog post
   and transition statement.
 
 I suspect for most new users, the validation process is complex and
 foreign enough that they don't understand which parts need to be done
 only once ever, and which parts need to be done at each download.

 In the introduction to this email I'm mostly talking about newcomers
 because we want to work on having full upgrades done from Tails itself
 quite soon as well (#7499). Then only people starting from scratch would
 go through this, so that's why I consider first time users as the target
 audience here.

 I don't have a good recommendation of how to improve this situation,
 because by definition they're using some O/S that we don't know about
 and can't control.
 
 Maybe there are ways that we could leverage Microsoft or Apple's
 built-in CAs somehow to provide certified ISOs on those platforms using
 the same identity, but certified by MS or Apple's pre-trusted roots?
 I don't really know what kinds of mechanisms exist for that, though.

 I agree with that. When we get a multiplatform installer and have more
 verification logic done directly in there, then we can have it do some
 basic OpenPGP and be happy with it. Since it will still be as weak as
 the original OS. That's also why I want to push full upgrades directly
 in Tails as well: you'd install Tails once and then, never have to trust
 your OS anymore to manipulate it.

 a bit of digging turns up some pretty silly UI for Apple's code signing
 (which isn't something we can use directly anyway, but probably should
 be better-protected than expecting users to notice a lock in the
 upper-right of the taskbar:
 
http://support.apple.com/en-us/HT202369

 I get an Access Denied on that from Tails :) That's promising!

 When the user clicks on the HTTP download button from the download
 page, we propose to install the extension.
 
 This seems like it's just moving the goalposts from verifying the ISO to
 verifying the extension; and given that extensions themselves can be
 tampered with by other extensions, it seems like it *could* raise
 issues.
 
 Though otoh we're expecting users to install gnupg on their systems to
 verify anyway, and doing that wrong (or fetching the wrong binaries)
 could result in even worse outcomes.

 Agreed.

 I guess this means that JavaScript will be needed on our download
 page, so that we can detect if the extension is already installed, as
 you note in the open questions below.
 
 I agree with Giorgio that it seems like this shouldn't require
 javascript if the extension is clever enough and the placement of the
 warning/recommendation is sensible but not overwhelming.

 So we all agree on that.

 Note that some browsers won't be able to install any extension we're
 likely to ship (e.g. IE or Safari), so direct download does still need
 to be supported.

 Yes. As part of the web assistant though, we won't help people with
 unsupported browsers. Firefox will be the first target, and then Chrome.
 I don't think that there is a really portable way of writing extensions.
 So that's another argument to 

Re: [Tails-dev] [review'n'merge:1.4.1] feature/9560-tor-0.2.6.9

[intrigeri]

intrigeri wrote (28 Jun 2015 16:28:03 GMT) :
 bertagaz wrote (28 Jun 2015 16:02:58 GMT) :
 I can do some reviews tomorrow morning, hopefully both, but happy to see
 if Alan manage to do some too. :)

 Excellent. Then, please assign one of those tickets to you.

Did anyone review this yet, and forgot to tell us about it?

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] ISO verification [Was: [RFC] UX for ISO verification + Tails Installer + full upgrades]

[intrigeri]

sajolida wrote (04 Mar 2015 17:43:01 GMT) :
 intrigeri:
 The Goals section doesn't address interrupted / paused / retried
 downloads. Is dealing with that a goal or a non-goal?
[...]
 Still, our goals make it clear that we want to be able to distinguish
 between corrupter and interrupted downloads (4th bullet point). What
 would you clarify?

It's been clarified already, apparently: In case of an interrupted
download, help the user resume it. This requires us to have our
mirrors stop sending HTTP ETag headers. See ticket #9022. :)

 Allow users who are downloading using BitTorrent to do the same
 level of verification as people downloading through their browser.
 
 IMO that could be demoted to a bonus goal, if time resources become
 scarce along the way. But perhaps we can postpone this discussion, and
 hopefully it won't be needed :)

 If that's a bonus, then how do those people verify their ISO image? If
 the answer is using OpenPGP, then I'm afraid I'll propose to stop
 advertising BitTorrent download in equally with HTTP download...

Fair enough.

 Note that all this works under the condition that the extension can
 verify file downloaded not through it. But in his answer Giorgio seems
 to mean that this is no problem. Anyway that point was on our radar
 already, see Open questions.

Great :)

 If we remove the download from the extension, and ask everybody to pick
 up the file from their file system, then supporting BitTorrent downloads
 comes for free.

Indeed, but then we can't do certificate pinning from the extension,
and have to rely on whatever certificate verification the browser does.

 tails-i386-x.x.x-VERIFIED.iso if the verification is successfully.
 
 I find it a bit surprising that a verified ISO hasn't its canonical
 name in the end, given we call it differently otherwise. But well, you
 have read more about UX than I did. Perhaps the reasons behind this
 design decision could be explained on the blueprint so that I, or
 someone else, doesn't propose to change that again in a year ;)

 This is somehow related to #7494 (I updated its description to include
 that proposal). My intuition is that if the unverified ISO makes it
 explicit, then the verified ISO have to make it explicit too.

 It's like traffic lights. They could theoretically be simplified into
 only a red light (with no light meaning go. But the green light is
 here to make it clear that the system is working and it's safe to go.

OK, thanks: I now understand your point better.

I'm not fully convinced that this analogy works that well here,
though: in the case at hand, we're not trying to distinguish two
roughly equivalents binary states, but what we want to distinguish is
the thing and something that might, or might not, be the real
thing. In this case, calling the thing with its own name (that is,
tails-i386-$version.iso) *feels* clearer to me than giving it any
different name (even if it's -VERIFIED). And that matches users'
past experience e.g. with temporary files browsers and P2P software
often create while downloading a file: I've seen some append .part,
and then remove it so that the downloaded file ends up having the
expected name in the end.

But it looks very much like a matter of taste and intuition, so
I won't insist :)

 * If some network attacker modifies the ISO on the fly: retry from
   another ISP, or using Tor, something like that could work? =
   I guess that's the reason why you want to handle it differently than
   an incomplete download, but the blueprint doesn't make it clear.

 See f38d56b (that's a bit minimal I admit).

Thanks. (Food for thought: this seems to assume that an ISO
voluntarily corrupted by an attacker will generally not be smaller
than the genuine one. Not sure how good an assumption this is.)

 We are considering here an attacker who can:
 
   (A) Provide a malicious ISO image to the user for example by
   operating a rogue Tails mirror or BitTorrent tracker.
 
 I don't get the BitTorrent tracker part. I'm no BitTorrent expert,
 but if the .torrent is genuine, then the tracker should not be able to
 have seeds provide malicious data without the client noticing, right?
 [As said elsewhere, one should check if popular BitTorrent clients
 actually do check the hashes found in the Torrent file, though.]

 Then that could be a rogue .torrent file.

OK, so I'm glad the referrence to or BitTorrent tracker was removed,
since it indeed didn't make sense.

 But maybe you think that
 people who don't download their torrent file from our website are not
 going through the assistant anyway and won't do the verification through
 the extension either and are thus hopeless (unless they know OpenPGP).
 That might very well be the case. If so, then I understand better your
 idea of putting BitTorrent as bonus goal. Is that why?

No, I was merely pointing out that I didn't understand how
a BitTorrent tracker could provide a malicious ISO image.

 (B) Do a man-in-the-middle attack by providing a 

[Tails-dev] Build failed in Jenkins: build_Tails_ISO_feature-jessie-32-bit-UEFI #1

[tails-sysadmins]

See 
https://jenkins.tails.boum.org/job/build_Tails_ISO_feature-jessie-32-bit-UEFI/1/

--
Started by user anonymous
Building remotely on isobuilder2 in workspace 
https://jenkins.tails.boum.org/job/build_Tails_ISO_feature-jessie-32-bit-UEFI/ws/
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository gitolite@puppet-git.lizard:tails
  git init 
  https://jenkins.tails.boum.org/job/build_Tails_ISO_feature-jessie-32-bit-UEFI/ws/
   # timeout=10
Fetching upstream changes from gitolite@puppet-git.lizard:tails
  git --version # timeout=10
  git -c core.askpass=true fetch --tags --progress 
  gitolite@puppet-git.lizard:tails +refs/heads/*:refs/remotes/origin/*
  git config remote.origin.url gitolite@puppet-git.lizard:tails # timeout=10
  git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
  timeout=10
  git config remote.origin.url gitolite@puppet-git.lizard:tails # timeout=10
Fetching upstream changes from gitolite@puppet-git.lizard:tails
  git -c core.askpass=true fetch --tags --progress 
  gitolite@puppet-git.lizard:tails +refs/heads/*:refs/remotes/origin/*
  git rev-parse refs/remotes/origin/feature/jessie+32-bit-UEFI^{commit} # 
  timeout=10
  git rev-parse refs/remotes/origin/origin/feature/jessie+32-bit-UEFI^{commit} 
  # timeout=10
  git rev-parse origin/feature/jessie+32-bit-UEFI^{commit} # timeout=10
ERROR: Couldn't find any revision to build. Verify the repository and branch 
configuration for this job.

___
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:master] doc/no-more-review-n-merge-email [Was: Getting rid of review'n'merge email on this list]

[intrigeri]

Hi,

I've implemented the solution that seemed to be consensual
in the doc/no-more-review-n-merge-email branch. Please review'n'merge :)

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] RFC: persistent Tor state

[intrigeri]

Hi,

anonym wrote (16 Jun 2015 13:11:47 GMT) :
 On 06/15/2015 07:09 PM, Alan wrote:
 The 1st drawback: If the attacker records that someone has been
 using a given Entry Guard at a given location in the past, and then
 someone uses the same Entry Guard at the same location, then there are
 chances that it's the same person who is back to that location. looks
 quite concerning to me, as I believe this kind of data can easily be
 recorded automatically and used afterwards: 

[...]

 - what about prompting the user, when they reconnect to an old location
   after having connected to other, if they want to reuse the data or
   not?

 Well, such prompts are not good UX, and since this will affect all users
 of persistence whenever they reconnect at an old place it will happen a
 lot and they will be trained to pick one of the options without thinking.

 We also toyed a bit about having an option in the greeter, which would
 merge this option with MAC spoofing (since both are about geotracking),
 but I'm not sure that's better. Also, we have good reasons for spoofing
 the MAC by default, and good reasons for using stable guards by default,
 and these are conflicting for such a merged option. And having two
 options about something that will have a similar high-level explanation
 seems confusing.

 So, perhaps a pop-up is the best we can do if we want to delegate the
 decision to our users?

In practice, I doubt we manage to express this question in a way that
empowers most users to make a reasonable security decision.

I won't repeat the discussion and proposed mitigations that are
already on the blueprint about this topic, but I'm still very much
opposed to querying the user, and instead they should think about it
and make the decision *once*, when deciding whether they want
a persistent Tor state or not, instead of every time they come back to
some place where they have been in the past.

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] RFC: persistent Tor state

[intrigeri]

Hi,

anonym wrote (16 Jun 2015 13:11:44 GMT) :
 On 05/21/2015 05:38 PM, sajolida wrote:
 So would it then make sense to hash:
 
 hash(Tails device secret, N bits of gateway MAC, SSID)
 
 Of course, I'm simplifying here to Wi-Fi only as there is no notion of
 SSID with wired connections. But you know, wire is deprecated :)

 If there's no SSID, like on wired connections, we just set a default
 SSID of the empty string or whatever.

I like this idea. sajolida, are you up to integrating it into the
blueprint, or should anonym or I do it?

 On another topic, I found the shortcut to the 6 number a bit too quick.
 How do you go from between 500 and 2000 Tor relays and N=6 → 64
 possible Tor states?

 We do not really have any solid reasoning here. We need to make a
 worst-case analysis for how N affects the probability of picking
 compromised guards in a Tor network where C out of G guards are
 compromised (and in the control of our local attacker).

Yep, the goal is to pick the smallest possible N that still leaves
room for enough persistent Tor states.

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] How to replace the green onion [was: What do we miss to replace Vidalia]

[intrigeri]

Alan wrote (18 Mar 2015 21:20:02 GMT) :
 On Sun, 15 Mar 2015 23:29:55 +0100
 intrigeri intrig...@boum.org wrote:
 sajolida wrote (15 Mar 2015 19:46:47 GMT) :
  I'm personally undecided wrt. which one of these two is the best.
 
  Neither am I :)
 
 Then I'm all for those who do the work decide — in this case, that
 would be Alan.
 
 Then there will be a menu I think.

May you (or someone else) please encode this decision (and sum up the
reasoning behind it) in a ticket, so that we don't have to retrieve it
from a lengthy thread in the future?

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] known issues - another laptop model

[intrigeri]

Hi,

was there any progress on this?

intrigeri wrote (23 Apr 2015 22:29:22 GMT) :
 emmapeel wrote (22 Apr 2015 11:46:11 GMT) :
 Here a patch for the known issues page,

 Thanks a lot!

 adding MacBook Air 6,1 to the list of laptops with Broadcom drivers

 Well, that's not a list of laptops with Broadcom drivers: it's rather
 a list of laptops with the BCM43224 Wi-Fi adapter.

 According to https://en.wikipedia.org/wiki/MacBook_Air#Specifications,
 the MacBook Air 6,1 (and 6,2, 7,1 and 7,2 by the way -- perhaps we
 could save some time for us and users if we add them in the same go)
 rather has something based on BCM4360.

 I'll trust the result of your investigations, and I'm not very
 surprised that said Wi-Fi adapter shares some issues with BCM43224.

 Still, my current understanding is that this patch, if applied as-is,
 would introduce incorrect information on the known issues page, that
 may confuse users looking for their laptop or network adapter name
 in there.

 = I think that this paragraph needs to be either split per-device, or
 adjusted somehow to cover all devices it's about. Good luck :)

 Hint: that the bcm43224 HTML anchor shall not be broken in the
 process, since it's been referred to in a blog post of ours in
 the past.

 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] Release versioning

[intrigeri]

Hi,

sajolida wrote (29 Jun 2015 09:52:29 GMT) :
   This would mean
   - Updating the calendar
   - Tweaking Redmine

Done. Note that Tails 1.9 or 1.10 will likely be called 2.0 actually,
since we'll be migrating to Jessie (and this will also change version
numbers for 1.11 and later). But we don't know exactly when yet, so
well, we'll see. Perhaps referring to releases *by date* is better for
things that are 6+ months in the future.

 + update release process doc,

Done.

 and possibly some internal documents.

Done what I could easily find, but no doubt I've missed some.

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] GNOME Keysign 0.2 released

[intrigeri]

Tobias Mueller wrote (27 Jan 2015 13:25:40 GMT) :
 On Sat, Jan 10, 2015 at 10:08:39AM +0100, intrigeri wrote:
 Frankly, I think I'll wait for this OPW round to be over, and then I'm
 happy to give GNOME Keysign a try and provide feedback.
 cool.

FTR, next steps are tracked on
https://labs.riseup.net/code/issues/8400 -- any taker?

   * is working Avahi required to use GNOME Keysign?
 Currently, yes.
 This is to provide an out-of-the-box experience.
 You fire up the program and you can connect those without having
 to know the IP address of the other party.
 Technically, it's possible to do without Avahi.
 But then the user interface gets more complicated.

Hmm, OK. I don't think we let Avahi go through in Tails,
let alone mdns if it's needed as well.

   * what exact networking connection needs to be allowed for GNOME
 Keysign to work, especially on the LAN? any ports than need to be
 open in the firewall for incoming and/or outgoing traffic?
 For now, the key is shared via HTTP on a dedicated port.

OK, so if the port is fixed that's something we might consider opening
(possibly dynamically, on-demand).

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] Virtual appliance for the browser

[intrigeri]

Hi,

Alex Coventry wrote (22 Feb 2015 21:52:56 GMT) :
 Sorry it's taken a while to respond,

[What should I say...]

 Is there any problem with presenting the persisted config files via vbox
 shared folders?

I've no idea = one should test it.

 Also, interacting with a browser that's itself running in a window
 manager in a VM may be weird, so this needs serious integration work.
 Here too, see what Qubes OS does.

 Virtualbox's seamless mode seems pretty good for this.  If you run it
 with a window manager which doesn't provide taskbars, each guest window
 simply shows up on your host desktop.

Cool.
___
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] Virtual appliance for the browser

[intrigeri]

Hi,

Alex Coventry wrote (06 Mar 2015 17:25:50 GMT) :
 ** Guest overview

- Virtualbox VM running barebones debian with the same window manager
  as tails.  Constructed using debian live.
- Does not share clipboard through vbox at all.
- Shares the ~/.tor-browser, ~/.mozilla, ~/{,Persistence/}Tor Browser
  directories with the host as Virtualbox shared folders.
- Does not share the tor browser binary/libraries with the host, but
  they can be essentially the same as in tails, using the host tor
  daemon via ports 9050/9051.
- When the guest wm is ready to start a browser, drops a file in a
  shared folder to indicate this to the host.
- A guest daemon watches the guest [[
 http://www.pygtk.org/pygtk2reference/class-gtkclipboard.html][clipboard]]
 for changes and saves
  them to a file in a shared folder.

Sounds plausible. Has it been tested?

 ** Host overview

- Guest is run on a host-only network. Ports 9050/9051 are forwarded
  over iptables or something similar.
- Guest boots from a virtual optical disk so it's the same code
  starting every time.
- Guest VM is displayed using virtualbox's seamless mode, so that its
  browser windows appear in standalone windows on the host desktop.
- Host checks for hardware virtualization support by running sudo
  modprobe kvm_{intel,amd}, and checking dmesg output for kvm: no
  hardware support or kvm: disabled by bios.  If it finds either
  of these messages, warns user on browser start that it's
  downgrading to unvirtualized browser, and everything runs the way
  it does now.
- Host also checks whether it's running under virtualization with
  /usr/sbin/dmidecode -s system-product-name.  If it is, check
  whether any CPU flags in /proc/cpuinfo suggest support for nested
  virtualization, and if not, same warning.
- Otherwise, all browser defaults are set to a script which
  1) starts the guest VM if it's not already up, removing any stale
 indication that the guest is ready to start a browser,
  2) waits for indication from the guest that it's ready to start a
 browser, and starts one with the supplied CL arguments, using
 VboxManage guestcontrol
- Host has up and down buttons in the task bar which transfer the
  contents of the clipboard from guest to host and vice versa.

OK, sounds plausible as well. I'd love to see a proof-of-concept.

  Could the guest be tails?

  If you disabled the firewall and greeter, you could possibly use the
  tails image itself for the guest, which would save a little space.
  I think that has potential for confusion, though.  Probably best to
  make it the minimal image needed to get the job done.

This has been looked into by David Wolinsky already, IIRC.
You'll find the discussion in the ML archive.

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] GUI for encrypted volumes from LUKS/TrueCrypt container files

[u]

Hi,

 Hi, random lurker speaking up here with a question.
 
 I don't mean to distract from the topic, but regarding
 interoperability, what about FreeOTFE? It's source was available,
 and someone else has picked it up and forked it on GitHub as
 DoxBox: https://github.com/t-d-k/doxbox

Looks like this would be Windows only, so I can't see the relevance of
this tool for Tails.

 Is there any consideration underway to support this solution and
 its development? I know it wouldn't solve all of the issues with
 the absence of TrueCrypt, but it certainly would broaden the
 relevance of LUKS.

Cheers
u.


 
 gl
 
 
 
 On Thu, 02 Apr 2015 19:39:15 + sajolida
 sajol...@pimienta.org wrote:
 intrigeri:
  sajolida wrote (20 Mar 2015 12:34:35 GMT) :
  I think that our long-term objective is to have people move out
 of
  using TrueCrypt technologies in general (be it the software,
 the
  volumes, or the containers).
 
  Now you make me curious: why do you think we should get rid of
 the
  TrueCrypt on-disk format?
 
 I was saying this because I thought it was our vision when getting
 rid
 of TrueCrypt, but I have no strong argument against TrueCrypt on-
 disk
 format as such myself. My understanding was basically that we had
 no
 good reasons for supporting it as we had LUKS already.
 
  The way I see it, we're stuck between a rock and a hard place:
 
  Ideally we'd like to be able to fully replace TrueCrypt volumes
 (I'm
  assuming that I'm missing information that makes you think we
 should)
  with something else, but nothing equivalent exists yet. Sadly,
 I'm not
  aware of any plan (let alone serious effort) towards making this
  a reality, when one takes into account the need for:
 
   - inter-operability (which I'm tempted to disregard as a
 dangerous
 way to share data with an untrusted OS, but then if we don't
 support TrueCrypt volumes at all, perhaps users who
 won't/can't
 fully give up proprietary software will just be forced to
 either
 store and share the very same data in cleartext, or to use
 something less safe than Tails)
 
   - hidden volumes (which may be a false promise in TrueCrypt,
 but
 still people want that and AFAIK there's nothing even
 approaching
 it, be it in terms of peer-review of existing production-
 quality
 implementations)
 
 Thanks to Jasper we can add containers to that list.
 
 All those are usability and interoperability issues that have real
 but
 non-obvious security implications (not in terms of crypto but in
 terms
 of user scenario). I'm not really convinced by containers and
 hidden
 volumes as such in the context of a pure Tails setup, so we're
 left with
 interoperability as the most interesting feature.
 
  With this in mind, supporting the TrueCrypt on-disk format (even
  minimally) still makes sense for the time being IMO. I doubt
 we'll
  actively patch out the corresponding code from cryptsetup, so I
 take
  for granted that we'll keep this support in Tails as long as
  cryptsetup has it.
 
 Agreed.
 
  We had good reasons to get rid of the TrueCrypt software itself,
 but
  no existing GUI for TrueCrypt volumes is satisfying right now,
 in the
  context of Tails.
 
  Now, of course a CLI-only interface isn't encouraging for Tails
 users
  to go on using TrueCrypt volumes. This has both advantages (as
  a long-term strategy, hopefully it'll encourage people to either
 fully
  replace TrueCrypt volumes with a better design), and drawbacks
 (until
  our fancy long-term plans are made real by $someone $some_day,
 Tails
  users have the choice between using something we claim we don't
 really
  support, with poor usability, and doing something even worse).
 
  So, the question I'm coming to is: assuming there *was*
 satisfying GUI
  support for the TrueCrypt on-disk format (in GNOME Disks,
 Nautilus,
  etc.), would we want to explicitly support that, or still depict
 it as
  a suboptimal feature, and call it unsupported because we think
 it
  should ideally be replaced by something else on the long term?
 
 We have a long tradition of advertising only one tool for one job.
 So
 what would we advertise TrueCrypt for? Exchanging encrypted data
 with
 other operating systems? With big fat warnings? Maybe...
 
  In other words: how hard should we push for adding support for
 the
  TrueCrypt on-disk format in udisks and friends? (Until 15
 minutes ago,
  I was convinced that it was the way to go, and prepared to go
 ping the
  right folks about it, but now you've planted some non-negligible
  amount of doubt in my mind, so I'm a bit lost in terms of
 strategy.)
 
 Me too :)
 
 --
 sajolida
___
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] Automated tests specification

[intrigeri]

Hi,

bertagaz wrote (25 Jun 2015 09:41:23 GMT) :
 I've prepared a blueprint to start this discussion and take notes of the
 decisions:
 https://tails.boum.org/blueprint/automated_builds_and_tests/automated_tests_specs/

Great work! I've pushed a few minor changes, and a more important one
(21870e1), on top.

 ## When to test the builds

 for base branches, we could envisage to run the full test suite on
 every automatically built ISO (every git push and daily builds) if
 we think that is relevant.

This would be great. A possible optimization would be to do it
(instead of all base branches, all the time) for:

 * the stable branch, so that we're always ready to put out an
   emergency release;
 * the branch that next scheduled release will be based on (can be
   either stable, or testing, or devel, depending on when in the
   release cycle we are).

 for feature branches, we could run the full test suite only on the
 daily builds, and either only the automated tests related to the
 branch on every git push, and/or a subset of the whole test suite.

I'm not sure what's the benefit of testing a topic branch every day if
no new work has been pushed to it. In the general case, as a developer
I'd rather see them tested on Git push only, with some rate limiting
per-day if needed. See below wrt. one specific case.

 We can also consider testing only the feature branch that are marked
 as ReadyforQA as a beginning, even if that doesn't cover Scenario
 2 (developers).

Absolutely, I think that would be the top-priority thing to do for
topic branches: let's ensure we don't merge crap.

 We can also maybe find more ways to split the automated test suite
 in faster subsets of feature depending on the context, define
 priorities for built ISO and/or tests.

This feels ambituous and potentially quite complex. I say let's design
something simple and then re-adjust.

 ## How to run the tests

 The automated test suite MUST have access to the artifacts of
 a given automated build corresponding to a given commit, as well as
 to the ISOs of the previous Tails releases.

The ISO of the one last release should be enough, no?

It also needs to know what commit that ISO was built from, in order to
run the test suite from the same commit. Surely we can dynamically get
this information by inspecting the ISO (maybe even in the iso9660
metadata), if passing through the info via Jenkins is too painful.
Maybe that's worth a research ticket?

 The automated test suite MUST be run in a clean environment.

I'm not sure what exactly you had in mind here, but in my experience,
the test suite is now quite resistant to being run multiple times in
a row, so don't bother too much about this -- just using
a fresh --tmpdir should be enough in general. If we really need to
e.g. reboot the isotesterN VMs between test suite runs, I've looked
into it a few weeks ago and dumped results of my research somewhere
(likely in some blueprint). It seemed to be doable, but adds quite
some complexity that I'd happily skip.

 The automated test suite MUST be able to run features in parallel
 for a single automated build ISO. This way, if more than one
 isotester are idle, it can use several of them to test an
 ISO faster.

Wow! Not sure if/how this can work out, or actually optimize things
much, with the upcoming new VM snapshots handling.

Anyway: I doubt we'll have the situation when we have idle
isotesterN's -- we're rather trying to limit the workload to something
they can handle -- so perhaps it's not worth putting too much time
into this? My current feeling is that this is a MAY at best, but I can
totally be missing something.

 The automated suite SHOULD be able when there are more than one ISO
 queued for testing to fairly distribute the parallelizing of
 their features.

 The automated test suite MUST not allocate all the isotesters for
 one ISO when others are waiting to be tested.

These seems to be related to the parallelizing of one test suite run
on multiple VMs, so I'll skip them until we've discussed that
topic more.

 The automated test suite MUST be able to accept a treshold of
 failures for some features before sending notifications. This can
 help if a scenario fails because of a network congestion, but other
 use cases will probably raise.

The current running theory is that the test suite *itself* (as opposed
to the way it's being run e.g. by Jenkins) should handle this itself,
see e.g. https://labs.riseup.net/code/issues/9515. I prefer it a lot
more to having Jenkins ignore failures, as it also benefits people who
run the test suite outside of Jenkins. But realistically, surely we'll
anyway have transient failures, and I'm not sure what's the best way
to deal with it. I doubt it parameterizes a lot how we design the
whole thing, though: it seems to be only about Jenkins publishers
configuration, and should not impact the rest, so perhaps we can just
postpone this topic (and not call it a MUST) until #9515 and friends
are resolved, and 

[Tails-dev] Low hanging fruit session: Sunday July 12

[sajolida]

The next low-hanging fruit session is scheduled for:

Sunday 12 July
#tails-dev on irc.oftc.net
 9 pm in Paris
 8 pm in London
 3 pm in New-York
12 pm in San Francisco

Everyone interested in contributing to Tails is welcome!

The idea is to spend a while together on many small tasks that
take less than 2 hours each.

Not only these sessions are very useful to make Tails better, but we
were happy to see new people joining recently. We hope to see even more
of that in the future as these sessions are great times to start
contributing to Tails!

For newcomers, the list of easy tickets should be a great
place to start: https://tails.boum.org/contribute/easy_tasks/

During these meetings, we exceptionally allow ourselves to do
the review  merge process on IRC instead of the usual
email-based workflow, so this should all go pretty smoothly.

We'll also try to handle bug fixes for the next release that are not assigned
to anybody.
___
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] Fwd: [Mozilla Enterprise] Delay in Firefox ESR release

[intrigeri]

BitingBird wrote (30 Jun 2015 20:05:02 GMT) :
 Maybe we could update the calendar saying it's probably delayed? Users
 are going to start asking, otherwise.

Good idea. Done, thanks.
___
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] A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in, Commercial VPN clients

[sajolida]

Forwarding here a tweet we received on tails-press.

 Forwarded Message 
Subject: Nick Mathewson (@nickm_tor) mentioned you in conversation on
Twitter!
Date: Tue, 30 Jun 2015 16:43:12 +0200

@tails_live devs should probably make sure that they aren't affected by
any of https://petsymposium.org/2015/papers/02_Perta.pdf. (I would guess
no) #pets2015

___
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] Tails contributors meeting: Friday July 03

[sajolida]

The next Tails contributors meeting is scheduled for:

Friday 03 July
#tails-dev on irc.oftc.net
 9 pm in Paris
 8 pm in London
 3 pm in New-York
12 pm in San Francisco
 
Everyone interested in contributing to Tails is welcome!

Feel free to propose and prepare discussion topics. Either:

  - Raise them in this thread so that others can ask details and prepare the
discussion too.

  - Update the blueprint of the agenda:

https://tails.boum.org/blueprint/monthly_meeting/

  - Make sure that the discussion tickets that you want to treat during the
meeting are well detailed on Redmine.

If you want to get involved but don't know yet how, please introduce
yourself during the meeting, and be sure to tell us what you are
interested in.

The meeting might not be the most adequate time and place to properly
introduce newcomers to the development process, but at least it should
be a fine place to know each others, and schedule a better
suited event.
___
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.