Set `persist-credentials: false` for actions/checkout.
By default, using `actions/checkout` causes a credential to be persisted on
disk. Subsequent steps may accidentally publicly persist the credential, e.g.
by including it in a publicly accessible artifact via actions/upload-artifact.
However, even without this, persisting the credential on disk is non-ideal
unless actually needed.
Link: https://docs.zizmor.sh/audits/#artipacked
By default, Dependabot does not perform any cooldown on dependency updates.
In other words, a regularly scheduled Dependabot run may perform an update
on a dependency that was just released moments before the run began.
This presents both stability and supply-chain security risks.
To mitigate these risks, explicitly set Dependabot cooldown period to 7 days.
Link: https://docs.zizmor.sh/audits/#dependabot-cooldown
Given that ERRNO_IS_SECCOMP_FATAL() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_SECCOMP_FATAL() are the
values returned by external libseccomp function seccomp_load() which is
not expected to return any positive values, but let's be consistent
anyway and move ERRNO_IS_SECCOMP_FATAL() invocations to the branches
where the return values are known to be negative.
Given that ERRNO_IS_DEVICE_ABSENT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_DEVICE_ABSENT()
are the values returned by external cryptsetup functions
sym_crypt_init_by_name() and sym_crypt_deactivate_by_name() which are
not expected to return any positive values, but let's be consistent
anyway and move ERRNO_IS_DEVICE_ABSENT() invocations to the branches
where the return values are known to be negative.
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_PRIVILEGE() are the values
returned by procfs_get_pid_max() and procfs_get_threads_max() which are
not expected to return any positive values, but let's be consistent
anyway and move ERRNO_IS_PRIVILEGE() invocations to the branches where
the return values are known to be negative.
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_PRIVILEGE() is the value
returned by json_parse_file() which is not expected to return any positive
values, but let's be consistent anyway and move the ERRNO_IS_PRIVILEGE()
invocation to the branch where the return value is known to be negative.
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_PRIVILEGE() is the value
returned by access_fd() which is not expected to return any positive
values, but let's be consistent anyway and move the ERRNO_IS_PRIVILEGE()
invocation to the branch where the return value is known to be negative.
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_PRIVILEGE() are the values
returned by set_oom_score_adjust() and set_coredump_filter() which are
not expected to return any positive values, but let's be consistent
anyway and move the ERRNO_IS_PRIVILEGE() invocations to the branches
where the return values are known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_NOT_SUPPORTED() are the
values returned by btrfs_subvol_make_fd() which is not expected to
return any positive values, but let's be consistent anyway and move
ERRNO_IS_NOT_SUPPORTED() invocations to the branches where
the return values are known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_NOT_SUPPORTED() are the
values returned by efi_get_variable_string() and efi_set_variable()
which are not expected to return any positive values, but let's be
consistent anyway and move ERRNO_IS_NOT_SUPPORTED() invocations
to the branches where the return values are known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by remount_idmap() which is not expected to return
any positive values, but let's be consistent anyway and move the
ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by efi_loader_get_entries() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by home_update_quota_auto() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by find_tpm2_auto_data() which is not expected to return
any positive values, but let's be consistent anyway and move the
ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by efi_loader_get_entries() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the
value returned by varlink_connect_address() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_DISCONNECT() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the value
returned by dns_transaction_emit_tcp() and dns_transaction_emit_udp()
which are not expected to return any positive values, but let's be
consistent anyway and move the ERRNO_IS_DISCONNECT() invocation
to the branch where the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_DISCONNECT() are the
values returned by instance_from_socket(), socket_load_service_unit(),
and service_set_socket_fd() which are not expected to return any
positive values, but let's be consistent anyway and move
ERRNO_IS_DISCONNECT() invocations to the branches where the return
values are known to be negative.
The previous definition was not quite appropriate for the library code
because it relied on the message domain set by textdomain() invocation
which is not necessarily the same message domain defined in
GETTEXT_PACKAGE macro.
The only code that uses _() so far is located in pam_systemd_home.c.
Fixes: 20f56fddcd ("Add gettext support")
Given that ERRNO_IS_PRIVILEGE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_PRIVILEGE() are the values
returned by read_one_line_file() which can legitimately return positive
values without errno semantics, so fix this by moving ERRNO_IS_PRIVILEGE()
invocations to the branches where the return values are known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the value
returned by manager_recv() which can legitimately return 1 without errno
semantics, so fix this by moving ERRNO_IS_DISCONNECT() invocation to the
branch where the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the value
returned by bus_socket_process_watch_bind(), bus_socket_process_opening(),
and bus_socket_process_authenticating() which can legitimately return
positive values without errno semantics, so fix this by moving the
ERRNO_IS_DISCONNECT() invocation to the branch where the return value
is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the value
returned by socket_acquire_peer() which can legitimately return 1
without errno semantics, so fix this by moving ERRNO_IS_DISCONNECT()
invocation to the branch where the return value is known to be negative.
Given that ERRNO_IS_RESOURCE() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_RESOURCE() is the value
returned by recurse_dir_at() which can legitimately return positive
values without errno semantics, so fix this by moving the ERRNO_IS_RESOURCE()
invocation to the branch where the return value is known to be negative.
In etc_hosts_lookup_by_address(), make sure the canonical name of the given
address is returned first in the list of names that address resolves to.
Resolves: #25088
quality_check_password() used to return the same value 0 in two
different cases: when pwq_allocate_context() failed with a
ERRNO_IS_NOT_SUPPORTED() code, and when pwquality_check() rejected the
password. As result, users of quality_check_password() used to report
password weakness also in case when the underlying library was not
available.
Fix this by changing quality_check_password() to forward the
ERRNO_IS_NOT_SUPPORTED() code to its callers, and change the callers
to handle this case gracefully.
Starting with commit acc1954a03, udevadm verify also checks token
delimiters, which are not necessarily a matter of udev rules syntax,
but rather a question of style and readability. Mention that in the
documentation to avoid confusion.
Suggested-by: Martin Wilck <mwilck@suse.com>
Complements: acc1954a03 ("udev-rules: check token delimiters")
When udevadm verify is invoked by an analyzer tool like rpminspect
to verify individual udev rules files, the summary just clutters the
output, so provide an option to turn the summary off.
When an argument specified to udevadm verify is a directory,
verify all *.rules files in that directory.
Suggested-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
When udevadm verify is given an argument that doesn't point to an
existing file, there used to be two diagnostics messages, the first one
at a warning level, and the second one at an error level:
$ build/udevadm verify /no/such/directory
Failed to open /no/such/directory, ignoring: No such file or directory
Failed to parse rules file /no/such/directory: No such file or directory
Fix this by issuing just the error message.
When udev_rules_parse_file() is called by udevadm verify, issue warnings
about the following conditions in udev rules:
* the first token in the rule is preceded with a comma
* the last token in the rule is followed by a comma
* there is no comma between tokens
* there is no whitespace between tokens
* there is more than a single comma between tokens
* there is whitespace between a token and a comma
* there is no whitespace after comma
Move udev_check_rule_line() invocation from udev_rule_file_get_issues()
to udev_rules_parse_file(), invoke udev_check_rule_line() only when
udev_rules_parse_file() is called by udevadm verify.
Subsequent commits are going to perform more checks invoked from
udev_rules_parse_file().
Fix check for conflicting and duplicate expressions of types that
support alternative patterns.
Fixes: 3ec58d0cd8 ("udev-rules: check for conflicting and duplicate expressions")
For those token types that support matching of alternative patterns,
their token values are interpreted as nulstr, so make sure the parser
does the right thing and makes these token values terminated by two
subsequent NULs so they could be safely interpreted as nulstr.
Before this fix, the following rules would result to "echo foo" invocation:
ENV{foo}=", RUN"
ENV{foo}=="bar", RUN+="echo foo"
because the value of `ENV{foo}` is treated as nulstr, and it used to match
against alternative patterns, in this case `bar`, `, RUN`, and `="echo foo`.
Fixes: 25de7aa7b9 ("udev: modernize udev-rules.c")
Log an error when a rule line contains conflicting match expressions, e.g.
NAME=="value", NAME!="value"
Log a warning when a rule line contains duplicate expressions, e.g.
NAME=="value", NAME=="value"
When a rules contains several LABEL tokens, the parser used to silently
discard all of them besides the last one without any diagnostics at all.
It's time to break the vow of silence and let the parser issue a warning.
When udevadm verify is invoked without positional arguments and loads
all rules files from the system like the udev daemon does, this option
can be used to operate on files underneath the specified root path.
When udevadm verify is invoked without positional arguments, that is,
when no udev rules files are specified, load all rules files from the system
like the udev daemon does, and verify them.
When udev rules file ends with a line continuation, the parser
used to silently ignore the line without any diagnostics at all.
It's time to break the vow of silence and let the parser issue some
error diagnostics.
Although udev rules are already being checked by rule-syntax-check.py
script, also check them using udevadm verify which performs more
thorough checks.
When built without blkid, then udev-builtin-blkid is not built,
and the verifier warns about the unknown builtin:
60-persistent-storage.rules:114 Unknown builtin command: blkid --hint=session_offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}
60-persistent-storage.rules:117 Unknown builtin command: blkid --noraid
60-persistent-storage.rules:120 Unknown builtin command: blkid
60-persistent-storage.rules: udev rules check failed
We seem to have no tool to verify udev rule files. There is a simple
udev rules syntax checker in the tree, test/rule-syntax-check.py, but
it is too simple to detect less trivial issues not detected by udev,
e.g. redundant comparisons (#26593) or labels without references.
Such a tool would be beneficial not only for maintaining udev rules
distributed along with udev, but also and even more so for maintaining
third party udev rules that are more likely to have issues with syntax
and semantic correctness.
Implement a udev rules syntax and semantics checker in the form of
'udevadm verify [OPTIONS] FILE...' command that is based on
udev_rules_parse_file() interface and would apply further checks
on top of it in subsequent commits.
Resolves: #26606
Traditionally, all issues found in udev rules by udev_rules_parse_file()
are logged and ignored, so there was no mechanism to propagate the
information about these issues back to the caller.
Introduce such a mechanism by adding a new member to UdevRuleFile.
This new member is a bitmask describing which log levels were used
in messages logged with regards to the rule file.
This mechanism is going to be used by udevadm verify in subsequent
commits.
Starting with commit ed88bcfb7c,
udev_rules_parse_file() silently skips files it fails to open with
ENOENT error, e.g. when they are broken symlinks. As this behavior is
undocumented and it seems to be unintended, let's treat ENOENT like any
other error. This change would also simplify the implementation of the
udev rules syntax checker mentioned in #26606.
udev_rules_load(), the only user of udev_rules_parse_file(), is not
affected by this change because it essentially ignores the value
returned by the latter, the only visible difference would be a log
message issued for every udev rules file that couldn't be open because
of ENOENT.
Fixes: ed88bcfb7c ("Be more careful when checking for empty files")
Starting with commit 2f3b873a49, when the path contains a specifier
and the argument is omitted, tmpfiles used to perform specifier
expansions twice: first specifier expansion was applied to the path
itself, and afterwards the result of the first expansion was used
in the constructed argument and expanded once again.
Resolves: #26244
Fixes: 2f3b873a49 ("tmpfiles: copy/link /usr/share/factory/ files when the source argument is omitted")
Make sure the argument of "C" type undergoes specifier expansion
before it's checked for validity. In particular, starting with
commit ce610af143, the check for path existence used to fail
in case of presence of any specifier in the argument.
Also, starting with commit 2f3b873a49, when the path contains
a specifier and the argument is omitted, tmpfiles used to perform
specifier expansions twice: first specifier expansion was applied
to the path itself, and afterwards the result of the first expansion
was used in the constructed argument and expanded once again.
Finally, starting with commit 849958d1ba, when the argument begins
with %h specifier, tmpfiles used to complain that the source path
is not absolute.
Resolves: #25381
Fixes: ce610af143 ('tmpfiles: in C lines, make missing source graceful error')
Fixes: 2f3b873a49 ('tmpfiles: copy/link /usr/share/factory/ files when the source argument is omitted')
Fixes: 849958d1ba ('tmpfiles: add new "C" line for copying files or directories')
Dmitry V. Levin