The title of this project is inspired from the must-see video

The afl fuzzer is an interesting tool that uses compile time instrumentation and genetic algorithms to automatically produce test cases that will trigger different code paths in binary...

git rebase is a very useful construct in source control management, as it allows you to re-apply your changes atop a different branch of the same repository. While this concept transitions perfectly to container management (updating a container could be as easy as a docker rebase), and the Docker client is inspired by the git semantics, Docker has no such feature (in fact, Solomon Hykes used rebase and merge as examples of things "that we don't want"). Currently, zypper-docker works by applying an updated layer on top of an existing image. While this does work quite well, it separates the process of updating the base image and updating all of your derivative images (you need to re-download new packages for each derivative image).

As detailed previously on devel and opensuse-factory the KDE team didn't have access to their bugs and could not actively subscribe.

We currently have a set of shell scripts that verify if patches can be properly installed on multiple combinations of base products, extensions and modules. These scripts are all written in shell and are annoying to maintain, as configuration and code is all mixed up.

The basic idea is is to boot the plain SUSE installation system (inst-sys) but to not let it run YaST.

There were several attempts to integrate ABRT to openSUSE. In this Hack Week I'd like to:

• learn how to code on golang
• create a script for docker testing (bash or python)

motivation

jenkins is a great CI system (continuous integration) with a plethora of plugins available. SUSE QA uses openQA extensively as it excels in distribution and product testing - not only image comparison (common misconception ;-) ). How about combining both in using jenkins with plugins to act as a UI for openQA?

It's a CTF like game, where the goal is to unlock "lock" devices. Having access to a disassembled code you have to create an input that will unlock the device by exploiting a bug in its code.