You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jspwiki.apache.org by Harry Metske <ha...@gmail.com> on 2014/02/02 12:02:22 UTC

Re: Public Wiki upload security

Brian,

we (committers) have discussed how to secure the wiki, and decided to start
with a fairly loose regime. If we end up with too much spam, we will also
end with a similar approach as you mentioned for the Tomcat project. But
for now we want to keep it as loose as possible.
About the contributed code (mostly plugins) , that has been discussed too.
Basically, everything that is added to the wiki is Apache licensed (that's
why the footer on each wikipage). I also remember we discussed contributing
code and wether ASF allows that to be downloadable from ASF infra, I can't
find that discussion anymore, maybe one of the other committers (or our
mentors) can shine a light here ?

regards,
Harry




On 31 January 2014 11:59, Brian Burch <br...@pingtoo.com> wrote:

> I recently posted a new version of the jar for my contributed plugin at
> https://jspwiki-wiki.apache.org.
>
> I was very surprised to discover my upload was successful... BECAUSE I HAD
> FORGOTTEN TO LOGIN!
>
> I realise that logging-in to the wiki doesn't really provide much
> security, but it would at least allow people to verify the correct person
> posted the executable code that they are intending to install on their own
> jspwiki system.
>
> Has this topic been discussed before? What is the current wisdom on
> securing the wiki - completely, or just for executable code?
>
> When the Tomcat project started using their wiki more actively, there was
> quite a lot of spam activity, i.e. posting irrelevant and unwanted urls.
> Their current wiki can only be updated by registered users (not just
> committers), and anyone abusing the privilege is quickly blacklisted. It is
> a fairly simple strategy, but has been surprisingly successful.
>
> From a personal point of view, I've always felt it would be good to have a
> source repository for plugins that have not been adopted as part of the
> standard distribution, but are contributed by others. However, I suppose
> apache infra don't like the idea of hosting stuff that isn't controlled by
> their adopted project committers?
>
> Regards,
>
> Brian
>

Re: Public Wiki upload security

Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi,

wrt contributed code locations: didn't search for the specific mail thread,
but I recall several options where proposed:

1.- proceed "as always", and put the plugin src / binaries anywhere at
jspwiki-wiki.apache.org

2.- http://code.google.com/a/apache-extras.org/hosting/
here anyone can sign up and set up a code repository. From the FAQ on this
site: "Apache Extras is a community of open source projects related to
Apache Software Foundation projects or based on their technology. It
provides the infrastructure services typically required by open source
projects, such as code repositories, bug tracking, project web sites/wiki.
Apache Extras is hosted by Google Code Project Hosting, so it will be very
familiar to developers already using Google Code Project Hosting."

I recall reading somewhere that google code is going to disable binary
downloads in the near future, and it's yet to be seen what this means for
apache-extras, so anyone setting up there, there's a possibility of not
having binary downloads

3.- github (or similar)page, which is linked from
jspwiki-wiki.apache.orgcontribution pages

There wasn't consensus on having a standard contribution way, and looking
back I think that's ok, mostly because not everyone is comfortable with the
same way of working. Uploading your contribution directly to
jspwiki-wiki.apache.org is fastest and simpler than setting up a github
account + repo, but you may also feel more comfortable working directly
with your github account and just link from jspwiki-wiki.apache.org


br,
juan pablo




On Sun, Feb 2, 2014 at 12:02 PM, Harry Metske <ha...@gmail.com>wrote:

> Brian,
>
> we (committers) have discussed how to secure the wiki, and decided to start
> with a fairly loose regime. If we end up with too much spam, we will also
> end with a similar approach as you mentioned for the Tomcat project. But
> for now we want to keep it as loose as possible.
> About the contributed code (mostly plugins) , that has been discussed too.
> Basically, everything that is added to the wiki is Apache licensed (that's
> why the footer on each wikipage). I also remember we discussed contributing
> code and wether ASF allows that to be downloadable from ASF infra, I can't
> find that discussion anymore, maybe one of the other committers (or our
> mentors) can shine a light here ?
>
> regards,
> Harry
>
>
>
>
> On 31 January 2014 11:59, Brian Burch <br...@pingtoo.com> wrote:
>
> > I recently posted a new version of the jar for my contributed plugin at
> > https://jspwiki-wiki.apache.org.
> >
> > I was very surprised to discover my upload was successful... BECAUSE I
> HAD
> > FORGOTTEN TO LOGIN!
> >
> > I realise that logging-in to the wiki doesn't really provide much
> > security, but it would at least allow people to verify the correct person
> > posted the executable code that they are intending to install on their
> own
> > jspwiki system.
> >
> > Has this topic been discussed before? What is the current wisdom on
> > securing the wiki - completely, or just for executable code?
> >
> > When the Tomcat project started using their wiki more actively, there was
> > quite a lot of spam activity, i.e. posting irrelevant and unwanted urls.
> > Their current wiki can only be updated by registered users (not just
> > committers), and anyone abusing the privilege is quickly blacklisted. It
> is
> > a fairly simple strategy, but has been surprisingly successful.
> >
> > From a personal point of view, I've always felt it would be good to have
> a
> > source repository for plugins that have not been adopted as part of the
> > standard distribution, but are contributed by others. However, I suppose
> > apache infra don't like the idea of hosting stuff that isn't controlled
> by
> > their adopted project committers?
> >
> > Regards,
> >
> > Brian
> >
>