Last week we launched the Mozilla Open Source Support Program (MOSS) – an award program specifically focused on supporting open source and free software. The first track within MOSS provides support for open source and free software projects that Mozilla uses or relies on. Our goal is to identify up to 10 such projects that we can fund in a thoughtful, meaningful way by December 12th.

You can find the link to apply along with more on the criteria and resources you will need to submit, in a longer post on my blog.

https://blog.mozilla.org/blog/2015/10/30/mozilla-open-source-support-program-applications-are-open/

Hello, SUMO Nation!

October is almost gone, here comes November… Are you ready? Are you celebrating something scary and gloomy in the coming days? We recommend you keep warm and happy using the most ancient of alchemies… tea & cookies!

Oh, right, one more thing… Have you heard about MOSS already? Nope? Read more here!

Welcome, New Contributors!

• MysteryTech (mysterious AND technical!)
• skylake
• pvac
• zabsonrejp

Community

• MozFest London is upon us! Get together and have a great time!
• A bit further down the line… There’s FOSDEM! Are you going?
• Are you a member of the Deaf community or know someone who is? Do you sign? Help us create open source support content in sign language!
• Final reminder: let us know what you think about contributor information at SUMO.
• Ongoing reminder: if you think you can benefit from getting a second-hand device to help you with contributing to SUMO, you know where to find us.

Support Forum

• Help Rachel explore support experience in places other than SUMO.
• Learn how to deal with angry users (or people in general) – (kudos to Andrew and Noah for sharing these!)

https://blog.mozilla.org/sumo/2015/10/30/whats-up-with-sumo-30th-october/

Here’s a story about a printing bug on OS X, and a lesson about how our IPC layer works.

Last week, :ehsan came up to my desk and said “Mike… printing is broken on OS X with e10s enabled. Did you know this?”

It was sad to hear. Nobody, as far as I knew, had been touching printing code (besides bobowen, but he hadn’t landed his patches yet), which meant that some mystery change had landed and it was my responsibility (as the one who had implemented printing on OS X for e10s) to fix it.

The first step was to confirm it. Yep, it looked like I couldn’t print on my Nightly. Crap¹. So we get the bug filed, and then I fired up my local build and lldb, and tried to trace out where the problem was occurring.

Drilling down to the regressing changeset

The problem was that my local build printed just fine. Eyebrow raised, I tried using my default profile with my local build to see if something about my profile was causing printing to break. Printing continued to work with my local build².

Scratching my head, I used mozregression to bisect the problem down to a single changeset.

Here’s the bug it spat out:

Bug 1209930 – Update Mac clang to match the version in use everywhere else

The hair stood up on the back of my neck. Printing got broken by a compiler upgrade? This had bad news written all over it.

Many try builds

So that, I guess, explained why I couldn’t reproduce the problem locally. I needed to build with a particular compiler in order to experience the bug.

The bad news was that I found out that the version of clang that we’d upgraded to didn’t work on my version of OS X (10.10.5). It was supposed to work on machines running OS X 10.7, but I didn’t have access to any³.

I was able to get debug builds off of try, but I had no luck convincing lldb to let me step through it, despite having the symbols and the right revision checked out⁴.

So this meant a lot of try builds. The good news is that I was able to add a bunch of logging to try, and just kinda walk away while it built. A few hours later, I’d have my build, and I’d get my results. I wasn’t blocked waiting on it to build, so I could work on other things.

What did the logging reveal?

Our printing code sometimes shows this progress dialog when printing starts. It’s put up so that while we’re laying out the page for printing, the user knows that stuff is happening. We show this progress dialog on Linux and Windows, but not on OS X (I guess OS X users don’t expect such a progress window… this was a decision made way back in the day).

The printing engine in the content process sends up a message to the parent saying, “I’m all set to print, let’s show the progress dialog!”. On OS X, the parent responds, “Uh, nope” (which is a return code of NS_ERROR_NOT_IMPLEMENTED), and the child is supposed to go, “Oh okay, I’ll just print right away”.

But here’s the kicker – along with message to show the progress dialog, the child sends an outparam⁵. That outparam is sent because for some platforms that show the progress dialog, we want to wait until the dialog closes before starting the actual print. On other platforms, we may just want to start printing right away when laying out the page finishes without waiting for the dialog to close.

That outparam is a bool initialized to a value of false in the print engine, and in the non-e10s case where we return “Sorry, no progress dialog” with NS_ERROR_NOT_IMPLEMENTED, that bool stays false, and when it stays false, it means that we start printing right away.

My logging showed that for some reason, that value was getting flipped to true despite not being touched by (seemingly) anything in the IPC sender / receiver nor the print progress dialog backend (which still just returns NS_ERROR_NOT_IMPLEMENTED when asked to open the printing dialog).

What the hell?

Here’s the PSA

Ehsan helped me dig into what was going on, and we figured it out. Here’s the big lesson / PSA here:

outparams over IPC, when untouched on the receiver side, get filled with values from uninitialized memory when returned to the sender.

I’ll give you an example. Here’s some sorta-pseudocode:

#include 

void someFunc(bool* aOutParam) {
}

int main(int argc, char** argv) {
  bool myBool = false;
  someFunc(&myBool);
  if (myBool) {
    printf("Wait, WHAT?");
    return 1;
  }
  return 0;
}

We should never enter that “Wait, WHAT?” conditional block because myBool remains false throughout. It’s initialized to false, and even though we pass a pointer to it to someFunc, someFunc never touches it, so it stays false, and so we skip the conditional and return 0 as expected.

If, however, you did the same thing, but over IPC… well, now you’re in for a fun treat.

On the receiver side of the IPC message, here’s a chunk of the generated code that calls into RecvShowPrintProgress on the parent side:

            bool notifyOnOpen;
            bool success;
            int32_t id__ = mId;
            if \((!(RecvShowProgress(mozilla::Move(browser), mozilla::Move(printProgressDialog), mozilla::Move(isForPrinting), (&(notifyOnOpen)), (&(success)))))) {
                mozilla::ipc::ProtocolErrorBreakpoint("Handler for ShowProgress returned error code");
                return MsgProcessingError;
            }

            reply__ = new PPrinting::Reply_ShowProgress(id__);

            Write(notifyOnOpen, reply__);
            Write(success, reply__);
            (reply__)->set_sync();
            (reply__)->set_reply();

That notifyOnOpen bool is the one that is the outparam in the child. Notice that it’s not being initialized to any value! That means its current value could be, well, anything. When we call into RecvShowProgress, we pass a pointer to that anything value. If RecvShowProgress doesn’t do anything with that pointer (like in the OS X case), well… that random value is what gets written to the IPC message that gets sent back to the child.

And somehow a clang upgrade made it far more likely that this value would evaluate to TRUE as a boolean instead of FALSE.

And so the child assumed that it’d have to wait for a dialog to close before starting to print – a dialog that would never open, because we don’t show it on OS X.

So the patch I eventually wrote initializes the outparam to false before calling into the OS X widget code that just returns NS_ERROR_NOT_IMPLEMENTED, and that fixed the bug.

It’s a small patch, but in my mind, it’s a big lesson, at least for me. I had assumed that outparams would work the same over IPC as they do in the same process, and that’s simply not the case.

I’ve filed bug 1220168 to try to make this sort of thing easier to spot in the future.

1. Our automated testing story for printing is pretty bad. We test some of the built-in UI for printing, but as for actually sending stuff to printer drivers… zero automated tests, which explains why this had gone uncaught for so long. 

http://mikeconley.ca/blog/2015/10/30/a-printing-story-and-a-psa-outparams-over-the-ipc-layer-might-not-behave-like-youd-expect/

This week, the U.S. Senate passed the Cybersecurity Information Sharing Act (CISA), a bill intended to promote the sharing of cybersecurity threat information. Mozilla joined the major tech companies and civil society groups in opposing this bill with concerns that it would undermine user trust, privacy, and security. Unnecessary and harmful sharing of private user information could be a real consequence of this bill.

But CISA is not law yet; CISA must be reconciled with the two cybersecurity bills that the U.S. House passed earlier this year, and both chambers will then need to pass the reconciled version. Unfortunately, it’s hard to see how any marginal improvements during these negotiations will be enough to fix its flaws.

If CISA follows this path and becomes U.S. law, it might be tempting for Members of Congress to feel like that they can “check the box” of cybersecurity and move on to the next hot topic. However, CISA and its counterparts will do little to stop exploits like the Target hack, the OPM breach, or the Heartbleed vulnerability.

If Congress wants to make meaningful progress toward improved cybersecurity, it should move now to ensuring that the government is disclosing critical vulnerabilities in computer networks and systems. Responsible disclosure of vulnerabilities would build on any information sharing legislation in a way that could gain widespread support.

CISA is far from the only mechanism for the private sector to share cybersecurity threat information with the government, and by itself is unlikely to result in meaningful improvements in cybersecurity. But information sharing through CISA will likely lead the government to acquire knowledge of critical vulnerabilities in computer networks and systems, and the government’s expeditious disclosure of those vulnerabilities with the relevant vendor(s), in contrast, would be highly valuable. Information sharing was never supposed to be a one-way street. Yet, there is currently no presumption in law that the U.S. government should disclose vulnerabilities. This makes CISA’s provisions requiring information shared with the Department of Homeland Security to be automatically shared with the NSA, DOD, and others in the intelligence community even more concerning.

While the Obama Administration has claimed that it discloses the vast majority of vulnerabilities, we know from recent FOIA documentation that the government currently lets the NSA lead the disclosure determination process, a discussion dominated by the intelligence community with inadequate participation from critical federal agencies like the Departments of Homeland Security or Commerce, and lacks accountability and transparency.

Indeed, the President’s own Review Group on Intelligence and Communications Technologies, which had security clearances and access to classified documents, found that there needed to be a significantly more robust and accountable process around vulnerability disclosure (see Recommendation #30). Implicit in this recommendation is the idea that the presumption should be that all vulnerabilities should be disclosed to the relevant vendor(s) so that they can be patched, and then in due course disclosed to the public. However, there may be times when delay in disclosure may prove so valuable to an ongoing intelligence operation, for example, that such a delay is merited.

Delays in disclosure should be few and far between, and the determination to delay disclosure must involve all of the relevant stakeholders in the government and be guided by a more detailed set of criteria than those Michael Daniel, the White House Cybersecurity Coordinator, laid out last year in a blog post about the Heartbleed vulnerability (although those are a good start).

Members of Congress should not think that their work on cybersecurity is done. With the passage of these information sharing bills, now more than ever, Congress should turns its attention to government vulnerability disclosure in order to meaningfully improve cybersecurity.

https://blog.mozilla.org/netpolicy/2015/10/30/vulnerability-disclosure-should-come-next-for-congress-on-cybersecurity/

Today I am happy to announce the second iteration of the Quarter of Contribution.  This will take place between November 23 and run until January 18th.

We are looking for contributors who want to tackle more bugs or a larger project and who are looking to prove existing skills or work on learning new skills.

There are 4 great projects that we have:

• Web Platform Tests – Results Explorer
• Web Platform Tests – WebDriver Infrastructure
• Pulse Guardian – Core Hacker
• Mozilla CI Tools – Polish and Packaging

There are no requirements to be an accomplished developer.  Instead we are looking for folks who know the basics and want to improve.  If you are interested, please read about the program and the projects and ask questions to the mentors or in the #ateam channel on irc.mozilla.org.

Happy hacking!

https://elvis314.wordpress.com/2015/10/29/looking-for-hackers-interested-in-hacking-for-6-8-weeks-on-a-quarter-of-contribution-project/

We asked Ann, Aur'elien, Elena, Sandra, and Varuzhan, 5 students from the ESCP Europe Business School to help us understand how to engage non-technical audiences...

https://air.mozilla.org/firefox-os-participation-escp-europe-business-school-consultancy-project/

The Participation Call helps connect Mozillians who are thinking about how we can achieve crazy and ambitious goals by bringing new people into the project...

https://air.mozilla.org/participation-call-20151029/

This is a weekly call with some of the Reps council members to discuss all matters Reps, share best practices and invite Reps to share...

https://air.mozilla.org/reps-weekly-20151029/

http://danielpocock.com/lumicall-rapid-provisioning-opus-and-other-enhancements

http://danielpocock.com/resiprocate-1.10-release

PSA: Pin Versions

Today, the website’s build broke. We made no changes to the tests, yet a wild dependency error emerged:

Generating...

  Dependency Error: Yikes! It looks like you don't have redcarpet or one of
its dependencies installed. In order to use Jekyll as currently configured,
you'll need to install this gem. The full error message from Ruby is: 'cannot
load such file -- redcarpet' If you run into trouble, you can find helpful
resources at http://jekyllrb.com/help/!

  Conversion error: Jekyll::Converters::Markdown encountered an error while
converting 'conduct.md':

                    redcarpet

             ERROR: YOUR SITE COULD NOT BE BUILT:

                    ------------------------------------

                    redcarpet

The command "jekyll build" exited with 1.

Although Googling the error was unhelpful, a bit more digging revealed that our last working build had been on Jekyll 2.5.3 and the builds breaking on a Redcarpet error all used 3.0.0.

The moral of the story is that where the .travis.yml said - gem install jekyll, it should have said - gem install jekyll -v 2.5.3.

http://edunham.net/2015/10/29/psa_pin_versions.html

Choo choo! The trains have kept rolling, and today, we’re happy to announce the release of Rust 1.4, the newest stable release. Rust is a systems programming language focused on safety, speed, and concurrency.

As always, you can install Rust 1.4 from the appropriate page on our website, and check out the detailed release notes for 1.4 on GitHub as well. About 1200 patches were landed in this release.

What’s in 1.4 stable

The story of 1.4 is mostly one of improvements and stabilizations, rather than new features.

However, there is one particular change which is a language fix that enables a new feature: RFC 1214, “Clarify (and improve) rules for projections and well-formedness”. While that’s a deeply technical title, the TL;DR is that we found some weaknesses in the definition and implementation of a few aspects of the type system. This RFC fixes these problems. Given that changes to the type system like this can cause regressions, but fixes like this are important for soundness, Rust 1.4 will warn on any code that violates the new rules, but still compile. These warnings will turn into errors in Rust 1.5. However, given the train model, the community has had time to deal with these changes while 1.4 was in beta, and the small number of crates we were aware of have already been fixed.

These soundness fixes enable the return of the ‘scoped threads’ feature, in which you can create threads that reference data stored on the stack in a safe manner. A few crates have implemented this feature, most notably crossbeam and scoped_threadpool. See their documentation for more information.

RFC 1212 is also in this release, which changes all functions dealing with reading ‘lines’ to treat both \n and \r\n as a valid line-ending. This was determined during the RFC process to be a bugfix, but we’re mentioning it here to raise awareness. The older behavior of only dealing with \n made for surprising behavior, where your crate would work well on Linux and Mac OS X, but fail on Windows. This fix brings these functions more in-line (

http://blog.rust-lang.org/2015/10/29/Rust-1.4.html

This is the meeting where all the Mozilla quality teams meet, swap ideas, exchange notes on what is upcoming, and strategize around community building and...

https://air.mozilla.org/quality-team-qa-public-meeting-20151028/

In case you're not able to attend in person, here you can watch the briefing on what all the volunteers at MozFest will be getting...

https://air.mozilla.org/mozfest-volunteer-briefing-october-28th-2015/

Not sure if I wasn’t paying enough attention, but I entirely missed the “Mozilla Strategy Articulation and 2016 Topline Targets” session from two weeks ago, recorded on Air Mozilla. This was the start of the 2016 planning process, where Chris Beard outlines our mission and 5-year vision. It should be required viewing for everyone interested in where Mozilla is or should be going in 2016, and in the next 5 years. We are planning for 2016 now; your input is welcomed.

http://feedproxy.google.com/~r/HackingForChrist/~3/aaMDbsvUrFs/

The HTTP/1.1 parser used in hyper, hasn’t really seen any API changes since it was designed, and in the spirit of moving “stable” things to 1.0, I bumped that magical number up.

httparse?

If you mainly use hyper (or a framework on top, like iron, nickel, rustless, etc), then this really shouldn’t affect you at all. It’s just the parsing logic for the HTTP/1.1 spec in a standalone crate.

If you work on some other project that requires parsing HTTP1¹, then you may want to try using httparse. Why?

It’s fast.

First, some buzz words. It’s stateless. It’s zero-copy. It performs zero allocations. It’s design piggybacks on the design of picohttpparser, which does the same.

• Stateless: Keeping state means branches. Branches slow down individual parsing attempts. Instead, state of a socket can and should be handled outside of the parser itself. As the socket receives more data, you can try to parse again
• Zero-copy
• Zero allocations

It’s safe.

To be fast, and yet safe, an Iterator is used to prevent unnecessary bounds checks. That implementation is encapsulated in an inner private module, so the safety is easier to audit, and a safe API is exposed from the module, so the main API must use the iterator safely.²

Coming 1.1 and 1.2

There’s two lower hanging fruit that could provide noticeable speed improvements: branch predictions, and SIMD. There’s an accepted Rust RFC for adding a likely intrinsic that gives us branch prediction, but its implementation needs an extra push to get in.

There’s the simd crate, with only 2 things preventing it from speeding up httparse: its using an unstable feature or three, and SSE4 support is needed to get _mm_cmpestri, which would provide the biggest boost.

Or maybe both of these will be available at the same time, and they both can be added in httparse 1.1.

http://seanmonstar.com/post/132094366797

mconley livehacks on real Firefox bugs while thinking aloud.

https://air.mozilla.org/the-joy-of-coding-32/

With my talk decks needing more re-use in the Windows/Microsoft community, I am trying to use Powerpoint more and wean myself off the beauty of Keynote (and its random crashes – yes, all software sucks).

One thing I realised today is that Powerpoint thinks it is sensible to break words anywhere to go to a new line, not by word, or even syllable, but by character:

Words are broken into new lines at any character, which makes alignment a not enjoyable game of “find the breakpoint”

This is the preset! To get rid of it, you don’t need to summon the dark lord, but all you need to do is to unset the default. You can find this in:

Format

https://www.christianheilmann.com/2015/10/28/quick-tip-stop-powerpoint-from-breaking-words-into-a-new-line/

http://danielpocock.com/2015-11-02-free-rtc-workshop-manchester

In this RC release, we disabled async plugin init. Besides this change, we took the usual kind of fixes (crashes, last bug fixes, etc).

• 17 changesets
• 74 files changed
• 284 insertions
• 342 deletions

List of changesets:

http://release.mozilla.org/statistics/42/2015/10/28/fx-42-b9-to-rc.html