It reports hundreds of issues, lots of them with critical severity.
The GitLab UI allows dismissing them one-by-one very quickly,
but I'm not a good person to do that.
Let's try to have a better signal/noise ratio for this first iteration.
According to
https://docs.gitlab.com/ee/user/application_security/dependency_scanning/,
"dependency scanning lets you know if your application uses an external (open
source) library that is known to be vulnerable".
AppArmor is not the kind of project that benefits from it: we don't link
statically against our dependencies, nor bundle them into released
artifacts.
libtool generates horrible shell code, you don't want to see the
shellcheck results for it ;-)
This is only relevant for local testing (not in CI) because these files
don't exist in git and therefore don't exist when the shellcheck CI job
runs.
This should avoid unconsciously introducing regressions wrt. best practices for shell code.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/842
Acked-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
- Assume /bin/sh has dash's features and ignore corresponding false positives
- Exclude parser/tst, tests and utils/test directories: they have tons
of shellcheck violations but they don't *directly* impact our users.
Let's first focus on code that runs on production systems.
- Exclude rc.apparmor.slackware: I don't know anything about Slackware's
/bin/sh.
The previous code happened to work only because we always pass either 0 or 1
arguments to these functions. If we ever passed them 2+ arguments,
unexpected things would happen.
For details, see https://www.shellcheck.net/wiki/SC2145
Found by rpmlint.
I propose this fix for 3.0 and master to keep the file in sync.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/846
Acked-by: Approved-by: intrigeri <intrigeri@boum.org> for 3.0 and master
Merged-by: Christian Boltz <gitlab2@cboltz.de>
Even if there are Red Hat / Fedora systems that use AppArmor, chances are that
they use systemd, and not an initscript. And even if somehow they do use an
initscript, chances are that it's not this one, as last time it has seen
a non-cosmetic change was in 2007.
* Don't call aa_log_action_end after calling aa_log_failure_msg, because
a generic "failure" message will be outputted twice by the Red Hat and
Slackware init scripts.
* Don't append a space to the initial output from apparmor_stop, in line
with other usages of aa_log_daemon_msg.
Debian doesn't use the init script provided in parser/rc.apparmor.debian,
instead preferring to patch parser/rc.apparmor.functions and call its
functions directly in an init script they maintain themselves (something
they have done since 2006). Since this script is no longer used, and
currently doesn't work correctly anyway because it lacks definitions for
several functions that are relied upon in parser/rc.apparmor.functions,
it can be removed.
If `apparmor_parser -N` (in `profiles_names_list()`) fails,
`aa-remove-unknown` possibly gets an incomplete list of profiles in
`/etc/apparmor.d/` and therefore might remove more profiles than it
should.
Replace the `profiles_names_list()` call with a direct `apparmor_parser`
call, and abort aa-remove-unknown if it exits with $? != 0
Before:
```
aa-remove-unknown -n
AppArmor parser error for /etc/apparmor.d/broken in profile /etc/apparmor.d/broken at line 1: syntax error, unexpected TOK_ID, expecting TOK_OPEN
Would remove 'delete_me'
```
After:
```
./aa-remove-unknown -n
AppArmor parser error for /etc/apparmor.d in profile /etc/apparmor.d/zbroken at line 1: syntax error, unexpected TOK_ID, expecting TOK_OPEN
apparmor_parser exited with failure, aborting.
```
And of course, after fixing the broken profile:
```
./aa-remove-unknown -n
Would remove 'delete_me'
```
Also drop the now-unused profiles_names_list() from rc.apparmor.functions - the only user was aa-remove-unknown.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/836
Acked-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
If apparmor_parser -N (in profiles_names_list()) fails,
aa-remove-unknown possibly gets an incomplete list of profiles in
/etc/apparmor.d/ and therefore might remove more profiles than it
should.
Replace the profiles_names_list() call with a direct apparmor_parser
call, and abort aa-remove-unknown if it exits with $? != 0
Before:
```
aa-remove-unknown -n
AppArmor parser error for /etc/apparmor.d/broken in profile /etc/apparmor.d/broken at line 1: syntax error, unexpected TOK_ID, expecting TOK_OPEN
Would remove 'delete_me'
```
After:
```
./aa-remove-unknown -n
AppArmor parser error for /etc/apparmor.d in profile /etc/apparmor.d/zbroken at line 1: syntax error, unexpected TOK_ID, expecting TOK_OPEN
apparmor_parser exited with failure, aborting.
```
And of course, after fixing the broken profile:
```
./aa-remove-unknown -n
Would remove 'delete_me'
```
Library versioning requires we keep these changes in sync. Since the
3.0.4 release bumped revision we need to do it here as well.
Signed-off-by: John Johansen <john.johansen@canonical.com>
