[ Intent to change ] Updates to Are We Triaged Yet
Hi, I want to give you a heads up on some incoming updates to the Are We Triaged Yet tool. You can see these at https://are-we-triaged-yet.glitch.me/. The changes: * This release gets rid of the separate sets of charts for each release, that way of tracking wasn't helpful. - Now there's two sets of columns for each component - The first is open bugs in a category by age: more than a month old, more than a week old (including previous column,) and less than a week old - The second set of columns are the numbers of open bugs in a category that were opened during the current nightly, beta, and release * The uplifts report has been removed The change means that the API for requesting charts no longer takes version as an argument on the query string. If you have questions or comments on the new version, please let me know, otherwise I plan to merge the changes into production next Monday. -- Emma ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookies are no longer stored by nsIHttpChannel?
More details: The same code works in TB60 and in the cookie list of the general options I can see all sorts of cookies being stored. In TB68, none of the expected cookies show up in the cookie list. Did something change in that region? What do I need to do to allow a channel / principal to store cookies now? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookies are no longer stored by nsIHttpChannel?
It happens also with the SystemPrincipal as well, so independent of the userContextId. I changed to code as follows now and get the same behaviour: let channel = Services.io.newChannelFromURI( uri, null, Services.scriptSecurityManager.getSystemPrincipal(), null, Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL | Ci.nsILoadInfo.SEC_COOKIES_INCLUDE, Ci.nsIContentPolicy.TYPE_OTHER); let httpchannel = channel.QueryInterface(Ci.nsIHttpChannel); httpchannel.loadFlags |= Ci.nsIRequest.LOAD_BYPASS_CACHE; I can see Set-Cookie headers in the responses from the server, but requests send out by my channel do not include any. Hm ... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookies are no longer stored by nsIHttpChannel?
This might be a cookie isolation, or something missing to recognize if
the cookie storage is allowed for the channel. Is the `userContextId`
the same all the time? If yes, can you capture a log with
nsHttp:5,cookie:5? Checking browser console for errors may tell you
something too.
CC'ing Ehsan directly in case he spots something immediately from your
code. My own cookie-fu is not strong enough at the moment.
-hb-
On 2019-09-16 14:23, john.bieling--- via dev-platform wrote:
Hi,
I have run into something strange. This is how I create network connections in
my (Thunderbird-) AddOn:
let channel = Services.io.newChannelFromURI(
aConnection.uri,
null,
Services.scriptSecurityManager.createCodebasePrincipal(aConnection.uri, {
userContextId }),
null,
Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL,
Ci.nsIContentPolicy.TYPE_OTHER);
let httpchannel = channel.QueryInterface(Components.interfaces.nsIHttpChannel);
httpchannel.loadFlags |= Ci.nsIRequest.LOAD_BYPASS_CACHE;
After updating from ESR60 to ESR68, that connection never uses cookies anymore.
This is a fresh profile, so there are no specific cookie settings being set
(network.cookie.cookieBehavior = 0).
I can see the request from the server to set cookies on each request, but on
the next response, the cookies are not included.
This is used for standard HTTP requests (CardDAV in my case).
Can someone point me to what I am missing?
Thanks,
John
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Cookies are no longer stored by nsIHttpChannel?
Hi,
I have run into something strange. This is how I create network connections in
my (Thunderbird-) AddOn:
let channel = Services.io.newChannelFromURI(
aConnection.uri,
null,
Services.scriptSecurityManager.createCodebasePrincipal(aConnection.uri, {
userContextId }),
null,
Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL,
Ci.nsIContentPolicy.TYPE_OTHER);
let httpchannel = channel.QueryInterface(Components.interfaces.nsIHttpChannel);
httpchannel.loadFlags |= Ci.nsIRequest.LOAD_BYPASS_CACHE;
After updating from ESR60 to ESR68, that connection never uses cookies anymore.
This is a fresh profile, so there are no specific cookie settings being set
(network.cookie.cookieBehavior = 0).
I can see the request from the server to set cookies on each request, but on
the next response, the cookies are not included.
This is used for standard HTTP requests (CardDAV in my case).
Can someone point me to what I am missing?
Thanks,
John
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: The sec-approval process makes users safer
Hi, I'm taking this opportunity to share a new wiki page documenting guidelines for patching a core-security bugs: https://wiki.mozilla.org/Security/Firefox_security_bug_fixing You'll find generic security principles about handling security bugs, as well as the detailed process for fixing security rated bugs. Should you be dealing with a security bug for the first time or wishing to refresh your memory, that's the place to go! For those of you who are familiar with the Bug Approval Process wiki page [1], you'll get similar information but specifically intended for a developers audience. Cheers, [1] https://wiki.mozilla.org/Security/Bug_Approval_Process On Tue, Sep 10, 2019 at 3:01 AM Jeff Walden wrote: > Those of you longer in the tooth may remember Firefox was successfully > exploited in Pwn2own 2012...and we didn't have to lift a finger to fix it. > We already had -- in the Firefox release shipping days later. 🤦 > > https://bugzilla.mozilla.org/show_bug.cgi?id=735104 (pwn2own bug) > https://bugzilla.mozilla.org/show_bug.cgi?id=720511 (cover bug, > discussion only of a spec-compliance issue) > https://bugzilla.mozilla.org/show_bug.cgi?id=720079 (sec bug noting the > sec issue) > > We later discussed whether the exploit had been "achieved" by reading our > public commits. https://bugzilla.mozilla.org/show_bug.cgi?id=735104#c2 > The fruit of this discussion was our security approval process, where > security patches land only after approval, in relative lockstep close to > release, with incriminating tests/comments removed. This is also where > sec-approval comment hoop-jumping began. > > sec-approval is a pain. Is it really worth it? > > The recent Apple iOS WebKit/JSC exploits conclusively answer "yes". The > Project Zero post > https://googleprojectzero.blogspot.com/2019/08/jsc-exploits.html > discusses the possibility that some exploits were acquired from published, > pre-release security fixes and testcases: > > > For many of the exploits it is unclear whether they were originally > exploited as 0day or as 1day after a fix had already shipped. It is also > unknown how the attackers obtained knowledge of the vulnerabilities in the > first place. Generally they could have discovered the vulnerabilities > themselves or used public exploits released after a fix had shipped. > > > > Furthermore, at least for WebKit, it is often possible to extract > details of a vulnerability from the public source code repository before > the fix has been shipped to users. > > > > CVE-2019-8518 > https://bugs.chromium.org/p/project-zero/issues/detail?id=1775 can be > used to highlight this problem (as can many other recent vulnerabilities). > The vulnerability was publicly fixed in WebKit HEAD on Feb 9 2019 with > commit < > https://github.com/WebKit/webkit/commit/4a23c92e6883b230a437bcc09f94422d7df8756c>. > This commit contains a testcase that triggers the issue and causes an > out-of-bounds access into a JSArray - a scenario that is usually easy to > exploit. However, the fix only shipped to users with the release of iOS > 12.2 on March 25 2019, roughly one and a half months after details about > the vulnerability were public. > > > > An attacker in possession of a working exploit for an older WebKit > vulnerability would likely only need a few days to replace the underlying > vulnerability and thus gain the capability to exploit up-to-date devices > without the need to find new vulnerabilities themselves. It is likely that > this happened for at least some of the following exploits. > > (paragraph breaks added) Incredibly, saying, "It is likely that > [attackers used public commits/testcases to create exploits]" *soft-pedals* > it. The first exploit the post discusses includes this text and image: > > > [T]he exploit trigger is almost exactly the same as in the bug report > and the regression test file in the WebKit repository. This can be seen in > the following two images, the left one showing the testcase published in > the WebKit code repository as part of the bugfix and the right showing the > part of the in-the-wild exploit code that triggered the bug. > > > https://1.bp.blogspot.com/-PEZlVLEefs0/XWg4BdDSxkI/NUs/ELjHWgzHOZIRKSTV45E-moRivJKrAWIkACLcBGAs/s1600/JSC%2BDIFF.png > (alt text: "This image shows a line-by-line, side-by-side comparison > between the vulnerability test case from the webkit tracker on the left, > and the vulnerability trigger code used in the exploit on the right. They > are very similar, with matching variable names and code structure. The only > difference is that one value which had the fixed value 1.45 in the test > case has been parameterised out to a variable named ow in the exploit, and > the trigger has been wrapped inside a function definition which takes ow as > an argument.") > > The *only* difference between testcase and exploit is s/1.45/ow/. There's > no plausible way that similarity (including variable names) is > coincidental. Attackers (the Chinese go
Re: Equivalent for XMLHttpRequest.overrideMimeType() in the world of nsIHttpChannel
Perfect! Having seen that, I also found the "contentType" attribute and its description here: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIChannel which allows me to mimic the behaviour. Thanks a lot for the pointer! John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Equivalent for XMLHttpRequest.overrideMimeType() in the world of nsIHttpChannel
The implementation of XMLHttpRequest.overrideMimeType() is here: https://searchfox.org/mozilla-central/rev/d1e33e3e11f559952d7d80e722d26a6cf5dd80ac/dom/xhr/XMLHttpRequestMainThread.cpp#3086-3090 You probably want to do something like this: https://searchfox.org/mozilla-central/rev/d1e33e3e11f559952d7d80e722d26a6cf5dd80ac/dom/xhr/XMLHttpRequestMainThread.cpp#1826-1828 Cheers! On Sat, 14 Sep 2019 at 09:45, john.bieling--- via dev-platform < dev-platform@lists.mozilla.org> wrote: > I am working on a wrapper for nsIHttpChannel with the interface of > MLHttpRequest. Mainly to be able to use the codeBbasePrincipal (or > ContextPrincipal as it is called now I think) with XHR requests, but > without authors having to rewrite their code. > > This is for Thunderbird Add-Ons, which still can access nsIHttpChannel. > > I am pretty far and it is working nicely. > > However, I was not able to find a place in the nsIHttpChannel > specification, which I could map to > > XMLHttpRequest.overrideMimeType() > > Is there any option/requirement to manually overide the MimeType of > responses received via a nsIStreamListener or a nsIStreamLoaderObserver. > > The wrapper is here, if you want to have a look: > > https://gitlab.com/jobisoft/CardBook/blob/Thunderbird67+/chrome/content/cardbookHttpRequest.js > > Thanks for any help, > John > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
