Re: [Tails-dev] thoughts about the persistence encryption
Hi, Daniel Kahn Gillmor wrote (18 Feb 2015 23:50:20 GMT) : On Wed 2015-02-18 16:24:51 -0500, goupille wrote: iteration time: it is low for slow systems, and Tails is aimed to work on relatively slow systems it should be increased iteration time only has a cost during boot (persistence unlock). I agree that spending extra cycles at boot is worthwhile. Agreed. For the Live system use case, tuning the number of iterations based on the speed of the machine where the LUKS device is initially created doesn't make much sense. IMO, ideally we would fix the iteration *count* ourselves. However, cryptsetup only supports setting the iteration *time* (with --iter-time), so next step would be to ensure there's a wishlist ticket in cryptsetup bug tracker to request a --iter-count or similar option. Now, this won't be enough. UDisks' PartitionCreate that we're using (and that in turn calls FilesystemCreate) doesn't support passing any specific option to cryptsetup. UDisks2 (that I'm going to port tails-persistence-setup to next months) similarly doesn't seem to support that in the org.freedesktop.UDisks2.Block's Format method. So another next step is to ensure there's a wishlist ticket in UDisks2 bug tracker about it. Not sure what the best interface would be, and I suspect that a simple list of arbitrary cryptsetup options would be hard to support (they may conflict with options UDisks2 passes itself), so perhaps adding support for encrypt.iteration-count (once cryptsetup supports this), akin to the existing encrypt.passphrase opion, would be best. Anyone interested in engaging with cryptsetup and/or UDisks2 upstream about this? 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] Logo Idea Proposal
Simon Jacquin: I recently discovered your project, I am a french graphic designer, pretty much an outsider of the online underground culture. But I stongly understand how project like yours may be a ultra relevant fight in the future for our freedom. Thanks for your interest in Tails. I don't know how you guys feel about your current logo Actually, our current logo got created and approved less than one year ago when we ran an open contest. See https://tails.boum.org/blueprint/logo/. And most of us are happy with it as far as I know. I just had an idea while reading an article talking about Tails, so I wanted to show it to you. Let me know what you guys think and keep up the good work ! It's nice and simple, but I'm afraid we won't be able to use it. We could keep your contact if you would be ready to contribute to Tails in other ways. We don't have that much graphic design work to do right now but we will have more over 2015 as we work on a new web assistant to get more people started with Tails. To get the rough idea: https://tails.boum.org/blueprint/web_assistant/ But we're still in the specification phrase, we'll move on to wireframing in March-April. Other than that, don't hesitate to tell us more about your skills so we can fine appropriate tasks if you want. ___ 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 and merge feature/8777-update-screenshots
Ticket:https://labs.riseup.net/code/issues/8777 Update screenshots on the website if relevant Branch:feature/8777-update-screenshots into devel Milestone: 1.3 That one should be easy. ___ 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 builds specification
Hi, On Tue, Feb 17, 2015 at 10:32:59PM +0100, intrigeri wrote: bertagaz wrote (16 Feb 2015 14:32:57 GMT) : On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote: That's a logical awesome idea I'm ashamed not to have had sooner. Still, it seems that it comes too late, after some searching it appears that our Jenkins don't keep much stats. As discussed on IRC, we have about 10 days of logs on the filesystem currently, so you can still retrieve recent stats about it. The earlier, the better, as we're frozen and the more we wait, the less the numbers will be meaningful. I've just pushed a new page in the blueprint section, that contains the number of branches merged per release (as your script told us), and the number of builds per day that happened since 2015-02-10. https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_stats/ The Global build stats Jenkins plugin [1] seems interesting to display the stats once more logs are kept. Shall I install it? Let's give it a try, yes. I'll do that soon then. * Scenario 3 : RM says I need to know when a branch FTBFS, but I see no notification mechanism planned, so... how is the RM supposed to know. Also, whenever stalled topic branches start failing, this can imply an avalanche of daily email to the RM, who will of course start ignoring all email from Jenkins and then we've lost. I'm particularly worried about this topic since anonym (our RM most of the time) didn't comment on this proposal yet, and has already expressed concerns about this kind of issues. I think anonym did comment on this proposal, he did a review of this blueprint already. OK. Let's keep in mind that he may not have thought of this potential problem yet. Now, I wonder if we could solve this quite simply by having the RM be notified for *base* branch build failure only. The RM doesn't care about topic branches that haven't been submitted for merging yet, right? I like this idea, simple and effective. :) So for the base branches, the RM would be the contact point for daily and on push build failure notifications. And for topic branches, that would be the last commiter. One thing that this question also raise is the fact that the RM is not always the same person, so I'm wondering how to have jenkins notifying the right email depending on who is the RM for the next release. First thing that come in top of my mind is... a schleuder address. :) Indeed, that's the kind of aliases the RMs can trivially update themselves, without asking the infra team to do anything. Great, I'll add that to the specs and will open the corresponding tickets. bert. ___ 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] thoughts about the persistence encryption
On Thu 2015-02-19 06:25:35 -0500, intrigeri wrote: Hi, Daniel Kahn Gillmor wrote (18 Feb 2015 23:50:20 GMT) : On Wed 2015-02-18 16:24:51 -0500, goupille wrote: iteration time: it is low for slow systems, and Tails is aimed to work on relatively slow systems it should be increased iteration time only has a cost during boot (persistence unlock). I agree that spending extra cycles at boot is worthwhile. Agreed. For the Live system use case, tuning the number of iterations based on the speed of the machine where the LUKS device is initially created doesn't make much sense. IMO, ideally we would fix the iteration *count* ourselves. However, cryptsetup only supports setting the iteration *time* (with --iter-time), so next step would be to ensure there's a wishlist ticket in cryptsetup bug tracker to request a --iter-count or similar option. here's the upstream bugtracker (requires a google account to post a ticket): https://code.google.com/p/cryptsetup/issues/list the code looks pretty straightforward if someone wants to work on a patch. git clone https://code.google.com/p/cryptsetup/ and take a look at: lib/setup.c lib/luks1/keymanage.c lib/libcryptsetup.h src/cryptsetup.c --dkg ___ 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: 1.3] bugfix/5394-time_syncing_in_bridge_mode
Hi, See the ticket for details, in particular from comment #16 and on. Please review and merge into devel and testing. 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] Automated builds specification
Hi, On Mon, Feb 16, 2015 at 04:39:22PM +0100, intrigeri wrote: bertagaz wrote (16 Feb 2015 12:03:12 GMT) : Ack, sounds reasonable. However from what I've seen, it sometimes means a lot of branches so I wonder if we scaled our infra enough for that, as we didn't include this branches in our maths since the beginning of the discussion. This seems like a serious bug in this discussion process. May you please then provide example numbers that match what the proposed algorithm would output, so that we can reason about it? I've added to the statistic page the doc branches that have been merged. Part of them were not in the output of the script because they often get merged in master. It seems to add 4 to 6 branches per release, but their development and integration flaw is a bit different. So in the end, I'm not sure they'll add a lot more load, but we have to count them in our maths. bert. ___ 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 builds specification
On Tue, Feb 17, 2015 at 09:47:51PM +0100, intrigeri wrote: bertagaz wrote (16 Feb 2015 14:37:56 GMT) : On Thu, Feb 12, 2015 at 12:22:45AM +0100, intrigeri wrote: Here's one more: the proposed notification mechanism makes sense to me for topic branches. But for base branches, it's more complicated: Thoughts? Agree with that as stated in my previous email. OK, good. Then I'll let you capture in the specification that problem, and our currently preferred solution. Done. What follows is only interesting for Jenkins folks. I guess almost everyone but DrWhax and bertagaz can stop here. I think it is doable to differenciate them, by splitting the daily and on git push job definiton maybe. = I think this trick would make the overall thing hard to understand and draw conclusions from, for anyone not deeply involved in our Jenkins stuff. That's my opinion too. Having a look at plugins might help, as well as how other projects do that (as you stated elsewhere). Yep. At least the obvious candidate (Email-ext plugin) doesn't seem able to email different recipients depending on what triggered the build out-of-the-box. But apparently, one can set up two 'Script - After Build' email triggers in the Email-ext configuration: one emails the culprit, the other emails the RM. And then, they do something or not depending on a variable we set during the build, based on what triggered the build. Likely the cleaner and simpler solution. Otherwise, we could have Jenkins email some pipe script that will forward to the right person depending on 1. whether it's a base branch; and 2. whether the build was triggered by a push or by something else. This should work if we can get the email notification to pass the needed info in it. E.g. the full console output currently has Started by timer or Started by an SCM change, but this is not part of the email notification. Could work, but a bit hackish and all kinds of things can go wrong. Also, I've seen lots of people documenting crazy similar things with some of these plugins: Run Condition, Conditional BuildStep, Flexible Publish and Any Build step. But then it gets too complicated for me to dive into it right now. Yes, feel also quite lost in all this big Jenkins ecosystem sometimes. But it's certainly doable. I'll spend time digging into this too. If you prefer, in the future I can dump such research results into the blueprint instead of here. Just tell me where it should go. The blueprint/automated_builds_and_tests/jenkins page seems perfect for that. bert. ___ 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] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
intrigeri: sajolida wrote (18 Feb 2015 11:32:17 GMT) : intrigeri: Alan wrote (12 Feb 2015 15:32:15 GMT) : - Ability to close a circuit manually. No idea what are the use case for this feature that we would want to support. If someone really wants it, better add it to arm IMO. Tor Monitor doesn't provide this feature yet. It would be very easy to add, even though I'm not sure I find it desirable: currently we only *monitor* Tor. Do we also really want to *control* it? Rather not IMO, but I guess everybody got that already :) I'd love to see Tails run no X application, except Tor Launcher, that is able to trivially deanonymize the user via the control port. Being able to close circuits could be useful to debug malicious exit nodes. For example, you get an unexpected HTTPS or SSH warning, write down the info about your exit node, and close that circuit to get a fresh one and confirm your suspicions. Good catch! How important would that be given it doesn't happen that often? On the other hand I understand the importance of not doing into controlling Tor. Indeed, I'm pretty sure that closing arbitrary circuits offers excellent avenues for de-anonymization attacks. It *might* be possible to mitigate this problem by strongly rate-limiting it, though. If it works, then this might be the easiest way out, but it would need a careful threat modeling and security discussion before I trust it. I think that would be the most elegant way to solve this problem. Everything that follows in this paragraph is just in case nobody works on this potential solution early enough. Do we think that the majority of users who can do this kind of analysis would suffer from having to do it in arm? If not, then the next step is to file a wishlist ticket about it in arm upstream. If yes, then it gets harder, but maybe there are good enough ways out for the users in the grey zone (skilled enough to conduct this analysis, not Unixist enough to be at ease in a terminal-based UI): * For HTTPS, one can already use Torbutton's New Identity feature to achieve the same result. IIRC the upcoming Torbutton's per-tab circuits viewer will have a New circuit for this tab feature, that will make it even better. * For other kinds of connections (ssh, imaps, pop3s, etc.) then there are two ways: - either using arm to trigger a New Identity, which is not *that* crazy: close the software that initiated the connection, open a root terminal (which may be a blocker in itself), run arm, type m, down arrow then enter - or restarting Tor, e.g. by disconnecting and reconnecting from the network using the NM applet = seems like we can address this corner case in a good-enough way without compromising security nor spending large amounts of energy on this topic. Fine with me. Still, we would need to have arm documented in the first place. And since I propose it to go in Advanced topics anyway we can explain the workaround there for now and create the upstream ticket that you mentioned as well. - Has there been any thought put already into how Tor Monitor would integrate into #7437 (Add a progress indicator while establishing a connection to Tor), or live aside of it? I was kinda hoping that removing Vidalia would help consolidating the sources of information we provide to the user about the network bootstrap process: I bet the variety of such sources participate in confusing users. So if Tor Monitor is meant to be an independent tool, perhaps it's better if it does *not* start by default. Anyway, I'm wandering a bit off-topic here, but you don't want me to wait 6 months before I ask this question, right? Right, there's definitely a UX side to this. The first thing I can think of is that people are going freak out if the green onion disappear as its currently the only indicator of the Tor state on the desktop. I'm not talking about the Tor is ready notification which is not an permanent indicator. I'm not sure that this green onion is actually an indicator of the Tor state, see below. We developers know that nothing can do wrong and everything that is not Tor would be blocked. But in term of usable security, I think it's important to have a visual indicator saying hey, everything is all-right. OK. If all we need is to convey the message that everything is configured to go through Tor, then we don't even need to talk to the control port: we can just display a green onion (once Tor has bootstrapped) and leave it there as long as the Tor service is running. I'm half-joking, but seriously, given we *know* that everything is alright, we can just say that in the way people want to hear it, which is apparently that green onion (I'll trust you on that one). And also how shall we let users know when their Internet connection is working but they loose their connection to Tor for some reason (say
Re: [Tails-dev] [RFC] UX for ISO verification + Tails Installer + full upgrades [was: ISO verification automation proposals]
Hi, sajolida: u: sajolida: sajolida: In the process of reworking globally the bootstrapping workflow for Tails, we brainstormed, together with tchou, on the idea of further automating the ISO verification process. Tails Installer --- https://tails.boum.org/blueprint/bootstrapping/installer Here are some thoughts on the blueprint: Autodetect if the destination key has Tails already. * Then display Install and Upgrade buttons accordingly. = Here, do we also want to have an option Overwrite or Reinstall? Or do people need to erase their USB sticks if they want this? Sorry for not being clear enough. * If the destination USB stick has no Tails installed, then only the Install button is displayed. * If the destination USB stick already has Tails installed, then two buttons are displayed: Install and Upgrade. We could rename the Install button into Reinstall here I think to be more explicit. Does that make more sense, now? The details of where the button are, and their precise label can be figured out later I think. That makes it clearer indeed. Thanks! Add visual and textual context to main interface. = = I'm not sure if i understand what you mean. That's work we should do with tchou. The idea here is to reuse some of the visuals that we will be using in the web assistant. People are going to follow paths with a clear progression (step 1 download, step 2 verification, etc.) So it make sense to integrate this in Tails Installer as well. But we still don't know how. ok. Add a splash about creating persistence after rebooting. = Could you please explain in detail when this screen would show up exactly as I am not sure if I understand. Is this be part of the Installer itself? That's still a rough idea but this would appear when the installation is over and explain (reusing the language and visuals of the web assistant) that people can (should) restart on that new USB stick and go on creating a persistent volume if they want to use it (about half of them do). [..] Sounds like a great idea. Cheers! u. ___ 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.
