Forbidding self publication of extensions on e.x.o using the attachment way?

Development
1

Hi devs,

We currently allow creating manually an extension page on e.x.o and attaching a binary for the version. See for example:

These 2 examples are examples of valid extensions and they provide their sources, which is good.

Over the years we’ve had a lot of other extensions created witha a XAR without any source and with very little or no documentation. And more importantly no way to discuss with the author, to ask questions or improve the documentation.

So the questions arises of whether we should continue allowing this or not.

The problems I see:

  • Security issue: It’s easy for someone to publish a XAR update with some malicious code since there’s no oversight
  • Quality issue: There’s no contact info asked and we can’t discuss with the person about the quality of the doc or the quality of the extension. We could go to the source when it’s indicated, find some contact info there, but it’s a pain and hard to do.

So I think we should instead propose only 2 ways to contribute a new extension:

  1. By developing a contrib extension (i.e. following contrib.xwiki.org rules)
  2. By requesting a publication. For example by asking to post on a new thread on the forum, explain the extension, etc. This would allow some oversight and provide a means to discuss with the author.

We’d still need to decide how we prevent attaching the sources on a exo page but I don’t see a big issue for achieving this.

WDYT?

Thanks

2

The first one is not a valid extension, so probably not a very good example.

3

Note: OTOH It’s really cool to see contributions, so we need to be careful to not stop that, and to encourage it.

1 Like
4

I think it is a good example actually of the quality issue I’m mentioning. It’s published as an extension so it’s supposed to be an extension. It may just be the publisher doesn’t know how to make it a real extension, and we need to discuss it with him/her.

5

Other examples:

6

Honestly, I don’t really have much doubt that we eventually won’t really have any choice than to forbid attachment based extension publication, and publish through import. The question is only “when ?” and the more we talk about security these days, the sooner it seems to be required. Even only allowing imported extension is not enough, but it’s a required step.

7

In this scenario, would people be allowed to publish extensions to exo even if the source is hosted in their own GitHub repo (or another source code host such as Codeberg for example)?

Either way, I think it’s good to ask people to first present the extension on the forum, and then let them post it on exo.

8

Hi!
Maybe we could add a clear warning on the extension page when it is not a contrib extension, so users understand that it is a extension and that it has not gone through the same process as contrib extensions.

Also, from a documentation pov, I think we should also think about how we handle these extensions when moving documentation away from e.x.o.

I don’t think we should have non-contrib extensions presented together with contrib extensions on xwiki.org (since we’re moving docs from exo to main wiki), because users won’t see the difference until landing on exo. I do think these extensions can be interesting and useful, but maybe the right path would be to encourage authors to move them to contrib. Thanks!

1 Like
9

I’m convinced we should indeed forbid it for security reasons and the sooner the better.

Do we still want to document that possibility and makes it a legit path? I’ve the feeling that it won’t be super useful honestly.

10

I was reading the Contributing guide, and I found 2 lines that feel a bit weird.
In the “Contribute Code” section (I bolded the parts that don’t feel right):

  • If you’ve developed some XWiki Extensions (applications, macros, even some code snippets in the form of scripts) you can share them easily with others by publishing them on the extensions wiki.
  • If you’re also interested in sharing the source code we encourage you to publish the code as an XWiki Contrib Project. This allows others to work collaboratively with you on this code and improve it and fix bugs.

To me, this sounds like anyone is allowed to publish extensions on exo, even closed source ones (unclear how they’d distribute them without using the attachment way). And, if they optionally want to publish the source code, they’re encouraged to do it in the contrib repo.

Mentioned it here so that it can be tracked and updated after this discussion.

11

Yes thx for pointing that out. The text is currently valid but indeed if we decide to restrict the publication of XARs we would need to change it a bit (but IMO it’ll still be valid as I don’t see why we would forbid publications of extensions developed elsewhere provided they match our publication criteria). So I see it more as adding additional rules on top.

1 Like