Working examples vs. security

[Jamon Camisso]

Combining the best of using a wiki for ease of adoption and 
participation with revision management using Git is possible.

One engine that does this is ikiwiki. It renders html pages from markup 
that is stored in an underlying git or svn repository, much like Bloxsom 
(for those who are familiar with it) did years ago.

The benefits are that:
1) ikiwiki allows editing through the wiki interface as one would expect
2) a git post-commit hook can easily be setup to force the underlying 
repository to pull from a remote with more strict access controls. The 
same code that Justin and I are working on for the post-commit URL with 
Jira can be repurposed to update the underlying repository in the event 
that someone adds malicious code etc.

Anastasia, Colin, if this sounds at all appealing or like a reasonable 
combination of requirements, would setting up a test instance make sense?

Regards, Jamon

On 2/9/2011 10:16 PM, Colin Clark wrote:
> Hi Anastasia,
>
> I think there are a few interesting questions we should consider beyond just, "how much of a concern should this be?" Obviously security is always an important concern. Let's see if we can unpack the potential risk and determine what tools we have available to us for mitigating it.
>
> There's certainly a risk that, if sample code is embedded directly in another page, someone might post a script that could scrape data from the wiki or phish for user input and then send it back to another server via JSONP. That's the nature of mashups. There are a number of ways we could handle this, ranging from only displaying code snippets within an iFrame to reviewing all code examples and posting them as read-only.
>
> That said, we've already got some pretty good tools for monitoring changes to our wiki. As a community, there are many of us who keep an eye on every change to our documentation.This lowers the risk quite a bit. To put it another way, we are constantly reviewing all changes to our wiki in real time. As a result, we can probably afford to be welcoming.
>
> I think there are some nice low tech, social solutions to issues like this. A combination of isolating sample code in iFrames and ensuring that our community stays vigilant seems like a reasonable balance between openness and caution.
>
> Colin
>
> On 2011-02-08, at 3:56 PM, Cheetham, Anastasia wrote:
>
>> Our goals for the new documentation include (among others):
>> 1) community editing, and
>> 2) live demos within pages
>>
>> This seems to open up a security concern: Support for community editing could allow editors to add malicious code to our documentation pages (not that anyone in our community would do that, but...).
>>
>> Some of the proposed systems involve a review process that would prevent this (source files in git requiring a pull, for example), but some wikis (Confluence, for example) allow editors to embed HTML and JS right in the page.
>>
>> How much of a concern should this be? Should a vetting provision for code be a requirement of any system we adopt? Any other thoughts on this issue?
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> http://fluidproject.org
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work