Re: [Tails-dev] Changing Tails 3.0 release date?
On Thu, 2017-06-01 at 10:18 +0200, intrigeri wrote: > hi! > > anonym: > > intrigeri: > > > I'll make the call as the 3.0 release manager if no consensus > > > emerges, > > After re-reading this discussion, it appears that the only people > substantially affected by this decision (apart of Tails users of > course) will be myself and our usual manual testers. So I'll make the > call by the end of this week, depending on how I feel about committing > to RM'ing an extra release. I may follow anonym's very reasonable > position, or go crazy for the sake of communication and > Debian/Tails/FOSS relationships. I'm undecided yet and want to sleep > on it and balance all this very carefully. > > > > A. Coordinate Tails 3.0 and Debian Stretch releases > > [...] > > > B. Don't bother and proceed as our calendar says > > > - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x: > > > this work has been based on the Tails 3.x codebase so far. I don't > > > know if rebasing it onto the stable branch would be trivial, or > > > a lot of work. anonym, what's your feeling? > > Cherry-picking these commits will not result in any difficult conflicts > > (it's mostly > > about s/32/64/, and some jessie vs stretch test suite images). But there > > could be > > issues with running 7.0a4 on Tails Jessie/i386 -- we haven't tested the 7.x > > series at > > all on that platform. Still I definitely believe it quite a bit more likely > > to Just > > Work rather than introduce issues we don't see on Tails Stretch/amd64. So > > my feeling > > is that this should be an hour of work. > > OK, thanks for the insight! > > > > - Option B is less work, therefore it increases the chances that we > > > manage to make 3.0 build reproducibly, which gives us good > > > communication opportunities. So: > > > > > > [...] > > > > > > * anonym (who is our lead developer on the reproducibility front): > > > if we go with option B, how confident are you that 3.0 can > > > build reproducibly? #12608, #12567 and #12566 should be good > > > starting points. > > At least for me, locally, the only problem I see (after applying all > > unmerged fixes) > > is that Chris' patch for #12567 seems to miss some case. I've asked for an > > ETA of > > a fix. So assuming Chris is available, or I manage to identify and fix the > > issue, > > it's looking really good. :) > > Great :) > > > > Other pros/cons or thoughts? > > A con for option A: > > * Users will be prompted to do two updates within four days, which > > is a bit much both in terms of nagging frequency, bandwidth > > usage, and pure inconvenience. > > Absolutely. This will be particularly painful for those who will have > to do a manual upgrade to 2.12.1, as everyone will have to do a manual > upgrade to 3.0 anyway. > > On the other hand, if 2.12.1 is a thing, we give users almost two > months to upgrade to 3.0 (vs. 0 days if we don't release 2.12.1), > which is nice as they're often scared by such drastic change; also, > anyone affected by a serious regression can temporarily downgrade to > 2.12.1 until Tails 3.1 fixes their problem. > > So all in all it's not clear cut to me which option provides the > greater UX (once considering dozens of thousands of real-world users, > and not only some theoretical, ideal one who would immediately upgrade > to 3.0 and not have any big problem with it). Agreed IMHO users come first ... continuity is not an optional. 3.x can wait > > I'd also like to stress (pun intended!) the fact that option A's "more > > work" (as in > > an extra release, 2.12.1) is not so suitable at this time. I think we're > > collectively > > exhausted, and should try to take whatever breaks we can. > > OK, thanks for sharing, I want to take this into account. > > I'm committed to be the RM for 3.0 already; I understand you don't > feel like taking care of 2.12.1 so let's assume I would handle both > releases myself (if I convince myself that option A is the way to go). > And then the additional work is only on my shoulders (I don't feel > exhausted personally) and manual testers' (no idea how they feel about > it, but we had no problem getting manual testers recently, did we?). > > In passing: we have 4 emergency releases budgeted this year, and we > did none of them yet. Given this data + the feelings you're sharing, > I think we should acknowledge that we probably won't do more than > 2 emergency releases this year. If you agree, I'll update our > accounting accordingly, so nobody counts on (paid) RM work that's > unlikely to happen in practice, first because there's no need for it, > second because our RMs are not exactly thrilled at the idea of doing > this work. Fair enough? > > > Yup, I'm quite a lot in favor of option B. > > Got it. > > > > The decision algorithm I intend to use is: > > > > > > - If the reproducible builds people tell me they can make 3.0 > > > reproducible and communicate
Re: [Tails-dev] CBC malleability attack
On Wed, 2013-12-25 at 21:34 +0100, intrigeri wrote: Hi, Marco Calamari wrote (24 Dec 2013 11:42:36 GMT) : After readint the descritpion of this attack (injection attack type against LUKS-CBC volumes) http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ I check that my persistent partition (built a lot of TAILS version ago) is of CBC type. If an attacker gets write access to a Tails USB stick, they can as well corrupt the initramfs or some other part of the system, and from there have a persistent file be modified during next boot, without having to guess what block this file is stored at in the persistent volume. Seems easier than the attack against CBC, no? Or did I miss the threat model you had in mind? Hi no, absolutely, you're right; but CBC is under critics since a long time, so at least doing persistency without it should not need an explicit danger, but only because it is not best of breed and the alternative block cypher is already there and comes for free Time to switch to XTS and/or warn user having CBC partition to reformat? Note that cryptsetup 1.6 defaults to XTS. Once Tails is based on Wheezy, we might want to install this version, assuming a backport is not too painful to produce and maintain. Anyone volunteering to try this? Additionally, this would provide compatibility with the on-disk TrueCrypt format (which is not very useful until the rest of the udisks / GNOME Disks / Nautilus stack has this support, wishlist bug reported there a while ago, needs someone to write the code). -- +--- http://www.winstonsmith.org ---+ | il Progetto Winston Smith: scolleghiamo il Grande Fratello | | the Winston Smith Project: unplug the Big Brother | | Marco A. Calamari mar...@marcoc.it http://www.marcoc.it | | DSS/DH: 8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B | + PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 --+ signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] CBC malleability attack
After readint the descritpion of this attack (injection attack type against LUKS-CBC volumes) http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ I check that my persistent partition (built a lot of TAILS version ago) is of CBC type. Time to switch to XTS and/or warn user having CBC partition to reformat? Thanks a lot and good X-mas -- +--- http://www.winstonsmith.org ---+ | il Progetto Winston Smith: scolleghiamo il Grande Fratello | | the Winston Smith Project: unplug the Big Brother | | Marco A. Calamari mar...@marcoc.it http://www.marcoc.it | | DSS/DH: 8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B | + PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 --+ signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Ticket #5705, desktop integration of cryptsetup TrueCrypt support
On Sat, 2013-10-05 at 22:17 +0200, intrigeri wrote: Marco Calamari wrote (05 Oct 2013 17:58:09 GMT) : One doubt; a corrupted encrypted volume id a really bad thing; is this feature stable from this standpoint? At least it's not documented as experimental. I suggest asking the cryptsetup maintainers, if you want a more authoritative answer :) WIll check for sure Truecrypt volume header have no signature, and cannot be seen in any way; it is indistiguishable from binary noise. Truecrypts devices looks as unformatted empty devices or partitions, or noise-filles files. OK, but then GNOME Disks and Nautilus could have a way to this is a TC volume, please unlock it. Gnome disk, Nautilus and NSA, all three cannot have that. Only possibility I see, to put some info in a persistent file of Gnome. But just a request telling something like. In the past you mounted this partition as Truecrypt container; wand to do that again? If yes, gimme password With no persistent properties, Nautilus may only look at all partitions, see those with no readable header of known type, and ask a possible mount for them. JM2C. Marco -- +--- http://www.winstonsmith.org ---+ | il Progetto Winston Smith: scolleghiamo il Grande Fratello | | the Winston Smith Project: unplug the Big Brother | | Marco A. Calamari mar...@marcoc.it http://www.marcoc.it | | DSS/DH: 8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B | + PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 --+ signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Ticket #5705, desktop integration of cryptsetup TrueCrypt support
On Mon, 2013-10-07 at 12:28 +0200, intrigeri wrote: Hi Marco, Marco Calamari wrote (07 Oct 2013 09:38:32 GMT) : OK, but then GNOME Disks and Nautilus could have a way to this is a TC volume, please unlock it. I suspect that I'm wasting the time of list readers. What I said is in favour of Truecrypt to remains included, in TAILS, also a deprecated option, until a mature and better option of LUKS will be avalaible in Debian or Debian-Backports (Cryptsetup 1.6.0) can be included in TAILS. (tcrypt option) About desktop automation, I propose nothing, but simply tell that no easy desktop automation can be done if you cannot say that an encrypted volume is there, without reliyng on dirty tricks like use of persistence. IMO, no desktop automation is needed in this particular case. JM2C. Marco -- +--- http://www.winstonsmith.org ---+ | il Progetto Winston Smith: scolleghiamo il Grande Fratello | | the Winston Smith Project: unplug the Big Brother | | Marco A. Calamari mar...@marcoc.it http://www.marcoc.it | | DSS/DH: 8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B | + PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 --+ signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Ticket #5705, desktop integration of cryptsetup TrueCrypt support
On Sat, 2013-10-05 at 14:43 +0200, intrigeri wrote: Hi, irregula...@riseup.net wrote (05 Oct 2013 12:12:09 GMT) : I made some simple tests in Debian testing to review desktop integration. Great, thanks! This was enough to motivate me to (procrastinate and) create tickets for the next steps. A user can open a Truecrypt container using cryptsetup in command-line with root privileges. I think that can be handled with sudo. Still, one could say it's complicated for the average user to fire up command line to open a Truecrypt container. That's a minus. This is a great news! Average user that can understand giving an optional boot parameter manage Truecrypt panel, will not have difficulties (IMO) using command line with some guide. After this, there is always space to make things better and easier, but this is a path than can be decided in a not-so-distant future. One doubt; a corrupted encrypted volume id a really bad thing; is this feature stable from this standpoint? Gnome Disk Utility seems not to recognize the Truecrypt volume as it does with say a LUKS volume. It just shows an unknown format's file with size equal to the Truecrypt volume, assigned at a loopback device. AFAIK, Luks volumes start with a signature, that make a volume recognizable. Truecrypt volume header have no signature, and cannot be seen in any way; it is indistiguishable from binary noise. Truecrypts devices looks as unformatted empty devices or partitions, or noise-filles files. Thanks. Marco Added this info to the blueprint: https://tails.boum.org/blueprint/replace_truecrypt/ So, it looks like the next thing to do is: #6337 - Add support for TrueCrypt volumes in udisks I've created this ticket in our bug tracker, and requested the feature upstream: https://bugs.freedesktop.org/show_bug.cgi?id=70164 This upstream feature request has way more chance to be fulfilled if someone proposes a patch. Any taker? -- +--- http://www.winstonsmith.org ---+ | il Progetto Winston Smith: scolleghiamo il Grande Fratello | | the Winston Smith Project: unplug the Big Brother | | Marco A. Calamari mar...@marcoc.it http://www.marcoc.it | | DSS/DH: 8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B | + PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 --+ signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Tails Truecrypt
As a fanatic supporter of Tails, I just want to rememebr how Truecrypt is widely diffused as easy crossplaform tool. I do not want to open another big thread about story, doubts, finding and opinions about Truecrypt, but just to point one question. We agree that the not-torified browser was an horrible but useful thing, and after careful proscons balance, the right decision was adopted, and now it is there. Because of this, I suggest to reconsider the log time announced Truecrypt sooner o later drop. There is no problem of space (we are in the DVD size since long), the feacture is activable only as kernel parameter, so why drop it when can be so useful for encryption-savvy people? I think that the current way to activate Truecrypt shield it from naive users. On the contrary, I'll prefer to see it cited explicitely in the interface as deprecated possibility (as the untorified browser is). OTOH licence problem IMO can be solved in some way. JM2C. Thanks to all. Marco -- Marco A.Calamari - Board Member marco.calam...@logioshermes.org +39.347.8530279 HERMES - Center for Transparency and Digital Human Rights Not for Profit association - Via Aretusa 34, IT-20129 Milan, Italy t. +39-02-87186005 (voicemail) f. +39-02-87162573 TaxCode: IT-97621810155 | EuropeAid: IT-2012-AOD-0806909254 w. http://logioshermes.org | m. i...@logioshermes.org signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Custominzing for out-of-the-bix use
On Sun, 2013-06-30 at 12:54 +0200, intrigeri wrote: Hi Marco all, Marco Calamari wrote (27 Jun 2013 05:01:25 GMT) : We are interested to make preloaded usb keys for use of Globaleaks application for whisteblowers thru Tails. I'm glad I read this :) We simply need to autoconnect to a secure web application in an automated fashion, using an https link or directly the .onion, not using the default startup page The default startup page is here to convey important news about the Tails project, that we feel to users need to read. So, you probably need to find another way to convey this information to users, once you've replaced the default browser homepage. Maybe this alternative way could be shared between regular Tails and your fork, by the way :) Yes, doing rebuild is one of the direction in wice we are moving, but a simple persistent customization of the main release via persistence has different purposes. Like a sport car to have fun, fast but that need a lot of care, respect a 20 years old lifeboat, found JIT when the ship sunk. I try to use persistence to make some trivial changes to the login process: 1) change login page URL for the autostarted iceweasel (important) We set the homepage URL depending on the chosen locale with a custom Firefox extension (/etc/iceweasel/profile/extensions/brand...@amnesia.boum.org/) that's copied to ~/.mozilla/firefox/default/extensions/ at boot time. Note that this implementation path may not work in the future: conflicts might arise once Torbutton uses something similar itself, so we might have to revisit this. 2) change desktop background (useful) That's a GConf key. See how the NetworkManager persistent connections preset works (it makes /home/amnesia/.gconf/system/networking/connections persistent + there's a hack in live-persist to make it work) 3) adding desktop icon for further documentation (nice-to-have) Simply making ~/Desktop/ persistent may work. However, it's likely that Tails based on Wheezy does not ship with anything like a Desktop anymore (GNOME3 classic mode defaults), so perhaps you instead want to anticipate this move, and find a better long-term entry point for your additional doc? Good news is that the existing link to Tails documentation can probably use the same path, so your efforts will help Tails! Glad to know this. Hope to have a finished work soon. I know (but not where to find instruction) that with a rebuild I can make changes and prepare a customized version of Tails, https://tails.boum.org/contribute/build/ but I woul prefere a lot to stick with the official version using persistence to do that I'm curious how you intend to ship the Tails + persistence stack to users. Will they share a common persistent volume encryption key? Yes, we of course already considered this issue. Worst, we plan to give preinstalled persistent USB keys with a predefined password for persistence equal for all copies. We'll give instruction to change it immediately (and how to do this) and to reinitialize the encrypted partition (why and how to do this) But target are totally non technical users that normally goes abroad in Internet Cafe' and use Gmail a weak solution is far, far better than current situation, and has a simple and straightforward path for hardening. But I'm aware that this is an highly controversial issue. Thanks for you help, understanding support. BTW, are Tails-related event planned during OHM2013? Thanks. Marco -- Marco A.Calamari - Board Member marco.calam...@logioshermes.org +39.347.8530279 HERMES - Center for Transparency and Digital Human Rights Not for Profit association - Via Aretusa 34, IT-20129 Milan, Italy t. +39-02-87186005 (voicemail) f. +39-02-87162573 TaxCode: IT-97621810155 | EuropeAid: IT-2012-AOD-0806909254 w. http://logioshermes.org | m. i...@logioshermes.org signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Custominzing for out-of-the-bix use
Hi all, We are interested to make preloaded usb keys for use of Globaleaks application for whisteblowers thru Tails. https://globaleaks.org/ https://github.com/globaleaks/GlobaLeaks/wiki Globaleaks is an application aimed to allow a secure whisteblowing process thru Tor and a specialized Tor hidden service We simply need to autoconnect to a secure web application in an automated fashion, using an https link or directly the .onion, not using the default startup page I try to use persistence to make some trivial changes to the login process: 1) change login page URL for the autostarted iceweasel (important) 2) change desktop background (useful) 3) adding desktop icon for further documentation (nice-to-have) but changing iceweasel setup, startup applications and Gnome destop preferences doesn't work for that. I know (but not where to find instruction) that with a rebuild I can make changes and prepare a customized version of Tails, but I woul prefere a lot to stick with the official version using persistence to do that Including GlobaLeaks acces in Tails should be, IMHO, a good enhancement for both application. May you help in some way? Thanks. Marco Calamari -- Marco A.Calamari - Board Member marco.calam...@logioshermes.org +39.347.8530279 HERMES - Center for Transparency and Digital Human Rights Not for Profit association - Via Aretusa 34, IT-20129 Milan, Italy t. +39-02-87186005 (voicemail) f. +39-02-87162573 TaxCode: IT-97621810155 | EuropeAid: IT-2012-AOD-0806909254 w. http://logioshermes.org | m. i...@logioshermes.org signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Storing keyboard lamguage preferences
When using persistence on USB stick, is there any automatic or easy way to store preferences like interface language, keyboard language keymap in a way they are restored at next reboot? Thanks. Marco -- +--- http://www.winstonsmith.org ---+ | il Progetto Winston Smith: scolleghiamo il Grande Fratello | | the Winston Smith Project: unplug the Big Brother | | Marco A. Calamari mar...@marcoc.it http://www.marcoc.it | | DSS/DH: 8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B | + PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 --+ signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Promoting Persistence features
On Mon, 2012-11-26 at 15:20 +0200, Maxim Kammerer wrote: On Mon, Nov 26, 2012 at 3:03 PM, Marco Calamari mar...@marcoc.it wrote: 2) adding a change persistence password in Utility menu would be a probably cheap but really useful feature. It would be a misleading feature, since due to wear leveling on solid state media, parts of old LUKS header may be recoverable. On the other hand, it's always possible to add a warning. Agreed, but this is not the only situation adversely affected to solid-state memories. LUKS header fits in a cluster and is normaly unchanged, so his remapping due to the wearing-leveller actions seems at least rare, if ever. And Carol will need to password-crack against all free blocks ... looks really an unreasonable scenario. OTOH having an unchangeable password from a security perspective is IMO simply unacceptable. A lot of user scenarios make this needed, forbid this oblige the user to copy the user area, wipe the media, reformat, reinstall the whole stuff if password is to be changed, and this can be needed for a lot of well-known reasons. We know how to do this from command line, but mr. AverageTailsUser IMO will not ... JM2C. Marco signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Promoting Persistence features
On Mon, 2012-11-26 at 14:41 +0100, intrigeri wrote: 2) adding a change persistence password in Utility menu would be a probably cheap but really useful feature. Doesn't the GNOME Disk Utility allow to change the LUKS volume passphrase already? Perhaps what's needed is some documentation only? Err... the mandatory answer is yes but making this firsthands looks an useful interface characteristic, also to possibly give a warning about theoretical LUKS header persistence as Maxim pointed out in the previous message. A two liner script can do that OTOH this is the neverending issue about how much who write software need and want to protect the user form himself . Marco signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] A really basic question.
Apart from remembering it (more difficult with age) or reasoning starting from kernel version, is there any way to know what version of Tails is in use? I think that should be evident somewhere; is the base of the warning system.. But maybe is already there, so pls help me to find ... Ciao.Marco -- +--- http://www.winstonsmith.org ---+ | il Progetto Winston Smith: scolleghiamo il Grande Fratello | | the Winston Smith Project: unplug the Big Brother | | Marco A. Calamari mar...@marcoc.it http://www.marcoc.it | | DSS/DH: 8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B | + PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 --+ signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Arbitrary DNS queries... and Tor 0.2.2.x
On Wed, 2011-07-27 at 12:22 +0200, intrigeri wrote: Hi, a...@boum.org wrote (27 Jul 2011 07:36:55 GMT) : I think it makes a lot of sense to actually switch the devel branch to the current Tor beta version when it's available. By doing so, we might notice bugs that other Tor users would not. Hrm... I'm not sure your proposal is taking into account that our devel branch is not an experimental playground, but rather something meant to become a Tails stable release at some point. According to this proposal, completed by the lines you wrote bellow, we would not be able to get a Tails major release out during the [ first beta, stable release ] time span, which does not seem reasonable to me. In this particular case, I think it's a reasonable blocker to m actually wait for the Tor project to declare the 0.2.2 branch as stable before releasing Tails 0.8. FroM a concerned user point of view, I totally agree to stick with stable Tor branch. Exception to this general rule can of course happen for serious reasons, but the current one seems not enough important to me JM2C. Keep up this good work! Marco signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://boum.org/mailman/listinfo/tails-dev
