Re: [Tails-dev] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]

2017-09-28 Thread Sylvestre Ledru
Hello team,

I don't recommend that you ship before us. We do take last minutes patches. 
Some of them, you won't care (example: Windows accessibility support) but
some others, you might (privacy issue or security fixes).
So, if you want us to 0-day you (and clearly, we don't want to do that to you 
;), you should really wait until we ship officially.

Cheers,
Sylvestre


Le 27/09/2017 à 00:15, anonym a écrit :
> 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.

Re: [Tails-dev] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]

2017-09-27 Thread intrigeri
Hi,

anonym:
> 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.

Thank you for pushing me to think about it deeper than expressing
raw feelings.

My general answer is: what a downstream does has all kinds of impacts
on their upstream, and that impact can be problematic especially when
downstream diverges in some way (be it by patching code, by changing
default settings, by releasing in an uncoordinated manner, etc.)

For example:

 - Releasing upstream's work before they do can create confusion for
   users wrt. version numbers and released / not released status,
   which can result in additional support work upstream (e.g. "why
   can't I install Firefox x.y? Tor Browser already has it").

 - Releasing upstream's work before they do can dilute
   their communication.

 - Releasing upstream's work before they deem it ready for prime time
   can result in bad user experience, and some users might erroneously
   (but understandably) think the root cause is upstream, which
   results in bad feelings/press about upstream.

 - Similarly, modifying upstream's code or default prefs can create
   confusion for users, erroneously attributed bad UX/feelings/press,
   and additional support work upstream.

 - See the last bullet list on
   https://tails.boum.org/contribute/derivatives/ :)

I suspect you'll easily find a bunch of other such problems if you
pretend *you* are the upstream, and then someone releases something
that's almost Tails but not quite, with either modified code/prefs or
a different release schedule, and despite their good faith and
attempts at clear communication, no matter what a bunch of people will
be confused, will get it wrong, will ask questions in the wrong place,
will write misleading stuff on Twitter, will write mistaken rants
on Reddit.

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] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]

2017-09-27 Thread anonym
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/publicity requirements (which fit very well to the
> technical issues (and solving them) related to this release cycle).

Thanks for the clarification!

To me this means the responsible thing vs. our users is to release now, but it 
is still unclear what is responsible vs release coordination with our 
upstreams. The sort of answer I'd be looking for is from our upstreams is:

* "As an upstream, we agree that protecting your users is more important than 
release coordination between our projects, so please go ahead and release 

Re: [Tails-dev] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]

2017-09-27 Thread 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?
> 
> Sure.
> 
>>> 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.
> 
> 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.

> 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.
> 
> 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/publicity requirements (which fit very well to the
technical issues (and solving them) related to this release cycle).

Georg




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.

Re: [Tails-dev] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]

2017-09-27 Thread 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?

Sure.

>> 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.

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.

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.

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?

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] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]

2017-09-27 Thread Georg Koppen
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?

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?

> 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.

> 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?

Fine with me.

Georg

> As for asking Mozilla, I'm not even sure who/where to ask. Does any one have 
> a clue?
> 
> 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.

Re: [Tails-dev] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]

2017-09-26 Thread anonym
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.