
The First Annual Underhanded Rust Contest - erickt
https://underhanded.rs/blog/2016/12/15/underhanded-rust.en-US.html
======
JackC
Suggestion: could you provide an example submission, which is ideal for what
you're looking for except for not being underhanded?

Benefits:

\- More approachable to mess around with for newbies -- download the example
and try to break it.

\- More likely that you'll get submissions from experts who have time to
implement the underhanded part but may not get around to putting together the
boilerplate.

\- More likely that submissions will get the general task right and look
similar for parts that don't matter, making for easier review.

Drawbacks:

\- Potential for too many cookie cutter submissions.

\- Might lead people away from thinking about alternate server designs that
are more underhanded.

Mostly I think this might be worth doing because of the second benefit --
you're asking people to do a bunch of grunt work even after they've figured
out the core underhanded technique.

~~~
erickt
That's a wonderful idea! I filed [1] to track it. I meant to do something like
this, but it got lost in the shuffle prepping for the announcement. We'll
publish one in a future blog post.

[1]: [https://github.com/rust-
community/underhanded.rs/issues/9](https://github.com/rust-
community/underhanded.rs/issues/9)

------
forgotpwtomain
Does the much broader scope and amount of code required here (compared to the
underhanded-c contest) make it a much weaker contest? For example they suggest
that one should create a web-server (rather than say, requiring one to
implement a couple specific methods for a hypothetical web-server):

> Create a simple web server that supports at least creating accounts and
> payment submissions. We recommend using one of the many Rust web servers
> like iron, nickel, or pencil, but you are welcome to create your own web
> server if you like.

Compare with the winning contest entry for the last underhanded-c contest
which is one printed-page of code in total.[0]

[0]
[http://www.underhanded-c.org/one.pdf](http://www.underhanded-c.org/one.pdf)

~~~
Manishearth
Rust has fewer gotchas to exploit compared to C. We considered reducing the
scope, but ultimately decided to keep the scope pretty broad because writing
underhanded code in Rust is _hard_

Note that using a library keeps the actual code size pretty small. You can't
introduce underhandedness into the library (unless you explicitly fork it).
But it gives you the opportunity to introduce underhandedness by misusing a
library API, which adds a whole new class of interesting tricks which you can
use.

Depending how this one goes, we may reduce the scope for the next ones.

~~~
dbaupp
_> We considered reducing the scope, but ultimately decided to keep the scope
pretty broad because writing underhanded code in Rust is hard_

Are we sure of this? The contest may prove otherwise.

Half-jokes aside, it would be surprising if it wasn't significantly harder in
Rust than in C, and presumably any glaring problems are easier to address
based on the more active nature of Rust development as well as tight feedback
between the language development/compiler and the rest of the community (along
with Rust's general attitude of "just be careful" not being good enough).

~~~
Manishearth
> Are we sure of this? The contest may prove otherwise.

No, we're not. Like I said, this can change in future competitions. It's no
big deal if the first one is too easy. If the first one is too hard we may not
get submissions and won't know if it is due to lack of interests or if it is
too hard.

My baseline for determining this was basically that almost all of the
underhanded C submissions use tricks that just can't work in Rust.

Furthermore, remember that the code will be run through clippy too. Many of
the gotchas (e.g. Option::iter()) that can be used to create potential
underhandedness should get caught by clippy.

But yes, we fully hope to feed back any findings into the
compiler/libraries/clippy.

~~~
vvanders
I love that you're using this as feedback into improving the ecosystem. I'll
say one thing about the Rust community, they really have their shit together
when it comes to stability and things like this.

I don't think I've ever seen a language release new versions with such
consistent cadence and predictability.

------
bitdivision
The reddit comments pointed out that there was a previous (unofficial) contest
last year [0]. Manishearth had a fun solution with lots of ideas: [1].

[0]
[https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_ru...](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/)

[1] [https://play.rust-
lang.org/?gist=cadcbee43557e8e3bbe0&versio...](https://play.rust-
lang.org/?gist=cadcbee43557e8e3bbe0&version=stable)

~~~
Manishearth
Just a clarification with that solution: The underhandedness is _not_ due to
the small size of the inputs. The inputs are tiny because I am lazy. They
should be arrays with ~1000 elements.

The solution can be found in the thread at
[https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_ru...](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr/)

------
eximius
The underhanded@rust-lang.org email does not work for me.

> We're writing to let you know that the group you tried to contact (rust-
> underhanded) may not exist, or you may not have permission to post messages
> to the group.

~~~
erickt
Thanks for the heads up! We fixed that setting, so mail away.

------
naasking
I expect some underhanded entries to exploit some type-level recursion. When
combined with traits, that could yield some nice surprises, particularly when
overloading specific instances.

~~~
shepmaster
Would you mind expanding on this a bit? The first thing that comes to mind:

    
    
        struct Foo {
            foo: Foo,
        }
    

Is caught by the compiler:

    
    
        error[E0072]: recursive type `Foo` has infinite size
         --> src/main.rs:1:1
          |
        1 | struct Foo {
          | ^ recursive type has infinite size
          |
          = help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Foo` representable
    

Obviously, I'm not thinking deep enough to understand the approaches you are
mentioning!

~~~
naasking
I'm not deep into Rust to try myself, but I meant something like type-level
integers, perhaps to encode an buffer length, and then a sneaky trait or two
that specializes on particular (common) buffer sizes to manipulate the buffer
in an exploitable way.

~~~
steveklabnik
Rust doesn't yet have type level integers, so that'll have to be saved for a
future contest. (It's highly desired, and there's an RFC open, but it's not
clear when they will land.)

I like this idea though!

~~~
mbrubeck
But there _are_ some crates like
[https://crates.io/crates/typenum](https://crates.io/crates/typenum) that
implement type-level integers on top of the Rust type system, and quite a few
other crates that then use these for things like array operations...

~~~
Gankro
Using typenum in production isn't a fireable offence?!

------
ysleepy
typo "distrobution" in the article.

~~~
erickt
Thanks! I just pushed up a fix for that.

