The -mretpoline flag is not documented in the current versions of gcc
and clang and it is what causes scan-build to fail:
$ ./configure CC=clang | grep retpoline
checking whether C compiler accepts -mretpoline... yes
EXTRA_CFLAGS: -mretpoline -fstack-clash-protection -fstack-protector-strong
$ scan-build --status-bugs make
scan-build: Using '/usr/bin/clang-15' for static analysis
make -C src/lib
make[1]: Entering directory '/tmp/firejail/src/lib'
/usr/bin/../lib/clang/ccc-analyzer [...] -mretpoline [...] -c common.c -o common.o
gcc: error: unrecognized command-line option ‘-mretpoline’
make[1]: *** [../../src/prog.mk:16: common.o] Error 1
make[1]: Leaving directory '/tmp/firejail/src/lib'
make: *** [Makefile:59: src/lib] Error 2
scan-build: Analysis run complete.
scan-build: Removing directory '/tmp/scan-build-[...]' because it contains no reports.
scan-build: No bugs found.
Environment: clang 15.0.7-9 and gcc 13.1.1-1 on Artix Linux.
Note: NO_EXTRA_CFLAGS was added to work around this issue by causing all
of the flags in EXTRA_CFLAGS to be ignored.
Note2: -mretpoline was added on commit 4a99c8aa2 ("spectre support for
clang compiler", 2018-03-30) and NO_EXTRA_CFLAGS was added on commit
490918c35 ("fix make scan-build for debian 10 and arch", 2019-07-22).
See also commit 2c64d1fdd ("use AX_CHECK_COMPILE_FLAG to check for
spectre flags", 2019-06-21).
Closes#5509.
Kind of relates to #2661.
General changes:
* Use a single -q on update, as the output is not too long
* Use a single -q on install, to show all packages at once
GitLab-specific changes:
* Use `DEBIAN_FRONTEND=noninteractive` to reduce noise
* Use --no-install-recommends to avoid installing unnecessary packages
* Filter out uninteresting lines on install
Note: `DEBIAN_FRONTEND` does not appear to be needed in the default
GitHub runner container and not many packages are currently being
downloaded/installed in them, so do the above changes only jobs that use
custom Docker images.
Example log of it failing:
$ ./configure
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/tmp/build':
configure: error: C compiler cannot create executables
See `config.log' for more details
Having CI always run on WIP branches without having to open a PR
beforehand makes it easier to debug CI issues.
GitHub currently does not have any apparent limit for CI runs and there
are no project-specific secrets as far as I know, so it should be safe
to remove these restrictions.
Relevant lines from build_and_test[1]:
endpoint called ip address:port 1.1.1.1:1025, domain:
endpoint called ip address:port 54.185.253.63:43, domain: whois.pir.org.
##[error]StepSecurity Harden Runner: DNS resolution for domain dns.quad9.net. was blocked. This domain is not in the list of allowed-endpoints.
##[error]StepSecurity Harden Runner: DNS resolution for domain whois.pir.org. was blocked. This domain is not in the list of allowed-endpoints.
The relevant tests were added in the following commits:
* ef4409e7b ("added whois and dig profiles", 2018-08-30)
* 171898233 ("more profile fixes/testing", 2023-01-19)
Relates to #5439#5485.
[1] https://github.com/netblue30/firejail/actions/runs/4854586882/jobs/8652141329
To make debugging easier.
Use a separate shell script instead of just a make target to ensure that
it can safely run before ./configure and without having make installed.
For increased readability.
Note: `>` basically turns each newline into a space while `|` keeps
newlines as is. Both remove leading indentation.
Note2: On jobs using `apt-get install`, this commit moves package names
to their own line, to make it easier to compare which packages are being
installed across such jobs.
Due to step-security/harden-runner blocking access to
objects.githubusercontent.com.
Log from a recent run of CodeQL[1] [2]:
##[group]Setup CodeQL tools
Did not find CodeQL tools version 2.12.6 in the toolcache.
Downloading CodeQL tools from https://github.com/github/codeql-action/releases/download/codeql-bundle-20230403/codeql-bundle-linux64.tar.gz. This may take a while.
connect ECONNREFUSED 54.185.253.63:443
Waiting 13 seconds before trying again
connect ECONNREFUSED 54.185.253.63:443
Waiting 12 seconds before trying again
##[error]connect ECONNREFUSED 54.185.253.63:443
##[error]Unable to download and extract CodeQL CLI
Post job cleanup.
[...]
Mon, 10 Apr 2023 07:20:18 GMT:endpoint called ip address:port 140.82.112.4:443, domain: github.com.
Mon, 10 Apr 2023 07:20:20 GMT:endpoint called ip address:port 140.82.112.6:443, domain: api.github.com.
Mon, 10 Apr 2023 07:20:23 GMT:domain not allowed: objects.githubusercontent.com.
Mon, 10 Apr 2023 07:20:23 GMT:ip address dropped: 54.185.253.63
Mon, 10 Apr 2023 07:20:23 GMT:endpoint called ip address:port 140.82.112.4:443, domain: github.com.
Mon, 10 Apr 2023 07:20:23 GMT:endpoint called ip address:port 54.185.253.63:443, domain: objects.githubusercontent.com.
Mon, 10 Apr 2023 07:20:35 GMT:domain not allowed: api.snapcraft.io.
[1] https://github.com/netblue30/firejail/pull/5781
[2] https://github.com/netblue30/firejail/actions/runs/4655304231/jobs/8238131624
Use two spaces to separate sentences to make the source easier to read
in monospace fonts (such as when editing or reviewing it), especially
for longer paragraphs. The HTML output should still look the same.
Misc: This also removes source-level ambiguity regarding abbreviations
(such as "Mr.") vs the end of sentences and enables moving between
sentences in vi with `(` and `)`, for example.
Changes:
* Add titles to referenced issues/discussions
* Use relative links for paths
* Separate repo paths from installed paths
* Turn some links and items into lists to make them stand out
Ensure consistent line breaks around headings, lists and code blocks.
To make them more readable and also more portable (which could help when
previewing/converting files locally).
From the CommonMark Spec (version 0.30, published on 2021-06-19)[1]:
> 1.2 Why is a spec needed?
[...]
> 2. Is a blank line needed before a block quote or heading? Most
> implementations do not require the blank line. However, this can
> lead to unexpected results in hard-wrapped text, and also to
> ambiguities in parsing (note that some implementations put the
> heading inside the blockquote, while others do not). (John Gruber
> has also spoken in favor of requiring the blank lines.)[2]
>
> 3. Is a blank line needed before an indented code block?
> (`Markdown.pl` requires it, but this is not mentioned in the
> documentation, and some implementations do not require it.)
Fixes[3]:
* MD022 Headers should be surrounded by blank lines
* MD031 Fenced code blocks should be surrounded by blank lines
* MD032 Lists should be surrounded by blank lines
Environment: ruby-mdl 0.12.0-1 on Artix Linux.
[1] https://spec.commonmark.org/0.30/#why-is-a-spec-needed-
[2] http://article.gmane.org/gmane.text.markdown.general/2146
[3] https://github.com/markdownlint/markdownlint/blob/main/docs/RULES.md
