Mozilla Nederland LogoDe Nederlandse

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 8 uur 50 min geleden

David Lawrence: Happy BMO Push Day!

wo, 18/11/2015 - 05:04

the following changes have been pushed to

  • [1221998] Make sure localconfig is generated deterministically
  • [1219767] Explicitly load extensions at Bugzilla->login
  • [1221423] unable to impersonate users when 2fa is enabled
  • [1181637] Update Req Opening Process (Cost Center list on 2015-07-08)
  • [1223495] String handling bug in form.creative on BMO
  • [1223669] don’t scroll to the top of the page when clicking on the resolution buttons
  • [1209625] MozReview API Keys should use a more specific error message
  • [1223590] Unable to login to bugzilla via login to github (fresh bugzilla account)
  • [1224620] Update VP list in Recruiting Product
  • [1187429] Remove the WebOps Request Form
  • [1225249] module subtitles should be the same size as other text on the page (13px)

discuss these changes on

Categorieën: Mozilla-nl planet

Chris H-C: Single-API Firefox Telemetry Plots: telemetry-wrapper.js

wo, 18/11/2015 - 01:14

Say you’ve read my earlier post on Firefox Telemetry and want to make your own plots like does. Well, like almost everything Mozilla does, that website is open source, so we can just copy what it does… except it’s a little convoluted. It needs to support a range of requirements and configurations, after all.

But your needs are just yours, so wouldn’t it be nice if there were something a little more direct?

Enter telemetry-wrapper.js. Simply include it and its dependencies in your HTML and then call it like so:

TelemetryWrapper.go(params, element);

Then ‘element’ will suddenly (after a few seconds to collate and render the data) contain one or more plots corresponding to ‘params’.

Want to see GC_MS compared by e10sEnabled setting on Nightly 44?

TelemetryWrapper.go({   channel: "nightly",   version: "44",   metric: "GC_MS",   compare: "e10sEnabled", }, document.body);

(e10s is looking like a win on this metric, though part of the sample population self-selected so we can’t be sure. Await blog posts from other quarters on A/B tests we’re conducting.)

How about the top three plugins activated in Firefox 42?

TelemetryWrapper.go({ channel: "release", version: "42", metric: "PLUGIN_ACTIVATION_COUNT", keyLimit: 3, }, document.body);

(no one is surprised that the top one is Flash and that most people only use it the once. But googletalk has an odd shape to it, being activated exactly twice by clients more often than any other frequency…)

The technical details are in the README. Use and reuse it to ask and answer questions about Firefox Telemetry data!


Categorieën: Mozilla-nl planet

Air Mozilla: Sam Piggott – The Dojo Story - Swift LDN - 20151116

di, 17/11/2015 - 11:53

Sam Piggott – The Dojo Story - Swift LDN - 20151116 Sam Piggot presents his experience in releasing The Dojo app on a tight schedule. This talk has been given as part of the Swift LDN...

Categorieën: Mozilla-nl planet

Air Mozilla: Radek Pietruszewski – Statically-typed Swifty APIs - Swift LDN - 2015116

di, 17/11/2015 - 11:52

Radek Pietruszewski – Statically-typed Swifty APIs - Swift LDN - 2015116 Radek described his experience and process to build a statically type API in Swift. This talk has been given as part of the Swift LDN...

Categorieën: Mozilla-nl planet

Air Mozilla: Emily Toop – WKWebView made me do it! – Swift LDN – 20151116

di, 17/11/2015 - 11:46

Emily Toop – WKWebView made me do it! – Swift LDN – 20151116 Emily Toop speaks about the hacks and tricks the Fennec iOS team went through to produce Firefox for iOS using WKWebView. This talk has been...

Categorieën: Mozilla-nl planet

Christian Heilmann: Meetup in London: why is Windows not your platform of choice

di, 17/11/2015 - 11:16

This Thursday, my colleague Mike Harsh and Keith Rowe (@krow) from Microsoft’s Windows and Devices Group invite you to the Square Pig in London for some drinks and a chat. These two program managers are leading efforts to make Windows-based machines a better place for web development.

I’ve put up a small web site with the info of the meetup and there’s also a Lanyrd page. Many thanks also to London Webstandards for banging the drum.

Whilst I am not affiliated with this group and I can’t be there as I am on my way to JSConf Asia to present, I’d love to see a lot of people go and talk to them. This is a genuine offer to improve what Windows has for web developers and I already gave them quite a bit of feedback on the matter (I am a Mac user…).

I’ve been worried about our Mac fixation as web developers for a while. We preach about supporting all platforms as “it is the web” but a lot of our tooling and best practices are very Mac/Command Line centric.

I know this is a bit last minute, but as it is with London Pubs, you have to spring a grand to get the room for the evening, so please show up and at least make sure this expense ends in the form of food and drinks inside people who Microsoft can learn from.

Categorieën: Mozilla-nl planet

Emily Dunham: Installing Rust without root

di, 17/11/2015 - 09:00
Installing Rust without root

I just got a good question from a friend on IRC: “Should I ask my university’s administration to install Rust on our shared servers?” The answer is “you don’t have to”.

Pick one of the two following sets of directions. I’d recommend using Multirust, because it automatically checks the packages it downloads and lets you switch between Rust versions trivially.


Categorieën: Mozilla-nl planet

Andy McKay: A year in cycling

di, 17/11/2015 - 09:00

When I started cycling into the office this year, I said I would probably end in November or December when it got too cold and wet.

Last night was really, cold, windy and I had so many near misses with cars, pedestrians and signs. The worst part was as usual the Second Narrows bridge which was really, really windy. A bus hit a puddle on the bridge and the wall of water went over the barricade and hit me. Coming off the bridge the ramp is covered in wet slippy composting leaves and when you are trying to avoid that unlit pedestrian, in the dark on skinny road tires with frozen fingers in driving rain....

So I'm done.

I cycled for about 9 months of the year from Deep Cove to the office for several days a week. Not too shabby. The real difference this year was training for the Fondo, which meant that in the summer when I cycled five days a week to the office, that's 170 km a week, I wasn't that tired but wanted to do more and started detouring over the Lions Gate bridge. I hit over 300km one week.

According to Strava I cycled 3,842km over 1712h this year. That's not too shabby. Next year I'm aiming for two Fondo's. But for now its time to go to the gym more and do more curling and snowboarding.

Categorieën: Mozilla-nl planet

Nick Cameron: concat_idents! and macros in ident position

di, 17/11/2015 - 03:14

In the next few blog posts I want to cover some areas for improvement for Rust macros. I'll drill down into one topic at a time. I'll propose solutions, but not in RFC-levels of detail. I hope to get lots of early feedback this way, rather than doing all the design myself and having a 'big-bang' RFC. A lot of the macro issues are inter-related, so some of the details in early areas won't get fleshed out until later.

I'm going to start with concatenating idents in macros and using macros as idents. This is a fairly small thing, but is an irritating thing for many macro authors. The problem space has been expored already, see the references section at the end for links to issues and a previous RFC.


It is often desired to merge two (or more) identifiers to make a new one in a macro. For example, a macro might take an identifier and create two functions - e.g., foo and foo_mut from foo. This is related to the issue of creating new identifiers in macros.

Currently we support this by using the concat_idents macro. There are two main problems with it - it is not very smart with hygiene, and it is not very useful since macros can't be used in ident position; so although it can synthesis idents, these can only be used as expressions. E.g., although we could access variables called foo and foo_mut given foo, we can't generate functions with these names or even call functions with those names.

The hygiene issue is that concat_idents creates a fresh ident. Essentially, the ident is only in the scope of the macro which created it. Generally, you want to inherit the hygiene context from one of the source idents.

Proposed solution
  • deprecate concat_idents! - without proper hygiene support, it is not suitable for stable use,

  • allow macros in ident position (see below for details),

  • provide libraries for manipulating hygiene contexts in procedural macros (see later blog posts),

  • provide a library of procedural macros which can concatenate identifiers with various different kinds of hygiene results (see below for details).

Macros in ident position

The concept is pretty simple - anywhere we accept an identifier in current Rust, we would accept a macro. This includes (but is not limited to): variable declarations, paths, field expressions, method and function calls, item names (functions, structs, etc.), field names, type names, type variables (declaration and use), and so forth. I propose that this facility is only available for 'new' macros, partly for technical reasons (see below, hygiene and types) and partly as a carrot to move people to the new macro system.

Examples, if foo is a macro:!() (field access),!(bar)() (method call), fn foo!(baz)(x: T) { ... } (function declaration).

If a macro occurs in expression or pattern position, then there is the question of whether it should be parsed as a macro in expression position or a macro in ident position as a path which is an expression (similarly with patterns). I think we can always choose the least specific option (i.e., expression rather than ident position) because we parse the macro body after expansion, so if it is an ident, the parser will wrap it to make an expression (if we assumed it was an ident, but it was a non-ident expression, we would be stuck). This only works for procedural macros if their output is tokens rather than AST (see later blog posts).

I believe parsing should not be too affected - after parsing an ident, we simply need to check for an !. Any AST node that contains an Ident must instead contain a new enum which can either be an Ident or a macro in ident position.

I don't believe there are issues with expansion or hygiene, expansion should work the same as for macros in other position and hygiene should "just work". One might imagine that since idents are the target of the hygiene algorithm, that creating new ones with macros would be difficult. But I don't think this is the case - the macro must expand to an ident only (or further macros that expand to an ident), and the hygiene context for that ident will be due to the macro which creates it and the expansion itself (see note on sets of scopes algorithm below). We might need to adjust the hygiene context of the ident in the macro where it is created, but that is a separate issue, see below. Note that in nearly all cases, users of a macro that produce an ident will need to pass some context to the macro to make the produced ident accessible.

There are some undecided questions where macros supply idents in items, types, and other places where we don't currently support hygiene. I propose to only support macros in ident position with new macros, which should be hygienic where current macros are not. This should make things easier. Exactly how macros in ident position interact with item hygiene is an open question until we nail down exactly how item hygiene should work.

Note: sets of scopes

I have been thinking of changing our hygiene algorithm to the sets of scopes algorithm. I won't go into the details here, but I think it will help with a lot of issues. It should mostly be simpler than the mtwt algorithm, but one area where it will add complexity is with use-site scopes. These are added to the sets of scopes in order to handle recursive macros, but when a macro contributes to a new binding (I believe this will mean macros in pattern position and macros in ident position where the ident introduces a binding), then we must be careful not to add use-site scopes. This point needs more consideration, but I think it will be OK - we just have to be careful about these scopes.

Drawbacks and alternatives

I think macros in ident position look ugly - having double sets of parentheses (in function calls) or parentheses where there wouldn't normally be is confusing to read. It also makes code harder to read in general, since names are an essential way we link parts of code together. Having names be macro generated makes code harder to make sense of. It's also confusing for tools.

One alternative would be to only allow macros in ident position inside macro definitions - this should address most use cases, without making general Rust code harder to read (macros are already harder to read, so there is less of an impact). I think I favour this alternative, although I am very keen to get others' opinions on it.

Another alternative would be to come up with some new syntax especially for use in ident position - this might be less ugly and give more of a hint of the generated name. However, since we must be able to pass arguments to macros, I'm not optimistic that this is possible. Furthermore, it is more syntax and thus a bigger language which is confusing in its own way.

Library macros for concatenation

This section will be a bit hand-wavey for now, we need to decide on the fundamental APIs for allowing procedural macros to interact with the hygiene system before we can settle the details.

I expect we want a fundamental create_ident! macro (or create_ident function) which takes a string name and a syntax context (probably some token which carries it's hygiene information, more on exactly how this works later). E.g., create_ident!(foo, "bar") would create an ident with the name bar and a hygiene context taken from foo.

We would also have fresh_ident! which would create an ident from a string name with a fresh hygiene context (similar to gensym'ing) and new_ident! which does the same thing but with an empty hygiene context (i.e., it gets only the context due to the expansion of the macro where it is created). The difference between the two being that two idents created with fresh_ident! would have different contexts, but two created with empty_ident! would have the same contexts.

We then provide convenience macros which take a list of idents and/or an ident (for its hygiene context) and a list of things which produce strings, and produce a new ident with either hygiene contexts taken from the first ident, or a seperately specified object, or a fresh context. Obviously, we need to make this a bit more concrete.

Example struct Foo { a: A, b: B, } macro! def_getters { ($f: ident, $t: ident) => { fn concat_idents_with!($f, "get_", $f)(&self) -> &$t { &self.$f } fn concat_idents_with!($f, "get_", $f, "_mut")(&mut self) -> &mut $t { &mut self.$f } } } impl Foo { def_getters!(a, A); def_getters!(b, B); } fn main() { let f = Foo { ... }; println!("{}", f.create_ident!(f, "get_a")()); }

Where concat_idents_with!($f, "get_", $f, "_mut") expands to an ident with name get_$f_mut and hygiene context taken from $f. Note that in this case concat_idents_with! is used in a binding context, so the hygiene context (under a set of scopes model) should not include a use-site scope.

The use of create_ident in main is a bit silly, it's just for demonstration purposes: f.create_ident!(f, "get_a")() has exactly the same meaning as writing f.get_a().


concat_idents tracking issue

macros in ident position issue

macros in ident position RFC

Categorieën: Mozilla-nl planet

Pascal Chevrel: Follow-up to my current migration to Atom Editor

di, 17/11/2015 - 01:19

After my recent blog post announcing that I was transisionning from Sublime Text to Atom, I got a couple of nice surprises from the community that fix some of the annoyances I have with Atom or that will just make it better.

How to fix the keyboard shortcut to comment out a single line on a French keyboard

Just click on the  'Edit/Open your Keymap' menu item and put that line at the bottom:

'.platform-linux atom-text-editor': 'ctrl-:': 'editor:toggle-line-comments'

That will make the shortcut work along with the keyboard localization package installed for French (and Belgian French too). If you are on Windows, use the selector .platform-win32 (I don't know what the MacOS one is).

How to have a basic project mode like in Sublime text and be able to switch projects

Install the Project Manager package (thanks to Giorgio Maone, mozilla Add-on dev for the tip), it's roughly equivalent in functionnality to Sublime's built-in project manager and it seems good enough to me. One caveat is that switching from one project to another is a bit slow.

Support for .lang Mozilla syntax files in Atom

This is a nice gift from my colleague Francesco Lodolo, he made a syntax highlighter for the DotLang localization text format we use for and other sites for which we need fast translations for, this will be useful to me but also to Mozilla localizers that could want to use Atom to edit their translations, here is the package:

DotLang language support in Atom

And a screenshot to give you an idea of the end result.

langAtom.png  New Version of Atom 1.2 stable and 1.3beta released

This is always nice to have, I like new stuff :) Here is their blog post about it: Atom 1.2

Codeintel equivalent in Atom for PHP ?

There is a series of packages called php-integrator-* (base, autocomplete plus, tooltips, annotations...) that are supposedly providing the equivalent services as Codeintel  but after indexing a single project for an hour (bringing my computer to its knees), I couldn't make it work. On a couple of occasions I saw a nice tooltip for a method indexed, but I don't know how I triggered it and I don't get any autocompletion of classes while typing. I guess it's still pretty much alpha stuff  but hopefully that will work some day. Also I suspect it tried to index all of my dependencies in the vendor directory… I only need my own code to be indexed, not the external dependencies or a whole framework. The good news I guess is that something is developped and I might get that feature one day.

Atoum integration in Atom ?

Another nice surprise from the community, looks like Julien Bianchi, one of Atoum developers is working on a package to get Atoum in Atom following my request on Twitter:



Many many thanks to him, I am always amazed at how nice the people in the Atoum project are with their users :)

UPDATE: here is the Atoum plugin and a video demoing it

Conclusion of the day

My transition is going well and progressing quickly, today I coded exclusively in Atom, I found some small bugs and needed to get my marks in the new environment  but it's not a revolution compared to Sublime and so far I felt rather productive. Most of the problems I have really are in the realm of polishing and finding where an option is set up or what a new shortcut is, that said, the experience is satisfying and I probably didn't get today more headaches than I had when I switched from Geany to Sublime a couple of years ago. So far, so good :)


Categorieën: Mozilla-nl planet

Nick Thomas: The latest on firefox/releases/latest

di, 17/11/2015 - 00:37

The primary way to download Firefox is at, but Mozilla’s Release Engineering team has also maintained directories like

to provide a stable location for scripted downloads. There are similar links for betas and extended support releases for organisations. Read on to learn how these directories have changed, and how you can continue to download the latest releases.

Until recently these directories were implemented using a symlink to the current version, for example firefox/releases/42.0/. The storage backend has now changed to Amazon S3 and this is no longer possible. To implement the same functionality we’d need a duplicate set of keys, which incurs more maintenance overhead. And we already have a mechanism for delivering files independent of the current shipped version – our download redirector Bouncer. For example, here’s the latest release for Windows 32bit, U.S. English:

Modifying the product, os, and/or lang allow other combinations. This is described in the README.txt files for beta, release, and esr, as well as the Thunderbird equivalents release and beta.

Please adapt your scripts to use links. We hope it will help you simplify at the same time, as scraping to determine the current version is no longer necessary.

PS. We’ve also removed some latest- directories which were old and crufty, eg firefox/releases/latest-3.6.

Categorieën: Mozilla-nl planet

The Servo Blog: This Week In Servo 42

ma, 16/11/2015 - 21:30

In the last week, we landed 106 PRs in the Servo organization’s repositories.

We have a new homepage,! Many thanks to nerith and lucywyman!

Prabhjyot Sodhi did some initial analysis of Servo’s E-Easy bugs to show how long it is before they are closed - for a large subset of them, it was within 24 hours!

Notable additions
  • SimonSapin added a ./mach run --android to help ease the new Android developer experience
  • rillian fixed our placeholder image
  • larsberg fixed the Gonk intermittent failures - still lots more intermittents to go, sadly!
  • ajeffrey made DOMString opaque, enabling future optimization and representation tricks
  • Manishearth enabled delegation, which allows reviewers to let contributors review-carry their PRs without having to wait for a reviewer
  • paul added the mozbrowsericonchangeevent API
  • nox made JS-managed objects weakref-able
  • David Raifaizen limited the image formats that Servo will accept
  • Michael Howell fixed a layout regression affecting sites declaring viewports
  • Greg Guthe implemented a subset of the NetworkTiming DOM API.
  • waffles made network requests cancellable.
  • Emilio Cobos Álvarez implemented WebIDL sequence type return values.
New Contributors Meetings

At last week’s meeting, we discussed our GitHub subproject handling, the new webpage, multi-repo workflows, and the revival of our Rust-tracking-bug.

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 16 Nov 2015

ma, 16/11/2015 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Daniel Pocock: Quick start using Blender for video editing

ma, 16/11/2015 - 19:53

Updated 2015-11-16 for WebM

Although it is mostly known for animation, Blender includes a non-linear video editing system that is available in all the current stable versions of Debian, Ubuntu and Fedora.

Here are some screenshots showing how to start editing a video of a talk from a conference.

In this case, there are two input files:

  • A video file from a DSLR camera, including an audio stream from a microphone on the camera
  • A separate audio file with sound captured by a lapel microphone attached to the speaker's smartphone. This is a much better quality sound and we would like this to replace the sound included in the video file.
Open Blender and choose the video editing mode

Launch Blender and choose the video sequence editor from the pull down menu at the top of the window:

Now you should see all the video sequence editor controls:

Setup the properties for your project

Click the context menu under the strip editor panel and change the panel to a Properties panel:

The video file we are playing with is 720p, so it seems reasonable to use 720p for the output too. Change that here:

The input file is 25fps so we need to use exactly the same frame rate for the output, otherwise you will either observe the video going at the wrong speed or there will be a conversion that is CPU intensive and degrades the quality. Also check that the resolution_percentage setting under the picture dimensions is 100%:

Now specify output to PNG files. Later we will combine them into a WebM file with a script. Specify the directory where the files will be placed and use the # placeholder to specify the number of digits to use to embed the frame number in the filename:

Now your basic rendering properties are set. When you want to generate the output file, come back to this panel and use the Animation button at the top.

Editing the video

Use the context menu to change the properties panel back to the strip view panel:

Add the video file:

and then right click the video strip (the lower strip) to highlight it and then add a transform strip:

Audio waveform

Right click the audio strip to highlight it and then go to the properties on the right hand side and click to show the waveform:

Rendering length

By default, Blender assumes you want to render 250 frames of output. Looking in the properties to the right of the audio or video strip you can see the actual number of frames. Put that value in the box at the bottom of the window where it says 250:

Enable AV-sync

Also at the bottom of the window is a control to enable AV-sync. If your audio and video are not in sync when you preview, you need to set this AV-sync option and also make sure you set the frame rate correctly in the properties:

Add the other sound strip

Now add the other sound file that was recorded using the lapel microphone:

Enable the waveform display for that sound strip too, this will allow you to align the sound strips precisely:

You will need to listen to the strips to make an estimate of the time difference. Use this estimate to set the "start frame" in the properties for your audio strip, it will be a negative value if the audio strip starts before the video. You can then zoom the strip panel to show about 3 to 5 seconds of sound and try to align the peaks. An easy way to do this is to look for applause at the end of the audio strips, the applause generates a large peak that is easily visible.

Once you have synced the audio, you can play the track and you should not be able to hear any echo. You can then silence the audio track from the camera by right clicking it, look in the properties to the right and change volume to 0.

Make any transforms you require

For example, to zoom in on the speaker, right click the transform strip (3rd from the bottom) and then in the panel on the right, click to enable "Uniform Scale" and then set the scale factor as required:

Render the video output to PNG

Click the context menu under the Curves panel and choose Properties again.

Click the Animation button to generate a sequence of PNG files for each frame.

Render the audio output

On the Properties panel, click the Audio button near the top. Choose a filename for the generated audio file.

Look on the bottom left-hand side of the window for the audio file settings, change it to the ogg container and Vorbis codec:

Ensure the filename has a .ogg extension

Now look at the top right-hand corner of the window for the Mixdown button. Click it and wait for Blender to generate the audio file.

Combine the PNG files and audio file into a WebM video file

You will need to have a few command line tools installed for manipulating the files from scripts. Install them using the package manager, for example, on a Debian or Ubuntu system:

# apt-get install mjpegtools vpx-tools mkvtoolnix

Now create a script like the following:

#!/bin/bash -e # Set this to match the project properties FRAME_RATE=25 # Set this to the rate you desire: TARGET_BITRATE=1000 WORK_DIR=${HOME}/video1 PNG_DIR=${WORK_DIR}/frames YUV_FILE=${WORK_DIR}/video.yuv WEBM_FILE=${WORK_DIR}/video.webm AUDIO_FILE=${WORK_DIR}/audio-mixed.ogg NUM_FRAMES=`find ${PNG_DIR} -type f | wc -l` png2yuv -I p -f $FRAME_RATE -b 1 -n $NUM_FRAMES \ -j ${PNG_DIR}/%08d.png > ${YUV_FILE} vpxenc --good --cpu-used=0 --auto-alt-ref=1 \ --lag-in-frames=16 --end-usage=vbr --passes=2 \ --threads=2 --target-bitrate=${TARGET_BITRATE} \ -o ${WEBM_FILE}-noaudio ${YUV_FILE} rm ${YUV_FILE} mkvmerge -o ${WEBM_FILE} -w ${WEBM_FILE}-noaudio ${AUDIO_FILE} rm ${WEBM_FILE}-noaudio Next steps

There are plenty of more comprehensive tutorials, including some videos on Youtube, explaining how to do more advanced things like fading in and out or zooming and panning dynamically at different points in the video.

If the lighting is not good (faces too dark, for example), you can right click the video strip, go to the properties panel on the right hand side and click Modifiers, Add Strip Modifier and then select "Color Balance". Use the Lift, Gamma and Gain sliders to adjust the shadows, midtones and highlights respectively.

Categorieën: Mozilla-nl planet

Tim Taubert: More Privacy, Less Latency - Improved Handshakes in TLS Version 1.3

ma, 16/11/2015 - 18:00

Up to this writing, TLS v1.3 (draft-11) has not been finalized and the proposals presented here might change. I will do my best to update this post timely.

TLS must be fast. Adoption will greatly benefit from speeding up the initial handshake that authenticates and secures the connection. You want to get the protocol out of the way and start delivering data to visitors as soon as possible. This is crucial if we want the web to succeed at deprecating non-secure HTTP.

Let’s start by looking at full handshakes as standardized in TLS v1.2, and then continue to abbreviated handshakes that decrease connection times for resumed sessions. Once we understand the current protocol we can proceed to proposals made in the latest TLS v1.3 draft to achieve full 1-RTT and even 0-RTT handshakes.

It helps if you already have a rough idea of how TLS and Diffie-Hellman work as I can’t go into every detail. The focus of this post is on comparing current and future handshakes and I might omit a few technicalities to get basic ideas across more easily.

Full TLS 1.2 Handshake (static RSA)

Static RSA is a straightforward key exchange method, available since SSLv2. After sharing basic protocol information via the ClientHello and ServerHello messages the server sends its certificate to the client. ServerHelloDone signals that for now there will be no further messages until the client responds.

The client then encrypts the so-called premaster secret with the server’s public key found in the certificate and wraps it in a ClientKeyExchange message. ChangeCipherSpec signals that from now on messages will be encrypted. Finished, the first message to be encrypted and the client’s last message of the handshake, contains a MAC of all handshake messages exchanged thus far to prove that both parties saw the same messages, without interference from a MITM.

The server decrypts the premaster secret found in the ClientKeyExchange message using its certificate’s private key, and derives the master secret and communication keys. It then too signals a switch to encrypted communication and completes the handshake. It takes two round-trips to establish a connection.

Authentication: With static RSA key exchanges, the connection is authenticated by encrypting the premaster secret with the server certificate’s public key. Only the server in possession of the private key can decrypt, correctly derive the master secret, and send an encrypted Finished message with the right MAC.

The simplicity of static RSA has a serious drawback: it does not offer forward secrecy. If a passive adversary records all traffic to a server then every recorded TLS session can be broken later by obtaining the certificate’s private key.

This key exchange method will be removed in TLS v1.3.

Full TLS 1.2 Handshake (ephemeral DH)

A full handshake using (Elliptic Curve) Diffie-Hellman to exchange ephemeral keys is very similar to the flow of static RSA. The main difference is that after sending the certificate the server will also send a ServerKeyExchange message. This message contains either the parameters of a DH group or of an elliptic curve, paired with an ephemeral public key computed by the server.

The client too computes an ephemeral public key compatible with the given parameters and sends it to the server. Knowing their private keys and the other party’s public key both sides should now share the same premaster secret and can derive a shared master secret.

Authentication: With (EC)DH key exchanges it’s still the certificate that must be signed by a CA listed in the client’s trust store. To authenticate the connection the server will sign the parameters contained in ServerKeyExchange with the certificate’s private key. The client verifies the signature with the certificate’s public key and only then proceeds with the handshake.

Abbreviated Handshakes in TLS 1.2

Since SSLv2 clients have been able to use session identifiers as a way to resume previously established TLS/SSL sessions. Session resumption is important because a full handshake can take time: it has a high latency as it needs two round-trips and might involve expensive computation to exchange keys, or sign and verify certificates.

Session IDs, assigned by the server, are unique identifiers under which both parties store the master secret and other details of the connection they established. The client may include this ID in the ClientHello message of the next handshake to short-circuit the negotiation and reuse previous connection parameters.

If the server is willing and able to resume the session it responds with a ServerHello message including the Session ID given by the client. This handshake is effectively 1-RTT as the client can send application data immediately after the Finished message.

Sites with lots of visitors will have to manage and secure big session caches, or risk pushing out saved sessions too quickly. A setup involving multiple load-balanced servers will need to securely synchronize session caches across machines. The forward secrecy of a connection is bounded by how long session information is retained on servers.

Session tickets, created by the server and stored by the client, are blobs containing all necessary information about a connection, encrypted by a key only known to the server. If the client presents this tickets with the ClientHello message, and proves that it knows the master secret stored in the ticket, the session will be resumed.

A server willing and able to decrypt the given ticket responds with a ServerHello message including an empty SessionTicket extension, otherwise the extension would be omitted completely. As with session IDs, the client will start sending application data immediately after the Finished message to achieve 1-RTT.

To not affect the forward secrecy provided by (EC)DHE suites session ticket keys should be rotated periodically, otherwise stealing the ticket key would allow recovering recorded sessions later. In a setup with multiple load-balanced servers the main challenge here is to securely generate, rotate, and synchronize keys across machines.

Authentication: Both session resumption mechanisms retain the client’s and server’s authentication states as established in the session’s initial handshake. Neither the server nor the client have to send and verify certificates a second time, and thus can reduce connection times significantly, especially when dealing with RSA certificates.

Full Handshakes in TLS 1.3

The first good news about handshakes in TLS v1.3 is that static RSA key exchanges are no longer supported. Great! That means we can start with full handshakes using forward-secure Diffie-Hellman.

Another important change is the removal of the ChangeCipherSpec protocol (yes, it’s actually a protocol, not a message). With TLS v1.3 every message sent after ServerHello is encrypted with the so-called ephemeral secret to lock out passive adversaries very early in the game. EncryptedExtensions carries Hello extension data that must be encrypted because it’s not needed to set up secure communication.

The probably most important change with regard to 1-RTT is the removal of the ServerKeyExchange and ClientKeyExchange messages. The DH parameters and public keys are now sent in special KeyShare extensions, a new type of extension to be included in the ServerHello and ClientHello messages. Moving this data into Hello extensions keeps the handshake compatible with TLS v1.2 as it doesn’t change the order of messages.

The client sends a list of KeyShare values, a value consisting of a named (EC)DH group and an ephemeral public key. If the server accepts it must respond with one of the proposed groups and its own public key. If the server does not support any of the given key shares the client may try again with a different configuration or abort.

Authentication: The Diffie-Hellman parameters itself aren’t signed anymore, authentication will be a tad more explicit in TLS v1.3. The server sends a CertificateVerify message that contains a hash of all handshake message exchanged so far, signed with the certificate’s private key. The client then simply verifies the signature with the certificate’s public key.

Session Resumption in TLS 1.3 (PSK)

Session resumption via identifiers and tickets is obsolete in TLS v1.3. Both methods are replaced by a pre-shared key (PSK) mode. A PSK is established on a previous connection after the handshake is completed, and can then be presented by the client on the next visit.

The client sends one or more PSK identities as opaque blobs of data. They can be database lookup keys (similar to Session IDs), or self-encrypted and self-authenticated values (similar to Session Tickets). If the server accepts one of the given PSK identities it replies with the one it selected. The KeyShare extension is sent to allow servers to ignore PSKs and fall back to a full handshake.

Forward secrecy can be maintained by limiting the lifetime of PSK identities sensibly. Clients and servers may also choose an (EC)DHE cipher suite for PSK handshakes to provide forward secrecy for every connection, not just the whole session.

Authentication: As in TLS v1.2, the client’s and server’s authentication states are retained and both parties don’t need to exchange and verify certificates again. A regular PSK handshake initiating a new session, instead of resuming, omits certificates completely.

Session resumption still allows significantly faster handshakes when using RSA certificates and can prevent user-facing client authentication dialogs on subsequent connections. However, the fact that it requires a single round-trip just like a full handshake might make it less appealing, especially if you have an ECDSA or EdDSA certificate and do not require client authentication.

Zero-RTT Handshakes in TLS 1.3

The latest draft of the specification contains a proposal to let clients encrypt application data and include it in their first flights. On a previous connection, after the handshake completes, the server would send a ServerConfiguration message that the client can use for 0-RTT handshakes on subsequent connections. The configuration includes a configuration identifier, the server’s semi-static (EC)DH parameters, an expiration date, and other details.

With the very first TLS record the client sends its ClientHello and, changing the order of messages, directly appends application data (e.g. GET / HTTP/1.1). Everything after the ClientHello will be encrypted with the static secret, derived from the client’s ephemeral KeyShare and the semi-static DH parameters given in the server’s configuration.

The server, if able and willing to decrypt, responds with its default set of messages and immediately appends the contents of the requested resource. That’s the same round-trip time as for an unencrypted HTTP request. All communication following the ServerHello will again be encrypted with the ephemeral secret, derived from the client’s and server’s ephemeral key shares. After exchanging Finished messages the server will be re-authenticated, and traffic encrypted with keys derived from the master secret.

Security of 0-RTT Handshakes

At first glance, 0-RTT mode seems similar to session resumption or PSK, and you might wonder why one wouldn’t merge these mechanisms. The differences however are subtle but important, and the security properties of 0-RTT handshakes are weaker than those for other kinds of TLS data:

1. To protect against replay attacks the server must incorporate a server random into the master secret. That is unfortunately not possible before the first round-trip and so the poor server can’t easily tell whether it’s a valid request or an attacker replaying a recorded conversation. Replay protection will be in place again after the ServerHello message is sent.

2. The semi-static DH share given in the server configuration, used to derive the static secret and encrypt first flight data, defies forward secrecy. We need at least one round-trip to establish the ephemeral secret. As configurations are shared between clients, and recovering the server’s DH share becomes more attractive, expiration dates should be limited sensibly. The maximum allowed validity is 7 days.

3. If the server’s DH share is compromised a MITM can tamper with the 0-RTT data sent by the client, without being detected. This does not extend to the full session as the client can retrospectively authenticate the server via the remaining handshake messages.

Defending against Replay Attacks

Thwarting replay attacks without input from the server is fundamentally very expensive. It’s important to understand that this is a generic problem, not an issue with TLS in particular, so alas one can’t just borrow another protocol’s 0-RTT model and put that into TLS.

It is possible to have servers keep a list of every ClientRandom they have received in a given time window. Upon receiving a ClientHello the server checks its list and rejects replays if necessary. This list must be globally and temporally consistent as there are possible attack vectors due to TLS’ reliable delivery guarantee if an attacker can force a server to lose its state, as well as with multiple servers in loosely-synchronized data centers.

Maintaining a consistent global state is possible, but only in some limited circumstances, namely for very sophisticated operators or situations where there is a single server with good state management. We will need something better.

Removing Anti-Replay Guarantee

A possible solution might be a TLS stack API to let applications designate certain data as replay-safe, for example GET / HTTP/1.1 assuming that GET requests against a given resource are idempotent.

let c = new TLSConnection(...); c.setReplayable0RTTData("GET / ..."); c.connect();

Applications can, before opening the connection, specify replayable 0-RTT data to send on the first flight. If the server ignores the given 0-RTT data, the TLS stack automatically replays it after the first round-trip.

Removing Reliable Delivery Guarantee

Another way of achieving the same outcome would be a TLS stack API that again lets applications designate certain data as replay-safe, but does not automatically replay if the server ignores it. The application can decide to do this manually if necessary.

let c = new TLSConnection(...); c.setUnreliable0RTTData("GET / ..."); c.connect(); if (c.delivered0RTTData()) { // Things are cool. } else { // Try to figure out whether to replay or not. }

Both of these APIs are early proposals and the final version of the specification might look very different from what we can see above. Though, as 0-RTT handshakes are a charter goal, the working group will very likely find a way to make them work.

Summing up

TLS v1.3 will bring major improvements to handshakes, how exactly will be finalized in the coming months (or years?). They will be more private by default as all information not needed to set up a secure channel will be encrypted as early as possible. Clients will need only a single round-trip to establish secure and authenticated connections to servers they never spoke to before.

Static RSA mode will no longer be available, forward secrecy will be the default. The two session resumption standards, session identifiers and session tickets, are merged into a single PSK mode which will allow streamlining implementations.

The proposed 0-RTT mode is promising, for custom application communication based on TLS but also for browsers, where a GET / HTTP/1.1 request to your favorite news page could deliver content blazingly fast as if no TLS was involved. The security aspects of zero round-trip handshakes will become more clear as the draft progresses.

Categorieën: Mozilla-nl planet

Eric Shepherd: Five-word movie review: “Terminator Genisys”

ma, 16/11/2015 - 14:56

Lots of fun! I’m serious.

Categorieën: Mozilla-nl planet

Daniel Stenberg: The most popular curl download – by a malware

ma, 16/11/2015 - 12:43

During October 2015 the curl web site sent out 1127 gigabytes of data. This was the first time we crossed the terabyte limit within a single month.

Looking at the stats a little closer, I noticed that in July 2015 a particular single package started to get very popular. The exact URL was

Curious. In October it alone was downloaded more than 300,000 times, accounting for over 70% of the site’s bandwidth. Why?

The downloads came from what appears to be different locations. They don’t use any HTTP referer headers and they used different User-agent headers. I couldn’t really see a search bot gone haywire or a malicious robot stuck in a crazy mode.

After I shared some of this data over in our IRC channel (#curl on freenode), Björn Stenberg stumbled over this AVG slide set, describing how a particular malware works when it infects a computer. Downloading that particular file is thus a step in its procedures to create a trojan that will run on the host system – see slide 11 for the curl details. The slide also mentions that an updated version of the malware comes bundled with the curl library already, which then I guess makes the hits we see on the curl site being done by the older versions still being run.

Of course, we can’t be completely sure this is the source for the increased download of this particular file but it seems highly likely.

I renamed the file just now to see what happens.

Evil use of good code

We can of course not prevent evil uses of our code. We provide source code and we even host some binaries of curl and libcurl and both good and bad actors are able to take advantage of our offers.

This rename won’t prevent a dedicated hacker, but hopefully it can prevent a few new victims from getting this malware running on their machines.

Update: the hacker news discussion about this post.

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 105

ma, 16/11/2015 - 06:00

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us an email! Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

This week's edition was edited by: nasa42, brson, and llogiq.

Updates from Rust Community News & Blog Posts Notable New Crates & Projects
  • rustfmt is now part of Rust Nursery.
  • Leaf. Open Machine Intelligence Framework.
  • lrs. An experimental, linux-only standard library.
Updates from Rust Core

95 pull requests were merged in the last week.

See the triage digest and subteam reports for more details.

Notable changes New Contributors
  • corentih
  • Danilo Bargen
  • Eric Findlay
  • Erik Davidson
  • Kohei Hasegawa
  • Sebastian Hahn
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

No RFCs were approved this week!

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

New RFCs Upcoming Events

If you are running a Rust event please add it to the calendar to get it mentioned here. Email Erick Tryzelaar or Brian Anderson for access.

fn work(on: RustProject) -> Money

Tweet us at @ThisWeekInRust to get your job offers listed here!

Crate of the Week

This week's Crate of the Week is Hyper which offers a Rust HTTP(S) implementation for both clients and servers.

Thanks to DanielKeep for this week's suggestion. Submit your suggestions for next week!

Categorieën: Mozilla-nl planet

Robert O'Callahan: Debugging Leaks With rr

ma, 16/11/2015 - 00:15

Last week I looked into a couple of Gecko leaks using rr. One fun aspect of using rr is discovering new debugging techniques. "What's the best way to use a record-and-replay debugger to track down memory leaks?" is a very interesting question. Maybe no-one has tried to do this before.

XPCOM_MEM_LEAK_LOG uses instrumentation to count object constructors and destructors and report any mismatches. That tells us immediately which classes of objects leaked. My next step was to identify the address of a leaked object, preferably one that is the root of an ownership tree of leaked objects. In my particular case I chose to investigate a leaked nsWindow, because only one was leaked and I guessed (correctly, as it turns out) that it was most likely to be the root of the leaked object tree.

Finding the address of the leaked nsWindow was easy: run the program with breakpoints on the nsWindow constructor and destructor, set to log the object address and continue. The constructor with no matching destructor has the address of the leaked object. At process exit I could inspect the window object and see that indeed it still existed with refcount 1.

My next move was to use a similar technique to log addref/release operations on that window. This is similar to what you'd get with Gecko's built-in trace-refcount instrumentation, but produced a lot of data that was hard to analyze. I realized the leaked reference to the window probably corresponds to a pointer to the window in memory when the process exits. So I added a real-tid command to rr to print the real thread-id of a replaying process, and wrote a small program to walk /proc/.../maps and /proc/.../mem to search all process memory for the pointer value. This worked very well and showed just two addresses where the pointer occurred.

The next problem was to figure out what those addresses belong to. I futzed around a bit before finding the correct approach: set hardware write watchpoints on those addresses and reverse-execute from the end of the process to find the writes that stored those addresses. This told me immediately where and why each reference was being stored, and if it was a strong reference. This made the bug obvious.

A lot of this could be more automated. It would be particularly interesting to grab the XPCOM_MEM_LEAK_LOG output and process it to automatically output the "leak roots" --- leaking references that are not contained in objects that themselves leaked. If there are no leak roots then instead there must be at least one cycle of strong references, which we can output.

Categorieën: Mozilla-nl planet