Hacker News Reader

Comment by forgotpwtomain | Hacker News Reader

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

View on HN

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.

> 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).

> 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.

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.

  > The contest may prove otherwise.

Which is exactly why I insisted on keeping the language in the opening paragraph as humble as possible. :P

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

Isn't testing that assumption a big point of the contest?

Too bad that underhanded-c has a broken RSS and Atom feed.

http://www.underhanded-c.org/_feed_rss2

http://www.underhanded-c.org/_feed_atom

I added those to my RSS reader a long time ago, but didn't notice the 2015 announcement, let alone the winning entries. Why? Because the feeds are stuck, their latest entries are more than 2 years old:

  11/03/2014 The 7th Underhanded C Contest is now Open
  09/29/2014 2013 Winners
  ...

This is our first crack at hosting an underhanded contest, so if this turns out to be a problem in practice we'll happily take this into account for next year. :) erickt is the one who came up with the specific challenge here, and I believe part of his motivation was to test not only the constructs of the language itself, but also to probe for the sort of exploitable bugs that may exist in real Rust codebases in the wild, e.g. web frameworks, in order to determine if tweaks to the language or stdlib would feasibly render such exploits toothless.

To add on to kibwen and Manishearth, another aspect is that one of the Rust Team's 2017 objectives [1] is to get our community more engaged in mentoring people and projects. We see the open ended aspect of this contest as a way to encourage people to help find and fix security bugs in our ecosystem. This should help to accelerate getting Rust even more production ready.

[1]: https://github.com/aturon/rfcs/blob/roadmap-2017/text/0000-r...

Reply on news.ycombinator.com