grumpyoldtroll / libmcrx Goto Github PK

Right now coverity scans are scheduled daily unconditional, so it's often re-scanning an unchanged repo:

I think re-scanning is a good idea if the coverity version changes or the repo changes, but ideally not otherwise.

Once it's a tighter conditional, it would also be good to scan PRs before integrating them if possible, and maybe make the check more frequent. The changes to this repo are infrequent enough that it's probably better to leverage the 7/day max limit differently than a hard once per day.

These three lines can be deleted as while(1)

If you give me permission, I can set up https://scan.coverity.com/ like https://github.com/SentryPeer/SentryPeer/blob/main/.github/workflows/coverity-scan.yml but I need to set a token in this project repo.

Another great one I can add

Some of these includes can be deleted, but I'm presuming the unused functions are for users of the library?

We could clear these warnings by using them in a test cases if possible.

https://github.com/SentryPeer/libmcrx/runs/5050408139?check_suite_focus=true

src/native.c:61:5: warning: ‘strncpy’ specified bound 1024 equals destination size [-Wstringop-truncation]
   61 |     strncpy(buf, ret, len);

Add an action to build and clean the project on push etc.

Resolving these, so we can then add a GitHub Action for CI/CD like:

https://github.com/SentryPeer/SentryPeer/actions/runs/1786335895
https://github.com/SentryPeer/SentryPeer/actions/runs/1786335895/workflow

then we can do Coverity scans and all sorts like:

https://github.com/SentryPeer/SentryPeer/actions

I've been running "make check" before commits, but it requires some local config before running. On linux, assuming libmcrx is in ~/src, that looks like:

docker container run -d --rm --name amtgw-5 --privileged grumpyoldtroll/amtgw $(python3 ~/src/libmcrx/driad.py 23.212.185.5)
sudo ip route add 23.212.185.5/32 dev docker0

Then, as long as my sender of traffic from 23.212.185.5->232.1.1.1:5001 is alive and properly registered in the DNS and reachable, the tests pass. (Else they hang forever, which maybe also should be fixed to fail after some time.)

Ideally, this would also be coupled with adding valgrind to the tests and failing on violations. Some links on how to do so are here:

• https://www.gnu.org/software/autoconf-archive/ax_valgrind_check.html
• https://tecnocode.co.uk/2014/12/23/automatically-valgrinding-code-with-ax_valgrind_check/
• https://www.gnu.org/software/autoconf-archive/ax_valgrind_check.html
• https://ansuz.sooke.bc.ca/entry/233

Other nice-to-haves would be gcov or similar, with some kind of coverage report shown on pages (also mentioned in some of the above but probably more research needed.)

• Run autoupdate
• Run autoscan to find all missing checks.

Pull Request coming.

I noticed this while running MNAT on the receiver. Packets arriving on the physical interface with a different source address than the subscribed (S,G) were received instead of filtered in the library. (The OS can't filter it because the listening UDP socket is only bound to the group and the port; even though the sockopt is an SSM join, that's not a filter for the receiving port.)

SonarCloud is another great free tool