Extensions that are not on the list shouldn't be allowed to be installed (since such option isn't exposed via UI)

The list isn't that safe really. Updates aren't vetted, only the initial addition:

https://github.com/FreshRSS/Extensions/blob/2ca8d82b0868014d6289cb25d9758913f68a6895/generate.php
https://github.com/FreshRSS/Extensions/blob/2ca8d82b0868014d6289cb25d9758913f68a6895/.github/workflows/generate.yml

But if there's no UI option to input a URL then of course code to handle it ranges somewhere between not making sense and being a security risk.

The list isn't that safe really. Updates aren't vetted, only the initial addition:

I'm aware, maybe something can be done about this?
(if it's the administrator installing the extension and not an XSS payload, then maybe an extra warning before installing that the extension could be potentially unsafe[1] would be good enough?)

[1]: only when the extension is outside of https://github.com/FreshRSS/Extensions

But if there's no UI option to input a URL then of course code to handle it ranges somewhere between not making sense and being a security risk.

It requires slightly more effort to get RCE if the malicious extension has to be on the list.
Or the attacker can just rely on some vulnerable extension that's already in the list if any.

I'm aware, maybe something can be done about this?

Unfortunately I don't think so. That would result in too much automated PR noise that nobody wants to deal with.[1] The only other truly functional model is how it was before, namely that an actual human being who cares makes a PR. But in that case you miss out on knowing about most updates. So it's pretty much a choice between how it was and how it is. There's a similar discussion over here btw, in case anyone comes up with something workable.

Perhaps Copilot could provide AI slop reviews of the changes, but the added value of such a thing is likely minimal if not counterproductive by giving a false sense of security.

[1] Though at the moment it seems okay, I suppose.

We probably don't need this if we only allow installing extensions from the list.

Has the same effect, but just for clarity

I'm not sure if this is necessary, it probably won't break any extensions, but I don't see the point.
It could remove files needed by the extension in some cases.

I think it's a bad assumption to make that required source code isn't also contained within test, tests or perhaps spec. Those directory names are somewhat generic.

As someone who cloned gigantic .git (several GB) folders for a simple script with 10 lines of code as well as received more API keys / passwords than I can count in my career, it felt like the right thing to do. The list is certainly not perfect (and I already broke an extension as I had the vendor folder on the list 😄) but it's a starting point. I would prefer a curated list of updates with vetted releases, but that requires some manpower. Very few of the plugins use the GitHub / GitLab releases at all, and I have to download the full source of the plugin instead of a "cleaned" release .ZIP.

As someone who cloned gigantic .git (several GB) folders for a simple script with 10 lines of code

Fair enough

The list is certainly not perfect (and I already broke an extension as I had the vendor folder on the list 😄)

Which is why it doesn't make sense to include generic names like the previously mentioned test, tests, spec or vendor

edit: was it this one? https://github.com/kapdap/freshrss-extensions/tree/master/xExtension-ClickableLinks

And getting rid of entire file extensions also seems like a little too much

But I'm okay with this part:

	// VCS and CI
			'.git',
			'.gitignore',
			'.gitattributes',
			'.gitmodules',
			'.gitlab-ci.yml',
			'.travis.yml',
			'appveyor.yml',
			'.github',
			'.circleci',

and

                        'node_modules',
			'.idea',
			'.vscode',
			'composer.phar',
			'yarn.lock',
			'package-lock.json',

			'.DS_Store',
			'Thumbs.db',

We should keep the list as small as possible.

You can do a shallow clone in Git btw.

Could the request timeout if there are a lot of extensions and the server is slow?
Maybe update progress should be shown via JS and each extension updated in individual requests

A timeout might happen. The updateallAction was more a quick addition than a finely planned out solution. In my testing, I never saw any issues, and most plugins are never / rarely updated and relatively small:

I've considered it "good enough" for a first implementation, but this and the single update function could certainly be improved with regard to timeouts or batch processing with GUI updates. The code could be on a self-hosted GitLab / Gitea instance located on the moon, running on grandma's first computer for all we know.

The commit date of extensions like YouTube Video Feed, Title-Wrap, ReadingTime etc. isn't correct because they are all in the same repository. (neither is the size)

The commit date of extensions like YouTube Video Feed, Title-Wrap, ReadingTime etc. isn't correct because they are all in the same repository. (neither is the size)

I'm aware of that. My point is that updating 5 extensions per 6 months with each being only a few KB / MB shouldn't be an issue (for now).

Hopefully not

The URL should be validated with checkUrl() from lib_rss.php