Re: [Tails-dev] [review'n'merge] Update news and security lists
xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: update_lists > Last Commit: ceaaf081b984d2132331fc18bd23327869a069cf Good catch! Merging :) ___ 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] [review'n'merge] Unfuzzy and fix translations
xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: translations3 > Last Commit: b30d00d06ece66fa92aa23b2753155d03eac0520 Merging, 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.
Re: [Tails-dev] [review'n'merge] update links
xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: update_links > Last Commit: 54320fe11fa53782ac3a7381a827774303560790 Merged, 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.
Re: [Tails-dev] [review'n'merge] remove obsolete page
xin: > Hello, I discover that the old donate page still exist (and is still > translatable)! > I also remove an obsolete part in a news. > Please review and merge. > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: remove_old_donate_page > Last Commit: b164ce733db0bd369f68504e4e620eb9a00c43e9 Good catch, thanks! Merging. ___ 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] [internal]1st week post-release help desk report
intrigeri: > But wait, IIRC the HTTPS error was about *pinning*, I've found that email again and indeed, the error is PINNING_MISMATCH, so I don't think it has anything to do with our mirror pool. ___ 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] [review'n'merge] Unfuzzy and fix translations
xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: translations2 > Last Commit: 164032ae0e746344de777b596ba90f9831d53552 Merging, 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.
Re: [Tails-dev] [review'n'merge] update screenshot
xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: update_screenshot > Last Commit: 25be431fc13ee53981af6e551109f2978c7b0e79 Good catch! Merged, 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.
Re: [Tails-dev] Including iso checksum in release announcements
Hi, Joe Nelson: > Hi devs, wondering if you could start including the SHA-256 checksum for the > tails > iso in future release announcement emails? We will document our answer to this question soonish. Meanwhile, see the discussion on https://labs.riseup.net/code/issues/12645 :) ___ 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] [internal]1st week post-release help desk report
Hi, u: >>> and a user reported that with firefox 55, downloading the IOS with the >>> add-on doesn't work due to a certificate mismatch (I still need to try >>> to reproduce before opening a ticket. >> >> nor that. > I've seen a screenshot from this user (puh, don't ask me where that > was) IIRC we've received it on tails@. Sadly I've deleted that email already :/ > and the URL was a mirror (it was 13.dl.amnesia.boum.org in the image), > which we had switched to HTTPS in the meantime and changed its URL. So I > suppose that this was the problem. The commit that switches this mirror to HTTPS dates back from June 8, so either it was pushed only later (after the 3.0 release), or we have another problem. But wait, IIRC the HTTPS error was about *pinning*, and the only pinning our add-on does is for downloading the IDF and mirror pool info from our website. That might be another hint that suggests the problem at hand is unrelated to the content of mirrors.json. Perhaps these users were "simply" man-in-the-middle'd. Can anyone else reproduce? 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] [internal]1st week post-release help desk report
Hi, first of all, thanks *a lot* for this report! tails-b...@boum.org: > a lot of users were affected by > https://tails.boum.org/news/version_3.0/#known-issues Yeah, sorry about that :/ I've sent a fix to the RM (bertagaz), who hopefully will release it soon so that at least Debian and Ubuntu users get it ASAP. > we've got a few reports of users having trouble with nividia (mostly > geforce 970) workarounded by adding nouveau.modeset=0 (likely #11831, > but they didn't seem affected with tails 2.*) OK. Can you please take over #12438 then? The workarounds have been known for a month, it would be nice to see them properly documented. If you have trouble with our style guide etc., stick to the basics: reuse existing similar text, and I'll polish a bit myself before merging. > 2 users affected by https://labs.riseup.net/code/issues/12543 were asked > to provide the info needed Thanks, I see one person already provided some info. I'll look into it shortly, we'll see if that's enough. > a few users having trouble with dual monitors (#12730) Indeed. Replied ⇒ back on goupille's plate. > 2 users reported that virtualbox shared folders does not work anymore #12724 OK. It's on goupille's plate for now, I'm waiting for more info. > and several users reported that installing by cloning "didn't worked" > (the window shut down and tails is not installed), apparently on devices > made with UUI. I lack information so I'll try to reproduce before > opening a ticket 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.
Re: [Tails-dev] [review'n'merge] Fix translations
xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: translations > Last Commit: 39fd2179895ed28763d85fd4842e4c4f579d8e8e Merging, thanks! 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] [review'n'merge] Remove redundant image
xin: > intrigeri: >> xin: >>> Yes it's right, I didn't think about that. >> >>> We just need to copy svg source to donate folder. >>> If someone want to translate donate image, it's better if the source is >>> in the same place. >> >> Right. Can you please do so? > Yes. > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: add_image_source > Last Commit: 5700f8f67a33393fd655ba7a6babe94e0ad1c552 Merging, thanks! 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] [review'n'merge] Remove redundant image
xin: > Yes it's right, I didn't think about that. > We just need to copy svg source to donate folder. > If someone want to translate donate image, it's better if the source is > in the same place. Right. Can you please do so? ___ 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] [review'n'merge] Remove redundant image
Hi, xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: remove_redudant_image > Last Commit: cfa722095636c441a467fdd7079a15d86be3075b I don't think it's a good idea: it's true that these images are currently rendundant, but if I merge this branch, then as soon as we update the version in donate/, then the blog post from our 2016 fundraising campaign will point to info about the future. IMO the 2016 blog post should keep referencing info that was correct at that point, while the donate page should reference up-to-date info. What do you think? 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] [review'n'merge] Wikipedia shortcuts
xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: wikipedia_shotcuts > Last Commit: a812545ea6a4c4a807d0e91f4ce94f808c94b1ad merging, 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.
Re: [Tails-dev] [review'n'merge] Fix Thunderbird documentation
xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: fix_thunderbird_doc > Last Commit: 52b89a482180a91fa3d98ddccca4addca41ed199 merging, 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.
Re: [Tails-dev] [review'n'merge] update links
xin: > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: update_links > Last Commit: b5172d11b4f7ac0f056c8430a8b7e6fcc29e3dcf merging, 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.
Re: [Tails-dev] Hidden part of FAQ
Hi, xin: > Hello, the FAQ have two commented paragraphs at the end since a long > time. What is the interest to keep it? I see: 1. "XXX: Push that information to the browser documentation?" 2. the "rawmaterial" section about chaining a proxy after Tor → in both cases, IMO this info should either live in a ticket, or deleted. I'll let sajolida decide whether it's worth tracking somewhere. 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] Incorrect link anchor in 3.0 release notes
hi, Cody Brownstein: > Changes > New features > Major upgrades to included software > The "migrated automatically" link specifies the anchor "#migrate" > instead of "#migration". > Fixed by attached patch. Thanks, applied! … and updated + unfuzzied PO files. 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] Tails 3.0 release schedule [Was: Changing Tails 3.0 release date?]
Hi, intrigeri: > So I'll make the call by the end of this week, depending on how > I feel about committing to RM'ing an extra release. I may follow > anonym's very reasonable position, or go crazy for the sake of > communication and Debian/Tails/FOSS relationships. I'm undecided yet > and want to sleep on it and balance all this very carefully. I've decided to follow anonym's "keep calm and stick to the plan" advice, so there won't be any scheduled 2.12.1 release, and Tails 3.0 will be released on June 13. By the way, it's amazing that we were able to predict a reasonable release date for 3.0 back in December last year! :) So here's the release schedule: * 2017-06-09: - Import Tor Browser 7.0. - Bump APT snapshots ([[!tails_ticket 12609]]). - Freeze: all branches targeting Tails 3.0 must be merged into the `devel` branch by 15:00 CEST. * 2017-06-10: Build and upload the Tails 3.0 tentative ISO image. * 2017-06-11 and 2017-06-12: Test the Tails 3.0 tentative ISO image (deadline: 2017-06-12, 17:00 CEST). * 2017-06-13: Release Tails 3.0 Testers, please let me know if you are available on 2017-06-11 and/or 2017-06-12. Thanks in advance! 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] Tor Launcher automation meeting
Hi, sajolida: > tails-dev: Part of my mission was to ask two more technical questions > but apparently it's too early to answer both of them with certainty: > 18:47:50: #1: What kind of network connections will Tor Launcher > initiate *itself* (as opposed to asking little-t-tor to)? None? > The answer is unclear but Tor Launcher will probably initiate some > network activity of its own, for example to start meek-client to talk to > bridgedb. OK, this is very good to know: it can prevent us from wasting time on developments that would be incompatible with this upcoming feature. That's a bit sad for upstream Tor Browser (as long as Tor Launcher is part of the Firefox process, this will make it impossible to sandbox Tor Browser in a way that it can't initiate network communication without going through little-t-tor). As far as Tails is concerned: * At the moment we run Tor Launcher as a dedicated user (so we're not affected by that sandboxing limitation); now, we have plans to change that (#9051), which would be very problematic once Tor Launcher needs to initiate network activity of its own. Added this note to that ticket. * We don't sandbox Firefox processes this much anyway: the benefit would be very limited considering we also have our firewall as an additional layer of protection that will prevent Tor Browser to bypass Tor. > 18:58:56: #3: Any news on the possible language and coding dependencies > for this new Tor Launcher? How easy is it going to be to reuse it in > Tails? :) > The answer is unclear as well but mcs says that they will likely not > have enough time to create a completely new Tor Launcher. So on the short term, nothing changes for us, but the future is uncertain apparently. I do hope Tor Launcher becomes an external process in light of the improved sandboxing it'll allow (outside of Tails). > Hope it's useful :) It is, thanks a lot! 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] Tails build system update
Hi anonym (and perhaps bertagaz), I think we've missed this email: Arnaud: > I just checked out the **stable** branch and tried the new build system. > Everything worked fine and smoothly on my machine (running Debian 9). > I've seen some warnings here and there, that were harmless but I'll > report it anyway just in case it matters. > -- During Box Creation -- > During the execution of > `vagrant/definitions/tails-builder/postinstall.sh`, the command `apt-get > update` generates this warning. I see the same warning later on, after > the box is created, for each `apt-get update` I think. > W: Conflicting distribution: > http://time-based.snapshots.deb.tails.boum.org jessie/updates InRelease > (expected jessie but got jessie/updates) > During `apt-get -y dist-upgrade`, and later on during various `apt-get > install ...`. > E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No > such device) > -- Misc -- > In the Vagrantfile, I've seen that there are still 4 lines mentioning > the box name, url and checksum. Is it still needed ? 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] Changing Tails 3.0 release date?
hi! anonym: > intrigeri: >> I'll make the call as the 3.0 release manager if no consensus >> emerges, After re-reading this discussion, it appears that the only people substantially affected by this decision (apart of Tails users of course) will be myself and our usual manual testers. So I'll make the call by the end of this week, depending on how I feel about committing to RM'ing an extra release. I may follow anonym's very reasonable position, or go crazy for the sake of communication and Debian/Tails/FOSS relationships. I'm undecided yet and want to sleep on it and balance all this very carefully. >> A. Coordinate Tails 3.0 and Debian Stretch releases [...] >> B. Don't bother and proceed as our calendar says >> - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x: >>this work has been based on the Tails 3.x codebase so far. I don't >>know if rebasing it onto the stable branch would be trivial, or >>a lot of work. anonym, what's your feeling? > Cherry-picking these commits will not result in any difficult conflicts (it's > mostly > about s/32/64/, and some jessie vs stretch test suite images). But there > could be > issues with running 7.0a4 on Tails Jessie/i386 -- we haven't tested the 7.x > series at > all on that platform. Still I definitely believe it quite a bit more likely > to Just > Work rather than introduce issues we don't see on Tails Stretch/amd64. So my > feeling > is that this should be an hour of work. OK, thanks for the insight! >> - Option B is less work, therefore it increases the chances that we >>manage to make 3.0 build reproducibly, which gives us good >>communication opportunities. So: >> >>[...] >> >> * anonym (who is our lead developer on the reproducibility front): >> if we go with option B, how confident are you that 3.0 can >> build reproducibly? #12608, #12567 and #12566 should be good >> starting points. > At least for me, locally, the only problem I see (after applying all unmerged > fixes) > is that Chris' patch for #12567 seems to miss some case. I've asked for an > ETA of > a fix. So assuming Chris is available, or I manage to identify and fix the > issue, > it's looking really good. :) Great :) >> Other pros/cons or thoughts? > A con for option A: > * Users will be prompted to do two updates within four days, which >is a bit much both in terms of nagging frequency, bandwidth >usage, and pure inconvenience. Absolutely. This will be particularly painful for those who will have to do a manual upgrade to 2.12.1, as everyone will have to do a manual upgrade to 3.0 anyway. On the other hand, if 2.12.1 is a thing, we give users almost two months to upgrade to 3.0 (vs. 0 days if we don't release 2.12.1), which is nice as they're often scared by such drastic change; also, anyone affected by a serious regression can temporarily downgrade to 2.12.1 until Tails 3.1 fixes their problem. So all in all it's not clear cut to me which option provides the greater UX (once considering dozens of thousands of real-world users, and not only some theoretical, ideal one who would immediately upgrade to 3.0 and not have any big problem with it). > I'd also like to stress (pun intended!) the fact that option A's "more work" > (as in > an extra release, 2.12.1) is not so suitable at this time. I think we're > collectively > exhausted, and should try to take whatever breaks we can. OK, thanks for sharing, I want to take this into account. I'm committed to be the RM for 3.0 already; I understand you don't feel like taking care of 2.12.1 so let's assume I would handle both releases myself (if I convince myself that option A is the way to go). And then the additional work is only on my shoulders (I don't feel exhausted personally) and manual testers' (no idea how they feel about it, but we had no problem getting manual testers recently, did we?). In passing: we have 4 emergency releases budgeted this year, and we did none of them yet. Given this data + the feelings you're sharing, I think we should acknowledge that we probably won't do more than 2 emergency releases this year. If you agree, I'll update our accounting accordingly, so nobody counts on (paid) RM work that's unlikely to happen in practice, first because there's no need for it, second because our RMs are not exactly thrilled at the idea of doing this work. Fair enough? > Yup, I'm quite a lot in favor of option B. Got it. >> The decision algorithm I intend to use is: >> >> - If the reproducible builds people tell me they can make 3.0 >>reproducibl
Re: [Tails-dev] [review'n'merge] unfuzzy page in testing branch
xin: > Hello, I found another page, please review and merge. > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: testing/unfuzzy2 > Last Commit: d4e9d5d8b7fc6b8f51fdc770ec37f5cc4579772c merging, 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.
Re: [Tails-dev] Tails 3.0-Beta 4 to RC 1 upgrade
Forwarding to our help desk, Bcc'ing -dev@ once: Justin Davis: > Hi, > The automatic upgrade from 3.0 beta 4 to RC 1 is not working. When I > try to upgrade using tails-upgrade-frontend-wrapper, it says the > system is up to date. How do I do an automatic upgrade? > Thanks, > Justin. 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] [review'n'merge] unfuzzy 2 pages in testing branch
xin: > Hello, I found 2 pages who don't need translation to be unfuzzy. > Please review and merge. > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: testing/unfuzzy > Last Commit: f7980d08ad237d85756779ca3cce63867701375f Thanks! I've verified that only strings that are newly marked as fuzzy between master..testing where unfuzzied, and checked how a few of them were unfuzzied. Looks good! Will build locally, commit a PO files update if needed, and push to testing+devel. ___ 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] Please help coordinate the work on Tails 3.0
Hi, I've just made a pass on the remaining 3.0 tickets, postponed some, and adjusted priorities here and there. So now would be a good time to sanity-check your (updated) plate, if not done yet :) 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] Changing Tails 3.0 release date? [Was: Planned release of stretch on 2017-06-17 and the last weeks up to the release]
Hi, ni...@thykier.net: > Release date > > We plan to release on 2017-06-17. > […] Yeah! I'm relieved this is now public info and we don't have to discuss our plans privately within a tiny Tails release managers cabal anymore. So, what should we do about it? I'll make the call as the 3.0 release manager if no consensus emerges, but I first need some input from a few people (at least anonym, Ulrike, and sajolida) to make up my mind, so please read on :) I see two options: A. Coordinate Tails 3.0 and Debian Stretch releases We can prepare two releases at the same time: 2.12.1 and 3.0. Both should be ready (including release notes, uploading ISO, manual testing) on June 13. But on June 13 we release 2.12.1 only (we have to release _something_ on that day anyway due to the Firefox security updates), and we wait until June 17 to publish Tails 3.0, at the same time as Debian Stretch. B. Don't bother and proceed as our calendar says I.e. simply release Tails 3.0 on June 13. Pros and cons: - Option A costs us one more "Emergency releases" i.e. 2.25 days of work (release management + manual testing). - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x: this work has been based on the Tails 3.x codebase so far. I don't know if rebasing it onto the stable branch would be trivial, or a lot of work. anonym, what's your feeling? - Option B is less work, therefore it increases the chances that we manage to make 3.0 build reproducibly, which gives us good communication opportunities. So: * Ulrike (who committed to handle such communication) and sajolida (who'll likely be needed to review it), do you think you can realistically take advantage of this opportunity? * anonym (who is our lead developer on the reproducibility front): if we go with option B, how confident are you that 3.0 can build reproducibly? #12608, #12567 and #12566 should be good starting points. - Option A gives good opportunities for communication: * On Tails' side: we can point out that we're releasing on the exact same day as Debian (which is a stronger symbol than 4 days earlier); I would love to see this happen as a way to re-affirm our strong relationship with Debian, which has been very important so far in terms of how we fit into the Debian community and the broader FOSS world. * On Debian's side: they can mention our release in their communication. But TBH they can probably do it anyway even if Tails based on Stretch is out earlier than June 17. Other pros/cons or thoughts? The decision algorithm I intend to use is: - If the reproducible builds people tell me they can make 3.0 reproducible and communicate about it _only_ if we pick option B, then I'll go this way. - Otherwise, if the reproducible builds plans are less clear, then: if it's not too hard to integrate Tor Browser 7.0 into Tails 2.x, and anonym+I find a way to share the additional RM'ing work, then I'll pick option A else, I'll fallback to option B. > The final weeks up to the release > = [...] > In the last week prior to the freeze, testing will be completely > frozen and only emergency bug fixes will be considered in this period. > Please consider Friday the 2017-06-09 at 13:00 UTC the absolute last > moment for changes to stretch. So I plan to bump our APT snapshots serials on 2017-06-09: #12609. 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] [Tails-support] Tails Browser Vulnerability
hi, [redirecting to tails-dev@, Bcc'ing -support@ once.] Whitey: > intrigeri: >> Whitey: >>> https://www.theregister.co.uk/2017/04/18/homograph_attack_again/ >> >>> The article shows links that look like "apple.com" or "epic.com", but >>> are actually "xn--80ak6aa92e.com" and "xn--e1awd7f.com". Let's get this straight first, to avoid basing our reasoning on mistaken assumptions: they are something that very much looks like "apple.com" and "epic.com" visually, but that is not "apple.com" nor "epic.com", and that can optionally be encoded and displayed as "xn--80ak6aa92e.com" and "xn--e1awd7f.com" (punycode encoding). >>> At the present time it affects Firefox 52 and it's derivatives, as well >>> as Chrome 57. >> >> Please check if the Tor Browser developers are aware of it, >> and if not, let them know: this is not the kind of things that should >> be fixed in Tails only. > O.K., did that Thanks. For the record, the Tor Browser ticket about it is: https://trac.torproject.org/projects/tor/ticket/21961 > but Tails developers should address the issue no matter > what the Tor Browser developers do. Relevant info can also be found there: https://bugzil.la/1332714 https://www.chromium.org/developers/design-documents/idn-in-google-chrome My understanding is that this is a complex issue, that has no obviously good solution: _always_ displaying punycode, as was suggested on this thread, would substantially harm web usability for users of languages written in non-Latin scripts. And the current state of things can make successful phishing attacks easier. So from where I stand, I'd rather let Mozilla and Tor Browser people make up their mind first, and come back to it once the dust has settled, decisions have been made, and we can draw inspiration from their reasoning. > On a non-Tails Tor Browser > installation the user can change the setting himself and it will persist > after a reboot. User Tor Browser configuration changes in Tails, > however, are not persistent. Sure, this is a strong argument in favour of shipping good default settings that work for most users. As said above, it's not obvious to me that the defaults we ship in Tails currently are worse than the other option, all things considered. 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] Heads up! testing & devel branches now based on Stretch
Hi, forget about feature/stretch, it's not a thing anymore. Now the testing and devel branches are based on Stretch. Please let me know if I broke something in the process. 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] Saving Additional Software
Hi, DanielBauer1989: > I recently created a post on the TAILS subreddit hoping that someone with > experience > could help solve my issue: > https://www.reddit.com/r/tails/comments/6cwail/need_help_saving_additional_software/ > Sadly, I am yet to conclude/solve this issue and I was hoping that you were > the right > people to ask. Are you the right people to ask for help, if not, who should > I be asking? https://tails.boum.org/support/ :) I'm forwarding this to our help desk now. 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] Please help coordinate the work on Tails 3.0
Hi, intrigeri: > Almost all big changes we want to see in 3.0 are done, or close to be. > We'll release 3.0~beta4 on Wednesday, and likely a first release > candidate around May 20, after which only minimal fixes for important > problems will go in. That's still the plan. The 3.0 milestone has 76 open tickets, which doesn't seem entirely realistic to me: let's fix that! Please have a look now at *your* Tails 3.0 tickets, and think: if you can handle them by the end of May, fine. If there are some you think you will not be able to address by the end of May, then please clarify your plans on Redmine ASAP so anonym and I have time to take over if we feel they are release blockers. Bonus points if you drop me a line privately once you've gone through this, so I know how to interpret any lack of action on Redmine :) Thanks a lot in advance! 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] Tails build system update
Hi, bertagaz: > I forgot to merge the related branches in master when releasing this > build system changes. I've fixed that since then, Thanks! Note we generally don't do code changes on the master branch (it's simply not its purpose): what I requested was merely to have the *doc* updated there. > as branches based on master were failing to build in Jenkins. FYI this is generally the case (I don't remember why) and not really a problem in practice AFAICT (nobody complained about it recently). > The doc should now be up-to-date. :) 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] About SquashFS default compression setting
anonym: > a ticket and patches renaming them to `fastcomp` and `releasecomp` (or > similar) would > be welcome. These names look OK to me. > This change will require some coordination with our infra's sysadmins, > though, so it might take a while for it to be applied. … unless "defaultcomp" remains unofficially supported for a little while, with a mere warning displayed, so that everyone learns about the transition they have to go through. I prefer such approaches to the flag day one that assumes everyone is on top of their tails-dev@ backlog etc. :) 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] Tails build system update
anonym:
> In addition, here are steps to clean up the old build environment as a one
> time step:
Thanks!
> vagrant box list | \
> grep -o "tails-builder-amd64-jessie-[0-9]\{8\}\>" | \
> xargs -l vagrant box remove ; \
This fails for me with:
"Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY."
The other commands worked fine :)
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] Tails build system update
bertagaz: > we strongly advise to have a look at the build documentation > [2] and adapt your usage. > [...] > [2] https://tails.boum.org/contribute/build I see no recent change made to this page. Perhaps the doc update was merged only on other branches? If so, please ensure the doc on the master branch is up-to-date. 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.
Re: [Tails-dev] Reintorducing I2P to Tails
Hi, Vasiliy Kaygorodov: > My name is Vasyl "vk" Kaigorodov, and I want to start working on > https://labs.riseup.net/code/issues/12264 (reintroduce I2P) and become an > I2P-Liaison Cool! > (and maybe Debian I2P packages maintainer eventually, though I'm not > a huge fan of Debian build system and their maintainer > guidelines). Personally, I would really like to see clear plans to get I2P in Debian proper before we reintroduce it. But IIRC this wasn't part of the blockers we agreed upon, was it? I'll let anonym clarify. > can also upload ISO somewhere, if needed). Publishing a Git branch would be enough :) > There're couple of minor issues: > - bootstrapping process in Tails checks if port is open on lo iface > and reports "I2P is ready" when it is; that's only partially true - > sometimes you can open an *.i2p address in the browser, sometimes you have > to wait additional 1-2 minutes until tunnels are built. That's probably the > reason for that sleep command to be present. Yes, probably. > I see two ways to solve it: > (1) improve the `i2p_built_a_tunnel()` to check not only the port, but also > trying to query some *.i2p site and (2) just update the docs saying that > due to the I2P network design, and the way I2P is used in Tails (Hidden > mode) - it might take some time for a user to be able to access I2P > resources. Thoughts? Indeed, this part of the I2P user experience in Tails has always been crappy. I would welcome an actual fix. Can you please file a ticket about it, if we have none yet? > - i2p packages still available in deb.tails.b.o repos, so I had to do some > pinning for deb.i2p2.de in apt preferences - should I report this to infra > guys in Redmine? Yes, please (and make sure you state clearly on the ticket what packages should be removed from what APT suite). > - not an issue but rather a question: do we need I2P repos in live Tails > system, or only in chroot during the build process? Currently I did add it > to both. We won't use the I2P repos when building official Tails images anyway: we instead import them into our own repo, as documented somewhere in the commit you reverted. But I understand you want to do that on your side for development purposes, so do whatever is more convenient for you: it won't affect Tails in the end :) > As being asked in #12264 I will first work on #8280, and then submit a huge > patch for review. Please let me know if you want to see it earlier - will > do the wip/ branch. A Git branch with atomic commits would be much, much nicer than "a huge patch". > Also: in #8280 it's mentioned that someone proposed to use bind mounts in > the mailing list, but there's no link provided to the exact post. I was > trying to search the archives with not much luck. Can someone point me to > the right direction here? Isn't https://labs.riseup.net/code/issues/8280#note-9 enough? > Or maybe something was already implemented for > Tor Browser, so I can re-use that for I2P browser? No. 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] QEmu guest agent in tails builder
Arnaud: > In the Vagrant build VM, there is no `systemd-logind` installed. OK, that's the problem. Let's not bother with acpid and instead get systemd-logind installed and running. I've filed a ticket for anonym about it: https://labs.riseup.net/code/issues/12525 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] French news index screwed up
u: >> I've just done that, and it worked. > How do you do that "fix some minor issue on one of the inlined pages" ? > Or should I just look at that myself in Git? :) So I can do it myself > next time.. See e.g. commit c2867ea05707d313191b7b7b4a0bb035414c6dda :) ___ 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-project] Preparing the next monthly report
sajolida: > I'm also wondering if I should continue cross-posting tails-dev and > tails-ux for this email. Over the last years I don't remember > contributions to the reports coming from people who are on tails-dev or > tails-ux and not tails-project. Yes, let's stop. Everyone who's not on tails-project@ and is interested in such matters: please do subscribe :) 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] French news index screwed up
u: > the news index in french is completely screwed up : > https://tails.boum.org/news/index.fr.html > Seems to work in other languages though. What's the problem here? We're feeding the ikiwiki PO plugin with things (combination of inlines, mixed source filetypes, and translatable + non-translatable pages, refreshing some PO files locally and letting our production website refresh some others) that it doesn't support well: https://labs.riseup.net/code/issues/6907 We've been aware of this for years, but I don't think there's any plan to address either the root cause of the problem in ikiwiki, nor to acknowledge these limitations and stop using buggy combinations of features; so for the time being we'll have to live with how things are. Sometimes forcing a refresh of the page (e.g. by fixing some minor issue in one of the inlined pages) is enough to fix the problem. I've just done that, and it worked. But https://tails.boum.org/index.fr.html is still buggy :/ ___ 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] Please help coordinate the work on Tails 3.0
Hi, sajolida: > intrigeri: >> tl;dr: please clarify by the end of April if you can handle your 3.0 >> and priority >= Elevated Redmine tickets by May 15. > I had a look at my tickets. I quite clearly won't be able to tackle all > my 3.0 and 3.0~rc1 ticket >= Elevated by May 15. Otherwise I would have > to spend nearly all of my Tails time on this and not on the many other > "not so urgent" stuff and that wouldn't be wise. Thanks for this update! > But most of them are documentation tickets and I think it's fine to > tackle them after May 15. Well, ideally I would like us to give translators a month to update their stuff. But I understand we're not living in an ideal world, so well, fair enough, surely the doc update can be completed later. So I would suggest: * prioritize doc updates that affect the code (e.g. the new Greeter's doc) or critical UX paths (e.g. discovering what's Tails, downloading, installing, upgrading, troubleshooting and basic usage) over doc about advanced or rarely useful topics (e.g. #12376, #12378); * communicate this to translators ASAP so they can get ready to deal with whatever timeline you think is realistic on your side. > I spotted three tickets that are not pure doc and that I will prioritize > (in this order) and should get done before May 15: > - #12368: Design UX for migrating databases to KeePassX 2 > - #11962: Update installation/upgrade process/tools/doc for amd64 > - #12441: Impossible to copy text from vim into X > And another ticket that could be handled by someone else, maybe you if > you feel its safer, but it shouldn't much work either so I'll very > probably be able to tackle it if prioritized wisely: > - #11573: Update po_translatable_pages for Tails 3.0 > How does it sound? Sounds good. You might want to use the new 3.0~rc1 target version to encode this in Redmine. 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] Adding Decentraleyes by default to complement uBlock?
imageverif.trial...@startmail.com: > This is just an idea that I got, since Tails already bundles uBlock Origin by > default > with the Tor Browser, wouldn't be great to also bundle Decentraleyes? I don't understand how this relates to uBlock Origin: we ship an ad-blocker to make the web browsing user experience nicer, not in the hope it will improve tracking resistance. Anyway, this was reported against Tor Browser, which is the right place to have this discussion IMO: https://trac.torproject.org/projects/tor/ticket/22089 So I'm going to close the Tails ticket about it: https://labs.riseup.net/code/issues/12487 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] QEmu guest agent in tails builder
Arnaud: > After a bit of digging and experimenting, it turns out that this is not > a bug, just the expected behavior. It seems that libvirt tries to > shutdown the VM by speaking to the QEmu Guest Agent, which is not > installed on the VM. So nothing happens, and the libvirt shutdown script > gets stuck there, and my laptop doesn't shutdown. I'm a bit confused: our infrastructure uses libvirt/KVM, and "virsh shutdown" works nicely. Back in the pre-systemd days, we had to install acpid in the VMs to enable this functionality, and now systemd-logind handles it by default in the KVM guests. So I wonder: what's special about our Vagrant build VM, that prevents this feature from working without qemu-guest-agent? ___ 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] Cleaning IUKs and updating disk space requirements for mirrors
Hi, sajolida: > But right, mirror operators might not store all their stuff on SSD > like we do. You might be interested in learning that we do things in a bit more sensible way: we store data that's rarely accessed, such as the data served by our rsync server, on cheaper, rotating hard-drives. Hopefully this helps you freak out less about this topic :) > I'm also not super happy to ask for much more than what we need (right > now three times more than what we use). But yeah, I guess that I'll bump > the number to 30 GiB, write all mirror operators and see if that's an > actual problem for some of them. Agreed. >>> 4. Make sure that we don't break them again silently in the >>> future. Would it be complicated to check the size of the whole >>> thing during the release process? I'll let the RMs tell me if it's >>> worth the extra work. >> >> Sounds like a good idea! Where can I find an always up-to-date list >> of what directories that are mirrored (IIRC not all of the ones in >> our rsync directory are)? Then I can cook up a command that uses that >> list to calculate the current mirror disk usage. > I always forgot how our uploading mechanism work as I never interact > with it myself. But if you are not sure yourself about how to compute > this number easily then it probably means that this idea is more > complicated than it should and that we should drop it :) It's actually very simple: everything is mirrored. We still tell mirror operators that they can exclude the "obsolete" directory if they wish, but we've deleted it on our side months ago, so I'm going to drop these bits from the doc. So, anonym: please either do this immediately after reading this email, or give yourself a ticket so we don't forget about it. I also thought that a monitoring check might be useful, but IMO it's overkill as we can solve this much more easily, and closer to where it should be fixed if a problem is found, in the release process doc. 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] Cleaning IUKs and updating disk space requirements for mirrors
Hi, sajolida: > During the 2.12 release at least one of our mirrors run out of disk > space. I believe this happened this time because the 2.11 ISO was deleted several days after the 2.12 release, while it should have been deleted earlier in theory. But such mistakes will keep happening, so this fact doesn't invalidate the problem you're raising :) 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] Feature #5929 create persistent volume by default
forgottenbeast: > 1)Where are we on that front (any news besides what's published here -> > https://labs.riseup.net/code/issues/5929) Nothing new: it's not on our roadmap, and nobody volunteered to make it happen. > 2) Any documentation on the topic besides what's at the address above? None that I'm aware of. ___ 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] Please help coordinate the work on Tails 3.0
Hi, intrigeri: > tl;dr: please clarify by the end of April if you can handle your 3.0 > and priority >= Elevated Redmine tickets by May 15. I've created a 3.0~rc1 target version, so these tickets are on one of these two Redmine views: https://labs.riseup.net/code/projects/tails/issues?query_id=242 https://labs.riseup.net/code/projects/tails/issues?query_id=198 Feel free to use the new 3.0~rc1 target version to better express your plans :) 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] Please help coordinate the work on Tails 3.0
Hi, tl;dr: please clarify by the end of April if you can handle your 3.0 and priority >= Elevated Redmine tickets by May 15. Almost all big changes we want to see in 3.0 are done, or close to be. We'll release 3.0~beta4 on Wednesday, and likely a first release candidate around May 20, after which only minimal fixes for important problems will go in. So far we shared the work very nicely among a number of people, and it's been amazing. Now, the release will happen in 2 months, and anonym and I are personally responsible for putting it in good shape, so I'd like to know more precisely what the two of us will have to deal with ourselves. So, please have a look now at *your* Tails 3.0 tickets with priority Elevated or higher, and think: if you can handle them by May 15, fine. If there are some you think you will not be able to address by May 15, then please de-assign you or at least clarify your plans on Redmine. Bonus points if you drop me a line privately once you've gone through this, so I know how to interpret any lack of action on Redmine :) Thanks a lot in advance! 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] Reducing attack surface of kernel and tightening firewall/sysctls
Hi,
[cleaning my INBOX]
tl;dr: all the proposed changes were applied in Tails 2.4. Thanks!
intrigeri (Thu, 11 Feb 2016):
> intrigeri wrote (05 Mar 2015 21:14:50 GMT) :
>> intrigeri wrote (18 Jan 2015 21:45:15 GMT) :
>>> I see this thread has been quiet for a bit more than a month.
>>> Maybe it's time for someone to sum up whatever consensus was reached,
>>> and whatever disagreement may still be remaining?
>> Ping?
> OK, OK, here we go :)
> Thank you all for your contribution!
> I have compiled everything that everybody seemed to agree in this
> thread, into a Git branch (feature/various-firewall-hardening).
> I'll build it and run our automated test suite on it.
> There's one question below, mainly for Oliver-Tobias, but anyone else
> is free to have a look.
> Anyone who participated in this thread, please consider checking my
> summary below. This is _not_ my area of expertise, and it may very
> well be that I got something wrong from your discussion, which is why
> I was asking for someone else to sum it up a year ago.
> Thanks in advance!
> Note that all patches pasted below are entirely untested.
> Regarding the firewall rules, I think the agreement that was reached
> is:
> --- a/config/chroot_local-includes/etc/ferm/ferm.conf
> +++ b/config/chroot_local-includes/etc/ferm/ferm.conf
> @@ -15,7 +15,7 @@ domain ip {
> policy DROP;
> # Established incoming connections are accepted.
> -mod state state (RELATED ESTABLISHED) ACCEPT;
> +mod state state (ESTABLISHED) ACCEPT;
> # Traffic on the loopback interface is accepted.
> interface lo ACCEPT;
> @@ -25,7 +25,7 @@ domain ip {
> policy DROP;
> # Established outgoing connections are accepted.
> -mod state state (RELATED ESTABLISHED) ACCEPT;
> +mod state state (ESTABLISHED) ACCEPT;
> # White-list access to local resources
> outerface lo {
> So far, so good.
FTR these changes went in Tails 2.4.
> Except one problem was raised about this change, i.e.
> the potential for breaking stuff if a link along the way has a small
> MTU. On this we have two messages from Oliver-Tobias:
> Oliver-Tobias Ripka wrote (04 Dec 2014 01:06:11 GMT):
>> there are some cases where TCP also depends on
>> ICMP. What comes to mind is PATH MTU discovery. As TCP always has the DF
>> bit set it, packets might get rejected by routers on the path that only
>> allow for a small MTU. This results in an ICMP destination
>> unreachable/fragmentation needed(DU/FN) message that has the "next hop mtu"
>> value set.
>> [...]
>> The bottom line is that we should test if this theory above actually
>> results in problems when sending large packets in these circumstances.
>> Possible solutions would be to tweak the sysctls to allow the Kernel to
>> determine an efficient MTU via black hole router detection and MTU
>> probing.
> If I understand correctly this means settig net.ipv4.tcp_mtu_probing=1.
> Right?
> I've tested this 9 months ago and at least it didn't break our
> automated tests (https://labs.riseup.net/code/issues/9268#note-10).
This went into Tails 2.4 to.
> Another point that was raised was:
>> If we look at on the latest Tails, we'll see
>> /proc/sys/net/netfilter/nf_conntrack_helper is set to 1. I propose
>> that we set it to 0. We do not want help tracking connections, we do
>> not want those extra protocol parsers in the kernel doing this kind of
>> heavy lifting.
> ... that I think we should try (via our automated test suite).
This was applied in Tails 2.4 too.
> To end with, this other unrelated firewall hardening proposal was left
> unchallenged and is probably good (we have good test coverage in this
> area so our automated test suite should tell us relatively quickly if
> it breaks anything):
> Oliver-Tobias Ripka wrote (09 Dec 2014 22:40:32 GMT):
>> At the same time we should be able to change the debian-tor rule to
>> allow only NEW TCP packets, disallowing all other protocols.
> ... that is something like:
> --- a/config/chroot_local-includes/etc/ferm/ferm.conf
> +++ b/config/chroot_local-includes/etc/ferm/ferm.conf
> @@ -141,7 +141,9 @@ domain ip {
> }
> # Tor is allowed to do anything it wants to.
> - mod owner uid-owner debian-tor ACCEPT;
> +mod owner uid-owner debian-tor {
> +proto tcp syn mod state state (NEW) ACCEPT;
> +}
> # i2p is allowed to do anything it wants to on the internet.
> outerface ! lo mod owner uid-owner i2psvc {
> Thoughts?
Ditto, applied in 2.4.
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 seed urandom (or not)?
Hi, [cleaning up my INBOX] FTR I'm killing this thread without reading it, assuming that the team working on this very topic is taking it into account (and if not, it's all in the August, 2014 archives of this mailing list :) 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] [Tails-testers] Request for JavaFX on Tails 3.0
Hi Collin, Collin Sullivan: >>>> I'll assume that the package Martus needs is either >>>> libopenjfx-java or libopenjfx-jni. > When I tested this, it appeared that both were required for openjfx to > run. Marking either for removal also marked openjfx for removal. >> OK, please let us know once you have the exact list of dependencies >> missing in Tails. > I've managed to get Martus up and running after installing via Synaptic: > + openjfx > + libopenjfx-java > + libopenjfx-jni > And nothing else. Thanks. Since then, we've removed I2P so openjdk-8-* are not installed by default anymore. So on current feature/stretch, installing these 3 packages pulls quite some more dependencies: The following additional packages will be installed: ca-certificates-java java-common libatk-wrapper-java libatk-wrapper-java-jni libgif7 openjdk-8-jre openjdk-8-jre-headless Suggested packages: default-jre icedtea-8-plugin libnss-mdns fonts-ipafont-gothic fonts-ipafont-mincho The following NEW packages will be installed: ca-certificates-java java-common libatk-wrapper-java libatk-wrapper-java-jni libgif7 libopenjfx-java libopenjfx-jni openjdk-8-jre openjdk-8-jre-headless openjfx 0 upgraded, 10 newly installed, 0 to remove and 293 not upgraded. Need to get 46.3 MB of archives. If you want to confirm that it's still enough to run Martus, please redo this experiment with Tails 3.0~beta3 or newer :) As a rule of thumb, the download size of compressed .deb's (46.3 MB) is generally pretty close to the impact on the ISO size if they were installed by default (and same for automated upgrades, e.g. openjdk-7 has seen no less than 9 security updates in Jessie over the last two years, during which we've released 22 versions of Tails ⇒ roughly 40% of our updates included openjdk-7 packages before we removed I2P). >> I suggest you look into this using a Tails experimental ISO based >> on Debian Stretch: […] > Ah, thanks. I missed this and was testing with the vanilla Tails 3.0 > beta 1, […] No, that's not necessary. Testing 3.0~betaN is good. >>> 2) I could look again, but the libraries we need (I think) were >>> not available in the Tails default repositories, so we needed to >>> add new ones. That's another step for the user. >> >> I expect this might have been fixed with Tails 2.x, or will be in >> 3.x. But you may want to double-check :) > I did have to add the stretch tester repository to Synaptic, as I did > not find any of those libraries in the included/default repos. What's the stretch tester repository? Do you mean on Tails 2.x or 3.0~betaN? > Anyway, a bit of positive movement on the testing side, and it sounds > like some of the Tails team will be at IFF next week. Happy to talk > more about this stuff there! I'm told there was some discussion about this topic at IFF; and I seem to remember someone reported about it somewhere else, which is great! It would be nice if someone could sum it up here too, for those who have been following the discussion on this mailing list only :) 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] Debian 9: Build fails consistently, name resolution fails sooner or later
Hi Arnaud, Arnaud: > On 03/11/2017 08:41 PM, anonym wrote: >> Arnaud: >>> --- a/vagrant/provision/setup-tails-builder >>> +++ b/vagrant/provision/setup-tails-builder >> [...] >>> +# Configure apt to retry >>> +echo 'APT::Acquire::Retries "20";' > /etc/apt/apt.conf.d/99retries >> This will only affect provisioning, not any usage of APT during the build, >> right? Or will it propagate into the chroot somehow? > Indeed, it is not effective in the chroot. > One way to set this setting in the chroot is to pass an option > explicitly when running `lb config` (patch attached). This seems to have fallen through the cracks. TBH we're not very good at tracking patches sent over email, so in the future, I recommend filing Redmine tickets, assigned to the current release manager (https://tails.boum.org/contribute/calendar/), and with a patch attached (or better: a pointer to a branch). 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 schedule for Tails 2.12
anonym: > Below you'll find the preliminary release schedule for Tails 2.12: May you please update [[contribute/calendar]] accordingly? ___ 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] Screen Reader and Tor Network Settings
Hi Justin, Justin: > A wile ago, I sent an email to this list to see if the Tor bridges screen > could be > made accessible to Orca users, by using the same method that made Onion > Circuits > work. Right. I believe my previous reply still applies: https://mailman.boum.org/pipermail/tails-dev/2017-February/011231.html > Is this being worked on, and if so, where is the ticket for this? I'm not aware of anyone is actively working on it, but here's the ticket: https://labs.riseup.net/code/issues/9051 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] Maintaining I2P
Hi, Alexandre Trottier: > Hello, > I'm interested in maintaining I2P for future releases of tails. > I'm profficient at python and bash, and do Sys Admin work as a job so I > feel like this is something that I could do. Great! > I have never had to maintain a package for a distribution before so I'm not > sure where to start. For the Debian packaging aspect, I recommend starting with: https://www.debian.org/doc/manuals/packaging-tutorial/ For the Tails integration aspect, the best entry point we currently have is: https://tails.boum.org/contribute/how/code/ 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] Maintaining I2P question
Hi, Alexandre Trottier: > In order to maintain I2P do all I need to do is build binaries from source > install onto a test distribution and make sure it works. Well, not exactly: there is also integration development + maintenance work, to make I2P work fine in the context of Tails. So there's Debian packaging, system integration work, and (as usual in Tails) communication with our technical writers and UX team to ensure the integration is up to our standards :) I'll let anonym follow up, since I think he has the list of the top-priority issues we want to see fixed in I2P integration before it's reintroduced into Tails. 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] Screen Reader issue tails 3.0 beta 2
Yphone: > Is this nightly build reasonably secure? Except "it's not been built in a trusted environment", it passes our automated QA (in the very same untrusted environment). 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] Screen Reader issue tails 3.0 beta 2
Justin Davis: > Awesome! Thanks for that! :) > Is there anyway that I can get a copy with the patch early, and > still get security updates for future releases? You *could* download an experimental ISO on https://nightly.tails.boum.org/build_Tails_ISO_feature-stretch/lastSuccessful/archive/build-artifacts/ but 1. it's not been built in a trusted environment; and 2. you won't get automated updates (only manual ones). ___ 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] Screen Reader issue tails 3.0 beta 2
Justin Davis: > In Tails 3.0 beta 2, the screen reader will not start in the greeter. Thanks for the report! Sorry! I've noticed and fixed this earlier today. It will be fixed in Tails 3.0~beta4, scheduled for April 18. Meanwhile, manually installing the speech-dispatcher-espeak-ng package should do the job, but of course this requires logging in and performing some operations without the screen reader first :/ ___ 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] Reproducible Builds sprint #2 report
Hi, here's a report of the second reproducible sprints that just ended. Ulrike volunteered to handle broader communication about this topic, so this report is only meant to share the news within our community. Completed = After many iterations we finally made our ISO image build reproducibly! The build environment variations we've tested include: build system clock (last month, next month; could not test next year yet), number of CPU cores, CPU brand and model, building in Vagrant or not. This implied fixing a number of things: * APT auto-removal file (#11986): patch submitted and accepted upstream, backported in Tails * Switched to the new squashfs-tools upstream, that builds SquashFS in a reproducible manner (#12032). * Various non-determinism issues in the content of the files included in our SquashFS, including fixing incorrect metadata in old blog posts and their translations (#11966 – who would have guessed this affected build determinism? :) * Various non-determinism issues in the mtimes of the files included in our SquashFS, that made not only the SquashFS non-reproducible, but also made the initrd non-reproducible despite the patches we sent upstream for initramfs-tools (#12330). * Drop the "Posted on" timestamp ikiwiki added to some pages on our website (#11987). Also: * Made diffoscope *way* faster when comparing SquashFS'es: changes made directly upstream * Improved performance of generating CA certificates databases on boot (#11971) In progress === * Review'n'merge the feature/5630-deterministic-builds branch into feature/stretch: one review happened, now blocked by a couple of the other WIP items and waiting for a second review, so it's unlikely these changes make it into 3.0~beta3, but I'm confident they'll be in 3.0~rc1 (mid-May)! * Ensure the reproducibly built ISOs pass our test suite (#11983): done for the subset of tests we run on Jenkins, left to be done for the other tests. Plus some new failures left to be investigated. * Build our IUKs reproducibly: branch ready for QA (#11974). * Avoid boot performance problems while generating the fontconfig cache: we've optimized this a bit with fancy systemd ordering, but since then one of us came up with a solution that's probably better (#11971). * Lots of progress was made to have static build environments: - Move the apt-cacher-ng data to a dedicated disk that can be shared among many Vagrant build VMs (#11979). - Create and provision a new Vagrant VM for every ISO build (#11980). - Switch our Jenkins ISO build system to vagrant-libvirt (#11972). Next steps are to make the whole thing robust enough both for developers and for our Jenkins CI environment. We expect this will be merged and deployed either very soon, or between April 19 and May 12. To be done == Not that much as far as we know! See remaining open tickets on https://labs.riseup.net/code/issues/5630. 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] [Tails-testers] Compact TAILS ISO
Hi, I'm relaying this to our development mailing list: Stuart Trusty: > I am interested in producing a minimal 360Mb .iso of TAILS that can be > written to a bootable DVD- not many utilities and programs, mostly focused > on getting online and running Electrum. > Why? I think that presently anyone with cryptocurrency on their desktops > and phones can be compromised, and that a credit card-sized TAILS that > operates Electrum wallet with a passphrase to restore wallet (instead of > USB with persistence) would be popular enough that the TAILS project could > even print some up for fund raising on the main website. > I am willing to play whatever part to help make this happen, I am pretty > good at Debian and can help in any way needed. > Thank you for your consideration, and thank you for all you do, > Stuart ___ 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] Experimenting with Tails, preferred workflow ?
Arnaud: > intrigeri: >> AFAIK, modifying the rootfs in a persistent manner will produce very weird >> results next time you boot > What do you mean ? Is it because of some security mechanism of Tails > that will detect my changes ? No. It's because some bits of the Tails startup process are not idempotent. 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] Experimenting with Tails, preferred workflow ?
Hi, Arnaud: > just pondering and wondering on the preferred way (if any) to experiment > and modify the Tails OS. I'd be happy to have Tails running in a VM and > WRITABLE, so that I can really play with it. This is really for > experimenting purpose. AFAIK, modifying the rootfs in a persistent manner will produce very weird results next time you boot, and then you won't be able to draw any serious conclusion from your experiments. I personally combine two approaches, depending on the need: * build a modified ISO image * start Tails and modify files in there (it *is* writable, but of course the modifications go to a ramdisk) 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] Debian 9: Build fails consistently, name resolution fails sooner or later
Arnaud: > I managed to build Tails, finally ! So let me share here the little > patch I ended up with, in case it can help someone. This patch deals > with the transient network problems I experienced. Thanks, applied! ___ 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] [PATCH 1/2] wiki: fix link to vagrant page
Arnaud: > Signed-off-by: Arnaud > --- > wiki/src/contribute/build/vagrant-setup.mdwn | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied, 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.
Re: [Tails-dev] Debian 9: Build fails consistently, name resolution fails sooner or later
Hi, Arnaud: > thanks for your support ! :) > However, after a lot of investigation (mostly in the wrong direction), > I'm pretty sure to know what's wrong. It's not Tails, it's not the VM, > it's not my config. It seems to be the network here in Vietnam. OK :( > From my understanding, I can change the Debian mirror used for > provisioning the VM. But when it comes to build the Tails iso, I have no > choice but to download the packages from the Tails mirror, right ? Same > goes for TorBrowser ? Exactly. > Right now I'm working on tweaking the build system, and adding retries > here and there, so that the build keeps going and doesn't give up so > easily. I think that `apt-cacher-ng` should help me to mitigate the > problem, but up to now I destroyed the VM too often to take advantage of > it ;) Sounds great! 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] Presentation slides for Tails
ghostla...@autistici.org: > There we have an alarming amount of materials. Making a request for zipped > archive > "download all" link somewhere on that page? Folder structure within the > archive would > be great. I've added a link to the Git repository on https://tails.boum.org/contribute/how/promote/material/ in the hope it helps people downloading the whole thing. 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] Debian 9: Build fails consistently, name resolution fails sooner or later
Hi Arnaud, Arnaud: > I've been trying to build a Tails image an didn't succeed yet. My > machine is running Debian 9. > As for Tails, I checked out the tag '3.0-beta1', and that's what I'm > trying to build at the moment. > So far, the build always fails sooner or later because of network > failure, and most precisely name resolution failure. A typical log looks > like that: > Err http://time-based.snapshots.deb.tails.boum.org sid Release.gpg > Could not resolve 'time-based.snapshots.deb.tails.boum.org' Please share the full build log and the exact commands you're running, so we can investigate. Thanks! 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] Adding an event to monthly report?
Austin English: > Slides are attached for anyone curious (apologies in advance for my > lack of Libreoffice skills). A pull request against https://git-tails.immerda.ch/promotion-material/ would be welcome so that your slides are listed on the Tails website :) ___ 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] [review'n'merge] March contributors meeting notes
segfault: > Hi, here are the notes of today's meeting. Please review and merge. applied, thanks! will you update the tickets accordingly in Redmine? ___ 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] [review'n'merge] Update links
xin: > Hello, I made a branch to update some links and add a missing punctuation. > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: links > Last Commit: 2dc5b83fdc843271eb60272b61467193c6979644 merged, 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.
Re: [Tails-dev] Can we make Tor Bridge configuration accessible with Orca?
Hi, Justin Davis: > I noticed the change that made Orca read Onion Circuits. Is it > possible to do the same thing to the Tor Bridges configuration to make > it readable with Orca as well? I've just had a quick look, and at first glance, indeed it seems doable to change the way we run Tor Launcher so that it is accessible, just like we did for Onion Circuits. Bonus points: it'll ease porting Tails to Wayland. anonym, if you agree: may you please file a ticket 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] [review'n'merge] december report
emma peel: > please review the December report and merge if suitable. Merged, fixed a few things on top (mostly 28c6f34 and 6700e16), pushed! 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.
Re: [Tails-dev] Persistent settings for Tails Greeter
Hi, Ru Tor: > First of all, really big thanks for your work. :) > Could you please add an option to the Tails Greeter can enter the > password from the Persistent volume and language settings applied > automatically? (And also, Root password, and may be setting bridges, > etc). I would also like to expand Persistent settings for the desktop > settings and browser settings. I believe we have Redmine tickets for all of those. Help / patches are welcome :) 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] Please upgrade to Tails 3.0~beta1 for daily usage
Dear Tails contributors, I need your help! [Sorry for exceptionally cross-posting this widely. Any reply should go to tails-test...@boum.org only.] Tails 3.0~beta1 was just published. From now on, we will provide security support for the 3.0 series, just like we do for (2.x) stable versions of Tails. It will also have automatic updates, whenever it's feasible. Tempting, uh? According to our automated test suite, this first beta release works pretty well :) This test suite reasonably ensures that this version is safe to use, but no doubt there are some undiscovered issues left. The usual narrative, that we've seen e.g. for the upgrades to Wheezy and Jessie, is the following. Exploratory testing will find some of these issues; but it will also miss a number of problems, that will make their way into 3.0, and will only be discovered once Tails 3.0 is out… as soon as enough people start using it every day. This kind of works, but frankly I've found this quite frustrating in the past. So I propose that we change this narrative a bit this time, and try to do better: how about we, Tails contributors, start using the 3.0 series for our daily usage *now*? I'm upgrading my Tails systems today. See you on https://tails.boum.org/news/test_3.0-beta1/ :) 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] Fwd: Did OS Tails have wpa_supplicant ?( today wpa* default for ubuntu, suse, w10 in Germany)
Hi! I don't understand why this was forwarded to the mailing list for Tails development. I'm pretty sure our help desk people are perfectly able to answer these two questions. I see you've already written them, so be patient and wait for their answers :) 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] suggestion for new tool
Hi, swi...@sigaint.org: > I like to listen to music while I work with TAILS, but none of the > included tools allows you to play music with mp4 extensions, or create > playlists. Include software for this purpose? Wrt. mp4: sadly, the extension doesn't mean much (it's just a container format). Can you please point us to a file online that the GNOME music/video player cannot play, so we can investigate what's going on? Wrt. playlist: music readers is an area where everyone has their preferred tool, and it's impossible to find a one-size-fits-all tool. So I would recommend installing the one you personally like: https://tails.boum.org/doc/advanced_topics/additional_software/ 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] Set coin selection to "privacy" by default in Electrum
Hi, Michael English: >> Still, this doesn't answer my question of why the setting called >> 'privacy' "helps to reduce blockchain UTXO". I would love to >> understand, if someone is kind enough to explain it to me. > I will try to explain to you what I think Electrum meant by reducing UTXO > bloat. I am > not a good teacher, but I hope that this helps. Thanks *a lot* for taking the time to explain :) > Honestly, reducing UTXO bloat depends on the circumstance. I will explain a > few > circumstances below. The UTXO set is most likely to be reduced by the > "privacy" > setting in a circumstance where one address has received three or more inputs. > There are three cases for transaction inputs and outputs: > 1. Find exact change > 1. This case is very unlikely unless transaction creation is hand >optimized. For example, let's say that I want to donate 0.01 BTC >to Tails ;) and I find that I have a UTXO of 0.012 BTC. I could >decide to spend the extra 0.002 BTC to protect my privacy and >save a small amount on transaction fees. In this case, the UTXO >set is not changed since there is one input and one output. ACK. Of course, this is less unlikely if one considers unspent outputs that are held by *all* addresses in a wallet, but it's still unlikely and that's a detail. > 2. Use Electrum's "priority" coin selection that uses older and >larger value UTXO first > 1. This case is likely to use a single large value UTXO and produce >two outputs since one output has to be the change. The extra >output created by this transaction could be considered "bloat." Sure. And assuming it works exactly like that, on the long term this contributes to ending up with tons of small unspent outputs that will be hard to use without spending substantial fees, unless manually combined with other, older/larger ones (been there, done that, not exactly my cup of tea). I have to say I'm a bit surprised that the algorithm works this way. I find it a bit simplistic, but really I'm not pretending it would be easy, or even doable, to make it better. From my (relatively newbie) perspective, I would have expected that it would balance these two factors with trying to 1. find exact change; 2. add tiny unspent outputs to the transaction to optimize *future* fees and benefit from the small fee required by the other, older/larger ones to avoid increasing the fees for the transaction being constructed too much. If the algorithm worked the way I would have naively expected, then looking at unspent outputs held by *all* addresses would help with reducing fees and UTXO bloat (compared to looking at only one address), not only for the transaction that's being constructed, but more importantly on the long run. > 3. Use Electrum's "privacy" coin selection that prioritizes the >number of UTXO in an address (and also optimizes change which we are >trying to avoid) > 1. This case takes several medium to small value UTXO and combines >them into two outputs. If the number of inputs are three or >more, then this could be considered reducing UTXO bloat. ACK. Thanks again for teaching me and fixing my naive expectations! 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] Set coin selection to "privacy" by default in Electrum
anonym: > I just spent an hour reading: […] Thanks for diving into it. > First, let me say that I absolutely do not want this feature documented for > end-users. I'm not sure how this could be explained in less a way so a user > could > make an informed decision without using thousands of words (with a thousand > possibilities to misunderstand). So, yeah, either we enable this by default > in Tails, > or we completely ignore it. Fully agreed! > Second, now I understand this feature better, and I feel quite convinced that > it > makes sense for Tails: we can take a selfish stance were we don't care about > the > potential negative effects this can have on the network and blockchain bloat; > then > only other drawback is potential increase of transaction fees, but that seems > like > a negligible effect to me. So, I say: let's do it! Works for me. 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] Set coin selection to "privacy" by default in Electrum
Hi, s7r: > intrigeri wrote: > The text was copied from Electrum man page. Thank you! > UTXO's are basically the coins you can spend. The spendable coins are in > UTXO's, not in addresses. Addresses are just a smart crypto way to let > the world know in advance who has the right to spend a given UTXO. > Existing unspent outputs cannot be reused, they are burned and re-crated > entirely every time. So you cannot spend part of a UTXO, you spend it > all (practice does not recommend re-using addresses - it's true nothing > keeps you from receiving the change in the same initial address that you > spent from, but you'll have a different UTXO). Yes, I had to learn all that last week already, but thanks anyway :) Still, this doesn't answer my question of why the setting called 'privacy' "helps to reduce blockchain UTXO". I would love to understand, if someone is kind enough to explain it to me. >>> Routing transaction relay through Tor is only part of the solution. The >>> blockchain is >>> a public ledger that can be analyzed anytime after the initial transaction >>> broadcast. >>> Private coin selection impedes correlation of transaction inputs and >>> outputs that >>> could link back to an identity. >> >> Sure. I hope our doc clearly states that it's very hard to use Bitcoin >> in a privacy-preserving way, for some various value of "privacy". > Agreed, but the setting indicated by Michael could be shipped as a > default imho. It makes sense in a context like Tails/Tor threat model. Sorry if I was unclear: I'm not arguing this point. I didn't look into it in details, so I am really not in a position to have opinion about it yet. It's clear to me that there's no way to optimize coin selection for all possible desired outcomes (e.g. optimizing the blockchain itself, optimizing usage of unspent outputs i.e. not wasting money via fees on the long term, optimizing some kind of privacy on the short term), but it's not obvious to me which way Tails should lean towards: at this point I have no idea if the (limited) privacy benefits brought by this feature outweigh the drawbacks it brings in other areas. Anyway: I personally don't feel responsible for maintaining the Electrum integration in Tails, would rather not to become more involved into it, and will therefore let its maintainer (i.e. anonym) make the call. But I'm genuinely curious about the unspent outputs optimization claim; I bet my intuition is wrong, and I'll learn something along the way :) 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] Set coin selection to "privacy" by default in Electrum
Hi Michael, Michael English: > It also helps to reduce blockchain UTXO (unspent transaction > outputs) bloat, This makes me curious. How does this help with that property, exactly? My intuition tells me that by restricting the set of coins that can be spent to one single address, on the contrary, the software has fewer possibilities to optimize towards 1. reusing existing unspent outputs; and thus 2. avoiding to create more. Also: where was this text quoted from? > Routing transaction relay through Tor is only part of the solution. The > blockchain is > a public ledger that can be analyzed anytime after the initial transaction > broadcast. > Private coin selection impedes correlation of transaction inputs and outputs > that > could link back to an identity. Sure. I hope our doc clearly states that it's very hard to use Bitcoin in a privacy-preserving way, for some various value of "privacy". 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] [review'n'merge] january contributors meeting - notes
emma peel: > here the notes for the monthly meeting, sorry for the delay! merged, 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.
Re: [Tails-dev] What is *not* erased (after shutdown) with PAX_MEMORY_SANITIZE enabled?
Hi everybody! Harlan Lieberman-Berg: > Thanks for weighing in, PaX Team. (And thank you for the awesome you > and spender do on kernel security!) +1 :) > To summarize, it seems that we have a couple different options to choose > from: > * Switch to a dedicated microkernel that does a memory wipe, and kexec > into it. This could be something custom, or an enhancement of the > preexisting solution. > Advantages are that it will (probably) give us the most clean wipe, as > we can reduce the amount of space the kernel takes up and drop all > functionality that's not absolutely needed. On the negative side, it > will require continuing to support a separate codeline that's not > going to be reused elsewhere, limiting testing and development > effort. It also requires us to reenable kexec functionality, which > exposes a risk of code injection unless we get signed kexec support. > * Rely on PAX_MEMORY_SANITIZE. This either takes the form of enhancing > cleaning memory on shutdown, or kexec'ing into the same version of the > kernel that's already running to rely on the buddy allocator clearing > everything again. > Definite pro in that it reduces the amount of code maintained > downstream by the Tails team to ~zero. Cons are increased reliance on > more complex functionality in the kernel, and potentially relying on a > somewhat undocumented and unplanned functionality in the kernel. (It > seems unlikely that it'll change any time without us noticing, but > it's possible.) > * Do it in userspace. Add functionality into the initramfs as > necessary to wipe memory, and simply run an abbreviated shutdown. > This lets us not have to deal with the potential for kexec's attack > surface, and is probably some medium amount of code between the above > two options. Downside is that it potentially is less reliable in > terms of clearing memory than the other options, and is probably > slower time-to-first-bit-erased than the other options. > Does that seem like a fair summary to everyone? It does seem like it to me. > If so, which path seems the best for us to move forward on? I prefer the two first options (mostly because the third one is essentially what we're already doing, and are trying to improve/replace). Not sure which one of those two yet, but the next thing to do in both cases is the same: make it possible to allow kexec without disabling GRKERNSEC_KMEM entirely. I don't know what configuration interface would be best: move kexec disabling out of GRKERNSEC_KMEM, to another kernel build-time config setting? Leave it as part of GRKERNSEC_KMEM, but add a sysctl to allow re-enabling kexec at runtime? pipacs, spender: what do you think? 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] [review'n'merge] Fix typo in news
xin: > Hello, I found a typo in the last news. > Repo: https://git-tails.immerda.ch/xin/tails/ > Branch: typo > Last Commit: 4ce842dbff05e7a3304b1c423dd649663cec9abd Good catch! Merged, 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.
Re: [Tails-dev] [Tails-testers] Request for JavaFX on Tails 3.0
Hi, [moving this discussion to tails-dev@] Collin Sullivan: > On 1/7/17 1:32 AM, intrigeri wrote: >> I'll assume that the package Martus needs is either libopenjfx-java >> or libopenjfx-jni. > I'll need to confirm with some of the devs on my side. When we were > experimenting with custom Tails builds that included Martus (where we > did make some progress but ultimately didn't end up making a fully > workable build), we included openjfx, libopenjfx-java and > libopenjfx-jni. I don't know if all of them were necessary, and don't > remember how large the resulting ISO was -- will look into that. OK, please let us know once you have the exact list of dependencies missing in Tails. I suggest you look into this using a Tails experimental ISO based on Debian Stretch: https://nightly.tails.boum.org/build_Tails_ISO_feature-stretch/lastSuccessful/archive/build-artifacts/ > You can look at the project here and see the other packages we > included while testing: https://github.com/benetech/mtails/ Interesting. For those who want to follow along at home: that script "remasters" a released Tails ISO to add some packages and Martus itself. Collin, if you folks ever come back to that script: you'll need to ensure you set a custom TAILS_PRODUCT_NAME in /etc/os-release, otherwise users of that Tails derivative will be proposed to install automatic Tails updates, which will make their system behave in undefined ways. Also, note that the way that script downloads .deb's is not safer than the network link to the Debian mirror being used, i.e. generally plaintext HTTP; I would not do that. And finally, our documentation for derivatives might be interesting to you: https://tails.boum.org/contribute/derivatives/ >> This seems to be exactly the kind of use cases for which we've >> created the Additional Software Packages feature. So I'm curious: >> >> 1. Assuming we would ship the requested package by default: what's >> the Martus setup process? Feel free to point me to you current >> end-users documentation, I'll be happy to read it myself. [...] > In short, though, if you were to ship the requested packages by > default, I assume the setup process would be something like: > 1. Visit Martus.org, download the latest version of Martus for Linux > (.zip file) to your Persistent folder and unarchive. > 2. Either use a Terminal to cd into the Martus folder and run a > certain command (which specifies Martus use the system Tor, saves all > records in a Persistent subfolder, etc.); or run an executable text > file including the command. > This is off the top of my head but I believe that would be about it. > Right now there are many more steps, including installing a non-system > (and non-libre :P ) Java to the Persistent folder and pointing the > Martus jar to that, which causes a lot of pain for users. OK, so if we included Martus dependencies (or once we have a GUI for managing additional software), the setup would be simplified, but it would still not be straightforward. This is what I wanted to understand. Thanks! >> 2. What are the blockers for you folks to use the Additional >> Software Packages feature to ensure the requested package is >> installed in Tails? > Good questions. There are a couple of things: > 1) Our ultimate goal is to make the process of using Martus on Tails > as easy as possible for our users. They tend to be somewhat > intimidated by Tails as it is. Long lists of steps, including steps > about installing additional packages, give them lots of opportunity to > quit during setup, lots of ways things can go wrong, etc. We want to > minimize frustration as much as possible. Sure. > 2) I could look again, but the libraries we need (I think) were not > available in the Tails default repositories, so we needed to add new > ones. That's another step for the user. I expect this might have been fixed with Tails 2.x, or will be in 3.x. But you may want to double-check :) > 3) The less our partners/users need to use root / su / sudo, the > better. Both for security and ease of use. Absolutely, especially if command line is involved. This drawback will be alleviated once there's a GUI to configure additional software (I'm pretty sure it'll still require an administration password for the initial setup, but at least there will be fewer steps that require command line usage, and they will be required by your custom stuff rather than by Tails limitations). 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] Heads up: upgrade your Vagrant build setup
anonym: > The Vagrant basebox has been updated, and apparently Vagrant won't > switch to it automatically. To completely delete the old builder VM and > basebox, please run these commands from Tails' Git root: FWIW I've personally kept the old one around, since branches based on stable are supposed to be built with it (I think). So I just did: rm -rf vagrant/.vagrant/ … in my checkout of the devel branch. ___ 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] Hey from Dash
hi, Dash Press: > my ‘source’ mentions that you are working on Dash with Tails implementation I'm sorry I don't understand what do you mean here :/ Care to rephrase or clarify? > can you please provide me any details / updates about that ? Certainly, once I've understood the question :) ___ 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] Memory Erasure Development
Harlan Lieberman-Berg: > Currently, I have a mostly-working prototype, but I'm not particularly > happy with the performance; it needs some more attention. Thanks for the update! >> However, we're looking into shipping a kernel with the grsecurity >> patch, and sadly, the GRKERNSEC_KMEM feature removes support for >> kexec. That feature is enabled in the Debian grsec kernels, and can't >> be disabled at runtime if compiled in. Any thoughts about this? > My prototype right now is itself a kernel that would need to be kexec'ed > into on shutdown, or started from grub. Instead of doing a kexec, you > could theoretically ACPI reboot the machine and work out a way of > signalling GRUB to boot the kernel, but that would cause you to pass > through the initialization procedures for the machine -- which is going > to be slow. Doesn't feel good enough, indeed. I seem to remember that EFI provides functionality to reboot directly into another OS without going through system initialization, but even if I was not dreaming 1. we still want to support legacy boot systems; 2. I doubt firmware & hardware vendors have bothered implementing and QA'ing it for the cheap laptop I can buy at the supermarket. > The security benefits to GRKERNSEC_KMEM seem pretty clear to me. I > suppose we could try to migrate the functionality we need into the > kernel itself and expose a custom syscall to trip the wipe off. That > would get around the kexec problem, but it would mean the prototype > would need to be completely redone (not a huge deal). This would at least be robust: the kernel knows how much it can wipe without killing its own ability to power off the machine afterwards. But maybe it's not worth the effort (that you evaluate as more than non-trivial below), because: > The separation in kernels was intentional; that way, we wouldn't > have to worry about what > structures might be keeping around infomation we wanted to wipe without > worrying about panic'ing the kernel we were running in. Agreed. Not having to worry about the memory that was in use by the previously kernel (e.g. tmpfs) is a key benefit of the kexec approach. While with the "add the functionality to the kernel itself" approach, the kernel needs to free the parts of its memory that can contain sensitive data (I suppose that's a long list and not always doable) before it can wipe free memory in a useful way. > We could also try and shim into the kernel the ability to kexec into > this wiping-kernel, […] I don't know how > much work that would be; my guess is a non-trivial amount, […] I doubt this has a chance to ever reach mainline, and I'm not looking forward to maintaining our own kernel, so unless it can be done as an out-of-tree module, I'd say let's not go this way. Now, taking a step back, I wonder: why does why GRKERNSEC_KMEM disables kexec? Is it because it's deemed dangerous in itself? Then perhaps it's be worth asking grsec people if they'd be open to controlling the kexec part with a more atomic setting. Or because it's broken by other protections brought by this feature? If it is so, how hard would it be to fix that? Two other random ideas, nothing too convincing but perhaps worth mentioning (it's not as if our current implementation was perfect, so let's aim for something that works with grsec even if it's not perfect either): * Extend PAX_MEMORY_WIPE to also erase the areas of the memory it currently leaves alone, and we care about, when they're freed; this buys much only a little, since it doesn't do anything about the memory still in use by the kernel; but perhaps it makes the result just as good as what we currently have, while improving robustness, UX and speed of emergency shutdown drastically. * Keep our current userspace approach, but run it using systemd + dracut's "go back to initramfs during shutdown" feature instead of kexec; we may erase a bit less RAM than currently (bonus from PAX_MEMORY_WIPE minus memory used by the kernel), but it would be compatible with kexec, and possibly more robust than the current initramfs-tools implementation. 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] Memory Erasure Development
Hi! Harlan Lieberman-Berg: > intrigeri writes: >> No: Tails 3.0 (based on Debian Stretch) will be x86_64 only. > Awesome! I've got one or two more bugs to crush, and I need to get > final sign-off from my employer, but I'll reach out wiht the results of > testing once I have all the ducks in a row. What's the current status? Our current implementation is working less well since we upgraded Linux to 4.x, and apparently even worse on our Debian Stretch -based ISOs: memory wipe works fine, but something weird happens in the initramfs that breaks shutdown. So a more robust replacement would be warmly welcome :) However, we're looking into shipping a kernel with the grsecurity patch, and sadly, the GRKERNSEC_KMEM feature removes support for kexec. That feature is enabled in the Debian grsec kernels, and can't be disabled at runtime if compiled in. Any thoughts 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.
[Tails-dev] What is *not* erased (after shutdown) with PAX_MEMORY_SANITIZE enabled?
Hi!
I'm working on Tails (https://tails.boum.org/).
Our threat model includes "someone breaks the door and you have 15
seconds to make your current Tails activity disappear". We assume that
this "someone" may be prepared to try and recover the memory of this
Tails system, e.g. via a cold boot attack.
I'm describing at the bottom of this email our current protection
against this scenario ("Current Tails implementation" section), in
case you're interested in more background; but for now I'll jump
directly to the questions I have for you.
We're considering dropping our current implementation, and relying on
PAX_MEMORY_SANITIZE instead; I know that PAX_MEMORY_SANITIZE was not
designed for this use case, but who knows: it might be good enough :)
I understand that the result won't achieve perfect protection, but our
current implementation doesn't either. I'd like to see numbers, but
it's hard for me to compare experimentally both approaches: our QA
about this relies on filling memory with a known pattern from
userspace, which works fine to measure the efficiency of our current
implementation, but of course PAX_MEMORY_SANITIZE will erase this
known pattern from memory… So for now I'll stick to the theoretical
level, and experimental measurements will come later.
If I got it right, with PAX_MEMORY_SANITIZE enabled, then:
* during the lifetime of a system, any memory allocated to
a userspace program that terminates is erased;
* during the lifetime of a system, any kernel memory that's
explicitly freed, e.g. with kfree(), is erased;
* on system shutdown, all processes are killed, and thus their memory
is erased.
So, what remains after system shutdown boils down to:
* kernel memory allocated and then freed, during the lifetime of the
system, through means that are not covered by PAX_MEMORY_SANITIZE:
is there any such thing? I'm interested in a (possibly incomplete)
list of these memory areas or allocation methods.
* kernel memory, that was still in use during shutdown, and that the
kernel does not explicitly free: again, is there any such thing?
* anything else?
I'm not a low-level person myself, so I'm happy to stand corrected,
and I'll probably need help from my team-mates (Cc'ed) to analyze your
answers :)
Current Tails implementation
Our current protection against this scenario is: when I unplug my
Tails USB stick, an emergency shutdown procedure is triggered, that
kexec's another kernel with some special command line parameter, and
then the initramfs erases all the memory that's available from
userspace. This ensures that even the memory that was kept in use by
the previous kernel (e.g. data in tmpfs) is overwritten at least once:
either by the new kernel re-using the same memory, or by the userspace
memory wipe process. Of course, some memory will still remain
unmodified, e.g. whatever data the kernel may have put aside out of
userspace's reach, without overwriting it. E.g. in our tests, a few
dozens of MiB are not erased by this process on a machine with 8 GiB
of RAM. Implementation details are documented there:
https://tails.boum.org/contribute/design/memory_erasure/
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] Debian derivatives census: activity ping: 2017
Paul Wise: > It would be great if you could bring your census page into sync with > the template and fill in as many of the fields as you have data for. Done earlier today. ___ 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] Suggestion to hep with exploit mitigation...
Tails: > What means, first to enhance QEMU. In general (without ARM and QEMU) > this is - as far as I understood - the idea of the QubeOS. Right. The biggest challenge here is integrating the isolation by virtualization without harming user experience too much. If/once we have that, using x86 or ARM virtual machines might be a detail. We have no clear long-term plans wrt. isolation by virtualization. This topic raises many questions, for example because I doubt we'll want to raise hardware requirements significantly, so requiring VT-x and/or VT-d is probably a non-starter for the primary use cases supported by Tails. We're in the process of organizing a meeting with Qubes OS, Whonix and Subgraph; my personal top priority there will be to discuss this very topic, and get a better idea of what we could do, how, and when. 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] Tails 3.0: current status & next steps
intrigeri: > * January 30 - Febuary 3: fourth sprint (remotely attended) I forgot: at the end of the January sprint, I want to release a Stretch based Tails 3.0 beta, that is safe and good enough for every Tails contributor to use in production until 3.0 final is out. I'll commit to keep it as up-to-date wrt. security vulnerabilities as our 2.x release branch is. That is, I'll release an updated beta every time we release a new Tails 2.x. There will be automatic, incremental upgrades. 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] Tails 3.0: current status & next steps
Hi! here's a report, status update, and some planning information about porting Tails to Debian Stretch. December sprint === We've had a great sprint last week about porting Tails to Debian Stretch. Most of our time was spent integrating the new Greeter (fixing the last known blockers, adjusting the test suite). Quite some time was also spent in other areas, mostly bug fixing, polishing, and updating the test suite. The complete list of what was worked on can be found there: https://labs.riseup.net/code/projects/tails/issues?c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=category&c%5B%5D=cf_15&c%5B%5D=assigned_to&c%5B%5D=cf_9&c%5B%5D=updated_on&c%5B%5D=status&f%5B%5D=fixed_version_id&f%5B%5D=updated_on&f%5B%5D=&group_by=&op%5Bfixed_version_id%5D=%3D&op%5Bupdated_on%5D=%3E%3C&set_filter=1&sort=status%2Cupdated_on%3Adesc%2Cpriority%3Adesc&utf8=%E2%9C%93&v%5Bfixed_version_id%5D%5B%5D=278&v%5Bupdated_on%5D%5B%5D=2016-12-19&v%5Bupdated_on%5D%5B%5D=2016-12-25 Schedule The next items on the schedule are: * January 30 - Febuary 3: fourth sprint (remotely attended) * February 5 2017 — Debian Stretch freeze starts * March 17-19th: fifth sprint (in-person) * June 2017 (???) — Debian Stretch is released * June-August 2017 — Tails 3.0 is released (June 13 seems realistic at this point, but it depends a lot on how much energy we can collectively put in the next two sprints) This schedule is kept up-to-date on the blueprint: https://tails.boum.org/blueprint/Debian_Stretch/#schedule What's left to do, and how can I help? == Here's how I see the big picture: * Finish updating the automated test suite, in order to identify more regressions ASAP. I did most of the trivial bits I could, so there's not much room left for helping unless you're anonym… who will likely focus on this during the January sprint. * Update the documentation. A list of what needs to be updated was created, some of the doc was updated already, quite some work remains to do. If you want to help, get in touch with spriver and sajolida. * Some small software development tasks in JavaScript (Torbirdy, GNOME Shell extensions), Python (Greeter), and Perl (OpenPGP Applet). It would be awesome to spread this work over more shoulders, talk to me & anonym if you're interested. * Some Tails-specific "glue" development and design decisions (e.g. shall we switch to using NetworkManager's MAC address spoofing feature?); I expect anonym and I will take care of this. Complete list of tickets: https://labs.riseup.net/code/projects/tails/issues?query_id=198 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] Fwd: Issues
Forwarding to our support mailing list: --- Begin Message --- On Sun, Dec 25, 2016 at 5:20 PM, Lucas Gelf wrote: > Hi TAILS, > I'm attempting to create a dual-partition flash drive, 8GB for TAILS and > the rest for my own personal files for my keychain. It's a 64GB Kingston > DataTraveler USB3.0. I've got two FAT32 partitions on it already. > > I'm on a Mac. Today, I downloaded the ISO (2.9.1), checked it with > OpenPGP, and installed it on the USB drive. I followed all of the > instructions and with minor hiccups, got the transfer to finish. My Mac > (Early 2015 Macbook Air) didn't recognize the interim drive (Kingston > DataTraveler SE9 16GB) even after I installed rEFInd. > > I looked around the internet and ended up buying (not FOSS :() Mac Linux > USB Loader <https://www.sevenbits.io/mlul/> based on a forum user's > advice. I installed the ISO on the USB drive and managed to boot with it. > > I booted into TAILS without incident, but upon attempting to clone the > drive to the next drive, I had no luck. Every time I clicked, nothing > happened. I've attached a video. > > I then downloaded VirtualBox, the VirtualBox Extension Pack, and installed > TAILS in a VM. I passed the USB in and successfully installed TAILS on it. > It did make me clear my partition and BT/WiFi both didn't work. I'll likely > buy one of the Penguin RYF WiFi adapters. That being said: > > Is my live USB via VirtualBox alright? > > How can I partition my drive so that most of it is for my files and only > part of it (4-8GB) is a live USB? Will it work? > > Do you know why any of my problems happened? > > Thanks so much! You guys seem to make a great software package. > > Lucas > > > > > ___ 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.--- End Message --- -- 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] HTTP sniffer soon ?
Hi, Nikito: > It could be great to have some HTTP sniffer integrated in Tails. Does > the idea come in mind before ? It would be useful to people who have > very low Internet bitrate and want to read a whole website offline. I recommend using httrack. It has a graphical interface (httraqt) that I never tested. IMO this feature would be used by very few people, so: https://tails.boum.org/doc/advanced_topics/additional_software/ 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] Proposal: new Tails version scheme and RM optimizations
Hi,
anonym:
> Proposal 1: let's adopt a skip-free versioning scheme
> -
> [...]
At first glance I like this one. I don't feel like re-reading the
thread we had last year about the same topic to refresh my memories of
what trade-offs we did when we picked our current versioning scheme,
and why. If both you and sajolida like the new proposed one, I'm sure
it's good and I trust you :)
> Proposal 2: simplify the QA of emergency releases
> -
> [No dependencies. And unlike all other proposals, I'd like to implement
> this one *now*.]
> [Background: with our current branch organization and workflow, we will
> ship all bugfixes that have been merged since the last release in
> emergency releases. Even though they have been reviewed, it's not
> uncommon that issues are detected during the manual test session.]
> True emergency releases are not prepared from the 'stable' branch but
> instead we prepare them in a new branch we could call 'security'. This
> way we can remain even more conservative with new code for emergency
> releases, making the QA way easier. So when merging a branch we'd merge
> it into 'security' only if:
> * it is a security fix triggering an emergency release.
> * it is a security fix that is not important enough for triggering an
> emergency release by themselves, but that still would be nice to have
> out ASAP.
OK.
> Note that "security fix" includes UX regressions since they imply bad
> usability, and usability is just one of many aspects of a holistic
> security perspective (Kumbaya!).
> As the (Mostly) Eternal Release Manager, who has experienced quite a few
> emergency releases by now, less QA at those times would be ${deity}sent.
> In fact, if we could formalize the practice of comparing the new ISO
> with the last release [1], and make that + manual tests of only
> upgraded/modified software + a full pass of the complete automated test
> suite all the QA we require, then emergency releases would be a single
> days work for an RM and no one else is blocking the release.
I agree with manually testing only the affected areas by comparing
ISOs. In practice, I doubt we can do this in a way that's both enough
of a time-saver, and doesn't let us overlook important changes, before
we have reproducible builds. So until we do have reproducible builds,
I would like us to keep doing the full manual test suite even for
emergency releases, if we can.
> Except the
> "Changes" section of the manual test suite, which must be done by
> someone else than the RM. I think we can allow the review to happen up
> to a few days after the emergency release was made public. If you
> disagree, well, this is what has already happened to us a couple of
> times (e.g. both 2.9 and 2.9.1 :)) so if we enforced your wish that
> means we sometimes will stall security fixes in fear of *potential*
> security issues [2] ... which feels wrong.
Agreed. Anyone who wants to raise the bar here should be prepared to
throw some work hours into it, on a regular (and unplanned) basis,
in order to make it happen.
> Proposal 3: treat X.esr as just another emergency release
> -
[...]
> The only real drawback I see with this is that low-prio bugfixes will
> take a longer time to reach users, since we won't ship those in X.esr
> releases any more.
That sounds like a possibly important problem to me, but that's
perhaps because I'm not quite sure what exact bug fixes would qualify
for inclusion in these releases. I've seen your proposed definition
above, but it would help me understand better if you gave examples of,
say, 3 bug fixes we have included in previous point releases, that
would satisfy the new criterion, and 3 bug fixes we have included in
previous point releases, that would *not* satisfy it. Please? :)
> Proposal 4: drop the 'devel' branch and use 'master' for development
>
> [Depends on Proposal 3.]
> While we are going crazy and retiring 'stable', why not retire 'devel'
> as well, and make 'master' the actual development + live website branch?
One problem with this is that we won't be able to merge the live
website branch into our other release branches (e.g. 'security' and
'testing') anymore, since its history will include changes that are
not suitable for those branches. This implies that any change done on
the live website branch since the last release, such as translation
updates, won't be included in the copy of the website we ship in the
ISO. This sounds like a blocker, no?
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] Retroshare is available for Debian
Hi, jurgenwi...@telfort.nl: > I, with many others, would love to use Retroshare over Tor. > Since, as far as I know, it is one of, if not, the best privacy solution > available. (See: http://secushare.org/comparison) > On the Tails website I find that Retroshare is not in Tails because > it is not available for Debian. Right, it's not in Debian. If it were, then you could easily use it with the Additional Software Packages feature. > However, when I visit the Retroshare website > (http://retroshare.net/downloads.html) > I find stable downloads for Retroshare on Debian. Right, they offer third-party packages for Debian. For many reasons we pull packages from Debian, not from upstream third-party APT repositories. Still, if you are fine with trusting and using these third-party packages, then the "Configuring additional APT repositories" section on https://tails.boum.org/doc/advanced_topics/additional_software/ might fit your needs :) 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] Tor Browser 6.0.8 could need some testing
intrigeri: > Georg Koppen: >>* Bug 20809: Use non-/html search engine URL for DuckDuckGo search >> plugins > @anonym: please check if this affects Tails#11913 :) Forget it, your branch already takes this into 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.
