Re: MozReview ready for general use
Gregory Szorc wrote: Support for specifying the base revision to review has landed. Just pull and update version-control-tools and you can use `hg push -r base -r tip` or `hg push -r base::tip`. \o/ Thank you! - Blair ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How do you run unit tests against Firefox?
On the A*Team we do many projects to bring new platforms online or make sure our test harnesses work in new situations (like e10s). We hear great ideas from folks we interact with (sometimes we make up our own ideas), but one thing we don't know is how people run unit tests and what type of workflow is normal. To answer this we created a survey: http://goo.gl/p45Iwo As different teams have different workflows, we would really appreciate if you fill out the team you work on (or do the most work for) - that is question 1 of 13 in the survey! Now is your chance to ask for automated sandwich making! -jmaher ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: http-schemed URLs and HTTP/2 over unauthenticated TLS (was: Re: WebCrypto for http:// origins)
On Mon, Sep 15, 2014 at 7:56 PM, Adam Roach a...@mozilla.com wrote: The whole line of argumentation that web browsers and servers should be taking advantage of opportunistic encryption is explicitly informed by what's actually happening elsewhere. Because what's *actually* happening is an overly-broad dragnet of personal information by a wide variety of both private and governmental agencies -- activities that would be prohibitively expensive in the face of opportunistic encryption. ISPs are doing it already it turns out. Governments getting to ISPs has already happened. I think continuing to support opportunistic encryption in Firefox and the IETF is harmful to our mission. Google's laser focus on preventing active attackers to the exclusion of any solution that thwarts passive attacks is a prime example of insisting on a perfect solution, resulting instead in substantial deployments of nothing. They're naïvely hoping that finding just the right carrot will somehow result in mass adoption of an approach that people have demonstrated, with fourteen years of experience, significant reluctance to deploy universally. Where are you getting your data from? https://plus.google.com/+IlyaGrigorik/posts/7VSuQ66qA3C shows a very different view of what's happening. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Web APIs documentation meeting Friday at 10 AM PST
The Web APIs documentation meeting is Friday at 10 AM Pacific Time (see http://bit.ly/APIdocsMDN for your time zone). Everyone's welcome to attend; if you're interested in ensuring that all Web APIs are properly documented, we'd love your input. We have an agenda, as well as details on how to join, here: https://etherpad.mozilla.org/WebAPI-docs-2014-11-07. If you have topics you wish to discuss, please feel free to add them to the agenda. We look forward to seeing you there! If you're unable to attend but have been working on documentation related to APIs, please add notes to the agenda about what you've been doing so we can share your progress. Eric Shepherd Developer Documentation Lead Mozilla Developer Network https://developer.mozilla.org/ Blog: http://www.bitstampede.com/ http://www.bitstampede.com/Twitter: http://twitter.com/sheppy http://twitter.com/sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: http-schemed URLs and HTTP/2 over unauthenticated TLS (was: Re: WebCrypto for http:// origins)
On Nov 12, 2014, at 4:35 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Sep 15, 2014 at 7:56 PM, Adam Roach a...@mozilla.com wrote: The whole line of argumentation that web browsers and servers should be taking advantage of opportunistic encryption is explicitly informed by what's actually happening elsewhere. Because what's *actually* happening is an overly-broad dragnet of personal information by a wide variety of both private and governmental agencies -- activities that would be prohibitively expensive in the face of opportunistic encryption. ISPs are doing it already it turns out. Governments getting to ISPs has already happened. I think continuing to support opportunistic encryption in Firefox and the IETF is harmful to our mission. You're missing Adam's point. From the attacker's perspective, opportunistic sessions are indistinguishable from Google's laser focus on preventing active attackers to the exclusion of any solution that thwarts passive attacks is a prime example of insisting on a perfect solution, resulting instead in substantial deployments of nothing. They're naïvely hoping that finding just the right carrot will somehow result in mass adoption of an approach that people have demonstrated, with fourteen years of experience, significant reluctance to deploy universally. Where are you getting your data from? https://plus.google.com/+IlyaGrigorik/posts/7VSuQ66qA3C shows a very different view of what's happening. Be careful how you count. Ilya's stats are equivalent to the Firefox HTTP_TRANSACTION_IS_SSL metric [1], which counts things like search box background queries; in particular, it greatly over-samples Google. A more realistic number is HTTP_PAGELOAD_IS_SSL, for which HTTPS adoption is still around 30%. That's consistent with other measures of how many sites out there support HTTPS. --Richard [1] http://telemetry.mozilla.org/#filter=release%2F32%2FHTTP_TRANSACTION_IS_SSLaggregates=multiselect-all!SubmissionsevoOver=Buildslocked=truesanitize=truerenderhistogram=Graph [2] http://telemetry.mozilla.org/#filter=release%2F32%2FHTTP_PAGELOAD_IS_SSLaggregates=multiselect-all!SubmissionsevoOver=Buildslocked=truesanitize=truerenderhistogram=Graph -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How do you run unit tests against Firefox?
What exactly do you mean by unit tests? At first I thought you were just referring to C++ unit tests, i.e. the ones that show up on Treeherder as Cpp. But the first page of the survey says We care about tests which are also run on tbpl (e.g. mochitests, reftest, xpcshell, marionette, etc.) so now I suspect you are referring to all tests... Clarification would be welcome, both here and on the survey itself. Thanks. Nick On Wed, Nov 12, 2014 at 5:17 AM, jmaher joel.ma...@gmail.com wrote: On the A*Team we do many projects to bring new platforms online or make sure our test harnesses work in new situations (like e10s). We hear great ideas from folks we interact with (sometimes we make up our own ideas), but one thing we don't know is how people run unit tests and what type of workflow is normal. To answer this we created a survey: http://goo.gl/p45Iwo As different teams have different workflows, we would really appreciate if you fill out the team you work on (or do the most work for) - that is question 1 of 13 in the survey! Now is your chance to ask for automated sandwich making! -jmaher ___ 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
Re: How do you run unit tests against Firefox?
On 11/12/2014 5:49 PM, Nicholas Nethercote wrote: What exactly do you mean by unit tests? I presumed that this meant all of our pass/fail test suites (not the performance tests): xpcshell, the various flavors of mochitest, reftests, etc. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Mailing list for version control discussion
version-control-...@mozilla.org is now a mailing list. Short term, we'll likely be talking about upgrading the server infrastructure and fixing Try. Long term, I imagine there will be some interesting discussions about more official Git support. If you care about version control or want to be in the know about what's going on, please consider joining the list. While I'm here, also consider joining https://groups.google.com/forum/#!forum/mozilla-code-review, which talks about the development of MozReview. There's lot of exciting things happening. Healthy debates are healthy for product quality. Please consider getting involved. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mailing list for version control discussion
On 11/12/14 5:58 PM, Gregory Szorc wrote: version-control-...@mozilla.org is now a mailing list. Short term, we'll likely be talking about upgrading the server infrastructure and fixing Try. Long term, I imagine there will be some interesting discussions about more official Git support. If you care about version control or want to be in the know about what's going on, please consider joining the list. While I'm here, also consider joining https://groups.google.com/forum/#!forum/mozilla-code-review, which talks about the development of MozReview. There's lot of exciting things happening. Healthy debates are healthy for product quality. Please consider getting involved. You can join version-control-dev @ https://mail.mozilla.org/listinfo/version-control-dev (sorry for the spam) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: http-schemed URLs and HTTP/2 over unauthenticated TLS (was: Re: WebCrypto for http:// origins)
On Wed, Nov 12, 2014 at 11:12 PM, Richard Barnes rbar...@mozilla.com wrote: On Nov 12, 2014, at 4:35 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Sep 15, 2014 at 7:56 PM, Adam Roach a...@mozilla.com wrote: The whole line of argumentation that web browsers and servers should be taking advantage of opportunistic encryption is explicitly informed by what's actually happening elsewhere. Because what's *actually* happening is an overly-broad dragnet of personal information by a wide variety of both private and governmental agencies -- activities that would be prohibitively expensive in the face of opportunistic encryption. ISPs are doing it already it turns out. Governments getting to ISPs has already happened. I think continuing to support opportunistic encryption in Firefox and the IETF is harmful to our mission. You're missing Adam's point. From the attacker's perspective, opportunistic sessions are indistinguishable from I assume you meant to say indistinguishable from https sessions, so the MITM risks breaking some https sessions in a noticeable way if the MITM tries to inject itself into an opportunistic session. That's true if the server presents a publicly trusted cert for the wrong hostname (as is common if you try to see what happens if you change the scheme for a random software download URL to https and get a cert for Akamai--I'm mentioning Akamai because of the [unmentioned on the draft] affiliation of the other author). However, if the site presents a self-signed cert, the MITM could check the chain and treat self-signed certs differently from publicly trusted certs. (While checking the cert chain takes more compute, it's not outlandish considering that an operator bothers to distinguish OpenVPN from IMAP-over-TLS on the same port per https://grepular.com/Punching_through_The_Great_Firewall_of_TMobile .) But even so, focusing on what the upgraded sessions look like is rather beside the point when it's trivial for the MITM to inhibit the upgrade in the first place. In an earlier message to this thread, I talked about overwriting the relevant header in the initial HTTP/1.1 traffic with spaces. I was thinking too complexly. All it takes is changing one letter in the header name to make it unrecognized. In that case, the MITM doesn't even need to maintain the context of two adjacent TCP packets but can, with little risk of false positives, look for the full header string in the middle of the packet or a tail of at least half the string at the start of a packet or at least half the string at the end of a packet and change one byte to make the upgrade never happen--all on the level of looking at individual IP packets without bothering to have any cross-packet state. This is not a theoretical concern. See https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks for an analogous attack being carried out for email by ISPs. If we kept http URLs strictly HTTP 1.1, it would be clear that if you want the fast new stuff, you have to do confidentiality, integrity and authenticity properly. Sites want the fast new stuff, so this would be an excellent carrot. By offering an upgrade to unauthenticated TLS, people both at our end and at the server end expend effort to support MITMable encryption, which is bad in two ways: 1) that effort would be better spent on proper https [i.e. provisioning certs properly as far as the sites are concerned; you already need a TLS setup for the opportunistic stuff] and 2) it makes the line between the MITMable and the real thing less clear, so people are likely to mistake the MITMable for the real thing and feel less urgency to do the real thing. I haven't been to the relevant IETF sessions myself, but assume that https://twitter.com/sleevi_/status/509954820300472320 is true. If even only some operators show a preference to opportunistic encryption over real https, that alone should be a huge red flag that they intend to keep MITMing what's MITMable. Therefore, we should allocate our finite resources to pushing https to be better instead of diverting effort to MITMable things. -- 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: MozReview ready for general use
Hi, I've been trying MozReview and I'm having trouble with updating a review with changes for my reviewers to verify. The documentation says, Oh, it just works, but in my case it doesn't. I'm using the evolve extension, so my repo have obsolescence markers, but I don't see them being sync'd with the review repo. Or maybe I'm using reviewboard incorrectly. Anyway, is there a way to tell MozReview that a changeset id is an update for an existing review, for example, by using the web interface to upload a diff, or should I discard my existing reviews and start again? thanks - Dan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozReview ready for general use
On 11/12/14 10:39 PM, Dan Glastonbury wrote: Hi, I've been trying MozReview and I'm having trouble with updating a review with changes for my reviewers to verify. The documentation says, Oh, it just works, but in my case it doesn't. I'm using the evolve extension, so my repo have obsolescence markers, but I don't see them being sync'd with the review repo. Or maybe I'm using reviewboard incorrectly. Anyway, is there a way to tell MozReview that a changeset id is an update for an existing review, for example, by using the web interface to upload a diff, or should I discard my existing reviews and start again? Please file a bug with STR. We don't sync obs markers using Mercurial yet. Instead, we transfer the obs markers as part of the initiate review payload. The server has them long enough to perform an intelligent mapping, then it discards them. As soon as native obs marker exchange scales to our level, we'll likely enable it. Unfortunately, we don't have any UI letting you know that obs markers are being used. Perhaps we should add that... It is always safe to push new commits to the review server. Worst case you discard the drafts and nobody sees the mess but you. This is a benefit of Review Board's draft-by-default workflow. If evolution is failing you or you aren't using evolution, commit reordering will often result in review requests getting mapped to the wrong commit. We know we need to implement a heuristic based commit matcher to detect this reordering and map review requests appropriately. It's just not the highest priority right now. Code is at https://hg.mozilla.org/hgcustom/version-control-tools/file/220f22694a45/pylib/reviewboardmods/reviewboardmods/pushhooks.py#l268 if someone wants to take a stab at it. (This is high on the list once we get basic UI warts and Bugzilla interaction squared away.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
