Extension management 2018 feedback/Finding

Extensions that have passed a security review should be searchable
I typically browse through mediawiki.org to find extensions to install. I'd like to be able to narrow my search results to extensions that have passed a security review. Legoktm (talk) 06:04, 16 May 2018 (UTC)

Endorsements

 * Legoktm (talk) 05:21, 16 May 2018 (UTC)
 * Ladsgroup (talk) 11:10, 23 May 2018 (UTC)
 * Smalyshev (WMF) (talk) 00:06, 24 May 2018 (UTC)
 * Cindy.cicalese (talk) 21:47, 3 June 2018 (UTC)

Comments

 * From the discussion we had during the Barcelona Hackathon:
 * "Security reviewed" is only one of the attributes that should be available. There could be any number of other "tags" that should be available for filtering, e.g. user ratings, test coverage, keywords from extension.json, etc.
 * "Security reviewed" in particular raises a number of questions that -to quote - "lead down a rabbit hole": Who is allowed to add the tag, how is it proven (link to a report on trusted source?), is a signed package of the reviewed extension provided?
 * It is understood that some of these imply "stretch goals", which would be projects of their own and certainly are not needed in a first version

--F.trott (talk) 19:28, 19 May 2018 (UTC)


 * It should probably also specify which version/tag was reviewed. Smalyshev (WMF) (talk) 00:06, 24 May 2018 (UTC)
 * Absence of such review would be seen as "this is a bad extension", even though it likely means "there aren't enough reviewers". Plus this discourages major refactoring (extension would require another review afterwards). Edward Chernenko (talk) 23:12, 6 June 2018 (UTC)

Central catalogue of extensions
There should be a central catalogue of extensions that is accessible via an API. This would allow people to build tools that enable automatic installation.

In addition to extension name and description, it should include the download location and method, including tarballs, git (Gerrit, Github, etc.), composer (from packagist).

It should be possible for other organisations to curate their own catalogues, and any usage of the catalogue in MediaWiki should be configurable. F.trott (talk) 08:12, 17 May 2018 (UTC)

Endorsements

 * F.trott (talk) 08:12, 17 May 2018 (UTC)
 * +1 Jonas Kress (WMDE) (talk) 09:29, 17 May 2018 (UTC)
 * Legoktm (talk) 18:01, 19 May 2018 (UTC)
 * Cindy.cicalese (talk) 20:44, 3 June 2018 (UTC)

Comments

 * Are you're asking for is something similar to the ExtensionDistributor API? But that it would automatically download and install it? Legoktm (talk) 17:33, 18 May 2018 (UTC)
 * Not really. I don't need a service to download stuff. I'd just like a catalogue that an external tool (e.g. an Extension Manager) could access. Also ExtensionDistributor has several shortcomings: It only supports one source (gerrit), it only supports git dumps, it requires from extensions to maintain versions per MW REL branch. (As far as I remember, which may be outdated. It's off topic, but if there is an easy approach to teach ExtensionDistributor to do any of the following I would be happy for links: load versions according to semver; load something else than git-dumps from gerrit; at least run build scripts before tar-balling.)
 * Got it. I've boldly changed the description, please edit/revert if it's inaccurate :) Legoktm (talk) 18:00, 19 May 2018 (UTC)
 * If we're talking about remote installation, there should be signing scheme, that allows to ensure the extension code is genuine. Of course if it is loaded from git then signed tag may be enough, provided that there's a list of authorized signers with public keys somewhere. Smalyshev (WMF) (talk) 00:06, 24 May 2018 (UTC)

Supported MediaWiki versions should be listed
MediaWiki knows at least two kinds of release versions that receive bugfixes and security patches: "Current Stable" and "Current LTS". An extension should specify which version of MediaWiki is actively supported. If I have a MW 1.31 I need to know which version of an extension should be used to benefit from bugfixes and security patches. Osnard (talk) 15:07, 19 May 2018 (UTC)

Endorsements

 * Osnard (talk) 15:07, 19 May 2018 (UTC)
 * Cindy.cicalese (talk) 20:44, 3 June 2018 (UTC)

Extension quality metadata should be collected/searchable
When searching for an appropriate extension to solve a problem, a variety of metadata would be useful:


 * Has the extension passed a security review?
 * Has the extension passed (unit, integration, acceptance . . .) tests?
 * Is the extension actively maintained?
 * Who is the maintainer of the extension?
 * What MediaWiki versions does the extension work with?
 * What extensions depend upon this extension?
 * What extensions extend the functionality of this extension?
 * What extensions is this extension incompatible with?
 * How many wikis are known to use this extension?
 * User reviews/ratings

This will need to be done per extension version. Ideally, extension versions would be signed. Ideally, as much of this information as possible would be machine-generated rather than reported by the extension owner.

Based upon the information above, it may be useful to categorize extensions in some way: fully supported with a seal of approval, partially supported, etc. Cindy.cicalese (talk) 20:42, 3 June 2018 (UTC)

Endorsements

 * Cindy.cicalese (talk) 20:42, 3 June 2018 (UTC)
 * F.trott (talk) 22:34, 5 June 2018 (UTC)

Comments

 * This item is based in part upon discussion at the Barcelona Hackathon.

Generate mediawiki.org extension infobox information automatically from extension.json
This may be rendered unnecessary by an extension catalog. But, it might still be useful depending upon how this is done. Cindy.cicalese (talk) 20:47, 3 June 2018 (UTC)

Endorsements

 * Cindy.cicalese (talk) 20:47, 3 June 2018 (UTC)
 * F.trott (talk) 22:34, 5 June 2018 (UTC) -- That'd be great. It's super error prone to maintain that infobox by hand.
 * Edward Chernenko (talk) 23:16, 6 June 2018 (UTC)

Comments

 * This item is based upon discussion at the Barcelona Hackathon.