Skip to content

Commit

Permalink
CI: add CodeQL workflow test
Browse files Browse the repository at this point in the history 
Add CodeQL workflow test to catch security vulnerabilities and enable
suggestion for better code.

All the dependency comes from the build-ubox workflow but all is built
on ubuntu instead of alpine image.

CodeQL queries enabled: security-and-quality

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
  • Loading branch information
@Ansuel
Ansuel committed Mar 2, 2024
1 parent 13d0432 commit 5101570
Showing 1 changed file with 88 additions and 0 deletions.
88 changes: 88 additions & 0 deletions .github/workflows/codeql.yml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
name: "CodeQL"

on:
push:
branches: [ "master" ]
pull_request:
branches: [ "master" ]
schedule:
- cron: '31 12 * * 1'

jobs:
analyze:
name: Analyze (c-cpp)
runs-on: ubuntu-latest
timeout-minutes: 360
permissions:
security-events: write

steps:
- name: Install Dependencies
run: |
sudo apt update && sudo apt install cmake make gcc pkg-config libjson-c-dev linux-headers-generic lua5.1 liblua5.1-0-dev
- name: Install libubox
run: |
git clone --depth=1 https://git.openwrt.org/project/libubox.git

This comment has been minimized.

Sign in to view

Copy link
@ynezz

ynezz Mar 3, 2024

Member

Just FYI

openwrt/libubox#2
openwrt/procd#2

and we started to discuss this a bit https://patchwork.ozlabs.org/project/openwrt/patch/20230308231810.2143384-2-hauke@hauke-m.de/#3075163

If you imagine and actually consider, that there is 30+ of similar C based projects (and usually 2 maintenance release/branches), I'm sure, that you would agree, that it would make sense to take a step back now and think about future a bit:

  • maintenance of such actions across all the internal/external (ucode, usteer etc.) C projects
  • maintenance of such actions across all supported branches
  • reproducibility of CI results/debug-ability on developer's machine as well

So it really should be some shared container(s) and shared GitHub actions, like we've now for the main OpenWrt repo.

We should probably consider a dedicated CI meeting and discuss this further?

This comment has been minimized.

Sign in to view

Copy link
@Ansuel

Ansuel Jun 29, 2024

Author Member

@ynezz retaking this... Main problem is that I don't see a way to have generic enough actions.

My idea for these tests was to have something that can compile on a normal system (aka detached from our openwrt buildroot) and make use of codeql tools.

We might consider to implement all these simple action in the shared repository? That might be a solution for branch and keeping these actions up to date.

The project itself will just have a simple action that will load the shared one (as we do in openwrt currently)

This comment has been minimized.

Sign in to view

Copy link
@ynezz

ynezz Jul 1, 2024 •
edited
Loading

Member

Main problem is that I don't see a way to have generic enough actions.

Indeed, its not crystal clear in the beginning, usually few projects are needed to see the changing bits and generalize them, I've done that for ~13 projects in the past https://github.com/search?q=org%3Aopenwrt+%2Fremote%3A.*openwrt-ci%2F&type=code (basically re-usable GitHub actions, done by GitLab means).

My idea for these tests was to have something that can compile on a normal system (aka detached from our openwrt buildroot)

Yep, this is certainly needed. I was calling this a native build (native-testing in that email referenced above) and within that container/environment you can run unit tests, static code analyzers, fuzzers etc.

We might consider to implement all these simple action in the shared repository?

Yes, IMO this is the only way for shareable GitHub CI integration?

BTW there is quite very old example in ucode, basically there is a generic action/container configured via CI_ENABLE_UNIT_TESTING: 1 and CI_TARGET_BUILD_DEPENDS: libnl-tiny ubus uci environment variables.

Why environment variables and not standard GitHub inputs variables? I wanted to make it CI agnostic, so developers can run the same CI tests locally (easier development/debugging) and on any CI system.

We should probably consider a dedicated CI meeting and discuss this further?

I'll have time in week 29 (15-19 July) so if you're interested we can have some online session to discuss this.
cd libubox
cmake -DBUILD_EXAMPLES=OFF
make
sudo make install
- name: Install libubus
run: |
git clone --depth=1 https://git.openwrt.org/project/ubus.git
cd ubus
cmake -DBUILD_EXAMPLES=OFF
make
sudo make install
- name: Install libuci
run: |
git clone --depth=1 https://git.openwrt.org/project/uci.git
cd uci
cmake .
make
sudo make install
- name: Install libudebug
run: |
git clone --depth=1 https://github.com/jow-/ucode
cd ucode
cmake .
make
sudo make install
- name: Install libudebug
run: |
git clone --depth=1 https://git.openwrt.org/project/udebug.git
cd udebug
cmake .
make
sudo make install
- name: Checkout repository
uses: actions/checkout@v4

# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init@v3
with:
languages: c-cpp
queries: security-and-quality

- name: Install ubox
run: |
cmake .
make
sudo make install
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v3
with:
category: "/language:c-cpp"

0 comments on commit 5101570

Please sign in to comment.