Archive for 2008

How to disable the Comodo reseller root certificate in Firefox

Wednesday, December 24th, 2008

Slashdot is a-buzz (and rightly so!) with news that people have been able to obtain an SSL certificate for a domain they don’t own, by applying with one of Comodo’s certificate resellers. It is clear that there has been a major breach of trust, but we’re not sure of the best general solution. There has been a discussion in the mozilla.dev.tech.crypto newsgroup about what steps Mozilla should take for this breach.

In the meantime, I recommend disabling the root certificate used by this certificate authority, to avoid the possibility that other fraudulent certificates are floating around in the wild. Here’s how to disable the relevant CA root in Firefox:

  1. Open the preferences window
  2. Select the “Advanced” tab
  3. Select the “Encryption” sub-tab
  4. Choose “View Certificates”
    Firefox Preferences Window: Advanced -> Encryption -> Certificates

  5. Find and select the “AddTrust AB / AddTrust External CA Root” item
  6. Choose the “Edit’ button
    Root Certificates Dialog

  7. Remove all trust setting check-boxes.
    Edit Certificate Dialog

Note: disabling this root certificate will SSL websites validated by this Comodo reseller to stop working. That’s why you’re doing it, but if it’s your favorite website that stops working, please don’t blame me! If you’re really paranoid, you could also disable all Comodo roots: these include all the certificates with names like “AddTrust”, “Comodo CA Limited”, and “The UserTrust Network”.

Thanks to Eddy Nigg for first providing these instructions.

Using SVG on the Web

Monday, December 22nd, 2008

If you are able to ignore Internet Explorer, all the other major browser can render SVG content. Recently, while writing previous posts and webapps, I discovered several quirks that may cause browsers to fail to render SVG content consistently.

Including SVG inline in the document.

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Using SVG inline in an XHTML document</title>
  </head>
  <body>
    <h1>Using SVG inline in an XHTML document</h1>

    <svg xmlns="http://www.w3.org/2000/svg" width="250" height="250"
         style="border: 1px solid black">
      <circle fill="rgb(250, 160, 20)"
              cx="100" cy="50" r="80" />
      <rect fill="rgb(20, 250, 20)" fill-opacity="0.6"
            x="35" y="85" width="180" height="85" />
    </svg>

  </body>
</html>

View this example in your browser.

Inline SVG is an attractive option because it doesn’t require an external file. Unfortunately, inline SVG has one significant problem: authors are forced to use XHTML and the application/xhtml+xml MIME type, instead of standard HTML and the text/html MIME type. XHTML is not a very forgiving language, and one I would generally discourage. Depending on authoring tools and other content on the page, producing valid XML may be difficult. Even more problematic is that Internet Explorer will refuse to display the page at all; there is no graceful fallback for the majority browser. Finally, syndicating SVG in feeds will often cause the SVG to be stripped as it is syndicated.

I used inline SVG for my Mozilla compiler warnings front end, because I don’t care about Internet Explorer users in that application. But it has very limited usefulness in general.

Referencing external SVG content

At first glance, it might seem that you could reference an SVG document using the HTML &lt:img> element., but this is not the case. SVG images are complete sub-documents. They have their own script context and can script themselves. They can also load additional sub-documents such as images. Because of this, browsers force authors to embed SVG images using <object> or <iframe>.

Embedding SVG with <object>

The <object> element is the generic HTML mechanism for embedding external content. It can be used just like an <iframe> for external HTML document. It can be used to embed plugin-rendered content such as Flash, and it can be used to embed SVG:

<object type="image/svg+xml"
        data="http://benjamin.smedbergs.us/blog/wp-content/uploads/2008/12/svg-document1.svg"
        width="250" height="250">
  Alternate markup here. If you see this, your browser may not support SVG, or a content aggregator may have stripped the object element.
</object>

Alternate markup here. If you see this, your browser may not support SVG, or a content aggregator may have stripped the object element.

The object element is the best choice in most situations. All browsers including Internet Explorer will display the fallback content if they don’t know how to display SVG or if the image won’t load. Using the object element, authors can even pass parameters to the SVG document.

Embedding SVG with <iframe>

It is also possible to include SVG content using the <iframe> element.

<iframe width="350" height="250"
        src="http://benjamin.smedbergs.us/blog/wp-content/uploads/2008/12/svg-document1.svg">
  Alternate markup here. If you see this, your browser might not support iframes, or a content aggregator might have stripped the iframe element.
</iframe>

There are minor but important differences using iframe rather than object to display SVG: Internet explorer will load the iframe but choke on the SVG content. The user won’t skip back to the fallback content within the <iframe>element, and in some cases the user may see a download prompt for the SVG document. But many content sanitizers such as those found in feed aggregators will allow <iframe> through while rejecting <object> And finally, iframes have a border by default. You can remove this border using CSS.

Use this MIME type: image/svg+xml

The correct MIME type for SVG content is image/svg+xml. Firefox will accept application/svg+xml but Safari will not!

Specify image dimensions

The author should know the image dimensions in advance. If you don’t specify the width and height in the <object> or <iframe> element, browsers will initially size the object at 300×150 pixels, and then their behavior will diverge:

<object>

<iframe>

Firefox

Resize to the image intrinsic size, once loaded

Scroll overflow content

Opera

Safari

Crop overflow content

Example

Your browser doesn’t appear to support SVG, or a content aggregator has stripped the <object> tag.


Don’t use rgba() colors in SVG

The CSS3 specification allows for any color to be specified with transparency using rgba syntax. Many web browsers support RGBA colors for HTML content, but only Firefox supports them for SVG content. Instead of using rgba colors, use the SVG properties fill-opacity and stroke-opacity for maximum portability.

<svg xmlns="http://www.w3.org/2000/svg" width="500" height="100">
  <circle fill="rgb(180, 180, 250)"
          cx="100" cy="20" r="85" />

  <text x="10" y="45" font-size="40" fill="rgba(0, 0, 0, 0.3)">rgba transparent text?</text>
  <text x="10" y="95" font-size="40" fill="black" fill-opacity="0.3">use fill-opacity instead!</text>
</svg>

SVG using rgba colors and fill-opacity

More Fun with Compiler Warnings

Friday, December 19th, 2008

My build machine for compiler warnings has been up for a while and reporting “warn-new” to the tinderbox. Since all this data is in a sqlite database, I wanted to present it in a better form than the tinderbox waterfall. So I’ve written up a quick frontend for the data.

Take a tour now!

I really love cherrypy+genshi+sqlite3 for this sort of work. It’s painlessly easy to get a database frontend up without worrying much about SQL or HTML injection.

The front-end graphs the count of unique warnings for each build, lists new warnings and fixed warnings for each build, and allows users to query warnings by directory, committer, and warning message. If you’d like to add additional queries, get the code here and contact me: I’m happy to upload the warning database for other people to experiment on.

As often happens, I’m hosting this on a machine in my home office, so it may disappear at any time. If it seems generally useful, I’ll talk to the Mozilla release team about getting a supported version running on the Mozilla network.

Christmas Candles

Thursday, December 18th, 2008

Candles in a Window

Around Christmastide, it is a common custom to place candles in the windows of houses at nighttime. For many people, this may just be decoration, but it is an meaningful and noble tradition. A house with candles is a beacon in the darkness; a shelter for travelers and the homeless.

This Christmas, if a pregnant teenager and her 35 year old husband came to your door and asked to stay the night and give birth in your house, would you welcome them in?

Nightly testers needed for mozilla-central!

Thursday, December 18th, 2008

Users who installed a build of Minefield before 24 November and have been using automatic update since then may be in for a surprise: you are no longer using Minefield or testing mozilla-central!

Your browser doesn’t appear to support SVG. Go get one that does.

On 24 November, the Firefox code branched: mozilla-central continues as the repository for all new code. After code has been tested in mozilla-central, it is ported to the 1.9.1 repository, a more stable codebase leading to Firefox 3.1.

Right now, we have many more nightly testers on the stable branch (1.9.1) than we do on mozilla-central. But we really want to catch regressions in mozilla-central before they land on the stable branch. If you are a nightly tester, please go download and install a new Minefield build today! (Windows, Mac, Linux).

Update: to figure out whether you’re running mozilla-central or a 1.9.1 branch nightly, just look at the application title: it will say Minefield for mozilla-central, or Shiretoko for 1.9.1. You can also check the About dialog.

Wordmaps without Java

Friday, December 12th, 2008

Word maps generated by wordle.net have been making the rounds. They are very cool representations of the frequency that various words appear in a hunk of text (such as a blog feed). Unfortunately, the code to generate these word maps is not open source, and it requires Java.

So I decided to take on Johnath’s challenge and produce something similar using HTML canvas and JavaScript:

Wordmap of BSBlog

You can take it for a spin too, but only if you have Firefox 3.1. Try it out!. I’m currently using some features that are specific to Firefox 3.1, such as JavaScript 1.8 and Canvas.measureText. I think I can backport this code to support Firefox 3 by checking for .mozMeasureText and .mozTextStyle. I don’t know whether Safari currently supports text drawing or measurement in their canvas implementation. If they do, this can probably be made to work there as well.

If you’re interested in the code, a Mercurial repository is available on hg.mozilla.org. There are a couple improvement possibilities noted in the README file. Some other possibilities that I’m just thinking of now:

  • Produce an image map to make all the terms link to the relevant post(s).
  • Produce SVG output to make the output scalable.

Laying Blame

Tuesday, December 9th, 2008

As I mentioned last week, I’ve been resurrecting a project to report on compiler warnings. A basic form of this buildbot is now operational on the Firefox tinderbox tree (look to the far right for the static-analysis-bsmedberg column). It prints a summary of the total number of warnings on the summary page: in the full tinderbox log, it lists each warning and who can be “blamed” for that warning:

/builds/static-analysis-buildbot/slave/full/build/memory/jemalloc/jemalloc.c:177:1: warning: C++ style comments are not allowed in ISO C90 blamed on Taras Glek  in revision hg:36156fbf817d8a0e2d54a271cf0bff94a1c41c13:memory/jemalloc/jemalloc.c
/builds/static-analysis-buildbot/slave/full/build/js/src/jsdbgapi.cpp:712: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object blamed on brendan@mozilla.org in revision cvs:3.36:js/src/jsdbgapi.c

Assigning blame can be a tricky process. In order to figure out the blame for a warning, the code uses the following steps:

  • Resolve relative paths against the current working directory, using GNU make “Entering/Leaving directory” markers as a guide.
  • Dereference symlinks to find the source tree location of an error. For instance, Mozilla headers which produce warnings often do so via paths in dist/include. We have to resolve these to their original source tree location in order to find blame.
  • Using mercurial APIs (through python), find the mercurial changeset which introduced the line in question.
  • If the code dates back to Mercurial revision 9b2a99adc05e, which is the original import of CVS code to Mercurial, use a database of CVS blame to find the original CVS checking which was responsible for introducing that line of code.

If you’re interested, take a look at the build log parsing code, or see the scripts which save CVS blame to a database (thanks Ted!).

The current reporting system for warnings is very primitive. I’m currently working on a second version of this code which will provide additional features:

  • Compare warnings with the previous build and highlight “new” warnings. I do this by recording the error text and the blamed location of the warning. As lines are added and removed from the code, the reported location of the warning changes, but the location of Hg/CVS blame doesn’t. This means it is a stable location which can be used for comparisons across runs. It even works across file renames/moves!
  • Web frontend to the warning database to allow users to query warnings by user or directory.
  • Classify warnings by “type”. This is not a simple process, because GCC mixes distinctive error text, such as “may be used uninitialized in this function” with variable names; and the granularity of -fdiagnostic-show-option is low enough that it’s not very useful by itself. Oh, I wish GCC had error codes like MSVC does: C1234 is easy to recognize!

At one point, I thought I could implement all of the warning mechanism on the buildbot server by parsing the BuildStep logs. It quickly became clear that I couldn’t do that, because I couldn’t resolve symlinks, and getting Mercurial blame was difficult or impossible. My new version actually uses a hybrid mechanism where the build log is parsed on the buildbot slave: this parses out warnings, resolves symlinks, and looks up blame. It then sends the results back via stdout to the master. A custom build step on the master parses this log, saves the information to a database, and does the checking for new warnings and prints various results to custom build logs.

Parsing Compiler Errors

Wednesday, December 3rd, 2008

Long ago, Mozilla had a tinderbox which would collate every warning produced by the Mozilla build and generate statistics and reports about them. I’m trying to re-create this tool.

When building Mozilla or most other large software projects that use GNU make, compiler warnings get sent to stdout (and sometimes stderr). The messages usually look something like this:

../../../dist/include/dom/nsIDOMXULSelectCntrlEl.h:33: warning: ‘virtual nsresult nsIDOMXULSelectControlElement::GetSelectedItem(nsIDOMXULSelectControlItemElement**)’ was hidden
../../../dist/include/dom/nsIDOMXULMultSelectCntrlEl.h:73: warning:   by ‘virtual nsresult nsIDOMXULMultiSelectControlElement::GetSelectedItem(PRInt32, nsIDOMXULSelectControlItemElement**)’

All of the file paths in the warning (or set of warnings in this case) are relative to the current working directory. Because the working directory changes during the build as make recurses through subdirectories, automatic parsers need some way to know what the working directory is at any point in the build log. Make provides the -w option which will print the following output every time it recurses into or leaves a directory:

make[1]: Entering directory ‘/builds/static-analysis-buildbot/slave/full/build’
make[1]: Leaving directory ‘/builds/static-analysis-buildbot/slave/full/build’

This is fine if you are only building in one directory at a time. But with the -j option, it is likely that make will be building in multiple directories at once. This will interleave output from multiple jobs in the same log, making it difficult for an automated parser to make any sense of them.

What I’d like is a tool or technique which will save the build log for each makefile command separately and combine them all at the end of a build.

Pre-emptive snarky comment: “switch Mozilla to use {scons,waf,cmake,ant,…}”

Woman accused of stealing mice

Wednesday, November 26th, 2008

Seen in today’s local paper:

A Johnstown woman was jailed after authorities said she tried to steal several small animals from a local pet store.

City police said Jennifer Lauren Jury, 42, of Broad Street, entered Animal Jack’s Pet Shop on Fifth Street on Monday and made her way to the second floor.

As Jury came downstairs and tried to leave the store, an employee noticed three hamsters and two mice in her purse.

“I could see them crawling out of her purse,” the employee said.

When the employee confronted her, Jury took the animals out of her purse and left the store, police said.

Jury was found at her residence, where police said she admitted she had been arrested for retail theft twice before.

Jury was charged with retail theft and arraigned by District Judge Michael Musulin of Johstown. She was sent to the Cambria County Prison after failing to post $5,000 bond.

The hamsters and mice were valued at $4, police said.

The story prompts numerous thoughts:

  • Why was she held on $5,000 bond for a $4 stealing misdemeanor?
  • Why did the paper bother writing this up at all, especially as a real news story?
  • Why are there so many one-sentence paragraphs? It’s really distracting!
  • If you want to steal small animals from a pet store, make sure you zip your purse.

Generated Documentation, part 2

Wednesday, November 26th, 2008

As I noted previously, I’ve been using our static analysis tools to generate documentation for the Mozilla string classes.

All of the code to generate this documentation is now checked in to mozilla-central. To regenerate documentation or hack the scripts, you will first need to build with static-checking enabled. Then, simply run the following command:

make -C xpcom/analysis classapi

To automatically upload the documentation to the Mozilla Developer Center, run the following command:

MDC_USER="Your Username" MDC_PASSWORD="YourPassword" make -C xpcom/analysis upload_classapi

One of the really exciting things about the Dehydra static-analysis project is that the analysis is not baked into any compiler. You can version your analysis scripts as part of your source code, run them from within your build system, and change them as your analysis needs change.

For example, I decided that a class inheritance diagram would help people understand the Mozilla string classes. So I modified the documentation script to produce graphviz output in addition to the standard XML markup. I then process the graphviz output to PNG with an imagemap and upload it to MDC along with the other output as an attachment1.

The output is available now. I’m still looking for volunteers to improve the output as well as the source comments to make it all clearer!

1. There is a MediaWiki extension so you can put graphviz markup directly in a wiki page and it will be transformed automatically. However, this extension currently doesn’t work on the Mozilla Developer Center. It’s being tracked in bug 463464 if you’re interested. ^