On the topic of debugging, it's worth noting that TLS 1.3 is going to be
quite a bit harder to debug from just network traces (without keying
material) than TLS 1.2 was because more of the traffic is encrypted.
-Ekr
On Tue, Apr 26, 2016 at 6:30 AM, Patrick McManus
wrote:
> I don't think the ca
Agree with everything here. Right now (from my just-skimmed-the-bug
perspective) this seems like a "the sky is falling!" panic that has not
been justified, with a large amount of serious downside.
On Tue, Apr 26, 2016 at 6:30 AM, Patrick McManus
wrote:
> I don't think the case for making this ch
I think we need to have reasonable answers to Patrick's questions before
landing this patch. It's clear what we're losing, but unclear what we're
gaining.
/a
On 4/26/16 08:30, Patrick McManus wrote:
I don't think the case for making this change (even to release builds) has
been successfully m
+1 to Patrick's points. With HTTP/2 still in it's early stages a lot of CDN's
and server dev's use the keylogs to help debug their integrations. I know
several of them have been using the keylogs that WebPageTest automatically
pulls when it captures a tcpdump during testing.
__
On 26-04-16 14:54, Richard Barnes wrote:
> I guess there's some marginal security in turning off this capability
> in release browsers (though I have difficulty precisely articulating
> the threat model where it makes sense).
Chrome's position on this is relevant to that statement:
https://twitter
I don't think the case for making this change (even to release builds) has
been successfully made yet and the ability to debug and iterate on the
quality of the application network stack is hurt by it.
The Key Log - in release builds - is part of the debugging strategy and is
used fairly commonly
On Tue, 26 Apr 2016, Martin Thomson wrote:
Maybe I'm unusual, but I just run debug builds when I want to investigate
this sort of thing.
That's easy for you and for all of us suitably involved and technically aware.
When ordinary users run into trouble and we ask them to wireshark their
traf
Keeping it in Nightly / Developer Edition seems like about the right
compromise to me. I guess there's some marginal security in turning off
this capability in release browsers (though I have difficulty precisely
articulating the threat model where it makes sense). But if we're going to
disable i
On Tue, Apr 26, 2016 at 6:08 PM, Jonas Sicking wrote:
> Limiting this to aurora builds might make the most sense here since
> that's what we're pushing as the build that developers should use.
I'm OK with that; that's why I asked here.
https://bugzilla.mozilla.org/show_bug.cgi?id=1188657
___
On Mon, Apr 25, 2016 at 11:17 PM, Martin Thomson wrote:
> On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan wrote:
>> Could we probably restrict it to non-release builds (aurora and nightly)
>> rather than restrict them to debug builds only? Debug builds are harder to
>> get, and are slow.
>
> That wa
On Tue, Apr 26, 2016 at 2:56 PM, Mike Hommey wrote:
> On Tue, Apr 26, 2016 at 02:27:31PM +0800, Xidorn Quan wrote:
> > On Tue, Apr 26, 2016 at 2:17 PM, Martin Thomson wrote:
> >
> > > On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan
> > > wrote:
> > > > Could we probably restrict it to non-release
On Tue, 26 Apr 2016, Mike Hommey wrote:
Very few developers will need to analyze traffic at a level requiring
SSLKEYLOGFILE.
Yes, but a larger share of users will do a network capture and submit to
Firefox developers on request when we debug network oriented problems. It is
almost standard p
On Tue, Apr 26, 2016 at 02:27:31PM +0800, Xidorn Quan wrote:
> On Tue, Apr 26, 2016 at 2:17 PM, Martin Thomson wrote:
>
> > On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan
> > wrote:
> > > Could we probably restrict it to non-release builds (aurora and nightly)
> > > rather than restrict them to de
On Tue, Apr 26, 2016 at 2:17 PM, Martin Thomson wrote:
> On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan
> wrote:
> > Could we probably restrict it to non-release builds (aurora and nightly)
> > rather than restrict them to debug builds only? Debug builds are harder
> to
> > get, and are slow.
>
>
On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan wrote:
> Could we probably restrict it to non-release builds (aurora and nightly)
> rather than restrict them to debug builds only? Debug builds are harder to
> get, and are slow.
That was suggested, but we decided against it in bug 1188657. I think
t
I can realize that this might open some holes, but it is also a useful
function for developers to investigate how their connection goes. (I
thought about this kind of function yesterday, but I wasn't aware it has
been already available.)
Could we probably restrict it to non-release builds (aurora
In NSS, we have landed bug 1183318 [1], which I expect will be part of
Firefox 48.
This disables the use of the SSLKEYLOGFILE environment variable in
optimized builds of NSS. That means all released Firefox channels
won't have this feature as it rides the trains.
This feature is sometimes used t
17 matches
Mail list logo
