[automation] Auto-update linters version, help and documentation

[nvuillam]

[automation] Auto-update linters version, help and documentation

[github-actions]

🦙 MegaLinter status: ⚠️ WARNING

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ BASH	bash-exec	5		0	0.06s
✅ BASH	shellcheck	5		0	0.14s
✅ BASH	shfmt	5	0	0	0.5s
✅ COPYPASTE	jscpd	yes		no	5.15s
✅ DOCKERFILE	hadolint	123		0	24.2s
✅ JSON	eslint-plugin-jsonc	23	0	0	3.13s
✅ JSON	jsonlint	21		0	0.34s
✅ JSON	v8r	23		0	19.19s
✅ MAKEFILE	checkmake	1		0	0.0s
⚠️ MARKDOWN	markdownlint	255	0	11	8.25s
✅ MARKDOWN	markdown-link-check	255		0	6.78s
✅ MARKDOWN	markdown-table-formatter	255	0	0	40.97s
✅ OPENAPI	spectral	1		0	1.97s
⚠️ PYTHON	bandit	200		61	3.25s
✅ PYTHON	black	200	0	0	7.4s
✅ PYTHON	flake8	200		0	2.7s
✅ PYTHON	isort	200	0	0	1.05s
✅ PYTHON	mypy	200		0	15.47s
✅ PYTHON	pylint	200		0	17.9s
⚠️ PYTHON	pyright	200		352	28.86s
✅ PYTHON	ruff	200	0	0	0.59s
✅ REPOSITORY	checkov	yes		no	46.79s
✅ REPOSITORY	git_diff	yes		no	0.47s
⚠️ REPOSITORY	grype	yes		1	12.41s
✅ REPOSITORY	secretlint	yes		no	10.6s
✅ REPOSITORY	trivy	yes		no	33.01s
✅ REPOSITORY	trivy-sbom	yes		no	1.69s
⚠️ REPOSITORY	trufflehog	yes		1	30.95s
✅ SPELL	cspell	665		0	38.77s
✅ SPELL	lychee	335		0	4.89s
✅ XML	xmllint	3	0	0	0.51s
✅ YAML	prettier	160	0	0	6.27s
✅ YAML	v8r	102		0	222.65s
✅ YAML	yamllint	161		0	2.1s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[echoix]

@nvuillam I've been searching for the last hour (at the start of writing this message) for the last three hours about the errors with phive... it's been quite recurring and it's not that reliable (compared to everything else except lychee with flaky sites).

phar-io/phive#384 (comment)

phar-io/phar.io#108 (comment)

And a link back to one of your issues : phar-io/phive#321 (comment)

So overall, the phar.io website (code here https://github.com/phar-io/phar.io) is quite hacky, and there release, is it is the same as
https://github.com/phar-io/phar.io/blob/50f4b90b6f07259cec1dd059d3cb56aa9c7f54bf/php/release.php

is really just taking back the GitHub release for us, but in a Man in the Middle way.

Instead of trying to download from their website, that will redirect and somehow get back to us downloading from a GitHub release, why don't we just directly download from the GitHub release https://github.com/phar-io/phive/releases/tag/0.15.2? We already know how to use the API URLs, and we know that there is a way to point to the latest release, and download the file if we already know the name, like

megalinter/flavors/java/Dockerfile

Line 335 in ee201af

&& curl --retry 5 --retry-delay 5 -sSLO https://github.com/pinterest/ktlint/releases/latest/download/ktlint && \

I imagine we would use up our own 1000 requests per hour of api, or not (maybe the links with releases/latest/download/ don't count since it's now a api.github.com url? We would need to check the headers), but I imagine we are trusting GitHub way more than that website.

Also, here, in the root of the PHP descriptor, we set an environment variable for exposing our GITHUB_TOKEN directly, and it is not needed there at all.

https://github.com/oxsecurity/megalinter/blob/ee201af532c22ac013bc0d18d27545c757d6e4f5/megalinter/descriptors/php.megalinter-descriptor.yml#L21-36

When it might be used (I find it a bit powerful to have that token), it is added for that specific tool, like

megalinter/megalinter/descriptors/php.megalinter-descriptor.yml

Lines 134 to 137 in ee201af

	install:
	dockerfile:
	- |
	RUN GITHUB_AUTH_TOKEN="$(cat /run/secrets/GITHUB_TOKEN)" && export GITHUB_AUTH_TOKEN && phive --no-progress install psalm -g --trust-gpg-keys 8A03EA3B385DBAA1,12CE0F1D262429A5

Finally, in the list of key servers in the command

https://github.com/oxsecurity/megalinter/blob/ee201af532c22ac013bc0d18d27545c757d6e4f5/megalinter/descriptors/php.megalinter-descriptor.yml#L28-31

• ❌ The keyserver.pgp.com server doesn't have the key for 0x9D8A98B29B2D5D79
• ❌ The sks-keyservers.net servers are out since 2019 https://unix.stackexchange.com/questions/656205/sks-keyservers-gone-what-to-use-instead
• ✅ The pgp.mit.edu has an entry for 0x9D8A98B29B2D5D79
• ✅ The keyserver.ubuntu.com (via website) has entries for 0x9D8A98B29B2D5D79, I assume they work with the hkps:// uri too.

It seems like the a most commonly used reference is the keys.openpgp.org (since 2019) not in our list. It contains an entry for 0x9D8A98B29B2D5D79. It confirms the emails of the keys uploaded instead of allowing anybody and multiple signatures attached, that was big CVE in 2019.

[echoix]

Oh, and my additionnal commit to the python version file out of sync was lost in the force-push

[nvuillam]

@echoix use of phive is an inheritance of super-linter, if you have ways more stable please feel free to use them :)

Maybe php guru @llaville has some opinion? :)

[llaville]

Getting PHAR version has changed : read at page https://phar.io/#Install the new way

Confirmed if you blame source code at https://github.com/phar-io/phar.io/blame/master/html/index.html#L74 you'll see this commit phar-io/phar.io@61810e1 that confirmed your previous comments

Hope it will help