Re: http-schemed URLs and HTTP/2 over unauthenticated TLS
On Fri, Nov 21, 2014 at 4:53 PM, Patrick McManus mcma...@ducksong.com wrote: Hi - On Fri, Nov 21, 2014 at 5:41 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: Indeed. Huge thanks to everyone who is making Let's Encrypt happen. regulatory compliance, What's this about? nosslsearch.google.com is an example of the weight of regulatory compliance in action. It's not clear what the regulation in question is. It seems that the stated use case for nosslsearch was allowing schools to MITM searches to filter out adult content, but Google seems to be transitioning to addressing this use case by allowing schools to make Safe Search at Google's end non-user-togglable. Anyway, the question I was trying to ask was: For what regulation do all of the following hold: 1) The regulation disallows crypto that is unMITMable without stealing keys or compromising/fooling a CA. 2) The regulation doesn't disallow all crypto but allows MITMable crypto. 3) The way the MITMability is used is decrypting and re-encrypting and not just inhibiting the upgrade. (If the upgrade is inhibited, OE is just plain old HTTP 1.1 after all.) 4) It is congruent with Mozilla's goals to accommodate the regulation beyond just letting the servers subject to the regulation stay on plain old HTTP 1.1. ? non-access to webpki. Does this mean intranets? mostly.. This is basically the Microsoft argument against https. It would be easier to accept if intranet-motivated things didn't leak to the public Web e.g. by being limited to RFC 1918 addresses. A limitation to RFC 1918 addresses would, for sure, irk some intranet admins who use end-to-end IP addressing, but, OTOH, they are better positioned to get publicly-trusted certs for their stuff. If the intranet case can't be isolated, it seems bad to make the public network worse off in order to let the intranet admins have more convenience. (Also, as an intranet gets larger, the notion of trusting the network gets a worse and worse an idea even on an intranet.) but more generally things that don't bind well to the global dns that the webpki relies on.. so potentially peer to peer and mesh interactions too.. How are these relevant to Firefox? (Also, if the thread on the C/ABforum list about issuing a cert for Facebook's .onion address shows anything, I think it shows that it's bad that the built-in validation of a DNS alternative sticks to a layer below http: and doesn't extend https: validation in a way that'd result in a consistent UX [the visible URL scheme being part of the UX] for all authenticated sites--PKI or not.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Components.returnCode not working as expected.
On 11/24/14 1:43 AM, Mark Hammond wrote: * Is Components.returnCode expected to be used when the code throws (as SessionStore.jsm does) or when the code returns without an exception? (Or maybe both?) * If it is supposed to be used with a normal return, is the change so GetPendingResult() is called the correct approach to take? (ie, should I open a bug with that as the patch?) I've also had this in nsIInterfaceRequestor::getInterface. If this function throws, an exception gets logged and other parts of the networking code treat it as a failure. Setting Components.returnCode and returning null seems to work. The code where we do this is a few years old so I don't know if anything has changed. Personally I'd prefer if the JS component could just throw and not have to use Components.returnCode at all, isn't there a way the caller can catch the exception without it being logged? Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Policy of EXPORTS?
Hi, Do we have policy about what headers should/could be in EXPORTS? I found that some exported headers include other headers that aren't exported so the header using site has to use LOCAL_INCLUDES which IMO defeats the purpose of EXPORTS. So exporting more headers could fix it, but that leads to the question about what headers should/could be in EXPORTS. I don't know much about the history of embedding gecko but I guess the exported files were considered part of the stable API? Kanru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Policy of EXPORTS?
On 11/24/2014 6:16 AM, Kan-Ru Chen (陳侃如) wrote: Hi, Do we have policy about what headers should/could be in EXPORTS? I found that some exported headers include other headers that aren't exported so the header using site has to use LOCAL_INCLUDES which IMO defeats the purpose of EXPORTS. So exporting more headers could fix it, but that leads to the question about what headers should/could be in EXPORTS. I don't know much about the history of embedding gecko but I guess the exported files were considered part of the stable API? I am pretty confident that we do not have an actual policy here. For historical context, we used to provide a stable C++ API, and things that went in EXPORTS wound up being part of that API, so it was important to be careful around that. We stopped promising that stable C++ API a while ago (although we do attempt to be kind to consumers of it by not breaking things willy-nilly), so that is not as much of a concern. Additionally, it used to be that module boundaries in Gecko were treated more seriously, in that they were built at different times and so you had to use EXPORTS to include headers from other modules (and you couldn't build dependencies in certain directions). Those days are gone, and we build most of Gecko in a single pass and we use LOCAL_INCLUDES all over the place. At this point, you probably shouldn't bother with EXPORTS unless you are trying to present a somewhat-official API to a component. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Components.returnCode not working as expected.
On 11/24/14, 4:40 AM, Philipp Kewisch wrote:
Personally I'd prefer if the JS component could just throw and not have
to use Components.returnCode at all, isn't there a way the caller can
catch the exception without it being logged?
There is. The question is _when_ it should do this. Consider this
function in a JS component:
f: function(arg) {
arg.snorp();
throw Components.results.NS_ERROR_UNEXPECTED;
}
Should this log anything when arg has no property named snorp? Why
or why not?
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming C++ Standards Committee meeting in Urbana-Champaign
As usual I will blog about the meeting after it's over. Lots of exciting things happened during this meeting! My blog post summarizing them is now online [1]. Cheers, Botond [1] http://theres-waldo.ca/2014/11/23/trip-report-c-standards-meeting-in-urbana-champaign-november-2014/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Tuesday, 25 Nov 2014 at 2:00pm PST
Note: new meeting time! The next Memshrink meeting is is brought to you by better accounting for GFx surface cache entries: https://bugzilla.mozilla.org/show_bug.cgi?id=1096913 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 25 November, 2:00 PM PST * http://arewemeetingyet.com/Los%20Angeles/2014-11-25/14:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Components.returnCode not working as expected.
On 24/11/2014 8:40 PM, Philipp Kewisch wrote: On 11/24/14 1:43 AM, Mark Hammond wrote: * Is Components.returnCode expected to be used when the code throws (as SessionStore.jsm does) or when the code returns without an exception? (Or maybe both?) * If it is supposed to be used with a normal return, is the change so GetPendingResult() is called the correct approach to take? (ie, should I open a bug with that as the patch?) I've also had this in nsIInterfaceRequestor::getInterface. If this function throws, an exception gets logged and other parts of the networking code treat it as a failure. Setting Components.returnCode and returning null seems to work. I believe that this will actually return NS_OK with a null result, which depending on the caller, is probably treated exactly the same way. Personally I'd prefer if the JS component could just throw and not have to use Components.returnCode at all, isn't there a way the caller can catch the exception without it being logged? When the caller is c++ there's no opportunity for the call site to control that (and indeed, the c++ caller generally has no idea they are calling into js). xpconnect tries to be helpful and logs most exceptions in that case - which is generally the right thing to do. IIUC, Components.returnCode is specifically designed for this case, but I'm convinced it simply doesn't work any more. Mark ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
