Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 12:31 PM, Bobby Holley wrote: > On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes > wrote: > >> Hey Daniel, >> >> Thanks for the heads-up. This is a useful thing to keep in mind as we >> work >> through the SHA-1 deprecation. >>

nsIProtocolHandler in Electrolysis?

What's different about nsIProtocolHandler in e10s? OverbiteFF works in 45 aurora without e10s on, but fails to recognize the protocol it defines with e10s enabled. There's no explanation of this in the browser console and seemingly no error. Do I have to do extra work to register the protocol

nsThread now leaks runnables if dispatch fails

(This is a continuation of the discussion in bug 1218297) In bug 1155059 we made nsIEventTarget::Dispatch take an already_AddRefed instead of a raw pointer. This was done to allow the dispatcher to transfer its reference to the runnable to the thread the runnable will run on. That solves a race

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

First a bit of good news: The overall trend line for SHA-1 errors is not spiking (yet). Bin 6 of SSL_CERT_VERIFICATION_ERRORS corresponds to ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED, which is what you get when you reject a bad SHA-1 cert.

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 1/4/16 11:20 AM, Richard Barnes wrote: First a bit of good news: The overall trend line for SHA-1 errors is not spiking (yet). Bin 6 of SSL_CERT_VERIFICATION_ERRORS corresponds to ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED, which is what you get when you reject a bad SHA-1 cert.

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 1/4/16 1:00 PM, Adam Roach wrote: One of the points that Benjamin Smedberg has been trying to drive home is that data collection is everyone's job. After sending, I realized that this is a slight misquote. It should have been "data is everyone's job" (i.e.: there's more to data than

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 01/04/2016 12:19 AM, Daniel Holbert wrote: > I wasn't able to > remotely figure out what the piece of spyware was or how to remove it -- > but the rejected certs reported their issuer as being "Digital Marketing > Research App" (instead of e.g. Digicert or Verisign). Googling didn't > turn up

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

aus5 (the server the app updater checks) is still pinned: https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h#739 On Mon, Jan 4, 2016 at 12:54 PM, Robert Strong wrote: > On Mon, Jan 4, 2016 at 12:46 PM, Jesper Kristensen < >

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 1/4/16 12:29 PM, Daniel Holbert wrote: I had a similar thought, but I think it's too late for such telemetry to be effective. The vast majority of users who are affected will have already stopped using Firefox, or will immediately do so, as soon as they discover that their webmail, bank,

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

For reference, I've now filed a bug to cover outreach for the specific tool that this user was using: https://bugzilla.mozilla.org/show_bug.cgi?id=1236664 I'm also trying to get my hands on the software, but it's "invitation only", so that may prove difficult. ~Daniel

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 01/04/2016 10:33 AM, Josh Matthews wrote: > Wouldn't the SSL cert failures also prevent submitting the telemetry > payload to Mozilla's servers? Hmm... actually, I'll bet the cert errors will prevent Firefox updates, for that matter! (I'm assuming the update-check is performed over HTTPS.) So

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 10:53 AM, Chris Peterson wrote: > On 1/4/16 10:45 AM, Daniel Holbert wrote: > >> On 01/04/2016 10:33 AM, Josh Matthews wrote: >> >>> >Wouldn't the SSL cert failures also prevent submitting the telemetry >>> >payload to Mozilla's servers? >>> >>

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 01/04/2016 12:07 PM, Daniel Holbert wrote: > UPDATE: in my family friend's case, the shoddy MITM spyware in question > was "Simmons Connect Research Application", a consumer profiling tool > that's tied to Experian which users can voluntarily install in exchange > for points that you can use to

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 1/4/16 10:45 AM, Daniel Holbert wrote: On 01/04/2016 10:33 AM, Josh Matthews wrote: >Wouldn't the SSL cert failures also prevent submitting the telemetry >payload to Mozilla's servers? Hmm... actually, I'll bet the cert errors will prevent Firefox updates, for that matter! (I'm assuming the

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 12:37 PM, Robert Strong wrote: > > > On Mon, Jan 4, 2016 at 10:53 AM, Chris Peterson > wrote: > >> On 1/4/16 10:45 AM, Daniel Holbert wrote: >> >>> On 01/04/2016 10:33 AM, Josh Matthews wrote: >>> >Wouldn't the SSL cert

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

I was under the impression (perhaps falsely) that the params for those entries made it so that aus4 and aus5 don't enforce pinning. On Mon, Jan 4, 2016 at 1:08 PM, Dave Townsend wrote: > aus5 (the server the app updater checks) is still pinned: > >

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

Den 04-01-2016 kl. 19:45 skrev Daniel Holbert: On 01/04/2016 10:33 AM, Josh Matthews wrote: Wouldn't the SSL cert failures also prevent submitting the telemetry payload to Mozilla's servers? Hmm... actually, I'll bet the cert errors will prevent Firefox updates, for that matter! (I'm assuming

Re: nsIProtocolHandler in Electrolysis?

On 1/4/16 12:09 PM, Dave Townsend wrote: On Mon, Jan 4, 2016 at 12:03 PM, Cameron Kaiser wrote: What's different about nsIProtocolHandler in e10s? OverbiteFF works in 45 aurora without e10s on, but fails to recognize the protocol it defines with e10s enabled. There's no

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Monday, January 4, 2016 at 2:27:57 PM UTC-5, Tanvi Vyas wrote: > On 1/4/16 11:20 AM, Richard Barnes wrote: > > So we can't get any measurements unless we revert the SHA-1 intolerance. > > Given this, I'm sort of inclined to do that, collect some data, then maybe > > re-enable it in 45 or 46.

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 12:46 PM, Jesper Kristensen < moznewsgro...@something.to.remove.jesperkristensen.dk> wrote: > Den 04-01-2016 kl. 19:45 skrev Daniel Holbert: > >> On 01/04/2016 10:33 AM, Josh Matthews wrote: >> >>> Wouldn't the SSL cert failures also prevent submitting the telemetry >>>

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

> { "aus5.mozilla.org", true, true, true, 7, _mozilla }, Just for clarification and future reference, the second "true" means this entry is in test mode, so it's not actually enforced by default. On Mon, Jan 4, 2016 at 1:08 PM, Dave Townsend wrote: > aus5 (the server the

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 1:11 PM, Robert Strong wrote: > I was under the impression (perhaps falsely) that the params for those > entries made it so that aus4 and aus5 don't enforce pinning. > and the pinning hack I added years ago was removed. > > > > On Mon, Jan 4, 2016 at

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

If you're forking mozilla-central, that shouldn't be a problem, right? On Jan 4, 2016 12:46 AM, "罗勇刚(Yonggang Luo)" wrote: > Well, cause that's not possible to implement APIs in webidl in the > external dll with the xul > > On Mon, Jan 4, 2016 at 3:55 PM, Bobby Holley

Re: Thanks for all the great teamwork with the Sheriffs in 2015!

Yeah! We do love our sheriffs! :) On Sun, Jan 3, 2016 at 9:42 PM, Nicholas Nethercote wrote: > Sheriffs make developers' lives easier. Thank you, sheriffs. > > Nick > > On Thu, Dec 31, 2015 at 1:19 AM, Carsten Book wrote: > > Hi, > > > > Sheriffing is

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On Mon, Jan 4, 2016 at 7:22 PM, Bobby Holley wrote: > If you're forking mozilla-central, that shouldn't be a problem, right? > I am asking for some help, seeking for problems when I was trying to implement XPCOM connect with js-ctypes. So far, the garbage collection would

Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

Heads-up, from a user-complaint/ support / "keep an eye out for this" perspective: * Starting January 1st 2016 (a few days ago), Firefox rejects recently-issued SSL certs that use the (obsolete) SHA1 hash algorithm.[1] * For users who unknowingly have a local SSL proxy on their machine from

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

Well, cause that's not possible to implement APIs in webidl in the external dll with the xul On Mon, Jan 4, 2016 at 3:55 PM, Bobby Holley wrote: > Why not use webidl to expose the apis you want in workers? > On Jan 3, 2016 8:08 PM, "罗勇刚(Yonggang Luo)"

Re: nsThread now leaks runnables if dispatch fails

Kyle Huey writes: > (This is a continuation of the discussion in bug 1218297) > > In bug 1155059 we made nsIEventTarget::Dispatch take an > already_AddRefed instead of a raw pointer. This was done to allow the > dispatcher to transfer its reference to the runnable to the thread the > runnable

Re: Single- vs. double-precision FP in gfx types

On Wed, Dec 9, 2015 at 3:49 PM, Nicholas Nethercote wrote: >> >> One interesting thing I found is that a *lot* of the functions that >> take an nsRenderingContext or gfxContext do so because they end up >> passing it into text run code -- gfxTextRun uses a gfxContext, via

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

WEBGL_dynamic_texture is due for a pruning refactor (I think I'm on the hook for this), so don't base anything on it as-is. IIRC, we don't believe WEBGL_security_sensitive_resources is viably implementable in a safe way (timing attacks!), so I suggest ignoring it. Extending texture uploads to

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 8:46 AM, Kearwood "Kip" Gilbert wrote: > Hello All, > > In WebVR, we often present UI as a Head's Up Display (HUD) that floats > in front of the user. Additionally, we often wish to show 2d graphics, > video, and CSS animations as a texture in 3d

Re: nsThread now leaks runnables if dispatch fails

>Kyle Huey writes: > >> (This is a continuation of the discussion in bug 1218297) >> >> In bug 1155059 we made nsIEventTarget::Dispatch take an >> already_AddRefed instead of a raw pointer. This was done to allow the >> dispatcher to transfer its reference to the runnable to the thread the >>

Re: nsThread now leaks runnables if dispatch fails

It seems like we should make the default behavior infallible + assert, and introduce a separate dispatch method for the fallible cases. On Mon, Jan 4, 2016 at 10:50 AM, Kyle Huey wrote: > (This is a continuation of the discussion in bug 1218297) > > In bug 1155059 we made

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

In any case, the pin check doesn't matter. The certificate verification will have failed well before the pin checks are done. On Mon, Jan 4, 2016 at 4:14 PM, David Keeler wrote: > > { "aus5.mozilla.org", true, true, true, 7, _mozilla }, > > Just for clarification and

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

Thanks for your feedback, Jeff! My comments below... On 2016-01-04 2:50 PM, Jeff Gilbert wrote: > WEBGL_dynamic_texture is due for a pruning refactor (I think I'm on > the hook for this), so don't base anything on it as-is. I'm glad I checked with you first. I would be interested in any

"-Moz-Element" -like API by extending WEBGL_dynamic_texture

Hello All, In WebVR, we often present UI as a Head's Up Display (HUD) that floats in front of the user. Additionally, we often wish to show 2d graphics, video, and CSS animations as a texture in 3d scenes. Creating these textures is something that CSS and HTML are great at. Unfortunately, I am

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 11:50 AM, Jeff Gilbert wrote: > I think that it would be most efficient just to have a meeting about > these topics, instead of iterating slower via email. > FWIW I feel like it's more efficient to use email, especially if not all issues can be

Re: nsIProtocolHandler in Electrolysis?

Cameron, The way the builtin protocols (HTTP/FTP/Websockets/etc) handle this is that the protocol handler code checks whether we're in a child process or not when a channel is created, and we hand out different things depending on that. In the parent, we hand out a "good old HTTP channel"

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Mon, Jan 4, 2016 at 4:46 PM, Robert O'Callahan wrote: > On Tue, Jan 5, 2016 at 10:46 AM, Kearwood "Kip" Gilbert < > kgilb...@mozilla.com> wrote: > >> In WebVR, we often present UI as a Head's Up Display (HUD) that floats >> in front of the user. Additionally, we often

Re: nsIProtocolHandler in Electrolysis?

On 1/4/16 6:29 PM, Kris Maglione wrote: On Mon, Jan 04, 2016 at 08:27:59PM -0500, Jason Duell wrote: In the child we hand out a stub channel (HttpChannelChild) that looks and smells like an nsIHttpChannel, but actually uses IPDL (our C++ cross-platform messaging language) to essentially shunt

Re: nsIProtocolHandler in Electrolysis?

On Mon, Jan 04, 2016 at 06:29:26PM -0800, Kris Maglione wrote: I think that doing this in an add-on is asking for trouble. I don't think I've ever seen nsIChannel implemented in JavaScript. I take that back. I see Overbite is indeed implemented this way. It still seems like asking for

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 1:18 PM, Jonas Sicking wrote: > A big problem is sticking HTML/CSS content into WebGL is that WebGL > effectively enables reading pixel data through custom shaders and > timing attacks. > If you read

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Mon, Jan 4, 2016 at 5:46 PM, Robert O'Callahan wrote: > On Tue, Jan 5, 2016 at 2:38 PM, Jeff Gilbert wrote: > >> > Essentially, we would extend the same API but allow the WDTStream >> >> interface to apply to more HTML elements, not just

Re: nsIProtocolHandler in Electrolysis?

On 1/4/16 5:27 PM, Jason Duell wrote: That makes sense, except I'm not sure how to split it apart. Are there any examples of what such a parent-child protocol handler should look like in a basic sense? The p-c goop in netwerk/protocol/ is not really amenable to determining this, not least of

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 2:38 PM, Jeff Gilbert wrote: > Yeah, we have a public mailing list: public_we...@khronos.org > As with anything WebGL related, you can also just talk to me about it. > I don't want to step on whatever you were thinking of changing, but I'm happy to

Re: Improving blame in Mercurial

On Mon, Jan 4, 2016 at 9:33 PM, Ehsan Akhgari wrote: > On 2015-12-11 6:28 PM, Boris Zbarsky wrote: > >> On 12/11/15 6:17 PM, Gregory Szorc wrote: >> >>> If you have ideas for making the blame/annotate functionality better, >>> please capture them at

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Mon, Jan 4, 2016 at 4:54 PM, Robert O'Callahan wrote: > On Tue, Jan 5, 2016 at 1:18 PM, Jonas Sicking wrote: >> >> A big problem is sticking HTML/CSS content into WebGL is that WebGL >> effectively enables reading pixel data through custom shaders and

Re: Improving blame in Mercurial

On 2015-12-11 6:28 PM, Boris Zbarsky wrote: On 12/11/15 6:17 PM, Gregory Szorc wrote: If you have ideas for making the blame/annotate functionality better, please capture them at https://www.mercurial-scm.org/wiki/BlamePlan This is a great plan! I'm excited to use this, I have never seen a

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 10:46 AM, Kearwood "Kip" Gilbert < kgilb...@mozilla.com> wrote: > In WebVR, we often present UI as a Head's Up Display (HUD) that floats > in front of the user. Additionally, we often wish to show 2d graphics, > video, and CSS animations as a texture in 3d scenes.

Re: nsIProtocolHandler in Electrolysis?

On Mon, Jan 04, 2016 at 06:47:10PM -0800, Cameron Kaiser wrote: This is what I'm considering, though the channel implementation is not fully clean and does some front-end manipulation as well (for example, it adds a notification box to the tab with the current gopher URL, so it needs to

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Tue, Jan 5, 2016 at 2:38 PM, Jeff Gilbert wrote: > > Essentially, we would extend the same API but allow the WDTStream > >> interface to apply to more HTML elements, not just HTMLCanvasElement, > >> HTMLImageElement, or HTMLVideoElement. > >> > >> We would also need to

Re: nsIProtocolHandler in Electrolysis?

On Mon, Jan 04, 2016 at 08:27:59PM -0500, Jason Duell wrote: In the child we hand out a stub channel (HttpChannelChild) that looks and smells like an nsIHttpChannel, but actually uses IPDL (our C++ cross-platform messaging language) to essentially shunt all the real work to the parent. When

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

Yes, I mostly meant XPConnect. On 04/01/16 14:36, smaug wrote: > On 01/03/2016 06:35 PM, David Rajchenbach-Teller wrote: >> Accessing XPCOM in a worker will most likely break the garbage-collector >> in novel and interesting ways, > > Why would it? Our workers are full of xpcom stuff. > One

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On 01/03/2016 06:55 PM, David Rajchenbach-Teller wrote: Well, XPConnect is designed for the main thread, and many of the things it does assume that everything takes place on the main thread. An example, from the topic of my head: whenever objects cross between JavaScript and C++ through

Platform and UX

At Mozlando we discussed how we could better coordinate between platform and UX. Put simply, platform's problem is the lack of UX input on API design, and UX' problem is not hearing about new platform features soon enough to influence the API design to better suit the needs of users. As a small

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On 01/03/2016 06:35 PM, David Rajchenbach-Teller wrote: Accessing XPCOM in a worker will most likely break the garbage-collector in novel and interesting ways, Why would it? Our workers are full of xpcom stuff. One needs to be careful what to touch sure, and deal with CC and GC handling like

[Firefox Desktop] Issues found: December 28th to January 1st

Hi everyone and Happy New Year! Here's the list of new issues found and filed by the Desktop Manual QA team last week, December 28 - January 1 (Week 53). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: nsThread now leaks runnables if dispatch fails

> In bug 1218297 we saw a case where dispatch to a thread (the socket > transport service thread in this case) fails because the thread has > already shut down. In our brave new world, nsThread simply leaks the > runnable. It can't release the reference it holds, because that would > reintroduce

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On Mon, Jan 4, 2016 at 9:53 PM, smaug wrote: > On 01/03/2016 06:55 PM, David Rajchenbach-Teller wrote: > >> Well, XPConnect is designed for the main thread, and many of the things >> it does assume that everything takes place on the main thread. >> >> An example, from the topic

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On 1/4/2016 9:24 AM, 罗勇刚(Yonggang Luo) wrote: 1、I was not trying implement new things in xpcom, our company(Kingsoft) are maintaining a fork of thunderbird, and at the current time We have to re-use existing XPCOM components that already exists in the thunderbid gecko world, beyond pure html

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On Mon, Jan 4, 2016 at 11:37 PM, Joshua Cranmer  wrote: > On 1/4/2016 9:24 AM, 罗勇刚(Yonggang Luo) wrote: > >> 1、I was not trying implement new things in xpcom, our company(Kingsoft) >> are >> maintaining a fork of thunderbird, and at the current time >> We have to re-use

Re: iframe overflow:hidden from build29 FF and XUL?

PS Assuming that the current behaviour is correct of W3C spec, is it not possible to retain the the old moz property -moz-scroll-bars-none so that content can still be scrolled (esp with touch screen devices) without showing the unwanted scrollbars ? "rvj"

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes wrote: > Hey Daniel, > > Thanks for the heads-up. This is a useful thing to keep in mind as we work > through the SHA-1 deprecation. > > To be honest, this seems like a net positive to me, since it gives users a > clear

Re: Improving blame in Mercurial

Gregory Szorc schrieb: If you have ideas for making the blame/annotate functionality better, please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let me know by replying to this message. Your feedback will be used to drive what improvements Mercurial makes. I really liked a

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 9:31 AM, Bobby Holley wrote: > On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes > wrote: > > > Hey Daniel, > > > > Thanks for the heads-up. This is a useful thing to keep in mind as we > work > > through the SHA-1 deprecation. >

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 9:47 AM, Mike Hoye wrote: > On 2016-01-04 12:31 PM, Bobby Holley wrote: > >> By "this sort of software" do you mean "Firefox"? Because that's what 95% >> of our users experiencing this are going to do absent anything clever on >> our end. We clearly need

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On Mon, Jan 4, 2016 at 10:01 AM, 罗勇刚(Yonggang Luo) wrote: > > > On Tue, Jan 5, 2016 at 1:33 AM, Bobby Holley > wrote: > >> On Mon, Jan 4, 2016 at 7:57 AM, 罗勇刚(Yonggang Luo) >> wrote: >> >>> On Mon, Jan 4, 2016 at 11:37 PM,

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On Mon, Jan 4, 2016 at 7:57 AM, 罗勇刚(Yonggang Luo) wrote: > On Mon, Jan 4, 2016 at 11:37 PM, Joshua Cranmer  > wrote: > > > On 1/4/2016 9:24 AM, 罗勇刚(Yonggang Luo) wrote: > > > >> 1、I was not trying implement new things in xpcom, our company(Kingsoft)

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 2016-01-04 12:31 PM, Bobby Holley wrote: By "this sort of software" do you mean "Firefox"? Because that's what 95% of our users experiencing this are going to do absent anything clever on our end. We clearly need to determine the scale of the problem to determine how much time it's worth

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On Tue, Jan 5, 2016 at 1:33 AM, Bobby Holley wrote: > On Mon, Jan 4, 2016 at 7:57 AM, 罗勇刚(Yonggang Luo) > wrote: > >> On Mon, Jan 4, 2016 at 11:37 PM, Joshua Cranmer  >> wrote: >> >> > On 1/4/2016 9:24 AM, 罗勇刚(Yonggang Luo)

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 01/04/2016 09:47 AM, Eric Rescorla wrote: > I believe that Chrome will be making a similar change at a similar time > > -Ekr In contrast, it looks like IE & Edge will continue accepting SHA1 certs on the web for another full year, until 2017. [1][2] ~Daniel [1]

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 2016-01-04 12:48 PM, Eric Rescorla wrote: On Mon, Jan 4, 2016 at 9:47 AM, Mike Hoye > wrote: On 2016-01-04 12:31 PM, Bobby Holley wrote: By "this sort of software" do you mean "Firefox"? Because that's what 95% of our users

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 1/4/16 2:19 AM, Daniel Holbert wrote: I'm not sure what action we should (or can) take about this, but for now we should be on the lookout for this, and perhaps consider writing a support article about it if we haven't already. I propose that we minimally should collect telemetry around

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

> > >> In fact, the only reason to use WebIDL is to getting javascript to using >> some native code, but the situation is I have no need to do that, all the >> new code we've writing down are in pure Javascript, if we have the willing >> to implement something with WebIDL, for example, the IMAP

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 01/04/2016 10:21 AM, Adam Roach wrote: > I propose that we minimally should collect telemetry around this > condition. It should be pretty easy to detect: look for cases where we > reject very young SHA-1 certs that chain back to a CA we don't ship. > Once we know the scope of the problem, we

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 01/04/2016 10:18 AM, Eric Rescorla wrote: > I believe you are confusing two different things. > > 1. Whether the browser supports SHA-1 certificates at all. > 2. Whether the browser supports SHA-1 certificates signed after Jan 1 2016 > (The CA/BF Baseline Requirements forbid this, so no

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On 2016-01-04 1:21 PM, Adam Roach wrote: On 1/4/16 2:19 AM, Daniel Holbert wrote: I'm not sure what action we should (or can) take about this, but for now we should be on the lookout for this, and perhaps consider writing a support article about it if we haven't already. I propose that we