Re: [Tails-dev] To register as Vendor
Hi, (I'm not speaking for the project at large -- if others disagree, please speak up and explain why :) Sindhu Jayakumar wrote (15 Oct 2014 09:07:31 GMT) : > We have added your distribution to our online shop www.zyxware.com/shop. > The link is http://www.zyxware.com/requestcd?&distribution_name=Tails > It would be great if we could formalize our relationship by registering as > a vendor [...] In the current state of things, sadly we cannot recommend Tails users to buy already made Tails devices, for two main reasons: * It's not easy to verify that the OS on the purchased device is genuine. Verifying this is key in the security Tails aims to provide. * We release every 6 weeks, so that users who buy a DVD from you will have to either keep running it and be affected by serious security issues in the future, or buy another one every 6 weeks, or learn how to download, verify and install Tails themselves. More details on https://labs.riseup.net/code/issues/7269. So, I'm afraid we cannot answer your request positively *yet*. Help would be much welcome to address the verification issue described above :) Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Time syncing design question
Hi, Sebastian Hahn wrote (14 Sep 2014 13:27:20 GMT) : > In the security discussion[0] it is mentioned that replaying consensuses > older than one week won't work, due to onion keys. I'm not sure this is > accurate: If I manage to do a sybil attack and get my 10 million relays > into the consensus, I could just not rotate onion keys on those relays > and use the consensus indefinitely, no? Am I confused about anything, or > was this forgotten? > Thanks for any pointers. Please CC me on replies, I'm not subscribed to > this list. > [0]: https://tails.boum.org/contribute/design/Time_syncing/#index1h2 anonym, you're the time sync' expert here => may you please have a look? Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] TBB in Tails: Release timing in general
Hi, For years Tails has shipped with an Iceweasel with the (relevant) Tor Browser patches applied. It has worked ok, but it's been high maintenance, and keeping the preferences synced with TBB was a bit of a chore, among other issues. Since Tails 1.2 we've migrated to installing the Tor Browser from the actual (32-bit Linux) TBB tarballs you distribute. We're very much interested in your comments on how we do this, so please have look at our design page: [1] [1] https://tails.boum.org/contribute/design/#index40h3 The main source of *potential* issues this has introduced is the added dependency on the timing of your TBB releases (rather, when the tarballs are made available). We aim at releasing Tails with a browser based on Firefox X.Y.Zesr on the same day as Mozilla officially releases it, i.e. every sixth Tuesday. Due to the time required for Tails' release process (including QA) that means that we need the final TBB tarballs based on that Firefox release *at the very latest* 24 hours before the planned Tails release. Just to get an idea, let's have a look at TBB's release history. Below I'll list the last -buildX tag for a given TBB release that upgrades to a new Firefox ESR (but I'm skipping exceptions outside the 6-week cycle) and the timing of when the tag was made vs the "ideal" time of a Tails release, which we say is at 18:00:00 (UTC) on the Firefox ESR (official) release day. Just to be clear, a high timing value is good for Tails. TBB release tag Tag date (UTC) Timing vs ideal Tails release tbb-4.0-build12014-10-13 17:34:22 +24 hours tbb-3.6.5-build1 2014-09-01 05:48:33 +36 hours tbb-3.6.3-build1 2014-07-24 08:58:10 -39 hours tbb-3.6.2-build6 2014-06-11 13:30:06 -19 hours tbb-3.6.1-build1 2014-05-06 12:19:26 -138 hours tbb-3.5.3-build1 2014-03-17 23:05:35 +19 hours tbb-3.5.2-build5 2014-02-07 18:14:41 -72 hours So, now we assume that the "Tag date" above also is the time when the tarballs are made available for download (and preferable announced on tor-qa@). Given that we want at least a +24 hours, this history doesn't look super promising for our (Tails') plans. I'm not sure the above assumption is very sound, though; for instance, the initial 4.0 tarballs (before the rebuild for POODLE but we're ignoring such exceptions) was announced on tor-qa@ on 2014-10-13 10:19:08 (UTC), which was 7 hours before the tbb-4.0-build1 tag. In any case it's true that if Tails had migrated to using the TBB in the beginning of 2014, we'd have trouble with several of our releases due to late TBB rebuilds. Of course, I'm not complaining that you have misbehaved. :) So far you haven't been working as an upstream for other projects so that they get a time window to include TBB and then do a same-day releases with you, e.g. like how Mozilla is an upstream to you, and was an upstream for Tails prior to our TBB-migration. However, do you think you can become such an upstream for Tails by trying to provide the time window detailed above? If you believe that window is too narrow, I suppose Tails could drop the "same-day release" goal and adopt a "day-after release" goal or possible even later. What do you think is possible? How can we help? To get a more concrete understanding of what exactly I'm proposing, let's use the next Tails release, 1.2.1, as an example: It's aimed to be released at 2014-11-25 18:00:00 (UTC), the same day as Firefox 31.3.0esr will be officially released. We'd need the (final) TBB (32-bit Linux) tarballs based on that Firefox version at the latest 24 hours before that, i.e. 2014-11-24 18:00:00 (UTC). Does that seem reasonable? I'm actually genuinely interested in an answer to this specific question, since I'm writing the Tails 1.2.1 release schedule as we speak and may have to adjust it if this turns out difficult for you to "promise". 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 1.2.1
Hi, I'll be the release manager for Tails 1.2.1, scheduled to be released on 2014-11-25. I'll start with the schedule part for the preparation of the final release: 2014-11-24 TBB 4.x based on Firefox 31.3.0esr is *hopefully* out Tag 1.2.1 in Git Build and upload 1.2.1 ISO and IUKs 2014-11-25 Test (early CEST) and release (late CEST) Tails 1.2.1 Yup, I've now adopted a test-and-release-on-the-same-day strategy. I think I've only seen one instance when having a dedicated day for testing was useful, and that was when we had to rebuild Tails 1.1. So while that is useful, it's just not realistic any more now that we've migrated to using the TBB; their release history shows that the final tarballs rarely are available that early. In the above schedule it's assumed that we'll have the TBB tarballs on 2014-11-24, and we'll have to see if that works out. [1] Expect updates to this schedule, so please pay attention for new posts in this thread and on the calendar [2] (now updated)! [1] https://lists.torproject.org/pipermail/tbb-dev/2014-October/000143.html [2] https://tails.boum.org/contribute/calendar/ So, Tails contributors, please let me know which of you are available for testing the final image on 2014-11-25 (early CEST)! Next up, the preliminary release schedule for the 1.2.1 release candidate, *if* we feel we need one: 2014-11-05 Feature freeze 2014-11-12 Tag 1.2.1~rc1 in Git Build and upload 1.2.1~rc1 ISO/IUKs 2014-11-13 Test (early CEST) and release (late CEST) 1.2.1~rc1 So we haven't had an RC for a point-release since 0.22.1-rc1 (unless we count 1.0 as a point-release) and I believe that one wasn't even formally released and tested. As I've recently become something like the Eternal Chairman of Release Managing I do like this, but at least intrigeri has asked for an exception to *maybe* push some features (specifically AppArmor stuff) into either Tails 1.2.1 or Tails 1.2.2 (2015-01-06) given how long it is until the next major release (Tails 1.3 on 2015-02-17). If that happens for 1.2.1, we may want to consider an RC. However, intrigeri also proposed that we may skip a formal RC, and that some of us still gather on IRC and collectively do some focused testing of any new features we'd like to go into 1.2.1. If we do this, I'd still propose this to happen on 2014-11-13. Personally, I would prefer this option, but I'd like to hear what the rest of you think. Opinions? In either case, I will be travelling 2014-11-07 to 2014-11-10, and do not expect to be available much of that time, and this is a bit problematic. That's why I've set the feature freeze to 2014-11-05, which is just two weeks away. That's mostly to signal that any work intended for 1.2.1 must be in good shape by then, because in practice I'll merge stuff until 2014-11-12. My intention is to have reviewed and tested the bulk of what's going into 1.2.1 by 2014-11-06. I hope this won't be an issue. So, Tails contributors, please let me know which of you are available for testing the RC (or similar) image on 2014-11-13! 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.
