Re: [Tails-dev] problem with downloading tails
On 19/04/2024 04.02, Dillon Arlo via Tails-dev wrote: Hi goats, Hey! Note that this is not a support forum, but for Tails development. However, I will respond any way in hopes of you aiding us on this front. If what I propose below doesn't work, please use our normal support channels: https://tails.net/support/ Just a FYI that there seems to be issues flashing to the drive with BalenaEtcher from windows. I tried with about 5 different UBS - some of different sizes and make. I tried to use different USB slots. Then I tried using a different computer. Same results always. The flash fails right at the end. The USB installs Tails partially (you can't use the USB anymore) but can't run it. First of all, let's make sure your Tails image is ok. tails-amd64-6.1.img should be exactly 1433403392 bytes to start with, but if the download was corrupted you could probably also experience the type of issue you reported. So please first verify your Tails .img file: https://tails.net/install/download/#verify We are considering alternatives to BalenaEtcher, so could you please try USB Imager? Depending on the operating system you want to install Tails *from*, pick one of these: * Windows: https://gitlab.com/bztsrc/usbimager/-/raw/binaries/usbimager_1.0.10_wo-i686-win-gdi-phy.zip * MacOS: https://gitlab.com/bztsrc/usbimager/raw/binaries/usbimager_1.0.10-intel-macosx-cocoa.zip * Debian/Ubuntu Linux or similar: https://gitlab.com/bztsrc/usbimager/raw/binaries/usbimager_1.0.10_wo-amd64.deb * Other Linux: https://gitlab.com/bztsrc/usbimager/raw/binaries/usbimager_1.0.10_wo-x86_64-linux-x11.zip Please report back here how it went, and which versions of the above you tested! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)
On 13/04/2024 13.55, NoisyCoil via Tails-dev wrote: It looks like fixing uBlock is quite trivial, actually, so I did it myself. When an upstream patch becomes available I will revert my changes and apply that instead. Why not submit your changes in a merge request to upstream? :) ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)
On 29/03/2024 20.53, NoisyCoil via Tails-dev wrote: en passing, to whoever caused the 6.1 retagging fuzz, I lost a full day of testing work because of that, I hate you. Kidding <3 Actually this happens every single release, where there is a ~1 hour window where you can fetch this to-be-overwritten tag. We know this isn't ideal, and have been lazy about fixing this for years, but I just filed an issue describing a pretty simple fix that I think we can put in use for Tails 6.2: https://gitlab.tails.boum.org/tails/tails/-/issues/20314 Sorry for the inconvenience! <3 ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 6.2
On 27/03/2024 12.18, groente via Tails-dev wrote: Hi, Anonym will be the RM for Tails 6.2 That is me! :) The current plan is: - Monday, April 22nd: build images, start testing - Tuesday, April 23rd: releasing @testers, please let the RM know how much time you'll have for manual QA from Monday 17:00 to Tuesday 11:00 (Europe/Berlin) The code freeze starts on Mon Apr 22 06:00:00 UTC 2024, and will end once the release is public. During the code freeze, please do not merge anything into the `stable` branch unless I have agreed to it! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 6.1
Hi, We have no yet decided who will be the RM for Tails 6.1. The current plan is: - Monday, 2024-03-25: build images, start testing - Tuesday, 2024-03-26: releasing @testers, please let the RM know how much time you'll have for manual QA from Monday 17:00 to Tuesday 11:00 (Europe/Berlin)! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 6.0
On 30/01/2024 12.28, boyska wrote: Hi, We still don't know who will be the RM for Tails 6.0 I will be the RM for Tails 6.0. The current plan is: - Monday, February 26: build images, start testing - Tuesday, February 27: releasing @testers, please let the RM know how much time you'll have for manual QA from Monday 17:00 to Tuesday 11:00 (Europe/Berlin) The above information is still true. The code freeze starts on Mon Feb 26 06:00:00 UTC 2024, and will end once the release is public. During the code freeze, please do not merge anything into the `testing` branch unless I have agreed to it! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Pip is not torified by default
On 06/02/2024 19.02, sajolida wrote: Stored for now in https://gitlab.tails.boum.org/tails/tails/-/issues/19320. I think David was mostly referring to the importance of documenting how users can add any custom persistence features themselves. I'm wondering why we don't support this in the GUI yet. We rejected a ticket about that [0] 10 years ago for reasons I doubt are valid still so I opened a new issue [1] where we can discuss this. Cheers! [0] https://gitlab.tails.boum.org/tails/tails/-/issues/5383 [1] https://gitlab.tails.boum.org/tails/tails/-/issues/20184 David A. Wheeler: On Feb 1, 2024, at 5:25 AM, anonym wrote: But, as already shown above, Tails allows you to customize it extensively through the persistence feature. The Additional Software persistence feature [3] allows you to keep any package from Debian installed and up-to-date, so just install python3-pip and the other tools you like that way. [3] https://tails.net/doc/persistent_storage/additional_software/ A persistent storage feature for user installed python packages could also be designed to be a hook that adds the appropriate corresponding .local folders to the persistence.conf upon activation of the feature. It is not a documented feature any more (I think because of bugs like #19267) but you can also make any folder persistent yourself. Start Tails with an administration password, login, start a Root Terminal. This makes ~/.local persistent: echo '/home/amnesia/.local source=dot-local' \ >> /live/persistence/TailsData_unlocked/persistence.conf You can do this multiple times, so this also makes the pip cache persistent: echo '/home/amnesia/.cache/pip source=pip-cache' \ >> /live/persistence/TailsData_unlocked/persistence.conf The `source=pip-cache` part means that the data will be stored on the persistent storage in `/live/persistence/TailsData_unlocked/pip-cache`, so just make sure to never re-use the same source as any other line in that file. You must restart Tails for lines added like this to take effect. I strongly recommend *documenting* this capability (e.g., in "additional software"). There's no way this group can directly support all special needs, but documenting how people can self-help would be really valuable. A few specific examples of common cases (I'd put pip in that category) would be especially helpful. --- David A. Wheeler ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] FWD: Re: Tails for arm64 (with support for Apple Silicon)
Hi, First of all, very impressive work! Damn! On 21/01/2024 23.04, NoisyCoil via Tails-dev wrote: In principle, making a universal arm64 image could be possible, but asides from the firmware (storing different firmware for different platforms on the same image may be feasible), the software and drivers may need different tweaks for different platforms. Quite a few Debian-based distros are providing different arm images for different platforms. When we looked into Tails on ARM [0] around 2017 what I quoted above was what at least made me give up. For instance, the Chromebook [1] I was experimenting with needed specific kernel patches (that IIRC breaks stuff for other ARM systems) in order to boot, and a proprietary graphics driver if you wanted any kind of hardware acceleration or nice screen resolutions. Looking at other systems it seemed like basically all of them required similar model-specific kernels/firmware/drivers/tweaks/fixes, and all this was also not documented really, so you had to reverse engineer this knowledge. [0] https://gitlab.tails.boum.org/tails/blueprints/-/wikis/ARM_platforms/ [1] https://gitlab.tails.boum.org/tails/blueprints/-/wikis/ARM_platforms/Acer_Chromebook_R_13_CB5-312T Is it your experience that the situation for ARM systems is basically the same now, 7 years later? Another thing that demotivated me was that the "ARM world domination" scenario, where Intel/AMD platforms would become niche and ARM dominat, that I semi-expected at the time, doesn't seem to be happening. I wonder if even a smaller ratio of laptops sold today have ARM than around 2017 (at least I see many Intel Chromebooks). But as long as Intel/AMD remain ~dominant it is hard for us to justify spending resources on other, less common platforms. And as for supporting Apple Silicon, well, we barely are able to support Apple Intel systems at the moment. Given our scarce resources we de-prioritizes Apple hardware, feeling OK with it due to the assumption that if you already have Apple hardware (Silicon or not) you are affluent enough to most likely already own an AMD/Intel-based computer that can run Tails, or afford to buy a cheap one. I say none of this to in any way dissuade you, just to give you my interpretation of the context of where the Tails project stand on these topics. We constantly re-evaluate our positions, so if some data shows that other platforms are relevant for our users and someone can do the work for us or fund us doing it, then Tails on e.g. Apple Silicon and some select ARM platforms could become a reality. Again, impressive work! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Pip is not torified by default
On 01/02/2024 04.46, Patrick wrote: Python3-pip should be added back next release It never was installed in any Tails release. and with a global config to torify it by default. You can make any single file (like `~/.config/pip/pip.conf`) persistent with the Dotfiles persistence feature. [0] [0] https://tails.net/doc/persistent_storage/configure/#dotfiles There are many nice python tools not included with tails that users may like to install. Also pip seems like a easy way to test different python tools for use and possible integration onto tails. Tails is not a general purpose operating system, we simply do not have resources to support all use cases. [1] Our focus are on the needs of our personas [2], and none of them are into Python development. :) [1] https://tails.net/support/faq/#new-software [2] https://tails.net/contribute/personas/ But, as already shown above, Tails allows you to customize it extensively through the persistence feature. The Additional Software persistence feature [3] allows you to keep any package from Debian installed and up-to-date, so just install python3-pip and the other tools you like that way. [3] https://tails.net/doc/persistent_storage/additional_software/ A persistent storage feature for user installed python packages could also be designed to be a hook that adds the appropriate corresponding .local folders to the persistence.conf upon activation of the feature. It is not a documented feature any more (I think because of bugs like #19267) but you can also make any folder persistent yourself. Start Tails with an administration password, login, start a Root Terminal. This makes ~/.local persistent: echo '/home/amnesia/.local source=dot-local' \ >> /live/persistence/TailsData_unlocked/persistence.conf You can do this multiple times, so this also makes the pip cache persistent: echo '/home/amnesia/.cache/pip source=pip-cache' \ >> /live/persistence/TailsData_unlocked/persistence.conf The `source=pip-cache` part means that the data will be stored on the persistent storage in `/live/persistence/TailsData_unlocked/pip-cache`, so just make sure to never re-use the same source as any other line in that file. You must restart Tails for lines added like this to take effect. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Persistence
On 07/07/2023 22.36, kb0...@juno.com wrote: Greetings; I have my Tails installed on a write protected 8gb Kanguru USB 3.0 flash drive, because it has a physical write protect switch. I write protect it after installing and after any updates, physically protecting Tails. I have Persistence on a separate phrase encrypted USB that is not write protected. I am curious, how did you create this separate persistence partition? When Tails boots it finds this Persistence on the computer and asks to unlock it. This has worked for many years, until v5.8 to the current version. This would have worked well with DVD's too. This undocumented and poorly supported (since we don't support creating a separate persistence partition) feature was apparently dropped in Tails 5.8 when the persistence subsystem was completely rewritten. It seems we still have a ticket about this where you can make your case for restoring it: https://gitlab.tails.boum.org/tails/tails/-/issues/6621 Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] new features coming in to be aware of
On 20/06/2023 19.19, richard wrote: Hi Tails devs, So the legacy tor daemon recently got two new features in alpha you should be aware of, proof-of-work and conflux circuits: Thanks for the heads-up! This is very valuable! - proof-of-work: Onion service providers will be able to opt-in to a proof-of-work requirement for connecting clients as a ddos counter-measure. Legacy clients which do not support this feature will not be able to connect to onion services making use of it. This feature will be transparent to the user, though in Tor Browser we may surface custom ui notifying the user if they failed to complete the pow in-time (or other pow-specific errors). The details are still tbd, but any error would be surfaced to applications via a custom SOCKS5 error code (similar to how the tor daemon notifies applications that client auth is required to access an onion service) Am I correct to assume that as long as we have a tor and Tor Browser that supports this, and our Tor Browser's SocksPort has ExtendedErrors enabled, then we are good to go for this feature, or is something more needed? - conflux circuits: the network team has developed a multiple-circuit selection routing system whereby clients will open multiple circuits to an endpoint, and divide traffic between the circuits to increase network performance. Any ux that shows a user's circuit will need to be updated to account for this new conflux circuit reality. For the initial stable release, conflux circuits will only work with clearnet endpoints so onion services are unaffected. The browser team will be working with ux on any required ui changes during the next release cycle, so if Tails has an analogous thing outside of Tor Browser you can probably follow our lead there. Tails has a simple Vidalia-esque circuit viewer where each circuit is listed along with its streams, so (if I understand correctly) with conflux circuits it can be the case that the same stream can be listed under multiple circuits. Since (IIRC) pre-conflux streams associate with a single circuit id it indeed sounds like there will be some work needed here. And this circuit viewer uses Stem, which is unmaintained, which could complicate things a bit further. :) Tails also has a control port filter (that sits between tor and the applications using the control port) that I believe will be affected: since Tails runs a single system-wide tor instance there are concerns about applications that have access to the control port snooping on other circuits/streams (among other things), so the filter enforces restrictions so a control port user only can see its own streams and associated circuits. If streams can associate to multiple circuits then Tails' control port filter must take that into account. Again, thanks for the heads-up! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 4.26
Hi, Tails 4.26 is scheduled for January 11. We haven't decided who is gonna be the release manager yet. Dear manual testers, please tell tails...@boum.org how much manual testing you can do on: - January 10, later afternoon CET - January 11, morning CET Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] NOPE
Please ignore this thread where I mistakenly wrote 4.25 when I meant 4.26. *tired brain* ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 4.25
Hi, Tails 4.25 is scheduled for January 11. We haven't decided who is gonna be the release manager yet. Dear manual testers, please tell tails...@boum.org how much manual testing you can do on: - January 10, later afternoon CET - January 11, morning CET Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 4.25
Hey! Tails 4.25 is scheduled for release on 2021-12-07. I will be the release manager. Dear manual testers, please tell tails...@boum.org how much manual testing you can do on: - December 6, later afternoon CET - December 7, morning CET Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] New release schedule for delayed Tails 4.24 [Was: Release schedule for Tails 4.24]
boyska: Hi, Tails 4.24 is scheduled for November 2. Tails 4.24 is postponed to Friday, November 5. (Reason: Tor Browser 11 was postponed until then.) I will be the release manager! Dear manual testers, please tell tails...@boum.org how much manual testing you can do on: - November 4, later afternoon CET - November 5, morning CET Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 4.23
anonym: Hi, Tails 4.23 is scheduled for October 5. We haven't decided who is gonna be the release manager yet. FWIW, I'll be the RM for this bugfix release. I'll start preparing it on the morning (CEST) of 2021-10-04. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 4.23
Hi, Tails 4.23 is scheduled for October 5. We haven't decided who is gonna be the release manager yet. Dear manual testers, please tell tails...@boum.org how much manual testing you can do on: - October 4, later afternoon CEST - October 5, morning CEST Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [tor-qa] Tor Browser 10.5.6 is ready for testing
anonym: Matthew Finkel: Hello! We are happy to announce the first Tor Browser 10.5.6 release candidate for wider testing. Packages can be found at: https://people.torproject.org/~sysrqb/builds/10.5.6-build2/ We lack a signature for sha256sums-unsigned-build.txt, please upload! Never mind, after some digging around I found a signature: https://people.torproject.org/~boklm/builds/10.5.6-build2/sha256sums-unsigned-build.txt.asc ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [tor-qa] Tor Browser 10.5.6 is ready for testing
Matthew Finkel: Hello! We are happy to announce the first Tor Browser 10.5.6 release candidate for wider testing. Packages can be found at: https://people.torproject.org/~sysrqb/builds/10.5.6-build2/ We lack a signature for sha256sums-unsigned-build.txt, please upload! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to build tails for testing purposes?
Hans: Yeah, yeah, sigh, it's me again Now I am running into a new issue, but I believe, something external happened. For learning I removed all the downloaded things completely. Then I deleted also ~/.vagrant.d/ in my home and started from the beginning with a new git clone and a new, but unchanged build. The proper way to reset and start over is to run: rake clean_all But now there is a new issue, related to vagrant. Please take a look at the last output. snip - /tmp.debootstrap-gnupg-i9oekjha *==> box: Box file was not detected as metadata. Adding it directly...* *==> box: Adding box 'tails-builder-amd64-buster-20210710-de2318f3ae' (v0) for provider: * box: Unpacking necessary files from: file:///space/tails-linux/tails-amd64/tails/tails-builder-amd64-buster-202 10710-de2318f3ae.box *==> box: Successfully added box 'tails-builder-amd64-buster-20210710-de2318f3ae' (v0) for 'libvirt'!* Bringing machine 'default' up with 'libvirt' provider... *==> default: Creating image (snapshot of base box volume).* Volume for domain is already created. Please run 'vagrant destroy' first. The basebox in ~/.vagrant.d are unpacked and the virtual machine images imported by libvirt and stored somewhere else, hence the "already created" above. List images with: virsh -c qemu:///system vol-list default Detele with: virsh -c qemu:///system vol-delete --pool default VOLUME_NAME So I suspect you will fix your issue with: virsh -c qemu:///system vol-delete --pool default tails-builder-amd64-buster-20210710-de2318f3ae_vagrant_box_image_0.img I wasa not lazy, and searched the web. vagrant destroy does not work, and vagrant global-status is telling me, there is no session running. I believe you! Our documentation about this is a bit lacking, and naturally we'd be thrilled to receive your patches improving them! :) OTOH, I don't think there was any good reason for you to start over like you did. Good luck! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to build tails for testing purposes?
Hans: Am Dienstag, 20. Juli 2021, 13:49:47 CEST schrieb anonym: In your previous email I see that you did some changes inside the tails folder without committing them to Git. Tails will only include changes that are in Git, and will refuse to build when you have uncommitted changes -- the ignorechanges option is just for disabling that check (only recommended if you know what you are doing), and proceeds to build without those uncommitted changes. If you are not too familiar with Git, you can try this (at the root of your tails folder) to add all files to Git: git add . git commit -m "Did some stuff" And then just `rake build` as usual. Cheers! Ok, I could do this. But does this not kill the original stuff? Nothing is ever lost when using Git. :) It keeps the history of how files have changed. My purpose is, to build my own tails version with XFCE and kali-undercover and without gnome. Just to make it as small as possible. Understood. That is compatible with the instructions I gave you above. However, removing Gnome is likely very hard. I suggest you install XFCE in addition to Gnome to save you tons of work (potentially weeks, I'd guess). Are saving ~100 megabytes really worth it? :) If I commit my personal changes to git, as you requesting, then (please correct me, if I am wrong) my changes will change the sources in github, what is the last thing I want to do. Don't worry, your local changes are not published anywhere by default (that requires the `git push` command). And you do not have permission to publish changed on Tails' GitLab any way. :) I still do not even know, if this, what I want to do, is really working. At the moment I am trying things, step by step. And I want to be sure, these things are only done on my own systems. This must be confirmed. That's awesome! "Try, fail, repeat" is a surefire recipe for learning! :) If you didn't already, have a look at HACKING.mdwn for some quick explanations of how to modify Tails! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to build tails for testing purposes?
Hans: Additionally the deb-package, I put below ~/chroot_local-packages/ is not going to be installed (maybe, because XFCE is not installed, as kali-undercover.deb needs got XFCE dependencies). The chroot_local-packages feature has frequently been broken, but I suspect there is another problem... Before build, I started export TAILS_BUILD_OPTIONS="ignorechanges" but got no success. My changes are ignored. I also tried In your previous email I see that you did some changes inside the tails folder without committing them to Git. Tails will only include changes that are in Git, and will refuse to build when you have uncommitted changes -- the ignorechanges option is just for disabling that check (only recommended if you know what you are doing), and proceeds to build without those uncommitted changes. If you are not too familiar with Git, you can try this (at the root of your tails folder) to add all files to Git: git add . git commit -m "Did some stuff" And then just `rake build` as usual. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 4.21
Hi! Tails 4.21 is scheduled to be released on August 10. boyska will be the mentoree RM [0] preparing this release! \o/ Manual testers, please let tails...@boum.org know if you can do manual testing on: * Monday, 9 August, later afternoon CEST * Tuseday, 10 August, morning CEST Cheers from boyska and anonym, who just finished the 4.20 release process! BLAZE IT! [0] Presumably with intrigeri as mentor since I'm on vacation! :) ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] NSA tails and closed code
Romper Stomper via Tails-dev: Is it true that the “tails” ports are controlled by the NSA? I'm not sure what you mean with "ports". However, NSA doesn't control anything related to Tails to our knowledge, and we do what we can to defend against it, e.g.: https://tails.boum.org/news/reproducible_Tails/ and why are there closed codes in “tails”? I guess you are referring to the firmwares required for hardware support? If we didn't ship these firmwares Tails would not run on most hardware. It's a necessary trade-off. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.19~beta1 postponed (and what about 4.19~rc1?)
Hi, As you might have noticed, 4.19~beta1 (for the Tor Launcher replacement) that was planned for release yesterday is not out yet. The explanation is: * I was supposed to prepare it, but I've been sick this week and haven't been able to put in the needed hours * We found some last-minute issues we'd ideally like to be fixed Also, as you might have seen elsewhere, Mozilla just pushed all releases one week into the future, which in particular means that 4.19 also will be released a week later than planned, so we actually have a bonus week and can afford to postpone. In other words, if we release 4.19~beta1 on Thursday, 29 April, we'd give users the same amount of time as before. I think we can do it earlier than that next week, on Tuesday, April 27. But then there would only be a bit more than a week until 4.19~rc1, which feels like a waste. So I propose we postpone it a week, until April 13. In summary, users will then have two weeks to test the beta (and we to fix the problems) until the RC, and then they have a bit more than two weeks to test it before the final release. tl;dr: Proposal: * Tails 4.19~beta1 is postponed from 2021-04-22 to 2021-04-27 * Tails 4.19~rc1 is postponed from 2021-05-06 to 2021-05-13 What do you think? Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Proposal: use the "Reviewer" field in GitLab MRs
intrigeri: Hi, A few months ago, GitLab Inc. open-sourced the "Reviewer" feature for Merge Requests. This allows keeping track _independently_ of: - Who's responsible for bringing the MR to completion: the Assignee. - Who's responsible for reviewing the MR: the Reviewer. I must say that I love to not lose track of my work just because I sent it for review! I propose we start using the "Reviewer" field in MRs, as described above and in the GitLab documentation. Yes, please! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.17 release schedule
Hi! Tails 4.17 is scheduled for March 23. The current plan is that intrigeri is the RM. tails-manual-test...@boum.org, please let tails...@boum.org know whether you can do manual testing on March 22 (mid/late afternoon UTC) or March 23 (morning UTC). Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [Tails-l10n] Tails 4.16 release schedule
intrigeri: Tails 4.16 is scheduled for February 23. I hope anonym will be the RM. I will be! :) ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.15.1 emergency release
Hey, Due to CVE-2021-3156 for sudo [0] we are preparing an imminent emergency release. The plan is to release Tails 4.15.1 tomorrow afternoon/evening (CET). Please don't touch the stable tails.git branch until Tails 4.15.1 is publicly released! Cheers! [0] https://gitlab.tails.boum.org/tails/tails/-/issues/18164 ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Simple suggestion - disable auto-maximizing windows
Justin McAfee: I believe there's a certain expectation by the OP that window sizes will be correlated with browser fingerprinting. Indeed. Probably because this used to be an issue in Tor Browser, which it warned about if you maximized the window. But this was solved in Tor Browser 9.0 (and a correctly configured vanilla Firefox 67+) around a year ago thanks to the "Letterboxing" anti-fingerprinting feature. Could you speak to the compensating controls or mitigations in place to prevent this sort of attack? * https://tails.boum.org/doc/anonymous_internet/Tor_Browser/index.en.html#letterboxing * https://blog.torproject.org/new-release-tor-browser-90 Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Next release: 4.14, December 15
Hi, Tails 4.13 is scheduled for December 15, and intrigeri is the Release Manager. Dear manual testers, please let tails...@boum.org know if you can do manual testing on December 14 (evening in Europe) and/or December 15 (morning in Europe). Thanks in advance! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Resend: Locking down stream-events in onion-grater
proc...@riseup.net: On 10/29/20 3:18 PM, anonym wrote: proc...@riseup.net: On a related note, with restrict-stream-events set to true, I was still able to access all stream events when testing with netcat in the workstation VM. Initially it worked as intended and didn't pass this info, but during subsequent trials it would read everything Tor was doing. Woah, so it would probably work inside Tails?! I am very much interested in reproducing and investigating this in that case. Please help me out with any info/instructions you have about this! Follow up: what is the best approach to capturing this section of the pattern $relayid~$relayid,$relayid~$relayid,$relayid~$relayid ? Just using (\S+) once or do I have to do \$(\S+)~\$(\S+),\$(\S+)~\$(\S+),\$(\S+)~\$(\S+) ? I'd say, use the most accepting rule that doesn't break the functionality you want to keep since it is the more fail-safe approach, so if the first one works, it's better IMHO. * Is it even possible to sanitize responses as large and varied as stream-events output without having something leak thru or is it best to keep it blocked for peace of mind? Theoretically, I think yes, but any black-list approach is pretty much futile to get perfect unless you put unreasonable resources on maintaining it. So at best you it can be considered in a defense-in-depth approach, but not as a single defense, IMHO. I think another problem is circuit info is multi-line and don't all start with 250+circuit-status= I'm guessing this prevents any use of a wildcard as an easy catch-all for the whole replies? First, let's note that the rewrite rules operate on a per-line basis, which indeed puts some limitations of what is possible. My understanding is that you want to rewrite the multiline response of e.g. `GETINFO circuit-status` from something like: 250+circuit-status= 16 BUILT … 18 EXTENDED … … . 250 OK to an "empty" response: 250+circuit-status= . 250 OK Is this correct? If so, yes, I think there is a problem. I believe the best we can do at the moment is to have a rule like: GETINFO: - pattern: 'circuit-status' response: - pattern: '[0-9]+ (BUILT|EXTENDED|…) .*' replacement: '' i.e. that matches all the other lines of the response and replaces them with the empty sting... but that would result in a response with a bunch of empty lines in it: 250+circuit-status= … one for each circ uit … . 250 OK which is think is invalid according to the control-spec. But it's worth testing, I guess! :) But the better solution would be to extend onion-grater with something like the `suppress` option that exists for events, e.g.: GETINFO: - pattern: 'circuit-status' response: - pattern: '[0-9]+ (BUILT|EXTENDED|…) .*' suppress: true which would mean that any response line matching the pattern is completely dropped. I'm not completely sure, but it shouldn't be that hard to implement. Is this what you would like, or am I way off? If the latter, please try to explain in more detail what it is you want to achieve, preferably with concrete examples of the Tor output you get and exactly how you want it transformed. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Resend: Locking down stream-events in onion-grater
proc...@riseup.net:
Re-sending this in a human readable form:
Thanks!
A couple of months ago I was looking at locking down the amount of info leaked
to Tor Browser in case it is compromised - if/when stream events access is
enabled. my thought was to have the cake and eat it too.
I guess you are not considering the restrict-stream-events option since this is
in a Whonix context?
stream-events are needed to supported auth onions IIRC.
Also the circuit view.
I ran into issues with escaping characters from Tor's output namely $ and +
which were included in an example output:
250+circuit-status=00 BUILT
$relayid~$relayid,$relayid~$relayid,$relayid~$relayid BUILD_FLAGS=NEED_CAPACITY
PURPOSE=GENERAL TIME_CREATED=2020-09-16T00:00:00.00
Questions:
* Can onion-grater currently deal with such characters without having to escape
them?
Du you mean if you can write a pattern (i.e. regexp) where you want to match + and $
(from Tor's output) without escaping them? If so the answer is no, escaping is the only
mechanism, and my question for you is why? What's the problem with escaping? For
instance, "pattern: '250\+circuit-status…" should work just fine.
I feel like I don't understand your question at all. :/
* Is it even possible to sanitize responses as large and varied as
stream-events output without having something leak thru or is it best to keep
it blocked for peace of mind?
Theoretically, I think yes, but any black-list approach is pretty much futile
to get perfect unless you put unreasonable resources on maintaining it. So at
best you it can be considered in a defense-in-depth approach, but not as a
single defense, IMHO.
The rule I used in the profile:
GETINFO:
- pattern: 'circuit-status'
response:
- pattern: '250(.+)circuit-status=(\S+) (\S+) (.+) (\S+) (\S+)'
- replacement: '250+circuit-status='
This rule is buggy! The fix is to remove the "-" before "replacement". I
spotted this issue thanks to the debug log where it is clearer:
host onion-grater[8471]: - pattern: circuit-status
host onion-grater[8471]: response:
host onion-grater[8471]: - {pattern: 250(.+)circuit-status=(\S+) (\S+)
(.+) (\S+) (\S+)}
host onion-grater[8471]: - {replacement: 250+circuit-status=}
As you can see, the 'pattern' and 'replacement' keys are in separate
dictionaries, but 'response' wants a list (in your case of length 1) of
dictionaries with exactly those two keys present. It becomes a bit more
apparent if you provide more than one rewrite rules:
GETINFO:
- pattern: 'circuit-status'
response:
- pattern: '250(.+)circuit-status=(\S+) (\S+) (.+) (\S+) (\S+)'
replacement: '250+circuit-status='
- pattern: ...
replacement: ...
- pattern: ...
replacement: ...
...
Yeah, onion-grater should do a better job validating that the filters it loads
are correct...
Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.12 release and testing schedule
Hi, The Tails 4.12 release is scheduled on 2020-10-20, mark you calendars! intrigeri has the honor the be the RM this time. Manual testers, intrigeri will let you know the exact time for testing, but by default it should be the day of the release and the day before, so the 19th and 20th of October. Try to keep those days open! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.11~rc1 on 2020-09-08 [Was: Tails 4.11 release schedule]
anonym: > So, here's the schedule I propose: > > # Tails 4.11~rc1 > > I'd like the release candidate to include the latest possible Tor Browser 10 > alpha, so I'm trying to coordinate with the Tor Browser developers. My guess > is that it will latest be on September 11, but I might want to try on > September 8 instead to give testers more time -- it will depend a bit on the > timing of the Tor Browser alphas and my personal availability. Stay tuned! I was just informed that the Tor Browser developers have drafted a rough release schedule until the 10.0 release: https://gitlab.torproject.org/tpo/applications/tor-browser/-/wikis/Release-Schedule It says that 10.0a7 is planned to be released on 2020-09-08, meaning it will be available for testing for a couple of days prior to that. So it looks like a perfect fit to prepare the images on the 7th and release 4.11~rc1 on the 8th as well, i.e.: 2020-09-07: - Freeze at 12:00 CEST! Please do not push anything to the stable or devel branches for the rest of the day! - Build the Tails 4.11~rc1 images. - Start testing. 2020-09-08: - Finish testing. - Release! - Translators can start translating new/modified strings. Testers, how does your availability look on: * 2020-09-07, evening? * 2020-09-08, morning-afternoon? Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.11 release schedule
Hi, I will be the release manager for Tails 4.11, a major release (IMHO, see below), scheduled to be available for users on 2020-09-22. Since it is a major release, we'll have a release candidate too this time. First, let me explain why I think we need a major release. There are two main reasons: 1. The next Tor Browser update is a major one, and is based on a new Firefox ESR series (78) which often breaks various edge cases. A release candidate would give users a chance to report these and us to fix them before the final 4.11 release. 2. We will enable persistence for all options set on the Greeter/Welcome Screen (#17136). In Tails 4.8 we enabled persistence for just the new Unsafe Browser option (#17085), but now it is time to enable the rest of segfault's amazing work. It just needs more testing, which is what we have release candidates for. So, here's the schedule I propose: # Tails 4.11~rc1 I'd like the release candidate to include the latest possible Tor Browser 10 alpha, so I'm trying to coordinate with the Tor Browser developers. My guess is that it will latest be on September 11, but I might want to try on September 8 instead to give testers more time -- it will depend a bit on the timing of the Tor Browser alphas and my personal availability. Stay tuned! # Tails 4.11 final 2020-09-20: - Freeze at 12:00 CEST! Please do not push anything to the testing branch for the rest of the day! 2020-09-21: - Build the Tails 4.11 images. - Start testing. 2020-09-22: - Finish testing. - Release! Testers how does you availability look at: * 2020-09-21, evening? * 2020-09-22, morning-afternoon? Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Fixing Torrent files for 4.9
emma peel: > intrigeri: >> Hi, >> >> Cyril Brulebois (2020-07-29): >>> Maybe we should make sure downloading over bittorrent finishes, and >>> not only starts? >> >> This would make the manual testing session start a bit later (with "a >> bit" being more or less long depending on the RM's Internet >> connection). What about adding the full Torrent download to the manual >> testing session instead? > > I think it would be easy to start the torrent at the start of the manual > testing session, and check if its finished after the other tests have > finished. > > I used to add the torrents to my seedbox while testing, but I haven't done it > consistently the last year (as I didn't found any problems in a long time, > being only useful a couple of times when the RM already had doubts about the > torrent working). > > This would also give one more seeder to spread the torrents when we actually > release. I proceeded to add this test, see commit 077a9150bb. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.9 release, testing schedule
Hi, As far as I know there has been no discussion about who will be the RM for Tails 4.9, so I'll apply our default rule that it will be kibi. Tails 4.9 is scheduled to be released on 2020-07-28. This will be a bugfix release. Manual testers, please report whether you are available for testing on 2020-07-28 (and possibly the day before) to kibi privately. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Request for change in communication culture
Hi! Let me first express the change we're seeking: when leaving a comment on a ticket, consider it your responsibility that the right person(s) will read it! If you don't @mention someone, you probably are failing this responsibility! [Note that @mentioning works in both Redmine and GitLab, and this proposal is meant for both.] So far we have been relying on one person subscribing to all Redmine changes and constantly following up on new comments and notifying the right people so they are not "lost into the void". This is not sustainable (and IIRC GitLab does not support subscribing to everything?) so we need to distribute this work. To me it makes most sense to put this responsibility on the poster, at least among us regular-ish contributors that are expected to have read the contributor's docs -- new (or "drive-by") contributors cannot be expected to have done this, and will be dealt with differently, some how. In practice this means you should do the following when leaving a comment: 1. Figure out who you want to read the comment! A good resource for this is: https://tails.boum.org/contribute/#mentors If you have trouble finding who to @mention, please mention @anonym and I'll try to help! 2. Is this person already the assignee of the ticket you are posting to? If so they will be notified any way, so we don't necessarily have to spam them further by @mentioning them. But please err on the side of over-using @mentions rather than under-using them! :) 3. Otherwise, just add a @mention (or several, if you think several people could be interested in this comment) somewhere in your comment. 4. Post! What are your thoughts on this? I know this proposal isn't 100% bullet proof, it's more of a necessary reaction to the fact that we won't have a person doing all this work for us any longer. Personally I think there might be a few cases when the above rule doesn't apply, e.g. if you just want to add some piece of info to a ticket no one is working on, just to make sure it is available to whoever might work on it in the distant future. Not sure how to formalize a rule around this, but remember: "please err on the side of over-using @mentions rather than under-using them". Related to all this, if you need a technical rubber-duck, try talking to me (e.g. by private email or pinging me on XMPP)! If I cannot outright help you directly, I most likely can find someone who is better suited to help. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Force pushed stable branch by mistake
Hi! Today I rebased a development branch on stable and proceeded to absentmindedly typed "stable" again when force-pushing: git push -f origin stable I.e. I force-pushed an old state of stable (cf9e208256acc3db931c51cd4df1066452c856c9). Oops! :S Looking at the last job for stable on Jenkins it seems its previous state was 17973cc452ae76823d27a54de7c247e3b21ff94a so I have restored it to that state. So I think all is good now, but if it seems I lost some history, please let me know! Also, I wonder if this force-push can have some other consequences on Jenkins (or other infra). It seems to me that restoring an old state should do nothing vs our garbage-collection mechanism, for instance, but I might overlook or not be aware of some other mechanism. Sorry for the inconvenience! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] GitLab: broken attachment links in comments [Was: Migration to GitLab: April 8-10]
See e.g. https://gitlab.tails.boum.org/tails/tails/-/issues/17367 The attachment links in the Attachment section work fine. However, the links in the comments where they were added have bad URLs: https://redmine.tails.boum.org/code/attachments/download/2547/GNOME+Settings+Selection.png It should be: https://redmine.tails.boum.org/code/attachments/download/2547/GNOME%20Settings%20Selection.png Also, why not point to the static Redmine archive directly? You will have to eventually. :) BTW, I noticed that the static Redmine pages lack an attachments section in the description. The attachments can still be found and accessed via the comments they were added in, however. Example: https://public-redmine-archive.tails.boum.org/code/issues/17367/ ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Migration to GitLab: April 8-10
intrigeri: > While Redmine is down, if you need to view a Redmine issue, until the > migration to GitLab is completed, you can now replace > https://redmine.tails.boum.org/ with > https://public-redmine-archive.tails.boum.org/ in the URL and access > our fancy new static archive of Redmine contents. Sweet! > For example: > > https://public-redmine-archive.tails.boum.org/code/issues/6094 Damn, I took a stroll down memory lane and read through the whole ticket. Good times! :) >> Whether we can actually do the migration at that time depends on >> a number of factors, including some that we have no control over. > > We have not reached the point of no return yet and there's still > a possibility we abort the migration. Fingers crossed! I am invoking the strength of Jupiter Optimus Maximus to your aid! :) Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [tor-dev] Tails vs the capacity of the Meek bridges
Iain Learmonth: > Hi, > > On 20/03/2020 15:30, sajolida wrote: >>> In Tails' threat model it is assumed that adversaries monitor the default >>> bridges provided by the Tor Browser, and that our users want to avoid >>> detection of that, so we are not interested in adding the default bridges >>> to Tails >> >> We're not offering the default bridges in Tails also because it's >> impossible right now to store your bridge configuration in the >> Persistent Storage. > > Maybe I've overlooked something obvious, but could you use Moat? > > https://gitweb.torproject.org/bridgedb.git/tree/README.rst#n391 > > This would use meek to fetch the bridges, but then you have non-default > bridges for the rest of the session. It can be automated as part of the > Tor start-up, but you do need to solve a CAPTCHA. Nothing is preventing us except more work. :) Essentially, Tails only allows the tor process to talk clearnet as part of its Tor enforcement [1], which makes this a bit trickier than in less locked down environments that Tor Launcher is designed to run from. But it indeed looks like also adding Moat support (and making it the default, I think) is the way for us to go, so thanks for the reminder! :) Cheers! [1] https://tails.boum.org/contribute/design/Tor_enforcement/ ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [tor-dev] Tails vs the capacity of the Meek bridges
David Fifield: > On Fri, Mar 20, 2020 at 11:51:41AM +0100, anonym wrote: >> tl;dr: if Tails makes it too easy to use Meek bridges, could it overload the >> current set of Meek bridges? > > The default meek bridge is already overloaded, unfortunately. Ack. Tails will then *not* add Meek support until it also provides another equally convenient option, like default bridges (unlikely) and/or Moat, so the situation is the same as in Tor Browser. > It's possible to set up a special bridge just for Tails users. It > requires setting up a bridge with meek-server (this is the cheap part) > and configuring a CDN to point to it (this is the expensive part). But > then you can let it run as fast as your budget allows. I doubt we can afford that. At best it could be part of some future grant to make Tails usable in China, or similar. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails vs the capacity of the Meek bridges
Hi, tl;dr: if Tails makes it too easy to use Meek bridges, could it overload the current set of Meek bridges? First some background: during startup Tails can be told to start Tor Launcher so users can e.g. configure any bridges they want. So far we have not provided any pre-configured bridges, i.e. the only option has been to manually enter the bridge information you have obtained yourself. In Tails' threat model it is assumed that adversaries monitor the default bridges provided by the Tor Browser, and that our users want to avoid detection of that, so we are not interested in adding the default bridges to Tails, but we are interested in adding support for Meek [1] (at least because it's the only PT that works in China), since our understanding is that it adds enough plausible deniability to avoid the above problem. So, in summary, Tails would like to provide two options in its (patched) Tor Launcher, Meek or manually providing the bridge info. [2] However, we wonder if the combination of not providing the default bridges while making Meek available could overwhelm the Meek bridges; we expect some significant amount of Tails bridge users to select the Meek option over manual entry simply out of convenience. Let's do some back-of-the-envelope estimations to see what we can expect: (Assumption: Tor Browser users and Tails users are very similar, e.g. similar ratios want to use each PT, similar requirements for "convenience over security", and so on.) Looking at your metrics, there are 1000k daily Tor Browser users [3], overall bridge/PT usage is 50k [4], Meek usage is around 10k [5], so 5% of Tor Browser users use bridges/PTs, and 1% use Meek. On the Tails side, we measure around 30k daily users (from update pings). >From what I said above, I don't think we can expect only 1% of the Tails users >to pick Meek; I would expect it to be closer to the 1% of Meek users plus the >x% of default bridge users, but I couldn't find stats for that in your >metrics. Still, we know that it cannot be more than the percentage of all >bridge/PT users, so we know that 1% + x% <= 5%. So, let's just assume the >worst case, that 5% of Tails users will use Meek, and we have that we expect >5% of 30k = 1.5k additional Meek users. Also, if we consider places where Meek is the only options, Tails probably has close to zero users there, but once Meek is supported it could grow. I guess China is the only such place (?), so with its 1250 Meek users in China [6] we can expect 1250 * 30k/1000k = 34 new Tails users using Meek. Basically a negligible amount. Even if we consider all Meek users, 10k * 30k/1000k = 300 doesn't change much. So, all-in-all, we can expect Tails to bring up to 1.5k + 300 = 1.8k new Meek users, but since those are upper-bound estimations it would probably be much lower. Looking on Meek usage over time, it seems to fluctuate way more than that, e.g. during the summer of 2019 it was up to over 25k, i.e. more than three times what it is now. So I guess we don't have to worry about shocking the Meek bridges? OTOH, a possible side-effect is that this change in Tails increases usage of Meek outside of China. Perhaps whoever pays the bills for the Meek instances don't want this? Please advice! Also, please let us know if there is something else we haven't thought of! Cheers! [1] https://redmine.tails.boum.org/code/issues/8243 [2] If you are really interested you can check out our PoC/WIP here: https://nightly.tails.boum.org/build_Tails_ISO_feature-8243-meek/builds/lastSuccessfulBuild/archive/build-artifacts/ [3] https://metrics.torproject.org/webstats-tb.html [4] https://metrics.torproject.org/userstats-bridge-transport.html [5] https://metrics.torproject.org/userstats-bridge-transport.html?transport=!%3COR%3E=meek [6] https://metrics.torproject.org/userstats-bridge-combined.html?start=2019-12-21=2020-03-20=cn ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Tails 4.4 release and testing schedule
Hi, lists! kibi (Cc:ed) will be the release manager for Tails 4.4, scheduled to be released on 2020-03-10 (Mozilla seems to still agree :)). kibi, please give us details about the release schedule, freeze, deadlines, etc if needed! Manual testers, please report whether you are available for testing on 2020-03-10 (and possibly the day before) to kibi privately! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] RMea culpa
Cyril Brulebois: > Hi folks, > > I'd like to offer my apologies for my tendency to be, or at least appear > to be, negative on the tails-dev XMPP channel when I'm preparing a new > Tails release. I tend to be easily frustrated when I cannot do anything > else than waiting for some cron job to get started, when some network > transfers seem to take way too long, and when I see delays getting > accumulated along the way, possibly derailing the target time schedule > (basically trying to be ready at 17:00 on Tuesdays). This list is not > exhaustive and that can happen for things that seem broken; which I > should just investigate and file a ticket for, instead of first > complaining about on a public channel… > > Besides the overall negativity that can be felt during such times, it's > been brought up to my attention it's not always clear to others what I'm > expecting during such times, which doesn't help restore a suitable mood. > I suppose it's basically either something that I (feel the need to) vent > about on the spot, or something that should be ending up in some ticket > or mail-based report once the release is over. I think I've done the > latter since my very first release, and I'll now focus on avoiding the > former when preparing the next releases. > > Thanks for your patience and for your tolerance so far. Feel free to > bring it up to my attention if I do that again in the future, so that I > try harder and/or differently to self-correct. Very cool and brave that you wrote this! Kudos! I must admit that I noticed a single instance of this happening during some release you were RMing months ago. My (private) reaction was annoyance/hurt in the sense: "I know our stuff is far from perfect, but please don't shit on our work", but it was rather quickly dissipated: I just had to remind myself of all the painful releases you'd had, and empathy was fully restored and I moved on without thinking "less" of you. However, I blame myself for not jumping in and helping you vent more constructively, which I definitely was in a position to and must have understood that you needed. I've been there myself, deep in the release process frustration, and I am certain I've puked hate over our stuff in front of others too. I hereby pledge to join you in being more careful how I vent on our communication channels! Thanks! ♥ ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Do you read the changelog?
Hi, Tails contributors! As release managers, one of the things we produce is the changelog (i.e. debian/changelog; we are *not* talking about the release notes). We have the following questions for you, potential users of this file: - Do you read the changelog at all? - If so, what do you use it for? That's all! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [Proposal] Redmine workflow simplification: drop "Fix committed" status
intrigeri: > If you're fine with this proposal, you may stop reading here. I like this proposal! And with my RM hat on I even love it because I hate the Fix committed → Resolved dance for new releases. :) ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Proposal: Redmine workflow change
intrigeri: > Hi, > > intrigeri: >> So I propose that we drop the "QA Check" field and instead, introduce >> a "Needs Validation" status. > > This proposal from March 24 was implemented on June 2. > > Any feedback about how this change impacted your work so far? 100% optimization, 0% loss of value! 10/10! :) ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [Tails-news] Tails 3.13.2 is out
[Whoops, dropped tails-dev in my first attempt to answer.] Georg Koppen: > Tails - News: >> This release is an emergency release to fix a critical security vulnerability >> in _Tor Browser_. >> >> It also fixes [other security >> vulnerabilities](https://tails.boum.org/security/Numerous_security_holes_in_3.13.1/). >> You should upgrade as soon as possible. >> >> # Changes >> >> ## Fixed _NoScript_ activation in _Tor Browser_ >> >> Starting from Friday May 3, a problem in _Firefox_ and _Tor Browser_ disabled >> all add-ons. This release reactivates all add-ons in _Tor Browser_, >> especially >> _NoScript_ which is used to: >> >> * Most importantly, protect against a very strong fingerprinting technique >> called _HTML5 canvas fingerprinting_ which can break your anonymity. > > Hm. How does it do that? In particular, what does it do in addition to > the defense we baked into Tor Browser and which is not NoScript > dependent? (see the: "Specific Fingerprinting Defenses in the Tor > Browser", subsection 2. HTML5 Canvas Extraction at > https://2019.www.torproject.org/projects/torbrowser/design/) There's been a misunderstanding. We were supposed to talk about fingerprinting enabled by the loss of NoScript's WebGL click-to-play, not HTML5 canvas fingerprinting. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] allow read only usb images
Elmar Stellnberger: > My security infrastructure has suffered a significant setback since > you have decided to separate usb and cd images. I need a read only > image that can be booted from a read only usb stick or in my case > from a read-only sdcard used with an sdcard reader that supports > write protection. I believe you have misunderstood the implications of the USB image. First of all, let me clarify that there just isn't anything like a "read-only image". An image is just the raw data intended to be written directly to a disk, with a valid partition table, file systems with files or even a complete operation system etc. So I am guessing that what you meant with "read-only" is that the resulting Tails installation should treat the media it is installed on as read-only, and I'm happy to tell you that that is still the case no matter how you install Tails. Whatever Tails does for write protection (i.e. considering some storage media as "read-only") is done purely in software, so it is just a root exploit away to be bypassed. In fact, the main reason Tails does it is not for security, but to support being able to run from a read-only media like DVD (Tails was originally CD only :)). And if your SD-card simply refuses to abide with writes on a physical level (ignoring signals sent via the card writer) there is no way to override and make the compromise persist. So as long as Tails boots on your read-only SD-card you are safe against persistent threats on that particular media (let's just hope They don't compromise your computer's BIOS or some firmware instead :)). Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Proposal: Redmine workflow change
intrigeri: > So I propose that we drop the "QA Check" field and instead, introduce > a "Needs Validation" status. Sounds much simpler, awesome! +1 > Given we now have "mentions" (@nickname) on our Redmine, for the > majority of cases, when the requested info can presumably be provided > cheaply and quickly, I think we should use mentions and not reassign > the ticket. And when I'm mentioned, if I realize that providing the > requested info needs will take me great amounts of work, I should > do whatever works for me to track this work, be it on a new ticket > or my personal offline organization tools. I quite like this feature and have set up filter rules in my email client for the resulting redmine notifications I receive so I don't miss them. However, I wonder how this works out if you don't do something like that. I also fear that the ad hoc tracking of "mentions" that you propose above is easy to forget. I just had a half-baked idea that might have some merit: say I work on ticket X and need info about "foo" from intrigeri. Then I just create a subticket Y of X called "Info needed: foo" and assign it to intri. When intri has posted the information about "foo" to X he can then mark Y as resolved. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [Tails-l10n] Release schedule for Tails 3.13
intrigeri:
> Hi,
>
> scratch all that. With the updates Georg nicely shared, we can now
> tell that 3.13 will be a regular bugfix release and there won't be any
> 3.13~rc1. It's not 100% clear yet who will be the release manager
> but kibi agreed to be the fallback option.
>
> I expect the schedule will be:
>
> - March 18: build and upload Tails 3.13
> - March 19: test and release Tails 3.13
>
> … but I'll let whoever ends up being the RM confirm and set deadlines
> for branches submission and merging :)
I'll be the RM, using this schedule:
* 2019-03-17:
- Feature Freeze: Unless I have told you otherwise, all feature branches
targeting Tails 3.13 should be merged into the `stable` branch by
noon, CET. Ask if you need an exception!
- Start preparing Tails 3.13.
* 2019-03-18:
- Build and upload Tails 3.13.
- Start testing Tails 3.13.
* 2019-01-19:
- Finish testing Tails 3.13.
- Release Tails 3.13.
> Anyone who's part of our internal QA process ("manual test suite"),
> please let tails...@boum.org know if you're available on March 19 to
> test the final release. Thanks in advance!
Please do!
Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 3.12
alienpup: > anonym wrote: >> anonym: >>> Testers, please let me know if you are available on: >>> >>> * 2019-01-19, to test Tails 3.12~rc1. >> >> Testers, how bad would it be for you if I tell you on the 18th that I >> will need another day to prepare the release, so testing will happen on >> 2019-01-20 (and maybe evening/night of 19th)? >> >> Cheers! > > anonym, > > Not a problem here, but I wonder if an RC deserves more than 24-48 hours of > testing. Time zones and the fact that (ideally) half of our testers are > asleep at any given moment also eat into a small testing window. Over to you > to determine how much testing is enough, but FWIW. Hey, Note that this was a call for our _internal_ testing and quality assurance that we always do before releasing (even RCs -- we don't want users to test crap). Once we're done with the internal testing we publish the RC so all users can test it for a bit over a week, and then we release the final release. I hope this clears things up! I think I'll start referring to this as "internal testing" to be less ambiguous from now on. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 3.12
anonym: > Testers, please let me know if you are available on: > > * 2019-01-19, to test Tails 3.12~rc1. Testers, how bad would it be for you if I tell you on the 18th that I will need another day to prepare the release, so testing will happen on 2019-01-20 (and maybe evening/night of 19th)? Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 3.12
Hi, I'll be the release manager for Tails 3.12, which is a major release scheduled for 2019-01-29. Here is the release schedule: * 2019-01-18: - Feature Freeze: All feature branches targeting Tails 3.12 should be merged into the `devel` branch by noon, CET. - Build and upload Tails 3.12~rc1. * 2019-01-19: - Test Tails 3.12~rc1. - Release Tails 3.12~rc1. * 2019-01-28: - All branches targeting Tails 3.12 *must* be merged into the `testing` branch by noon, CET. - Build and upload Tails 3.12 ISO image and IUKs. * 2019-01-29: - Test Tails 3.12. - Release Tails 3.12. Testers, please let me know if you are available on: * 2019-01-19, to test Tails 3.12~rc1. * 2019-01-29, to test Tails 3.12 (final). In case you are eager to get started, note that the images most likely will be made available during the evenings before the above dates, as usual. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Second request: Help needed to build ISO
ambifarius: > Hi anonym > > Thanks for your tip. > > I am still unable to build the Tails ISO 3.6.2 despite following your > suggestion. > > Below are some of my questions based on the error message (please see > attachment to this email): > > 1. Lines 150 and 172 indicate "bad redirection". From line 152 to 183 > indicate "Connection closed". Is there something wrong with Tails' servers? Possibly, or something's wrong on your end or with the connection between you and the server. I'd recommend retrying, possibly a couple of times. Please report back even if it works! > 2. "The SSH command responded with a non-zero exit status. Vagrant assumes > that this means the command failed. The output for this command should be in > the log above. Please read the output to determine what went wrong." > > a. Is it because I was unable to fetch some packages? In this case, yes. > b. Where is the log please? In what folder is the log to be found? Everything is written to the terminal so if you want to save it, that is up to you (e.g. `rake build | tee log.txt`)! Only on build success is the log is saved (as a .buildlog), but that doesn't help you in this case. :) 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] Help needed with building ISO
ambifarius: > Hi, > > I have problems building an ISO using the current stable release, 3.6.2 > > rake build was aborted due to command error. Please refer to the attachment > for details. You tried to build from our 'master' branch, which we recommend against. Please read the "Git branch organization" section at: https://tails.boum.org/contribute/how/code/HACKING/#index1h1 which probably will end up with you building from the 'devel' branch! If you want to build a specific Tails release, like Tails 3.6.2, then you just check out the corresponding Git tag and build, e.g.: git checkout 3.6.2 rake build Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [Tails-project] Tails contributors meeting: Tuesday April 03
Hi, tails-dev@, tails-ux@ and tails-l10n@ lists! You were excluded from u's proposal (only sent to tails-project@) to move today's contributor's meeting to 16:00 CEST; below you'll see that she thinks her proposal wasn't done on time, while others think it was and has passed, so there's quite some confusion about when the meeting is gonna happen today: sajolida: > intrigeri: >> Hi! >> >> u: >>> As said I won't be able to make it this month and did not manage to >>> reschedule on time. >> >> My understanding of the decision making process you've initiated is >> that your proposal¹ to reschedule will pass unless someone objects by >> March 30. You've proposed this more than a week before the meeting >> which seems entirely fair to me :) >> >> [1] https://mailman.boum.org/pipermail/tails-project/2018-March/001092.html > > Yep. My automated announcement came shortly after your started the > discussion about changing time and that looked a bit awkward. But I > think we're still in time to choose a different time. Personally I just read this -- while I read tails-project@ I do not do it often, so next time, please send such proposals to all lists. Also, for this reason I do not think we can expect most people to have seen this, and should consider u's 16:00 CEST proposal invalid => today's meeting happens at the normal time (19:00 CEST). Personally I would greatly prefer 16:00, and will be present then (by default, since that still is "office hours") to see what happens. 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] Release schedule 3.6.2
Hi, A patch for a "potentially exploitable crash" [0] in Firefox was made public by mistake, resulting in Firefox 52.7.3esr and Tor Browser 7.5.3, so we need yet another emergency release, Tails 3.6.2, which I'll be the RM for. This also gives us the opportunity to sneak in a few other important fixes. You can extract the plan from the release manager view: https://labs.riseup.net/code/projects/tails/issues?query_id=295 Due to lack of RM resources the schedule is very relaxed: * 2018-03-27: Start preparing Tails 3.6.2. * 2018-03-30: - Finish preparing Tails 3.6.2. - Build and upload Tails 3.6.2. - Start testing Tails 3.6.2. * 2018-04-03: - Finish testing Tails 3.6.2. - Release Tails 3.6.2. ((( Actually, the above schedule is so relaxed it paints a pretty pessimistic picture in terms of how long users are potentially vulnerable. I find the following schedule more likely to be what happens in practice *if* tester availability is good on 2018-03-29 and 2018-03-30: * 2018-03-28: - Finish preparing Tails 3.6.2. * 2018-03-29: - Build and upload Tails 3.6.2. - Start testing Tails 3.6.2. * 2018-03-30: - Finish testing Tails 3.6.2. - Release Tails 3.6.2. ))) Usual testers, you'll be asked for your availability off-band. Others that want to help are encouraged to email me privately (unless you are fine with sharing your availability in public on this thread :)). Cheers! [0] https://www.mozilla.org/en-US/security/advisories/mfsa2018-10/ ___ 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] Searching documents in an airgap Tails
Loic Dachary: > Journalist using SecureDrop decrypt and read documents in an airgap Tails. I > wonder which tools are available to search the documents stored in their > persistence. What about GNOME Files' built-in search functionality [1]? It works well enough for me (although I can imagine it is slow if 1000s of files are involved) so I first would like that answered before proceeding with the rest of your email. [1] https://help.gnome.org/users/gnome-help/stable/files-search.html Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Release schedule for Tails 3.5
Hi, I'll be the release manager for Tails 3.5, which is a minor/bugfix release scheduled on 2018-01-23. The list of tickets targeting Tails 3.5 can be found here: https://labs.riseup.net/code/projects/tails/issues?query_id=276 Below you'll find the preliminary release schedule: * 2018-01-22: - All feature branches targeting Tails 3.5 should be merged into the `stable` branch by noon, CET. I'm open to make exceptions if you can be online and responsive during that afternoon, but ask me first! - Build and upload Tails 3.5. - Start testing Tails 3.5 during late CET if building the image went smoothly. * 2018-01-23: - Finish testing Tails 3.5 by the afternoon, CET. - Release Tails 3.5. Testers, please let me know: * if you are available on 2018-01-22, late CET * if you are available on 2018-01-23, morning to afternoon, CET. 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] Electron Cash in Tails
Fidel Ramos: > Hello everyone. This is my first message to this mailing list. I'm a Tails > user, but I haven't contributed code before, just donations. Welcome, Fidel! I hope you won't be dissuaded by my negative answer... > As you may know Bitcoin Cash is a fork of Bitcoin that has been > growing a lot, especially in the past few days. People (including me) > have shown interest in having a Bitcoin Cash wallet in Tails, as it's > a very secure solution. Adding a feature to Tails has a very real, non-zero cost which poses the question: is it worth spending time that we otherwise would use to improve Tails in concrete ways? For a BTC fork that has been showing promise "in the past few days" it's simply way too premature. > What are the steps to be followed to get a change like this > implemented in Tails? To truly get this done, make a push for a wallet software that supports *multiple* cryptocurrencies (and ideally not only BTC forks, but also fundamentally different designs like Monero, Zerocoin/Zcash/Zerocash/Zzzz-whatever etc). This should not only help Tails, but improve this landscape for all cryptocurrency users. 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] HTML prototype for new download page
Uzair Farooq: > Hey, > >> How long does it take to get a successful result of the verification >> extension on your machine? > > It took half an hour for us. We haven't processed such large SHA files > previously so I wasn't aware that it could take this long. Again, the > problem here is that the javascript implementation of the SHA algo is not > that efficient enough. We can try some other SHA libraries but I don't > expect they will make a considerable difference. Looking at this benchmark: https://github.com/brillout/test-javascript-hash-implementations I can see a >10x speed difference between different implementations, so I think it's worth looking into this, so let's hope you picked a comparatively slow library. :) Regarding the time it takes to do the computation: - 30 minutes is just too long to expect our users to wait (in addition to the download), to the point where I think we'd decide to drop the whole extension idea. :/ - Ideally calculating the checksum should take less than 1 minute. - If we can't get that fast, we might have to add a progress bar to the computation: we can't expect people to wait several minutes without any indication on how long the whole process will take. With a progress bar maybe up to 5? 10? minutes maximum would be acceptable. So, can you please look at the top candidates among those implementations and report back your measurements? Of course, we're only interested in "streaming" variants, that can calculate the digest chunk-by-chunk, so not the whole ISO image has to be read into RAM at the same time. >> So do you confirm that we won't be able to do certificate pining in the >> new extension? > > Yeah, unfortunately not possible with webextensions. That's unfortunate, but not catastrophic (users visit our web page without certificate pinning involved). We'll discuss internally what to do about this (if anything) but for now let focus on solving the issue around hashing first as it's a critical one. 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] HTML prototype for new download page
sajolida: > Uzair Farooq: >> I've pushed two repositories: >> >> Extension: https://github.com/usman-subhani/verification-extension > > anonym: Can you check this one? Sure! The lack of atomic Git history makes it hard to wrap my head around it, but luckily it's short so I'm not really worried about this. However, from now on I'd really prefer atomic commits with meaningful commit messages. Any way, since my JavaScript is really poor I'd really like to be able to run this code and play around with it a bit to get a better understanding of how things are related. Uzair and Usman, how exactly can I test this (and my own modifications to it) in Firefox? I suppose I need a development build of Firefox to work around extension signing, right? But then what? Do I need to package the extension somehow? Assume I known nothing about Firefox extensions, because that is almost the case. ;) 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] Release schedule for Tails 3.3
Hi, I'll be the release manager for Tails 3.3, which is a minor/bugfix release scheduled on 2017-11-14. The list of tickets targeting Tails 3.3 can be found here: https://labs.riseup.net/code/projects/tails/issues?query_id=252 There are currently 170 open tickets listed. Go get 'em! Below you'll find the preliminary release schedule for Tails 3.3: * 2017-11-15: - All feature branches targeting Tails 3.3 should be merged into the `stable` branch by noon, CET. I'm open to make exceptions if you can be online and responsive during that afternoon, but ask me first! - Build and upload Tails 3.3. - Start testing Tails 3.3 during late CET if building the image went smoothly. * 2017-11-16: - Finish testing Tails 3.3 by the afternoon, CET. - Release Tails 3.3. Testers, please let me know: * if you are available on 2017-11-15, late CET * if you are available on 2017-11-16, morning to afternoon, CET. 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] [Updated] Release schedule for Tails 3.2
anonym: > * 2017-09-26: > - Finish testing Tails 3.2 by the afternoon, CEST. > - Release Tails 3.2 during late CEST. Tails 3.2 is ready to be released, but we'll follow the Tor Browser and Firefox plan to delay the release until tomorrow. Details: https://mailman.boum.org/pipermail/tails-dev/2017-September/011718.html Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]
Georg Koppen: > intrigeri: >> Hi, >> >> Georg Koppen: >>> anonym: >>>> Georg Koppen: >>>>> Just to inform you about things we learned a couple of minutes ago: the >>>>> Firefox release is due on Thursday. It got postponed by two days mainly >>>>> to give 57 beta more publicity. >> [...] >> >>>> Still, it makes me want to remember/re-evaluate *why* we always >>>> wait on Mozilla. >>>> >>>> What are your feelings around this? What are the arguments for/against >>>> releasing early? >> >>> Not sure what you mean with "early", probably not as soon as one >>> critical security bugfix lands on the esr52 branch (because there are >>> many :) ). Releasing once candidate build1 is done then? It sometimes >>> happens that additional changes get pushed and a buildN is done or that >>> some of the patches need to get backed out due to issues Mozilla found >>> during their Q I guess you don't want that risk either? I was not talking about the general case, but about the specific situation we are in now with Tails 3.2, i.e.: we're told Tor Browser is delayed because of Mozilla PR reasons, but we are ready to release two days early (well, "one day" by now). (I know you said "mainly" above, but I must confess I more or less ignored that word, so your statement became much more absolute in my head. I certainly assumed it meant that the QA was done, and that you would be clear with the QA not being done if you knew it to be the case. Lot's of assumptions, I know, but in my defence I never intended to act without some sort of ACK from Mozilla. :)) So, for the general case: if Mozilla's and your (Tor Browser folks) QA has passed, and you are only waiting x time before releasing publicly for non-technical reasons, do you care about Tails releasing x time earlier than you? >>>> TBH this has always seemed odd to me. I remember argument for this being >>>> about us >>>> behaving like good Free Software community members by coordinating >>>> releases. >>>> I wonder if they really care, especially given our users' position. So, >>>> let's >>>> ask them! >> >>> I don't know whether they care but that argument has some weight for me >>> at least. >> >> Same here. I would really want to understand this (and possibly agree as well :)). Why do both of you (and others?) feel this is important? This is not a rhetorical question, I simply don't get it. If your explanation depends on the QA status, please also include the case where QA passed so you answer can be applied for the Tails 3.2 case. >> But even putting ethical considerations aside, there's a strong >> technical argument in favour of waiting for Mozilla: their release >> engineering team is a much better position than us to judge when their >> code is ready to be shipped to users, and I don't think we should >> second-guess them. > > Yes, I agree with that. Me too! If it is not clear by now, my interpretation was that the code was ready to be shipped to users, and the delay was due to PR concerns only. >> Now, I'm open to making the occasional exception e.g. when we're >> certain that the *only* reason Mozilla has to delay a release, that >> they otherwise consider as "ready to ship", is about >> marketing/communication wrt. channels we don't track ourselves. >> If/when we do so, we should be extremely clear (e.g. in our changelog >> and release notes) that we're shipping something based on what will >> probably become FF ESR x.y.z, and not something based on FF ESR x.y.z. Agreed! >> In the case at hand, Georg wrote "mainly" so it's not clear to me what >> other reasons they have for delaying the release. Until this is >> clarified, I don't think we're in a good position to tell we can go >> ahead without waiting. Georg, can you please share any other info you >> have (possibly privately to tails...@boum.org if needed) or put anonym >> in touch with the Mozilla release engineering folks who could answer? > > The delay was planned due to Firefox 57 Beta getting more publicity. I > used "mainly" because Mozilla needed this time six candidate builds for > Firefox 56 fixing, among others, last minute crash bugs (the last > candidate build got kicked off yestderday). I am not sure whether they > would have delayed the release for those, though. They might have > shipped follow-up releases instead. So, I think it is fair to summarize > the situation that Firefox 56 (and Firefox 52.4.0esr) got delayed by two > days due to PR
Re: [Tails-dev] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]
Hi, Mozilla folks! Geb told me you might be able to answer whether Mozilla cares if a Firefox downstream would release something based on Firefox ESR 52.4 earlier than you (or that you might be able to forward it to the right channel within Mozilla). For details and the full context, see the quoted parts below! Cheers! anonym: > Georg Koppen: >> Hi, >> >> Just to inform you about things we learned a couple of minutes ago: the >> Firefox release is due on Thursday. It got postponed by two days mainly >> to give 57 beta more publicity. >> >> We'll follow and release Tor Browser on Thursday as well. > > Got it! It makes sense for you Tor Browser folks, since the Firefox security > issues fixed in ESR 52.3 are not publicly known yet (at least in theory, but > the code changes have been out for a week so they can have been > reverse-engineered). > > But what about Tails? Tails 3.2, which is ready to be published right now, > would fix several publicly known security issues for our users, including > some potential RCEs (Thunderbird, libsoup, ...). Of course, some of these > issues have been out for weeks already, so what's two more days of delay? > Still, it makes me want to remember/re-evaluate *why* we always wait on > Mozilla. > > What are your feelings around this? What are the arguments for/against > releasing early? > > TBH this has always seemed odd to me. I remember argument for this being > about us behaving like good Free Software community members by coordinating > releases. I wonder if they really care, especially given our users' position. > So, let's ask them! > > Tor Browser folks, would you care if we released Tails 3.2 right now, so we > in effect release Tor Browser 7.0.6 way before you? What do you feel about > this in general? > > As for asking Mozilla, I'm not even sure who/where to ask. Does any one have > a clue? > > 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] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]
Georg Koppen: > Hi, > > Just to inform you about things we learned a couple of minutes ago: the > Firefox release is due on Thursday. It got postponed by two days mainly > to give 57 beta more publicity. > > We'll follow and release Tor Browser on Thursday as well. Got it! It makes sense for you Tor Browser folks, since the Firefox security issues fixed in ESR 52.3 are not publicly known yet (at least in theory, but the code changes have been out for a week so they can have been reverse-engineered). But what about Tails? Tails 3.2, which is ready to be published right now, would fix several publicly known security issues for our users, including some potential RCEs (Thunderbird, libsoup, ...). Of course, some of these issues have been out for weeks already, so what's two more days of delay? Still, it makes me want to remember/re-evaluate *why* we always wait on Mozilla. What are your feelings around this? What are the arguments for/against releasing early? TBH this has always seemed odd to me. I remember argument for this being about us behaving like good Free Software community members by coordinating releases. I wonder if they really care, especially given our users' position. So, let's ask them! Tor Browser folks, would you care if we released Tails 3.2 right now, so we in effect release Tor Browser 7.0.6 way before you? What do you feel about this in general? As for asking Mozilla, I'm not even sure who/where to ask. Does any one have a clue? 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] Releasing ISO as a GPG encrypted archive?
anonym: > Besides, with what key would Tails be encrypted with? Our *public* key? Here I meant: "Our *secret* key, so it can be decrypted with the *public* key?" ___ 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] Releasing ISO as a GPG encrypted archive?
Anonymous: > Have the developers considered the idea of releasing the > Tails ISO as a GPG encrypted archive? This would create > another verification method with distribution as users would > need to decrypt the archive via a specific method in order > to utilize the ISO and further verify it once extracted. AFAICT, encryption applied in this manner does not help authentication, so signature verification alone suffices. Besides, with what key would Tails be encrypted with? Our *public* key? Actually, that is what a signature is (modulo the part where it generally only encrypts a hash of the file, so they can be tiny). Lastly, even if this added something useful we'd have to weigh it against the increased complexity for our users. 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] [Updated] Release schedule for Tails 3.2
anonym: > anonym: >> * 2017-09-14: >>- Feature Freeze: All feature branches targeting Tails 3.2 should >> be merged into the `devel` branch by noon, CEST. I'm open to make >> exceptions if you can be online and responsive during that >> afternoon, but ask me first! >>- Build and upload Tails 3.2~rc1. >>- Start testing Tails 3.2~rc1 during late CEST if building the image >> went smoothly. >> >> * 2017-09-15: >>- Finish testing Tails 3.2~rc1 by the afternoon, CEST. >>- Release Tails 3.2~rc1. > > FYI, I'm very late with this, as it's 2017-09-15 and I still am not done with > the work I need to finish *before* even starting with the 3.2~rc1 release > process. Currently it looks like this RC (only! not the final release) will > be delayed by exactly 1 day. Stay tuned... Due to all delay this turned into: * 2017-09-16: - Test Tails 3.2~rc1. - Release Tails 3.2~rc1. :) 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] [Updated] Release schedule for Tails 3.2
anonym: > * 2017-09-14: >- Feature Freeze: All feature branches targeting Tails 3.2 should > be merged into the `devel` branch by noon, CEST. I'm open to make > exceptions if you can be online and responsive during that > afternoon, but ask me first! >- Build and upload Tails 3.2~rc1. >- Start testing Tails 3.2~rc1 during late CEST if building the image > went smoothly. > > * 2017-09-15: >- Finish testing Tails 3.2~rc1 by the afternoon, CEST. >- Release Tails 3.2~rc1. FYI, I'm very late with this, as it's 2017-09-15 and I still am not done with the work I need to finish *before* even starting with the 3.2~rc1 release process. Currently it looks like this RC (only! not the final release) will be delayed by exactly 1 day. Stay tuned... 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] Help us build Tails 3.2~alpha1 build reproducibly
anonym: > ### ... and the checksums differ (i.e. reproduction failed). > [...] > sudo apt -o APT::Install-Suggests="true" \ > -o APT::Install-Recommends="true" \ > install diffoscope -t stretch-backports It was reported to us that the above command pulls in ~3500 dependencies (~3.5 GB packages, 14 GB disk usage) on a minimal Debian Stretch, including a full GNOME desktop environment. Whoops! You will get 80% less dependencies (but still all the needed ones!) with this command: sudo apt -o APT::Install-Recommends="true" \ install diffoscope/stretch-backports Sorry for the inconvenience (again)! 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] [tor-dev] Help us build Tails 3.2~alpha1 build reproducibly
anonym: > git checkout 3.2~alpha1 Oops! That should be: git checkout 3.2-alpha1 In other words, the "~" (tilde) should be a "-" (dash). Sorry for the inconvenience! Cheers! signature.asc Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Help us build Tails 3.2~alpha1 build reproducibly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear Tails and Tor contributors,
dear Reproducible Builds community,
We have sent out a first call [1] for testing to build Tails 3.1 reproducibly
and we have received some build reports. Thank you very much for your help! We
have since then tried to fix most of the identified issues [2] in Tails
3.2~alpha1, and thus we'd kindly like to ask you to try to build the new ISO
image again, or even for the first time. Please don't hesitate to contact us
if you get stuck at some point in the process, for example by connecting to our
chatroom [3]! You can also send us email to tails-dev at boum.org (public) or
tails at boum.org (private).
Note that Tails 3.2~alpha1 is *not* recommended for real usage, since it has
not gone through *any* QA. Please use Tails 3.1 instead until Tails 3.2 is
released!
# How?
For your convenience all instructions needed to attempt to reproduce
Tails 3.2~alpha1 are included hereafter. However all commands are
adapted for Debian Stretch (and Buster/Sid), so your results may vary if
you run another Linux distribution. Our full build instructions [4]
might help if you are having problems.
## Setup the build environment
Building Tails requires the KVM virtual machine hypervisor to be
available, a minimum of 1 GiB of free RAM and a maximum of 20 GB of
free storage.
### Install dependencies
sudo apt-get install \
git \
rake \
libvirt-daemon-system \
dnsmasq-base \
ebtables \
qemu-system-x86 \
qemu-utils \
vagrant \
vagrant-libvirt \
vmdebootstrap && \
sudo systemctl restart libvirtd
### If building as a non-root user
(Skip this section if you intend to build Tails as the root user!)
Make sure that the user that is supposed to initiate the build is part
of the relevant groups:
for group in kvm libvirt libvirt-qemu; do sudo adduser $user $group; done
Then run `newgrp` (or just reboot) to apply the new group memberships
to the session.
## Build Tails 3.2~alpha1
git clone https://git-tails.immerda.ch/tails
cd tails
git checkout 3.2~alpha1
git submodule update --init
rake build
# Send us feedback!
No matter how your build attempt turned out we are interested in you
sending us feedback. For that we'll first need some information of the
system you used -- please run these commands in the exact same
terminal session that you ran `rake build` in (e.g. run them right
after `rake build`)!
sudo apt install apt-show-versions || :
(
for f in /etc/issue /proc/cpuinfo
do
echo "--- File: ${f} ---"
cat "${f}"
echo
done
for c in free locale env 'uname -a' '/usr/sbin/libvirtd --version' \
'qemu-system-x86_64 --version' 'vagrant --version'
do
echo "--- Command: ${c} ---"
eval "${c}"
echo
done
if which apt-show-versions >/dev/null
then
echo '--- APT package versions ---'
apt-show-versions qemu:amd64 linux-image-amd64:amd64 vagrant \
libvirt0:amd64
fi
) | bzip2 > system-info.txt.bz2
Please have a look at the generated file with
bzless system-info.txt.bz2
to make sure it doesn't contain any sensitive information you do not
want to leak in case you send this file to us or make it public!
Next, please follow the instructions below that match your situation!
## If the build failed.
Please open a ticket on our bug tracker [5] with "Category" set to
"Build system" and `system-info.txt.bz2` attached (note that this makes
this file public).
## If the build succeeded ...
Please compute the SHA-512 checksum of the resulting ISO image:
sha512sum tails-amd64-3.2~alpha1.iso
and compare it to:
1c928336264fc44821562f2fffbda4da97dcdc38072fce58f55b749fde04ac60055273cfc021b6c57120c5d276980859ffa3a5b0bd0f9c98851f34b682a09b02
tails-amd64-3.2~alpha1.iso
Bonus points if you verify the signed (with: [8]) message containing
the checksum below (note that manually inserted line-wraps marked with
"`\`"). If you run Tails, the verification is very easy! :) [9]
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
$ sha512sum tails-amd64-3.2~alpha1.iso
1c928336264fc44821562f2fffbda4da97dcdc38072fce58f55b749f \
de04ac60055273cfc021b6c57120c5d276980859ffa3a5b0bd0f9c98 \
851f34b682a09b02 tails-amd64-3.2~alpha1.iso
- -BEGIN PGP SIGNATURE-
iQJDBAEBCgAtFiEEuiwiL0SsAO2YmTiTmP7GvHUqPbYFAlmxqwAPHHRhaWxzQGJv
dW0ub3JnAAoJEJj+xrx1Kj22RgAP/0auINj6Y5svR7DfeRF8HxPdnd2Rw/8VIiaM
isN3eQoAmNGUtEe50b9VXY+UidCdWtApbZbyZPKFz9ITJOxp0XeSGS8K2+Y0PZIx
NSIEYCx2LEWlzY96ivH2B4pboeq2TIzj/VkPLISYGc80CYRT32OzMRkDDcQn+3+Y
2dkGVf1HPvreZ7c7cUfozay4TNPhKrn2p5IZp1jHgpiq8aAYIv5jcubR//lm1W3S
Ol/IpTQrxzCShJHzsCh1l6/7zLSx5Dv8ITTEIHTj2OTCsZdAcFnznB4byaHVfVQ0
jSogb+b2J6skNhlsHtX2Jo9xK6Ni9NKsCzYYQ2KgWufC93Cvpmh5J164CqkI/DEd
ixe/KbFURP9sTzEL38ExS2DVbMvFvYTmmBmWzvU3USMo0nWfaErye2RIs4yB2pM6
Re: [Tails-dev] Reproduction of Tails 3.1 Failed
Andres Pavez: > Hi, > I have failed trying to reproduce Tails 3.1. I got a iso with a different > hash. > Then, I was able to successfully reproduce the failed iso again with > the same hash. > > Attached you will find the info, I hope helps to improve the > reproduction of Tails. Thanks! Make no mistake, you *are* helping! :) From the diffoscope report I only see evidence for #12738 and #12740, i.e. already known issues that we are progressing well on. Hopefilly you'll be able to reproduce Tails 3.2 successfully! 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] Release schedule for Tails 3.2
intrigeri: > Hi, > > anonym: >> * 2017-10-02: >> - All branches targeting Tails 3.2 *must* be merged into the >> `testing` branch by noon, CEST. >> - The upcoming Tor Browser is hopefully out so we can import it. > > Ouch, I think this release schedule is wrong, since the next Firefox > release is scheduled on 2017-09-26 Ouch, indeed! Thanks for notifying me! > ⇒ please adjust our own release > schedule accordingly. (The sooner the better, since at least I will > have to reorganize my plans accordingly to cope with a shorter release > cycle than expected.) Done! > Might it be that you skipped reading > contribute/working_together/roles/release_manager? Totally! I realized I was late, and didn't even think about the proper procedure at the time, just to get the schedule out as fast as possible. And -- surprise! -- stressing through it also fucked it up. Sometimes I wish I was a better (or at least more consistent/disciplined) documentation-to-work compiler. :) > I've just updated our calendar with all the other future, already > known release dates. Thanks again! 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] Please ignore this release schedule! [Was: Release schedule for Tails 3.2]
For the correct release schedule, please see "[Updated] Release schedule for Tails 3.2", or: https://mailman.boum.org/pipermail/tails-dev/2017-September/011642.html Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] [Updated] Release schedule for Tails 3.2
Hi, [This is a repost of <19736ec9-e3b1-87f3-5752-eaeaac33a...@riseup.net> with the correct dates. Please ignore the previous plan which incorrectly put the Tails 3.2 release on 2017-10-03!] I'll be the release manager for Tails 3.2, which is a major release scheduled on 2017-09-26. The list of tickets targeting Tails 3.2 can be found here: https://labs.riseup.net/code/projects/tails/issues?query_id=198 Below you'll find the preliminary release schedule for Tails 3.2: * 2017-09-14: - Feature Freeze: All feature branches targeting Tails 3.2 should be merged into the `devel` branch by noon, CEST. I'm open to make exceptions if you can be online and responsive during that afternoon, but ask me first! - Build and upload Tails 3.2~rc1. - Start testing Tails 3.2~rc1 during late CEST if building the image went smoothly. * 2017-09-15: - Finish testing Tails 3.2~rc1 by the afternoon, CEST. - Release Tails 3.2~rc1. * 2017-09-25: - All branches targeting Tails 3.2 *must* be merged into the `testing` branch by noon, CEST. - The upcoming Tor Browser is hopefully out so we can import it. - Build and upload Tails 3.2 ISO image and IUKs. - Hopefully start testing Tails 3.2. * 2017-09-26: - Finish testing Tails 3.2 by the afternoon, CEST. - Release Tails 3.2 during late CEST. Testers, please let me know: * if you are available on 2017-09-14, late CEST * if you are available on 2017-09-15, morning to afternoon, CEST. * if you are available on 2017-09-25, late CEST. * if you are available on 2017-09-26, morning to afternoon, CEST. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Substitute Tor-launcher with Anon-Connection-Wizard in Tails?
anonym: > intrigeri: >> * it integrates nicely in a GNOME desktop (e.g. in terms of HIG ⇒ >>consistent UI & UX). I did a quick and dirty test: git clone https://github.com/Whonix/anon-connection-wizard git clone https://github.com/Whonix/python-guimessages sudo env XDG_CURRENT_DESKTOP=GNOME PYTHONPATH=/home/amnesia/anon-connection-wizard/usr/lib/python3/dist-packages/:/home/amnesia/python-guimessages/usr/lib/python3/dist-packages/ /home/amnesia/anon-connection-wizard/usr/bin/anon-connection-wizard which starts a-c-w (but actually configuring Tor fails, which I expected). GNOME integration is currently not great: * the fonts are very small (and perhaps blurrier?). FTR, I observe the same in Electrum. * Qt GUI elements (e.g. buttons) are fairly different than the GTK ones. My hope is that we could improve this with something like qt5-gtk-platformtheme, or perhaps themes like QGnomePlatform and adwaita-qt. This initial testing also tells me that there are quite some Whonix-specific stuff going on, so a-c-w will not be a drop-in-replacement, but require some substantial modification. I'll have a closer look next week, hopefully. > Well, unless I'm mistaken the alternative (the new Tor Launcher) will be in > the same situation (non-native, but probably using GTK somehow in the end), > so I think it would be unfair to treat a-c-w any different. Needless to say, > I want it to look no worse than Tor Launcher currently does, so I don't think > there's any disagreement. :) I take this back: (the old) Tor Launcher looks really nicely integrated in GNOME. 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] Substitute Tor-launcher with Anon-Connection-Wizard in Tails?
iry: > anonym: >> All this looks promising, so to answer your question whether we're >> interested: yes! :) > > Hi anonym! That sounds awesome! > >> I haven't looked at this in detail yet (from what I saw so far I >> think some people will be sad over it using Qt instead of GTK), > Just in case you, or anyone else are interested in the details of it, > here is some links: > > The details of the code can be found here: > https://github.com/irykoon/anon-connection-wizard > > The details of the development discussion can be found here: > https://forums.whonix.org/t/graphical-gui-whonix-setup-wizard-anon-conne > ction-wizard-technical-discussion/650/303 Thanks! >> but I've made a note that we might want to switch directly to it >> instead of the new Tor Launcher now in November: >> https://labs.riseup.net/code/issues/14555 > Thank you so much for your work! > > I have watched this ticket Cool! If we pick a-c-w that ticket will likely be rejected, and I'll open a new one about a-c-w but I'll do my best to add you as a watcher to that and related tickets in that case. > and please let me know if there is anything I can help with! I'd like to know how you feel about extending a-c-w so it deals with the network connection setup as well, as I have alluded to before [1]. I could imagine this benefiting from switching to a plugin architecture, where plugins correspond to pages in the wizard. Example: those wanting a-c-w to act as Tor Launcher would only load those plugins, but in Tails (and Whonix?) we'd also load the network connection setup plugin, the MAC spoofing plugin, and a Tails-specific "Congrats, your Tails is connected to Tor! Here are some recommendations of what to do next..." plugin that only we ship, or something like that. As for a larger collaboration, I could see us in Tails providing UX insight and GUI design work, and coding if necessary (although I'm sure you're eager to be the main developer, which would be perfect for us :)). Whonix and Tails could apply for funding together (increased probability of acceptance) to have us paid for doing this work and pay for UX research, user testing etc. Note that this is just *my* vague vision, and I have no clue how the rest of the Tails crew feels about it. :) What do you think? [1] https://tails.boum.org/blueprint/network_connection/ > Btw, these two links maybe useful on network connection blue print > page: https://tails.boum.org/blueprint/network_connection/ > > At Tor: > Tor UX team's design of new Tor launcher: https://marvelapp.com/3f6102d > > At Whonix: > The old blog post link may can be replaced by this one: > https://forums.whonix.org/t/graphical-gui-whonix-setup-wizard-anon-conne > ction-wizard-technical-discussion/650/303 Thanks! I've added/changed these. 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] Substitute Tor-launcher with Anon-Connection-Wizard in Tails?
intrigeri: > anonym: >> (from what I saw so far I think some people will be sad over it >> using Qt instead of GTK) > > As long as: > > * it's Qt5 (let's please stop adding apps that only work with the >obsolete Qt4; we already ship Qt5 and the corresponding Python >binding for OnionShare and Audacity anyway); It was ported to Qt5 in March, yay! :) > * it integrates nicely in a GNOME desktop (e.g. in terms of HIG ⇒ >consistent UI & UX). Well, unless I'm mistaken the alternative (the new Tor Launcher) will be in the same situation (non-native, but probably using GTK somehow in the end), so I think it would be unfair to treat a-c-w any different. Needless to say, I want it to look no worse than Tor Launcher currently does, so I don't think there's any disagreement. :) > What's the design for giving Anon-Connection-Wizard (and thus the > desktop user) limited privileges on Tor? In other words, is it > designed with OnionGrater in mind, and with a threat model in which > the user who runs the GUI is not trusted? (I'm mainly asking because > of the upcoming switch to Wayland and our strong desire to support > a11y technologies, various input methods, etc., that all require > running such a Tor config app as the desktop user.) tl;dr: migrating to a-c-w actually solves this problem for us, but not for the reason you anticipated. Long answer: I doubt a-c-w is designed with this in mind (and note that that means its no worse than (old|new) Tor Launcher), since Whonix doesn't use onion-grater like we do -- in Whonix it's used to filter on the host-level, not between processes/users like in Tails. But if we move to a-c-w we will be able to drop the dedicated user without any negative consequences! Let me explain: Tor Launcher is a XUL-application so it will run via the (unconfined, FWIW) Firefox binary, so that is the path we must match on in the Tor Launcher filter. That binary is also used by the Unsafe Browser, so to prevent it from accessing the Tor control port we also have to match on user (an alternative solution would be yet another unconfined-firefox copy). Instead of a dedicated user we could match on `amnesia`, but if that user is compromised an attacker could craft a Firefox add-on that runs any commands, and then run it through the Firefox binary as `amnesia` while being subject to the Tor Launcher filter's rather loose permissions (e.g. it can set an attacker-controller proxy => game over). Yup, onion-grater isn't ideal when the target application is extensible (or can run arbitrary code in some other way, e.g. an interpreter) and the filter allows dangerous commands. However, a-c-w is not extensible, so if we migrate to it we can simply match the onion-grater filter on its path and the `amnesia` user and we're completely locked down to commands that a-c-w can formulate through interaction with its GUI, and not arbitrary ones. So we're good! 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] Release schedule for Tails 3.2
Hi, I'll be the release manager for Tails 3.2, which is a major release scheduled on 2017-10-03. The list of tickets targeting Tails 3.2 can be found here: https://labs.riseup.net/code/projects/tails/issues?query_id=198 Whoops, there are 182 of them right now! :S I suppose (hope!) there is some triaging about to happen post-summit! Below you'll find the preliminary release schedule for Tails 3.2: * 2017-09-20: - Feature Freeze: All feature branches targeting Tails 3.2 should be merged into the `devel` branch by noon, CEST. I'm open to make exceptions if you can be online and responsive during that afternoon, but ask me first! - Build and upload Tails 3.2~rc1. - Start testing Tails 3.2~rc1 during late CEST if building the image went smoothly. * 2017-09-21: - Finish testing Tails 3.2~rc1 by the afternoon, CEST. - Release Tails 3.2~rc1. * 2017-10-02: - All branches targeting Tails 3.2 *must* be merged into the `testing` branch by noon, CEST. - The upcoming Tor Browser is hopefully out so we can import it. - Build and upload Tails 3.2 ISO image and IUKs. - Hopefully start testing Tails 3.2. * 2017-10-03: - Finish testing Tails 3.2 by the afternoon, CEST. - Release Tails 3.2 during late CEST. Testers, please let me know: * if you are available on 2017-09-20, late CEST * if you are available on 2017-09-21, morning to afternoon, CEST. * if you are available on 2017-10-02, late CEST. * if you are available on 2017-10-03, morning to afternoon, CEST. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Substitute Tor-launcher with Anon-Connection-Wizard in Tails?
Patrice Mannoni: > I highly recommend against this. Ack. But what are we supposed to do with a recommendation lacking any sort of argumentation/motivation? Please share your thoughts! > And hope it isn't implemented over the short-term. Tor Launcher (even the new one) would at best be a mid-term solution for Tails, since our long-term vision [1] goes beyond Tor Launcher, and we'd have to do implement something like anon-connection-wizard any way. Cheers! [1] https://tails.boum.org/blueprint/network_connection/ ___ 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] Substitute Tor-launcher with Anon-Connection-Wizard in Tails?
iry: > Hi Tails developers! > > Several months ago, anonym and I had a discussion about the future of > anon-connection-wizard on the @tor-dev[0], where he said: > >> [snip] Thanks for picking up this again! > Now, though there are still a lot of improvements can be done, > anon-connection-wizard is mature enough to be integrated into the > upcoming Whonix14. Congrats! > Therefore, I am wondering if Tails community still consider it as a > good idea to replace Tor-launcher with anon-connection-wizard when it > is mature enough? > > Apart from what has been pointed out by anonym above, the following is > some information that may be helpful for your decision: > > - Here is a recent post introducing anon-connection-wizard which also > contains a set of screenshots of it[1] > - the anon-connection-wizard UI is basing on Linda’s PET paper[2] and > Tor UX team’s proposal[3] to new Tor-launcher. > - although anon-connection-wizard has not been packaged into Debian > repository, all its dependencies are already available in Debian > - The future goal of anon-connection-wizard is to be packaged as a > generic standalone application into Debian so that it can be used by > different anonymity focused distributions like Whonix and Tails > - anon-connection-wizard do not assume user has a Tor or Firefox > browser to use, which is a low-coupling design All this looks promising, so to answer your question whether we're interested: yes! :) I haven't looked at this in detail yet (from what I saw so far I think some people will be sad over it using Qt instead of GTK), but I've made a note that we might want to switch directly to it instead of the new Tor Launcher now in November: https://labs.riseup.net/code/issues/14555 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] Reproduction of Tails 3.1 Failed
Thanks for participating! So the problem in your ISO image is that /etc/hostname gets all executable bits set, which shouldn't happen. I've filed this as: https://labs.riseup.net/code/issues/13623 nock, it'd be interesting to see if you can reproduce this issue again. So, can you please retry building Tails 3.1 in the exact same environment? 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] Changing Tails 3.0 release date? [Was: Planned release of stretch on 2017-06-17 and the last weeks up to the release]
intrigeri: > 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. I agree these are the only reasonable options we have. > Pros and cons: > > - Option A costs us one more "Emergency releases" i.e. 2.25 days >of work (release management + manual testing). Ouch. > - 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. > - 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. :) > - 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? 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. 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. Yup, I'm quite a lot in favor of option B. > 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. [I might consider sabotaging option A by pretending, as a reproducible buids person, that "Tails 3.0 will only be reproducible if we pick option B". Will I have to? :)] >> The final weeks up to the release >> = > > [...] > >> In the last week prior to the freeze, testin
[Tails-dev] image attachment
___ 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] Testing Tails 3.0~rc1
[Sorry if this is a ~repost -- my MUA crashed while sending the email.] anonym: > During mine and intrigeri's upcoming Stretch sprint we plan to build and > upload Tails 3.0~rc1 on 2017-05-19 and release it on 2017-05-20. Testers, > please let me and intrigeri know: > > * if you are available on 2017-05-19, late CEST > > * if you are available on 2017-05-20, morning to afternoon, CEST. We have bumped these dates with +1 day, so: We plan to build and upload Tails 3.0~rc1 on 2017-05-20 and release it on 2017-05-21. Testers, please let me and intrigeri know: * if you are available on 2017-05-20, late CEST * if you are available on 2017-05-21, morning to afternoon, CEST. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Testing Tails 3.0~rc1
anonym: > Hi, > > During mine and intrigeri's upcoming Stretch sprint we plan to build and > upload Tails 3.0~rc1 on 2017-05-19 and release it on 2017-05-20. Testers, > please let me and intrigeri know: > > * if you are available on 2017-05-19, late CEST > > * if you are available on 2017-05-20, morning to afternoon, CEST. We have bumped these dates with +1 day, so: We plan to build and upload Tails 3.0~rc1 on 2017-05-20 and release it on 2017-05-21. Testers, please let me and intrigeri know: * if you are available on 2017-05-20, late CEST * if you are available on 2017-05-21, morning to afternoon, CEST. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Testing Tails 3.0~rc1
anonym: > Hi, > > During mine and intrigeri's upcoming Stretch sprint we plan to build and > upload Tails 3.0~rc1 on 2017-05-19 and release it on 2017-05-20. Testers, > please let me and intrigeri know: > > * if you are available on 2017-05-19, late CEST > > * if you are available on 2017-05-20, morning to afternoon, CEST. These dates have been bumped +1 day, so: We will build and upload Tails on 2017-05-20 and release it on 2017-05-21. Testers, please let me and intrigeri know: * if you are available on 2017-05-20, late CEST * if you are available on 2017-05-21, morning to afternoon, CEST. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] About SquashFS default compression setting
intrigeri: > anonym: >> 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. :) Right, that's much better! 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] About SquashFS default compression setting
Arnaud: > Dear Tails, > > this is just a detail I'd like to discuss. > > When I did my first Tails build a while ago, I didn't specify any > SquashFS compression setting. So I expected the compression to be the > default. And amazingly, there's a setting called 'defaultcomp', which > correspond to xz compression. So I was a bit surprised to see in the > logs that I ended up with gzip compression instead. > > What I'm trying to say is that, from the point of view of the person who > builds Tails, there's no 'default' compression. The compression is > automatically chosen by the build system: xz for release, gzip otherwise > (tell me if I'm mistaken). > > So I think it's a bit misleading to have a setting named 'defaultcomp', > and it would be better named 'xzcomp'. > > What do you think ? I can open an issue and provide a patch if you agree > with me. Yeah, and it even used to be even worse, cause we hadn't unambiguously defined when a "release build" should occur before, but since the recent rework of the build system this is well-defined (build a release if and only if HEAD is tagged). Any way, a ticket and patches renaming them to `fastcomp` and `releasecomp` (or similar) would be welcome. This change will require some coordination with our infra's sysadmins, though, so it might take a while for it to be applied. Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails build system update
Arnaud: > Hi, > >> In order to get Tails builds reproducible, we had to refactor the way we >> use vagrant in our build system [1]. Under the hood, a lot of our build >> scripts have changed, but for most use cases the transition should be >> transparent. > > I have made some very minor cosmetic changes, I don't know exactly > what's the best way to submit it, I don't think it's worth opening a > ticket. You can have a quick look on my branch available here: > > https://gitlab.com/arnaud-preevio/tails/commits/arnaud/build-cosmetic Thanks, merged! Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails build system update
Vasiliy Kaygorodov:
> On Wed, May 10, 2017 at 6:20 PM, anonym <ano...@riseup.net> wrote:
>>
>>
>> Might I instead suggest that you add vmdebootstrap to your PATH, i.e.:
>>
>> export PATH="${PATH}:${HOME}/ve/tails/bin"
>>
>> so you can have a clean Git state ...
>>
>
> source ve/tails/bin/activate takes care about it, but PATH is not in the
> list of env_keep in /etc/sudoers on most distros, also for sudo commands
> PATH is set to whatever is in the secure_path - so setting PATH env
> variable for root won't work too.
Right, I forgot about `vmdebootstrap` being called wrapped by `sudo`, so forget
about the PATH nonsense.
Alternative: create a symlink /usr/bin/vmdebootstrap ->
${HOME}/ve/tails/bin/vmdebootstrap
> I'd solve it by having git-ignored
> builder-overrides.sh in vagrant/definitions/tails-builder/, and support for
> overrides in generate-tails-builder-box.sh - but IMO the effort/outcome
> ratio is pretty low here to bother (taking into account one does not have
> to build a new box after every rebase). Or what do you think?
If the above isn't good enough: sure, that would work, patches are welcome! As
would patches for the simpler approach where the path is given in an
environment variable (that defaults to `vmdebootstrap` if not set).
Cheers!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tails build system update
Vasiliy Kaygorodov:
> Edit vagrant/definitions/tails-builder/generate-tails-builder-box.sh and:
> - modify "vmdeboostrap" line with the full path to vmdeboostrap installed
> in virtualenv, e.g.: ${HOME}/ve/tails/bin/vmdeboostrap
Might I instead suggest that you add vmdebootstrap to your PATH, i.e.:
export PATH="${PATH}:${HOME}/ve/tails/bin"
so you can have a clean Git state ...
> export TAILS_BUILD_OPTIONS="${TAILS_BUILD_OPTIONS} ignorechanges" # since
> we did modify path to vmdeboostrap above
> rake build
... and this option is not needed.
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.
