Add initial build.sh and Dockerfile for irssi

[josephbisch]

This integrates irssi fe-fuzz with oss-fuzz.

Thanks for providing this service!

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[josephbisch]

I signed it!

[googlebot]

CLAs look good, thanks!

[inferno-chromium]

LIB_FUZZING_ENGINE is already defined, i will remove after landing.

[inferno-chromium]

Did you try verifying your fuzz target works using
python infra/helper.py run_fuzzer $PROJECT_NAME irssi-fuzz

I see
/out/irssi-fuzz: error while loading shared libraries: libgmodule-2.0.so.0: cannot open shared object file: No such file or directory

See https://github.com/google/oss-fuzz/blob/master/docs/fuzzer_environment.md#dependencies

[josephbisch]

I tried with the ossfuzz/base-libfuzzer docker image and it worked. Changed last minute to ossfuzz/base-builder. I'll try verifying that it works with ossfuzz/base-builder locally.

[inferno-chromium]

No, base-builder and base-libfuzzer are builder images and have dependencies installed in build.sh. But for ClusterFuzz, we test with base-runner image that does not the build time install dependencies. Made doc changes to make this more clear - fe049a4.

python infra/helper.py run_fuzzer command use base-runner image (make sure to git pull to latest oss-fuzz code).

[josephbisch]

@inferno-chromium - Thanks, it runs for me with python infra/helper.py run_fuzzer irssi irssi-fuzz now that I have it statically linking. I'll submit a PR to fix it. But first I have a question.

I ran into an issue with the amount of output that irssi was generating when fuzzing it. My terminal eventually becomes unresponsive (whether or not the fuzzer is running inside of Docker). If irssi with this change wfm locally with python infra/helper.py run_fuzzer irssi irssi-fuzz can I expect it to work on oss-fuzz infra? My confusion comes from this page saying that /dev/ is unavailable, but I am opening /dev/null to redirect stdout and it seems to work. Or is there a better way to handle the excessive output?

[Dor1s]

@josephbisch, the best way to disable excessive logging is to do it during compilation. For example:

• in libpng we disable that by setting a special configuration flag (

  oss-fuzz/projects/libpng/build.sh

  Line 18 in a143b9b

  # Disable logging via library build configuration control.

  )
• in libxml2 we provide a custom error handler (https://github.com/google/oss-fuzz/blob/master/projects/libxml2/libxml2_xml_read_memory_fuzzer.cc#L15)
• other projects often have a preprocessor definition like -DLOG_LEVEL=

If irssi doesn't have a way to mute those messages, you can add the following option into irssi-fuzz.options file:

[libfuzzer]
close_fd_mask=3

For more info about the .options file, please take a look at https://github.com/google/oss-fuzz/blob/38e4301909ec62d1652ecd05187cf3cf4db9f655/docs/new_project_guide.md#custom-libfuzzer-options-for-clusterfuzz

[inferno-chromium]

@josephbisch - check out @Dor1s comment for the answer.

Regarding "python infra/helper.py run_fuzzer irssi irssi-fuzz" is similar to ClusterFuzz, but ClusterFuzz has an additional enforcer using Minijail for a secure environment, that is why /dev is unavailable (@oliverchang, can you confirm). Best to disable logging during compilation phase, otherwise close_fd_mask=3 is fine (remember that it will exclude all output, including any debug asserts that you want us to catch as crashes).

[kcc]

@josephbisch , I've noticed your blog about fuzzing irssi: https://irssi.org/2017/05/12/fuzzing-irssi/
Meanwhile, did you check the coverage generated by fuzzing irssi on oss-fuzz?
The coverage looks pretty low (12%) and so it's quite likely there are some low hanging fruit there
(e.g. better seed corpus, dictionary, more fuzz targets, etc)

[josephbisch]

@kcc - Other irssi people showed me the coverage info, so I did see it. The particular function that is being fuzzed on oss-fuzz now (printtext_string) was chosen because it can be reached over the network by other clients and servers. I definitely think this is a case where it will help if I add more fuzz targets, since there is just a lot of irssi code that isn't reached by calling that one function.