Re: Treeherder New Login Flow
On 2/9/18 9:30 AM, ha...@mozilla.com wrote: > - Treeherder session will stay alive as long as access to the site > happens once every 24 hours. 3 days session expiry is no longer in > effect. This doesn't seem to be the case: I'm logged in when I go to bed, and 7 hours later when I get up I'm logged out; I'm logged in when I leave for work, and 4.5 hours later when I get home on my lunch hour I'm logged out. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improved wpt-sync now running experimentally
On 09/02/2018 19:59, Josh Bowman-Matthews wrote: On 2/9/18 1:26 PM, James Graham wrote: * One bug per PR we downstream, filed in a component determined by the files changed in the PR. What does this mean exactly? What is the desired outcome of these bugs? They're tracking the process and will be closed when the PR lands in central. They are used for notifying gecko developers about the incoming change, and in particular contain the information about tests that went from passing to failing, and other problems during the import. They are not essential to the sync so if they end up not working well at keeping people informed we can revisit the approach. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improved wpt-sync now running experimentally
On 2/9/18 1:26 PM, James Graham wrote: * One bug per PR we downstream, filed in a component determined by the files changed in the PR. What does this mean exactly? What is the desired outcome of these bugs? Cheers, Josh ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improved wpt-sync now running experimentally
On 2/9/18 1:26 PM, James Graham wrote: The new code is intended to provide the following improvements over the old periodic batch sync approach: Thank you. This is awesome. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Improved wpt-sync now running experimentally
The new sync for web-platform-tests is now running experimentally. This provides two way sync between the w3c/web-platform-tests repository on GitHub and mozilla-central, so allowing gecko developers to contribute to web-platform-tests using their normal gecko workflow, and ensuring that we get all the upstream changes submitted by the community including engineers at Google, Apple, and Microsoft. The new code is intended to provide the following improvements over the old periodic batch sync approach: * Faster sync. The code to actually land changes to mozilla-central is still undergoing testing, but the intent is that we can get at least one wpt update per day once the system is fully operational. * One bug per PR we downstream, filed in a component determined by the files changed in the PR. * One PR per bug we upstream. Currently this will be created when a patch lands on inbound or autoland and should be merged when the patch reaches central. In some hypothetical future world in which there's a single entry point for submitting code to land in gecko (e.g. phabricator) this will change so that the PR is created when the code is submitted for review, so that upstream test results are available before landing (see next point). * Upstream CI jobs run on PRs originating from gecko repositories. Previously we skipped upstream travis jobs on pushes we landed, occasionally causing breakage as a result. Now these jobs are run on all our pushes and the original bug should get a notification if the jobs fail. * Notifications of notable changes introduced by upstream PRs. In particular we will add a comment when tests that used to pass start to not pass, when there are crashes or disabled tests, and for new tests that fail. This notification happens in the bug for the sync, but there is already an issue open to move things that obviously require attention (e.g. crashes) into their own bug. If you notice problems with the sync, please file an issue [1] or complain in #wpt-sync on irc. The project team consists of: * jgraham and maja_zf (development, primary contacts) * AutomatedTester (project management) Issues are not unanticipated at this time, so thanks in advance for your patience as we work out the kinks in the system. [1] https://github.com/mozilla/wpt-sync/issues ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Treeherder New Login Flow
Hi, I am writing to inform you about Treeherder’s new login flow. In the past, logging in with Treeherder meant being redirected to the login.taskcluster.net service. This had a couple of drawbacks, but one of the main annoyance was that credentials expired every 3 days. You are probably already familiar with the following error: "Your credentials are expired. They must expire every 3 days (Bug 1328434). Log out and back in again to refresh your credentials." The new login flow now uses Auth0 instead of login.taskcluster.net for SSO. Some relevant information to note: - When you login for the first time, you will get a prompt asking permission for treeherder.mozilla.org to access “full-user-credentials”. It’s not something to be worried about. This is simply a request to access your taskcluster credentials. Bug 1437116 was created to change that to "taskcluster-credentials”. - Treeherder session will stay alive as long as access to the site happens once every 24 hours. 3 days session expiry is no longer in effect. - If an email is associated with multiple login providers, then the most secure login method should be used (LDAP > GitHub 2FA > GitHub > Google > Passwordless). Thanks, Hassan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Chrome will start marking HTTP pages as "Not secure"
Yeah, there's a team working on this stuff (and they/we have been in touch with the Chrome people for a long time) and this is not a call we should make on a mailing list. There's a valid concern around warning fatigue (plastering so many sites with "Insecure" that users easily dismiss it) and we made those prefs to be able to run user studies on it. I believe the original question was whether there are any blockers to shipping this in Firefox right now. Technically? No. We should still give product the chance to take a good look at the potential impact and how it works in our design concept and not make this a race to the moon. Thanks Johann Jonathan Kingston wrote: > Hey, > > So we have two issues here: > - We have less testing on security.insecure_connection_text.enabled > - security.insecure_connection_icon.enabled is a lot heavier handed as MT > notes and also we use this for insecure passwords too. > > We also have the pbmode variants if we wanted both enabled when in Private > Browsing mode. > > We are discussing the impact of shipping the "Not Secure" text with product > at the moment which is likely much safer to ship right now. > > Thanks > Jonathan > > On Fri, Feb 9, 2018 at 2:02 PM, Tom Schuster wrote: > >> If you flip just security.insecure_connection_text.enabled and not >> security.insecure_connection_icon.enabled you get Chrome's behavior. >> Flipping both gives you the broken lock and the "Not Secure" text. I >> don't see a big difference there and I hope we can ship this as soon >> as possible. >> >> On Fri, Feb 9, 2018 at 1:55 AM, Martin Thomson wrote: >>> +ffxdev >>> >>> There's a tangible difference between text saying "Not Secure" and a >>> broken lock icon. I think that we're close, but we'd be making a >>> stronger statement than Chrome if we did this. >>> >>> On Fri, Feb 9, 2018 at 8:17 AM, Chris Peterson >> wrote: Chrome will start marking HTTP pages as "Not secure" in July 2018 >> (Chrome 68): https://security.googleblog.com/2018/02/a-secure-web-is- >> here-to-stay.html Firefox has a similar insecure HTTP warning icon, currently disabled by >> the `security.insecure_connection_icon.enabled` pref added in bug 1310447. Are there any blockers for Firefox shipping this feature? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform >>> ___ >>> firefox-dev mailing list >>> firefox-...@mozilla.org >>> https://mail.mozilla.org/listinfo/firefox-dev >>> >> ___ >> 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Chrome will start marking HTTP pages as "Not secure"
Hey, So we have two issues here: - We have less testing on security.insecure_connection_text.enabled - security.insecure_connection_icon.enabled is a lot heavier handed as MT notes and also we use this for insecure passwords too. We also have the pbmode variants if we wanted both enabled when in Private Browsing mode. We are discussing the impact of shipping the "Not Secure" text with product at the moment which is likely much safer to ship right now. Thanks Jonathan On Fri, Feb 9, 2018 at 2:02 PM, Tom Schuster wrote: > If you flip just security.insecure_connection_text.enabled and not > security.insecure_connection_icon.enabled you get Chrome's behavior. > Flipping both gives you the broken lock and the "Not Secure" text. I > don't see a big difference there and I hope we can ship this as soon > as possible. > > On Fri, Feb 9, 2018 at 1:55 AM, Martin Thomson wrote: > > +ffxdev > > > > There's a tangible difference between text saying "Not Secure" and a > > broken lock icon. I think that we're close, but we'd be making a > > stronger statement than Chrome if we did this. > > > > On Fri, Feb 9, 2018 at 8:17 AM, Chris Peterson > wrote: > >> Chrome will start marking HTTP pages as "Not secure" in July 2018 > (Chrome > >> 68): > >> > >> https://security.googleblog.com/2018/02/a-secure-web-is- > here-to-stay.html > >> > >> Firefox has a similar insecure HTTP warning icon, currently disabled by > the > >> `security.insecure_connection_icon.enabled` pref added in bug 1310447. > >> > >> Are there any blockers for Firefox shipping this feature? > >> ___ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-platform > > > > ___ > > firefox-dev mailing list > > firefox-...@mozilla.org > > https://mail.mozilla.org/listinfo/firefox-dev > > > ___ > 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
Intent to remove: Throttling of timeouts from tracking scripts
TL;DR We have decided to not (re-)turn on throttling of timeouts from tracking scripts, and also remove throttling of timeouts from tracking scripts altogether. This feature was, in the beginning, only intended for tabs in the background, but experiments were also conducted to see the effect of throttling for foreground tabs. These experiments showed that users became inclined to abandon pages to a higher degree than before, and after letting the feature be turned on for Nightly for a period of time, issues that would actually block user interaction were noticed. Actually being able to resolve these issues for foreground tabs is difficult, especially in light of how we schedule timeout events after the rewrite that allowed us to only use a single timer per window[1,2]. Even being able to solve the issues related to throttling of background tracking timeouts would introduce unwarranted complexity, and by instead removing throttling of timeouts from tracking scripts we would reduce complexity of timeout handling. The silver lining is that the importance of throttling of timeouts from tracking scripts has been reduced since we started throttling all timeouts from background windows using the background execution budget, to the degree that we are confident that throttling of tracking timeouts is not as necessary anymore. Cheers, Andreas [1] Bug 1363829: https://bugzilla.mozilla.org/show_bug.cgi?id=1363829 [2] Bug 1371787: https://bugzilla.mozilla.org/show_bug.cgi?id=1371787 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Chrome will start marking HTTP pages as "Not secure"
If you flip just security.insecure_connection_text.enabled and not security.insecure_connection_icon.enabled you get Chrome's behavior. Flipping both gives you the broken lock and the "Not Secure" text. I don't see a big difference there and I hope we can ship this as soon as possible. On Fri, Feb 9, 2018 at 1:55 AM, Martin Thomson wrote: > +ffxdev > > There's a tangible difference between text saying "Not Secure" and a > broken lock icon. I think that we're close, but we'd be making a > stronger statement than Chrome if we did this. > > On Fri, Feb 9, 2018 at 8:17 AM, Chris Peterson wrote: >> Chrome will start marking HTTP pages as "Not secure" in July 2018 (Chrome >> 68): >> >> https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html >> >> Firefox has a similar insecure HTTP warning icon, currently disabled by the >> `security.insecure_connection_icon.enabled` pref added in bug 1310447. >> >> Are there any blockers for Firefox shipping this feature? >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: gkrust compilation RAM requirements and 32-bit systems
On Fri, Feb 9, 2018 at 12:00 PM, Emilio Cobos Álvarez wrote: > On 02/09/2018 10:49 AM, Henri Sivonen wrote: >> Is there some trick to make gkrust compilation succeed on a 32-bit system? > > The BSD folks seem to be using --disable-debug-symbols for that, see > https://bugzilla.mozilla.org/show_bug.cgi?id=1401093 Thanks. Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1436981 . (gkrust completed. libxul linking still ahead. Building with -j 1 isn't very fast...) On Fri, Feb 9, 2018 at 1:31 PM, Ted Mielczarek wrote: > https://convolv.es/blog/2017/08/25/building-firefox-for-linux-32-bit/ There seems to be a step that involves running code within the chroot environment to set thing up. I take it that to target armv7, the host would then need to be aarch64 and not x86_64? Or maybe one could run mach bootstrap on a real ARMv7 system and then dump the file system to an external disk and move that over? Anyway, considering how complicated this is, it would be great to have try server targets for ARMv7+NEON GNU/Linux and aarch64 GNU/Linux for testing stuff in a hopefully Android-representative way when using actual Android looks even messier. (Running gtest microbenchmarks on hardware that, unlike phones, has stable clock speed under single-threaded 100% load but hopefully is close enough to phones in terms of core design to be representative.) -- 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: PSA: HTML injection in chrome documents is now automatically sanitized
My bad! This is certainly a bug in the linter. The fix is underway. On 09.02.2018 12:35, Gijs Kruitbosch wrote: > Sorry about the waste of time. :-( > > Re: difficulty: it depends on your measure of 'very'. Internally the > sanitization is whitelist-based. It is used in many places (not just for > chrome-privileged docs), where it would be wrong to show warnings > (possibly very *many* warnings!). It may be possible to add a flag to > the sanitizer to log warnings for every removed attribute/element, and > to pass that explicitly from the callsites that Kris added. It'd be > worth filing a bug for that. > > To be honest, I would have expected there to have been an eslint error > if using innerHTML/createContextualFragment with anything other than a > fixed string, which might have saved you a lot of headache. If that > linter isn't catching createContextualFragment, then we need to fix the > linter so that it does. If you were using a fixed string that got > sanitized, can you point me to the bug/patch that you're working on? I'm > having trouble thinking of cases where we use innerHTML with fixed > content that would get sanitized in this way, without any > injection/replacement, but perhaps I'm missing something. > > ~ Gijs > > On 09/02/2018 02:18, Brendan Dahl wrote: >> Would it be very difficult to warn when something is sanitized and >> removed? >> >> I wasted a good deal of time trying to figure out why >> createContextualFragment wasn't working. >> >> On Fri, Feb 2, 2018 at 2:10 AM, Gijs Kruitbosch >> >> wrote: >> >>> FWIW, if you're running into this with the usecase "I have a localized >>> string that needs to have links (or other markup) in it" and were >>> formerly >>> using getFormattedString combined with innerHTML, we now have a utility >>> method that can help a little bit. Rather than hand-rolling splitting >>> the >>> string etc., on nightly you can use BrowserUtils.getLocalizedFragment as >>> a replacement. Given a document, raw string (fetch using getString / >>> GetStringFromName instead of the "formatted" APIs), and DOM nodes to >>> insert, it'll produce a DocumentFragment that you can >>> appendChild/insertBefore etc., take care of splitting your strings >>> for you, >>> and will work with both indexed (%1$S) and non-indexed (%S) replacement >>> points in the localized string. In the further future, I expect this >>> type >>> of problem will go away entirely because of Fluent. >>> >>> ~ Gijs >>> >>> >>> On 02/02/2018 07:13, Kris Maglione wrote: >>> As of bug 1432966, any HTML injected into chrome-privileged documents[1] is automatically sanitized to remove any possibility of script execution. The sanitization is whitelist-based, and only allows a limited set of HTML elements and attributes. All scripts, XUL nodes, or privileged URLs will automatically be removed. This change has been uplifted all the way to 58 release. If you're thinking about writing new code that injects HTML strings into chrome-privileged documents, please think again. Unless it's extremely simple, it probably won't be compatible with these changes (and will also be rejected by our default ESLint rules). Existing HTML injection in chrome documents is being gradually removed. Once that's done, the sanitization may be replaced with an outright prohibition. -Kris [1]: Using the usual HTML fragment creation methods such as `innerHTML`, `outerHTML`, `insertAdjacentHTML`, and `createContextualFragment`. Not, notably, when using document.write(). ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev >>> >>> >>> ___ >>> firefox-dev mailing list >>> firefox-...@mozilla.org >>> https://mail.mozilla.org/listinfo/firefox-dev >>> > > ___ > 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: PSA: HTML injection in chrome documents is now automatically sanitized
Sorry about the waste of time. :-( Re: difficulty: it depends on your measure of 'very'. Internally the sanitization is whitelist-based. It is used in many places (not just for chrome-privileged docs), where it would be wrong to show warnings (possibly very *many* warnings!). It may be possible to add a flag to the sanitizer to log warnings for every removed attribute/element, and to pass that explicitly from the callsites that Kris added. It'd be worth filing a bug for that. To be honest, I would have expected there to have been an eslint error if using innerHTML/createContextualFragment with anything other than a fixed string, which might have saved you a lot of headache. If that linter isn't catching createContextualFragment, then we need to fix the linter so that it does. If you were using a fixed string that got sanitized, can you point me to the bug/patch that you're working on? I'm having trouble thinking of cases where we use innerHTML with fixed content that would get sanitized in this way, without any injection/replacement, but perhaps I'm missing something. ~ Gijs On 09/02/2018 02:18, Brendan Dahl wrote: Would it be very difficult to warn when something is sanitized and removed? I wasted a good deal of time trying to figure out why createContextualFragment wasn't working. On Fri, Feb 2, 2018 at 2:10 AM, Gijs Kruitbosch wrote: FWIW, if you're running into this with the usecase "I have a localized string that needs to have links (or other markup) in it" and were formerly using getFormattedString combined with innerHTML, we now have a utility method that can help a little bit. Rather than hand-rolling splitting the string etc., on nightly you can use BrowserUtils.getLocalizedFragment as a replacement. Given a document, raw string (fetch using getString / GetStringFromName instead of the "formatted" APIs), and DOM nodes to insert, it'll produce a DocumentFragment that you can appendChild/insertBefore etc., take care of splitting your strings for you, and will work with both indexed (%1$S) and non-indexed (%S) replacement points in the localized string. In the further future, I expect this type of problem will go away entirely because of Fluent. ~ Gijs On 02/02/2018 07:13, Kris Maglione wrote: As of bug 1432966, any HTML injected into chrome-privileged documents[1] is automatically sanitized to remove any possibility of script execution. The sanitization is whitelist-based, and only allows a limited set of HTML elements and attributes. All scripts, XUL nodes, or privileged URLs will automatically be removed. This change has been uplifted all the way to 58 release. If you're thinking about writing new code that injects HTML strings into chrome-privileged documents, please think again. Unless it's extremely simple, it probably won't be compatible with these changes (and will also be rejected by our default ESLint rules). Existing HTML injection in chrome documents is being gradually removed. Once that's done, the sanitization may be replaced with an outright prohibition. -Kris [1]: Using the usual HTML fragment creation methods such as `innerHTML`, `outerHTML`, `insertAdjacentHTML`, and `createContextualFragment`. Not, notably, when using document.write(). ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: gkrust compilation RAM requirements and 32-bit systems
On Fri, Feb 9, 2018, at 4:49 AM, Henri Sivonen wrote: > Is it expected that Firefox can no longer be built on a 32-bit system? Yes. > The cross-compilation documentation on MDN seems to predate Rust code > in Firefox. Is there an up-to-date guide for compiling Firefox for > ARMv7+NEON (or aarch64 for that matter) GNU/Linux on an x86_64 > GNU/Linux host? I don't know that there have ever been good docs for this scenario--our well-supported cross-compile scenario is Android, which has its own SDK. Cross-compiling other things on Linux without a chroot is a giant PITA. jryans did write a good blog post[1] last year about building a 32-bit Firefox on 64-bit Linux, which might be useful. AFAIK Rust is the easy part, since you can just `rustup target add armv7-unknown-linux-gnueabihf` or whatever target you need. Getting all the -dev packages for various system libraries is the hard part. -Ted 1. https://convolv.es/blog/2017/08/25/building-firefox-for-linux-32-bit/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: gkrust compilation RAM requirements and 32-bit systems
On 02/09/2018 10:49 AM, Henri Sivonen wrote: > Is there some trick to make gkrust compilation succeed on a 32-bit system? The BSD folks seem to be using --disable-debug-symbols for that, see https://bugzilla.mozilla.org/show_bug.cgi?id=1401093 -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
gkrust compilation RAM requirements and 32-bit systems
Previously, the RAM-critical operation during Firefox build was linking libxul, which on Linux was known not to work with 1 GB of RAM but did work with 2 GB of RAM. Now, when trying to build Firefox (opt build) on ARMv7 Linux with 2.3 GB of *free* RAM at the start of the build, building gkrust fails. (Nightly rustc OOMs and stable rustc causes the system to reboot.) Do I understand correctly that even on an ARMv7 system that has more than 2 GB of physical RAM, a userspace process (rustc) can address only 2 GB and, therefore, with 2.4 GB free at the start of the build and build failing with -j 1, rustc got the maximal RAM it can possibly get? (The reboot bit suggest something other than mere userland virtual address space exhaustion, though. This is with a Chrome OS kernel that doesn't let me enable swap.) Is it expected that Firefox can no longer be built on a 32-bit system? Is there some trick to make gkrust compilation succeed on a 32-bit system? The cross-compilation documentation on MDN seems to predate Rust code in Firefox. Is there an up-to-date guide for compiling Firefox for ARMv7+NEON (or aarch64 for that matter) GNU/Linux on an x86_64 GNU/Linux host? -- 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: PSA: HTML injection in chrome documents is now automatically sanitized
On Friday, February 2, 2018 at 2:11:02 AM UTC-8, Gijs Kruitbosch wrote: > In the further future, I expect this type of problem will go away > entirely because of Fluent. That's correct! Fluent brings the concept of DOM Overlays which allow for safe mixing between developer provided DOM fragments and localization. We're currently completing the feature set of DOM Overlays to allow for element ordering (to allow translations to reorder elements in a localizable fragment), but the core functionality is in tree and is used in the current migration of Preferences to Fluent. It's all sanitized and safe following W3C localization guidelines. :) zb. p.s. the timeline for when you'll be able to use Fluent is a bit in flux. We're currently testing Fluent migrating Preferences to it and need a bit more time to gain confidence that all parts of the system are ready - we wouldn't want you to start using it for your component and then have to tell you to stop, because some feature is not ready yet. Hope to unblock Fluent for new code soon! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
