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)[reply]

Endorsements

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

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)[reply]

It should probably also specify which version/tag was reviewed. Smalyshev (WMF) (talk) 00:06, 24 May 2018 (UTC)[reply]
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)[reply]
I am not sure how this could be done efficiently. However if it is done it should probably be added via a flag to "extension.json" and be connected to a particular revision. Moreover the review should expire after some time. --[[kgh]] (talk) 14:00, 20 June 2018 (UTC)[reply]

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)[reply]

Endorsements

F.trott (talk) 08:12, 17 May 2018 (UTC)[reply]
+1 Jonas Kress (WMDE) (talk) 09:29, 17 May 2018 (UTC)[reply]
Legoktm (talk) 18:01, 19 May 2018 (UTC)[reply]
Cindy.cicalese (talk) 20:44, 3 June 2018 (UTC)[reply]
[[kgh]] (talk) 14:02, 20 June 2018 (UTC)[reply]
Nischayn22 (talk) 17:33, 10 July 2018 (UTC)[reply]
...

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)[reply]
- 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)[reply]
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)[reply]
I think we should use Wikidata for this. We have heaps of properties over there and then it would also make sense to use the data. Currently all extensions are also tracked at Wikidata but I dunno for what reason. --[[kgh]] (talk) 14:02, 20 June 2018 (UTC)[reply]

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)[reply]

Endorsements

Osnard (talk) 15:07, 19 May 2018 (UTC)[reply]
Cindy.cicalese (talk) 20:44, 3 June 2018 (UTC)[reply]
[[kgh]] (talk) 14:05, 20 June 2018 (UTC)[reply]
...

Comments

We also have "Current legacy". I am not sure how this could be automated. --[[kgh]] (talk) 14:05, 20 June 2018 (UTC)[reply]

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)[reply]

Endorsements

Cindy.cicalese (talk) 20:42, 3 June 2018 (UTC)[reply]
F.trott (talk) 22:34, 5 June 2018 (UTC)[reply]
[[kgh]] (talk) 14:06, 20 June 2018 (UTC)[reply]
...

Comments

This item is based in part upon discussion at the Barcelona Hackathon.
Again, I think we should use Wikidata as central data storage. --[[kgh]] (talk) 14:06, 20 June 2018 (UTC)[reply]

Generate mediawiki.org extension infobox information automatically from extension.json

Tracked in Phabricator
Task T209084

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)[reply]

Endorsements

Cindy.cicalese (talk) 20:47, 3 June 2018 (UTC)[reply]
F.trott (talk) 22:34, 5 June 2018 (UTC) -- That'd be great. It's super error prone to maintain that infobox by hand.[reply]
Edward Chernenko (talk) 23:16, 6 June 2018 (UTC)[reply]
[[kgh]] (talk) 14:09, 20 June 2018 (UTC)[reply]
Nischayn22 (talk) 17:33, 10 July 2018 (UTC)[reply]
...

Comments

This item is based upon discussion at the Barcelona Hackathon.
We already do this for needs dbupdate. The info should probably piped trough Wikidata to have only one point of data retrieval. --[[kgh]] (talk) 14:09, 20 June 2018 (UTC)[reply]

Way to announce and publish new extensions and features

Tracked in Phabricator
Task T209085

Currently when we create a new extension/skin/script, nobody gets to know about it. Same is the case when adding a new feature to an existing extension. There should be a way to register a new extension somewhere and then it gets published in a digest mail to the mediawiki-l mailing list. New features could be announced in a similar way. This should be automated to some extent probably by using extension.json. Nischayn22 (talk) 07:12, 12 June 2018 (UTC)[reply]

Endorsements

Nischayn22 (talk) 07:12, 12 June 2018 (UTC)[reply]
Edward Chernenko (talk) 14:08, 14 June 2018 (UTC)[reply]
[[kgh]] (talk) 14:10, 20 June 2018 (UTC)[reply]
...

Comments

Also see What's New Nischayn22 (talk) 07:12, 12 June 2018 (UTC)[reply]

We have the newsletter functionality so I think it should be done via this channel instead of creating some page somethere. Moreover who will manage this newsletter or "way"? --[[kgh]] (talk) 14:10, 20 June 2018 (UTC)[reply]
- I think it should be automated. The extension.json file could have a "whats new" field where we can add some info (similar to how android apps have a What's New). This should be browseable on mw.org and there should also be a way to subscribe for this.Nischayn22 (talk) 17:32, 10 July 2018 (UTC)[reply]