Re: [Tails-dev] Next release: process, schedule and iceweasel backports
Ague Mill wrote (26 Sep 2012 13:48:11 GMT) : October 9th: 0.14 freeze + release of RC1. October 23th: ESR backport is (hopefully) available. October 25th: release of RC2. October 30th: release of 0.14. Fine with me. Suits me well. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] incremental upgrades: phase one almost done, release plan
Hi, (thank you for following-up :) a...@boum.org wrote (26 Sep 2012 17:43:09 GMT) : 2. When 0.13.x point-releases are out, write developers documentation and tools, prepare IUK, update update-description files, ask beta testers to try the incremental upgrade process. Catch and fix most remaining bugs. What is the state of this phase? Waiting for the next release. 0.13.x point-releases are out did not happen yet. Will we do that for the next release? If it's not a point release, then when will we do that? I'm unsure. I started thinking of this recently, but I was waiting for an agreement on my next release is 0.14 proposal. I think I'll want to prepare and publish an IUK for 0.14, and have some early testers try it. I'm not sure the developers doc and tools will be part of that first test. I've just updated the roadmap to reflect the state of my thoughts about this. Write user documentation [4] and hand it to translators. sajolida, do you want/plan to write the user documentation? Yes! I would be happy to work on that. I haven't done much work on the documentation since the persistence volume but that's sound like the perfect opportunity to catch up. What's the progress of the documentation? AFAIK, it's waiting for the first batch of IUK too. Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
berta...@ptitcanardnoir.org wrote (26 Sep 2012 18:28:06 GMT) : My fault, I did a simple merge and forgot the --no-ff option :/ How can I solve this? We won't rewrite history for such a tiny detail, so you cannot solve what already happened. However, you may solve it for future cases by writing a how to review and merge a branch checklist, that would contain often forgotten bits such as check that the design doc was updated, check that user doc was written and reviewed, use --no-ff, once merged, tag the ticket pending, etc. :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shipping a 686-pae kernel
12/09/12 11:05, intrigeri wrote: hi, anonym wrote (06 Sep 2012 18:27:37 GMT) : The crash occurs on my (64-bit) laptop. :/ Do you mean, on your own system (if so: both kernel / userspace 64-bits? Debian Wheezy?) or within Tails feature/multikernel with the 686-pae kernel? This was in Tails built from feature/multikernel. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shipping a 686-pae kernel
anonym wrote (27 Sep 2012 09:38:32 GMT) : This was in Tails built from feature/multikernel. Thank you. I updated the ticket accordingly. So, next step is: somehow fix our USB installer vs. the 686-pae kernel. I'm not committing to do it any time soon. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/hide_TailsData_volume
From: intrigeri intrig...@boum.org Date: Thu, 27 Sep 2012 09:18:25 +0200 a...@boum.org wrote (26 Sep 2012 17:42:56 GMT) : I can't find a ticket for this issue. Please file one or point me to the ticket I have missed. I'm happy you are playing the nitpicker role, but seriously, that one is a regression caused by a branch of yours, so don't you think *you* might want to follow-up on this and create the missing ticket? Right, done: https://tails.boum.org/todo/hide_only_current_running_TailsData/ Cheers -- pgpIJclKH1KRn.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Thu, Sep 27, 2012 at 09:26:51AM +0200, intrigeri wrote: berta...@ptitcanardnoir.org wrote (26 Sep 2012 18:28:06 GMT) : My fault, I did a simple merge and forgot the --no-ff option :/ How can I solve this? We won't rewrite history for such a tiny detail, so you cannot solve what already happened. That's what I thought, asked just in case I missed a trick. However, you may solve it for future cases by writing a how to review and merge a branch checklist, that would contain often forgotten bits such as check that the design doc was updated, check that user doc was written and reviewed, use --no-ff, once merged, tag the ticket pending, etc. Good idea. I think now I've made the mistake, it will already solve that part. But a documentation page would still be precious, so let's do that. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Integration of Tor, Tor Browser, Tor IM, Tor Birdy, Vidalia, Tor Router, Tails, etc.
Hi, a...@boum.org wrote (27 Sep 2012 10:05:14 GMT) : I don't think we replied to this email. Should we? Volonteers? I've had a look, and I don't think there is anything we have to add to the wiki page created by adrelanos, which is basically a long list of issues and usecases, including the ones we have. This is strongly related to https://tails.boum.org/todo/replace_iceweasel_with_Torbrowser/ Whatever implementation path we end up choosing, we will effectively contribute, in some way, to the effort adrelanos calls for. I think we still have quite some initial experiments to run before we know more clearly what path we pick, and thus what contribution to the wider Tor distributions ecosystem we make. So, all in all, apart of we acknowledge these issues and usecases exist, and yeah, that would be great if $SOMEONE did the work to solve all of these, I'm not sure what useful input we could bring, as of today, into the discussion started by adrelanos. adrelanos, did you read me, or should I forward this to you? :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] live-boot_3.0~b4-1_i386.changes ACCEPTED into unstable
Hi, Debian FTP Masters wrote (27 Sep 2012 11:32:32 GMT) : Changes: live-boot (3.0~b4-1) unstable; urgency=low . * Switching to final name for the persistence configuration file 'persistence.conf' in line with boot parameter. [...] Is this change really meant for the 3.x series, or is this the result of some unfortunate mistake? If it is really meant for 3.x: I wonder what the reason for this switch is, given the Git commit message is voiceless on the matter, which was discussed and decided upon months ago. I'm quite surprised this change happens *now*, because IIRC, the deadline that Daniel set for user interface changes in the 3.x series is now quite far in the past, and that change breaks already deployed persistent volumes that use the old agreed upon name. FWIW, as far as Tails is concerned, either backward-compatibility is ensured, or we'll have to ship a patched live-boot (again), or we'll have to add some custom logics to rename existing deployed configuration files :( Daniel, what about supporting the old filename as well as the new one? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/assymetric_gpgApplet [sic!]
24/08/12 09:21, intrigeri wrote: anonym wrote (22 Aug 2012 08:53:02 GMT) : All is merged into experimental. Thanks. Unfortunately, I forgot to merge it at pre-freeze time, and unfortunately nobody noticed it in time since the todo/qa tag was not set after the last development round, so that will be stuff for the 0.14 merge window. I updated the ticket to reflect the current state of things. Sorry about that :( Let's make sure this gets merged in time for the Tails 0.14 freeze (which seems to be October 9th). That will require an overhaul of the current documentation on how to use OpenPGP. I had a quick look and this is what has to be updated: doc/encryption_and_privacy/openpgp_passphrase_encryption (symmetric) The context menu for gpgApplet is now different, so both screenshots (encryption and decryption) have to be updated. doc/encryption_and_privacy/openpgp_with_gedit (asymmetric) -- This page should be renamed since gpgApplet is to be used, not gedit. Perhaps openpgp_public_key is a better name. Then the pages content has to be heavily re-worked for the same reason. Actually there may be a point in uniting these pages into a single one now since the same tool is used in both cases. Thoughts? sajolida, were you committed to this? Cheers! signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/assymetric_gpgApplet [sic!]
27/09/12 15:19, intrigeri wrote: hi, anonym wrote (27 Sep 2012 13:09:17 GMT) : doc/encryption_and_privacy/openpgp_passphrase_encryption (symmetric) The context menu for gpgApplet is now different, so both screenshots (encryption and decryption) have to be updated. While we're at it, we could drop screenshots (as adviced by GNOME documentation guidelines, that some of us found very inspiring) and get rid of this problem. At first I intuitively felt strongly opposed to this, but after reading the relevant part of GNOME-STYLE [1] and thinking some about this, I now agree. I still think we should keep the screenshot for locating the applet, though. [1] http://developer.gnome.org/gdp-style-guide/stable/infodesign-8.html.en#infodesign-10 doc/encryption_and_privacy/openpgp_with_gedit (asymmetric) -- This page should be renamed since gpgApplet is to be used, not gedit. Perhaps openpgp_public_key is a better name. The symmetric one is called openpgp_passphrase_encryption, so perhaps we want to have this one contain _encryption too? Sure. Let's say openpgp_public_key_encryption then. Actually there may be a point in uniting these pages into a single one now since the same tool is used in both cases. Thoughts? I'm not sure the same tool is used is a good criterion for deciding how we organize end-user documentation. These are pretty different usecases, probably targetting quite different people, so I'd rather keep separate (shorter) pages. E.g. some people use symmetric encryption, and don't even know any other kind of encryption exists, so pointing them to a page where both are documented may be an additional factor of confusion. Keeping these pages separate also makes it easier to link to the one or the other. You may be right. OTOH, some parts will be (largely) duplicated, like how to find the applet in the notification area, the explanation that gpgApplet operates on the clipboard, and how to decrypt/verify stuff. Cheers! signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Integration of Tor, Tor Browser, Tor IM, Tor Birdy, Vidalia, Tor Router, Tails, etc.
Jacob is about or is already working on it. https://trac.torproject.org/projects/tor/ticket/6948 intrigeri: adrelanos, did you read me, or should I forward this to you? :) I did read *this* e-mail, no others. And I am subscribed to tails-dev, although I can't read *all* tails-dev mails. Some stuff does not apply to me. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] tails_htp SSL fingerprint pinning
Hi, I think it would be good if tails_htp security would be further improved. Anyone able to break SSL can tamper with the user's clock. This leads to at least two known problems. https://sourceforge.net/p/whonix/wiki/Security/#whonixs-secure-and-distributed-time-synchronization-mechanism (To be fair, I wrote that.) If the clock is too much off, it's also easy for an adversary's webserver to detect Oh, that's the Tor Browser user who's clock is X in past/future., thus allowing the adversary to link all sessions to the same pseudonym. Also quoting again: https://tails.boum.org/contribute/design/Time_syncing/ If your bridge also can setup a SSL MitM attack against the HTP connections (e.g. the attacker also controls a SSL CA shipped by Debian), it can trick you into using this old consensus for max. one week, which is much worse. It is now possible to pin certificates in curl. Pin the SSL public key for real, not the much weaker method of pinning the certificate authority: https://sourceforge.net/p/whonix/wiki/Dev_sslcertpinning/ (It was possible before, but no one except the curl devs knew about.) Why not start pinning certificates? I can think of multiple paths depending on cooperation of the tails_htp remote servers. Idea 1 (least secure, least maintenance): At build time we download the SSL public certificates, verify they are valid using CA and hope at build time they were legit. Use the downloaded certificate for certificate pinning. Problem: SSL certificates expire. Idea 2: Ask the website owners if they can publish the gpg signed fingerprints of their SSL public keys. Problem: SSL certificates expire. Idea 3 (most secure, least maintenance, most one time work for website owners): They install a second self signed SSL certificate (for a part of their website) and and publish a gpg signed message with SSL public keys fingerprints. Cheers, adrelanos ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
