libbacktrace crash and os::self_exe_name race condition #21889

semarie · 2015-02-03T08:58:46Z

This issue is to report several problems linked:

libbacktrace (embeded in every rust-compiled program) is fragile (a bad input could generate a crash, I don't have checked for code-execution at this moment)
a race condition exists with os::self_exe_name that could permit to exploit the previous issue by replacing at runtime the binary by a specially crafted elf.

I will first speak about the race, and next about libbacktrace.

First, about os::self_exe_name: it is a function that return an Option about the running binary (the filepath to the binary used for launch the running processus).

The function is used in rustc:

by librustc to infer the default sysroot directory (rustc and rustdoc use it)
by libbacktrace under bsd system for gets the binary symbols
(but note that for others platforms, libbacktrace obtain symbols by itself using similar method than os::self_exe_name, so there is the same problem)
by severals tests

The implementation (sys::os::load_self) is platform dependant:

freebsd: sysctl()
dragonfly: readlink(/proc)
linux, android: readlink(/proc)
macos, ios: _NSGetExecutablePath()
windows: GetModuleFileNameW()

Just returning a filepath is subject to race condition for many usages. The libbacktrace usage is one of them.

libbacktrace is initialized on sys::backtrace::print() call (so not at the beginning of the processus). This function is called by sys::backtrace::write(). And on panic, a backtrace is showed if RUST_BACKTRACE environment is setted.

So, when a panic occurs, libbacktrace will read the previously obtained filepath (from os::self_exe_name or by itself). It will open this filepath, parse the ELF structure, search for symbols and addresses... and do all the thing it need for print a pretty backtrace.

The problem is libbacktrace seems not robust enought for specially crafted ELF. I have started to test it with afl-fuzzer, and it reports severals crashs (that may or not be suceptible to produce code-execution).

As libbacktrace is embeded in (near to) every rust-compiled programs, it could be a dangerous thing.

To successfully exploit it, the following conditions are required:

run libbacktrace code:
- RUST_BACKTRACE environment variable to be setted
- trigger a panic in running process
have libbacktrace read a crafted-elf:
- replace the file of the running program by another one after the start of the program, and before the panic

The conditions are relatively high for simple exploitation, but as it is a problem present in (near to) every rust-compiled code, some attention should be need.

The text was updated successfully, but these errors were encountered:

huonw · 2015-02-03T09:08:59Z

The possibility of code-execution seems worth nominating, however, it seems to me that you're likely to be pwned already if an attacker can modify the binary being run (on the other hand, maybe the problem described here can be exploited in other ways).

semarie · 2015-02-03T09:39:16Z

It is heavily depending of the context, I am agreed. But it is a problem in every compiled program, not just in rustc.
And it is not possible to ensure the safetly of use of every rust-compiled-program.

As example, it could be possible to consider https://play.rust-lang.org/:

it is possible to call os::setenv("RUST_BACKTRACE", "1")
it is possible to trigger a panic
As result, the backtrace code is runned, and the backtrace at the panic!() call will be displayed.

After, I don't known about detail of compilation and execution for this service, and if the race could be exploited to achieve code-execution.

huonw · 2015-02-03T09:43:09Z

Yes, but it seems that the only way to exploit this is to either cause self_exe_name to point to some new file (I imagine this isn't possible on most platforms?), or to actually modify the file pointed to by self_exe_name(). The latter is the case I was referring to: if the attacker can change the executable itself on disk, you've likely got deeper problems than unsafety in libbacktrace.

semarie · 2015-02-03T16:19:23Z

I'm not able to test every platform, and as said the exploitation possibility is dependent of the context.

A locally installed program will not be vulnerable to this kind of problem (or, as you said, without deeper problems).
I was more thinking about ephemerals binaries, that are more exposed.

Some notes about several implementations:

Linux: basically a readlink("/proc/self/exe")
They should be safe, the content seems to be valid or absent: it don't point to replaced binary and the system don't permit modification a a running binary.
FreeBSD: use the value returned by sysctl()
Same conclusion than for Linux.
DragonFly: same method as Linux (but using "/proc/curproc/file")
If the binary is moved, the link follow it. But if it is deleted, it seems the link could point to a new file.
OpenBSD: it is the one I wrote, and as OpenBSD don't provide method for obtain the filepath of a running program, it use argv[0] as source of information.
In a security perspective it is bad as argv[0] could be forged by the parent processus.
MacOS or Windows : not tested.

pnkfelix · 2015-02-05T21:37:04Z

P-high, not 1.0.

semarie · 2015-03-01T15:53:49Z

Just a comment about "safety" in my previous comment: the race remains even if the platform is "safe".

For example for Linux, when reading the file /proc/self/exe, you know you read the good file. But here, you dereference the link to obtain a filename, and some time after that you read the file pointed by this filename.

steveklabnik · 2016-03-24T20:59:30Z

Triage: no change

brson · 2016-05-08T03:06:59Z

cause self_exe_name to point to some new file (I imagine this isn't possible on most platforms?)

This is easy to do on Unix, since files can be deleted or moved while they are running.

In thinking about how both rustc and rustup use current_exe, it seems like it would be easy to influence what code they run by changing file at that path, particularly with rustup, which will actually execute it during uninstallation.

At the same time, when I think of bugs that could lead attackers to cause a compiler like rustc to execute arbitrary code, I start to think of all the other ways people could influence rustc to execute arbitrary code, and it seems hopeless. If an attacker has local disk access there are unlimited things they could do to cause a compiler to execute anything.

brson · 2016-05-09T21:16:45Z

The libs team discussed this issue recently and agreed to do two things:

Disable libbacktrace in configurations where we know it to be insecure.
Update the current_exe docs to be more explicit about the its dangers.

brson · 2016-05-09T21:21:57Z

An aspect that the libs team didn't consider in the discussion is the behavior of current_exe following symlinks. @semarie suggests it is insecure to do so.

/cc rust-lang#21889

If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889

@alexcrichton

…hton Don't use env::current_exe with libbacktrace If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889 r? @alexcrichton cc @semarie

If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889

@alexcrichton

…hton Don't use env::current_exe with libbacktrace If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889 r? @alexcrichton cc @semarie

@alexcrichton

…hton Don't use env::current_exe with libbacktrace If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889 r? @alexcrichton cc @semarie

If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889

@semarie

Add some warnings to std::env::current_exe /cc #21889 @rust-lang/libs @semarie I started writing this up. I'm not sure if we want to go into other things and in what depth; we don't currently have a lot of security-specific documentation to model after. Thoughts?

alexcrichton · 2016-10-25T16:08:43Z

Ah this was handled awhile back, so closing.

This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called "libbacktrace". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time, unfortunately, though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself, both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose, which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate, by default, uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency, this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly, but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option, and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself, enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note, however, that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway, so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly, but a dependency of `addr2line`. * `adler32`- not used directly either, but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library, especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - rust-lang#12602 * OOM with libbacktrace - rust-lang#24231 * Backtrace failure due to use of uninitialized value - rust-lang#28447 * Possibility to feed untrusted data to libbacktrace - rust-lang#21889 * Soundness fix for libbacktrace - rust-lang#33729 * Crash in libbacktrace - rust-lang#39468 * Support for macOS, never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - rust-lang#29293, rust-lang#37477 * Update procedure is quite complicated due to how many patches we need to carry - rust-lang#50955 * Libbacktrace doesn't work on MinGW with dynamic libs - rust-lang#71060 * Segfault in libbacktrace on macOS - rust-lang#71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away, but correctness and performance may still have bugs arise. The gimli and `backtrace` crates, however, are actively maintained unlike libbacktrace, so this should enable us to at least efficiently apply fixes as situations come up.

…Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called "libbacktrace". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time, unfortunately, though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself, both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose, which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate, by default, uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency, this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly, but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option, and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself, enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note, however, that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway, so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly, but a dependency of `addr2line`. * `adler32`- not used directly either, but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library, especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - rust-lang#12602 * OOM with libbacktrace - rust-lang#24231 * Backtrace failure due to use of uninitialized value - rust-lang#28447 * Possibility to feed untrusted data to libbacktrace - rust-lang#21889 * Soundness fix for libbacktrace - rust-lang#33729 * Crash in libbacktrace - rust-lang#39468 * Support for macOS, never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - rust-lang#29293, rust-lang#37477 * Update procedure is quite complicated due to how many patches we need to carry - rust-lang#50955 * Libbacktrace doesn't work on MinGW with dynamic libs - rust-lang#71060 * Segfault in libbacktrace on macOS - rust-lang#71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away, but correctness and performance may still have bugs arise. The gimli and `backtrace` crates, however, are actively maintained unlike libbacktrace, so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR, however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (rust-lang/backtrace-rs#349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - rust-lang/backtrace-rs#325, rust-lang/backtrace-rs#326, rust-lang/backtrace-rs#350, rust-lang/backtrace-rs#351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely rust-lang/backtrace-rs#349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change, so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR), but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this, so I'm hoping others can help me figure that out!

This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called "libbacktrace". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time, unfortunately, though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself, both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose, which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate, by default, uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency, this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly, but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option, and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself, enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note, however, that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway, so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly, but a dependency of `addr2line`. * `adler32`- not used directly either, but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library, especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - rust-lang#12602 * OOM with libbacktrace - rust-lang#24231 * Backtrace failure due to use of uninitialized value - rust-lang#28447 * Possibility to feed untrusted data to libbacktrace - rust-lang#21889 * Soundness fix for libbacktrace - rust-lang#33729 * Crash in libbacktrace - rust-lang#39468 * Support for macOS, never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - rust-lang#29293, rust-lang#37477 * Update procedure is quite complicated due to how many patches we need to carry - rust-lang#50955 * Libbacktrace doesn't work on MinGW with dynamic libs - rust-lang#71060 * Segfault in libbacktrace on macOS - rust-lang#71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away, but correctness and performance may still have bugs arise. The gimli and `backtrace` crates, however, are actively maintained unlike libbacktrace, so this should enable us to at least efficiently apply fixes as situations come up.

huonw added the I-nominated label Feb 3, 2015

pnkfelix added P-medium Medium priority and removed I-nominated labels Feb 5, 2015

aturon added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 9, 2016

steveklabnik added a commit to steveklabnik/rust that referenced this issue May 9, 2016

Add some warnings to std::env::current_exe

8478d48

/cc rust-lang#21889

steveklabnik mentioned this issue May 9, 2016

Add some warnings to std::env::current_exe #33526

Merged

sfackler mentioned this issue May 11, 2016

Don't use env::current_exe with libbacktrace #33554

Merged

sfackler added a commit to sfackler/rust that referenced this issue May 11, 2016

Don't use env::current_exe with libbacktrace

9c2e691

If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889

sfackler added a commit to sfackler/rust that referenced this issue May 12, 2016

Don't use env::current_exe with libbacktrace

9393e52

If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889

alexcrichton pushed a commit to alexcrichton/rust that referenced this issue May 17, 2016

Don't use env::current_exe with libbacktrace

a3c3c30

If the path we give to libbacktrace doesn't actually correspond to the current process, libbacktrace will segfault *at best*. cc rust-lang#21889

This was referenced Oct 20, 2016

Rust stack backtrace filled with unknown on Windows 8.1 #33985

Closed

Fix backtraces on Windows/GNU #37359

Closed

alexcrichton closed this as completed Oct 25, 2016

This was referenced Nov 4, 2017

cargo test with RUST_BACKTRACE causes SIGBUS #45731

Closed

Disable backtraces on OSX #45760

Closed

main-- mentioned this issue Dec 20, 2017

Debuginfo-based panic locations rust-lang/rfcs#2154

Open

alexcrichton mentioned this issue Jun 17, 2020

std: Switch from libbacktrace to gimli #73441

Merged

6 tasks

semarie mentioned this issue Oct 18, 2020

convince OpenBSD kernel developers to support an executable obtaining the path to its own binary ziglang/zig#6718

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

libbacktrace crash and os::self_exe_name race condition #21889

libbacktrace crash and os::self_exe_name race condition #21889

semarie commented Feb 3, 2015

huonw commented Feb 3, 2015

semarie commented Feb 3, 2015

huonw commented Feb 3, 2015

semarie commented Feb 3, 2015

pnkfelix commented Feb 5, 2015

semarie commented Mar 1, 2015

steveklabnik commented Mar 24, 2016

brson commented May 8, 2016

brson commented May 9, 2016

brson commented May 9, 2016

alexcrichton commented Oct 25, 2016

libbacktrace crash and os::self_exe_name race condition #21889

libbacktrace crash and os::self_exe_name race condition #21889

Comments

semarie commented Feb 3, 2015

huonw commented Feb 3, 2015

semarie commented Feb 3, 2015

huonw commented Feb 3, 2015

semarie commented Feb 3, 2015

pnkfelix commented Feb 5, 2015

semarie commented Mar 1, 2015

steveklabnik commented Mar 24, 2016

brson commented May 8, 2016

brson commented May 9, 2016

brson commented May 9, 2016

alexcrichton commented Oct 25, 2016