dbus-broker should probably be sent to Coverity Scan automatically #316
Comments
|
Just linking the respective coverity.yml and coverity.sh. IIRC I synced them between the dfuzzer and systemd repos so it should be more or less the same stuff, sans the build dependencies, project name, and the actual build command. The systemd version also sets the email address for the scan notification to a pre-defined one (which is currently my email) contrary to the dfuzzer version which uses email address from the latest commit. I did that in systemd to make sure I'll get notified on any possible fails (and because I think the scan notification is usually useless for people not involved in whole Coverity stuff). |
That would be yours too I believe :-) I've just sent dbus-broker with af6bf48 included and Coverity confirmed that it's gone :-) Anyway the scripts are ready. I can keep running it manually from time to time until the secret is added to the repository. |
Let's make a full use of Coverity and submit the builds for analysis automatically every midnight. We can't do that for every PR, since there are quite strict rate limits that limit how many builds we can submit per day and per week (see [0]). The action (and the script) requires two environment variables to be set - $COVERITY_SCAN_TOKEN for authentication (can be found here [1]), and $COVERITY_SCAN_NOTIFICATION_EMAIL for sending the email notification when the build analysis is done. Originally this email used to be set to the email from the latest commit, but since the author of that commit might not even have permissions to see the Coverity report it's best to set it to one of the dbus-broker maintainers. Resolves: bus1#316 [0] https://scan.coverity.com/faq#frequency [1] https://scan.coverity.com/projects/dbus-broker?tab=project_settings
Let's make a full use of Coverity and submit the builds for analysis automatically every midnight. We can't do that for every PR, since there are quite strict rate limits that limit how many builds we can submit per day and per week (see [0]). The action (and the script) requires two environment variables to be set - $COVERITY_SCAN_TOKEN for authentication (can be found here [1]), and $COVERITY_SCAN_NOTIFICATION_EMAIL for sending the email notification when the build analysis is done. Originally this email used to be set to the email from the latest commit, but since the author of that commit might not even have permissions to see the Coverity report it's best to set it to one of the dbus-broker maintainers. Resolves: bus1#316 [0] https://scan.coverity.com/faq#frequency [1] https://scan.coverity.com/projects/dbus-broker?tab=project_settings
Let's make a full use of Coverity and submit the builds for analysis automatically every midnight. We can't do that for every PR, since there are quite strict rate limits that limit how many builds we can submit per day and per week (see [0]). The action (and the script) requires two environment variables to be set - $COVERITY_SCAN_TOKEN for authentication (can be found here [1]), and $COVERITY_SCAN_NOTIFICATION_EMAIL for sending the email notification when the build analysis is done. Originally this email used to be set to the email from the latest commit, but since the author of that commit might not even have permissions to see the Coverity report it's best to set it to one of the dbus-broker maintainers. Resolves: bus1#316 [0] https://scan.coverity.com/faq#frequency [1] https://scan.coverity.com/projects/dbus-broker?tab=project_settings
It's mostly prompted by https://bugs.launchpad.net/ubuntu/+source/dbus-broker/+bug/2015538/comments/5.
and I agree with @eslerm here.
It should be possible to borrow the action from
systemdordfuzzerto run that cron job daily on GitHub but to get it to work a secret namedCOVERITY_SCAN_TOKENshould be added to the repository: https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository. The token can be found at https://scan.coverity.com/projects/dbus-broker?tab=project_settings.Since Ubuntu is used on GHActions the AppArmor stuff should start being analyzed automagically too. Currently it's missing there.
In theory
dbus-brokercan be integrated as is and false positives can be suppressed manually there but it would be better to help coverity a bit with, say,c_assertand add#ifdef __COVERITY__.cc @mrc0mmand.
The text was updated successfully, but these errors were encountered: