Setup CI Pipeline on Github

Purpose

Setup a CI pipeline for Github and Jenkins. The goal is to integrate CI DevOps practice both for the project and for personal learning. This is to include code coverage, static analysis, and lint. May setup a zenhub board to better manage issues and explore other devOps tools offered on Github and Jenkins to improve workflow.

Tasks/Goals

[x] Ensure Github Actions can Build Ubuntu Builds
[x] Setup Jenkins Server on Raspberry Pi
[x] Setup Security Code Analysis
[ ] Setup Ubuntu node on Jenkins (perhaps change to Fedora)
[x] Setup static analyzers
[x] Setup doxygen workflow generation and deployment
[ ] Setup linter
- [ ] See if splint is a good idea to add to workflow
[ ] Setup fuzzer (i.e. afl)
(optional) setup cppcheck

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

Github action workflow to build code has been completed
Github action workflow static analysis has been completed (using CodeQL)
Github action workflow to generate oxygen and deploy on github pages has been completed

Side Notes (for future references)

fuzzer: afl

Installation:

download tarball
make
sudo make install
create afl_in and afl_out directories
add sample test cases into afl_in

Running:

Problem 1:

$ afl-fuzz -i afl_in -o afl_out -- ./fuzzgoat @@
...
[-] Hmm, your system is configured to send core dump notifications to an
    external utility. This will cause issues: there will be an extended delay
    between stumbling upon a crash and having this information relayed to the
    fuzzer via the standard waitpid() API.

    To avoid having crashes misinterpreted as timeouts, please log in as root
    and temporarily modify /proc/sys/kernel/core_pattern, like so:

    echo core >/proc/sys/kernel/core_pattern

Resolution 1: export AFL_I_DONT_CARE_ABOUT_MISSING_CRASHES=1

Problem 2:

[-] Whoops, your system uses on-demand CPU frequency scaling, adjusted
    between 390 and 4003 MHz. Unfortunately, the scaling algorithm in the
    kernel is imperfect and can miss the short-lived processes spawned by
    afl-fuzz. To keep things moving, run these commands as root:

    cd /sys/devices/system/cpu
    echo performance | tee cpu*/cpufreq/scaling_governor

    You can later go back to the original state by replacing 'performance' with
    'ondemand'. If you don't want to change the settings, set AFL_SKIP_CPUFREQ
    to make afl-fuzz skip this check - but expect some performance drop.

Resolution 2: export AFL_SKIP_CPUFREQ=1

consider: https://github.com/google/AFL/blob/master/docs/notes_for_asan.txt Apparently, using asan with fuzzer is not a good idea. So need to disable asan when using fuzzer probably.

Testing Framework:

check
- reference: https://www.ccs.neu.edu/home/skotthe/classes/cs5600/fall/2015/labs/intro-check.html
- example: https://github.com/intel/cc-oci-runtime/tree/master/tests
cpputest
- https://www.amazon.ca/Test-Driven-Development-Embedded-C/dp/193435662X
- https://www.sparkpost.com/blog/getting-started-cpputest/

also take a look if this would be useful: (pam_wrapper) https://lwn.net/Articles/671094/

Todo:

[ ] create unit test cases with asan enabled
[ ] ensure NDEBUG is not set to have assert in production build
[ ] create small programs to test major functions and provide it into the fuzzer

Future Reference: https://medium.com/@ayushpriya10/fuzzing-applications-with-american-fuzzy-lop-afl-54facc65d102

zakuArbor / proxyAuth