Re: [Tails-dev] Requirements for a Pidgin replacement
Would this be an acceptable point to introduce the suggestion of a serverless communicator of some kind being included? Uses should be obvious, but in case not, it eliminates some MITM options and reduces reliance on infrastructure outside the intended participants. Some examples: Tox - definitely isn't mature enough yet (hasn't had any external audits) Ricochet - very reliable/stable (though a bit stagnant) and made to work with Tor onion services exclusively Serverless chat in XMPP (xep-0174, no known mature implementations) Ring (from Savoir-Faire) - development in full swing with a large and active team Ring and Ricochet are the strongest candidates as far as I can tell, but people with better knowledge of ideal crypto implementation might want to look over their choices. In any case, I'd like to see it in Tails, even if it has to mean including two separate clients. gl On 2016-01-27 10:01, intrigeri wrote: sycamoreone wrote (26 Jan 2016 22:03:00 GMT) : sajolida: intrigeri: I am also for keeping D separately. But the blueprint should document the use-cases A, B, C, and E that Pidgin and its potential replacement should address. And also the use-case D that it need not. Yes. I see that it's been done already (with a new nomenclature), cool! > I don't know of any tool that provides D _and_ another one among A, > B and C. So for the moment, I think that D should be solved separately. Exactly. Yes. I'm glad we agree on dealing with D separatedly. 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] Serverless chat [Was: Requirements for a Pidgin replacement]
ghostla...@autistici.org wrote (08 Feb 2016 09:01:59 GMT) : > Would this be an acceptable point to introduce the suggestion of a serverless > communicator of some kind being included? Yes, thanks for caring about this problem! Earlier in this thread we agreed to treat "D. One-to-one chat that protects metadata end-to-end" separately, mostly because in the current state of things, it can't be addressed with the same tools as the candidates we have to replace Pidgin ⇒ I'm renaming this subthread. On the Ricochet side of things, you'll want to have a look at https://labs.riseup.net/code/issues/8173, and in particular at the last set of updates. 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] ebuild for tails-installer
Miguel Angel Marco Buzunariz: > If you want to include this information in the web page, and need > some further explanations, please contact me. The way our documentation (eg https://tails.boum.org/install/debian/usb) is built is both quite complicated and new. So I want to take some time to think about how integrating new package in other distros. I didn't expect this to go this fast! :) I create https://labs.riseup.net/code/issues/11080 to track this. Once Gentoo is documented I think it will be easier to add more distros in there. > However, I think roght now it would be better to wait and see if > Austin English can manage to include the ebuild in the main portage > tree, which would make the process even simpler. I'm glad I'll have a bit more time to work on #11080 :) ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] [Tails - Feature #5991] Include BitTorrent software
Hi, sajolida: join forces and coordinate on #9563 I closed #5991: Include BitTorrent Software, since #9563 addresses the issue. Wordlife, Spencer ___ 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] Notes of the contributor-meeting-20160203
Hi, Meeting Notes: segfault wants to rethink the installation and upgrade process Where is this being tracked? I would like to follow along if permitted (: Wordlife, Spencer ___ 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] GNOME infrastructure needs to ease tails development
Hello, During FOSDEM someone asked for an easier way to track GNOME bugs as that would help tails development. I asked him (forgot the name) to send an email to bugmas...@gnome.org, but didn't receive anything yet. Is that still wanted? I suggested to add a keyword. Ok and what should it be called (tails?)? Anything else from GNOME side (e.g. infrastructure related) that would help? I never really followed tails. Just ask away on any topic. If it isn't possible or I don't know I'll say so. If no clue what to ask: I suggested same once to MATE. They took over a few git.gnome.org modules (incl tarballs on download.gnome.org). -- Regards, Olav ___ 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] Requirements for a Pidgin replacement
I think I lost track of the original message that started referencing the options according to letters :) I'd like to suggest an end alltogether of all-in-one communication clients. It may fit a Windows-style mode for use, but it contradicts one of the more elegant and sensible parts of the Unix philosophy, that being one application per task. Anyway what I'm getting at is in order to facilitate simplicity I think it might be helpful to talk about these things in terms of protocols or types of delivery that Tails wants to prioritize (rather than using client examples as the article of dialogue), and then choose a discrete and simple client for each, which will probably change of course as time goes by; ideally the protocols Tails supports in one way or another will not. Using this perspective, it looks to me as if there are really only a grand total of four clients needed here: SMTP, XMPP, IRC, and some form of serverless system. Is this thought disruptive in a good way or bad? It just doesn't seem like the hunt for an all-in-one client is going to be a good design choice in the long run, especially when individual clients can come relatively cheap size and code-wise. gl On 2016-01-27 10:01, intrigeri wrote: sycamoreone wrote (26 Jan 2016 22:03:00 GMT) : sajolida: intrigeri: I am also for keeping D separately. But the blueprint should document the use-cases A, B, C, and E that Pidgin and its potential replacement should address. And also the use-case D that it need not. Yes. I see that it's been done already (with a new nomenclature), cool! > I don't know of any tool that provides D _and_ another one among A, > B and C. So for the moment, I think that D should be solved separately. Exactly. Yes. I'm glad we agree on dealing with D separatedly. 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.
