Bug:

Every single top level script is responsible for enforcing security (which means every plugin can subvert security) rather than the central core libraries (such as the storage subsystem), meaning the entire data model is broken.

-- MS- on irc

Yes? And your point being?

Its not that I'm unconcerned about security, just that I recognise that there is a trade-off between power, functionality and 'security that gets in the way of getting things done". As someone said elsewhere, if we do something like block the ability to insert HTML (for forms and more elaborate tables) then we are going to have to ivnent sme pretty ugly TWiki ML or other constructs.

Should plugins be security audited? OF course. Should ones that come up short be banned? NO WAY! Post a warning, let the people who want to use them decide if they are going to accept the risk.

A Wiki is a collaborative environment. We extend trust to the community and to a degree - whatever degree - that community is open. We hope its not as open as, say, USENET, so we don't get drowned in univited spam, porn and ill informed wannabees. We want registration -- though not all wikis do - so we can have accountability; even when Matt posts in my name (Hi Matt!) the audit trail makes it clear it was him and not me.

Ok, so this isn't up to the level a military or a financial system might require, SarbOx or HIPPA, but the consequnces of failure, to say nothing of the development budget, are a lot less.

-- AntonAylward - 27 Nov 2004

It's rather unfair to post in a way that MS can't respond to, so if MS wants to reply on IRC, I will make sure his response gets onto this page.

FWIW I think Michael's point is a good one. As I read it he is observing that what security TWiki does have is in many places. This makes it much harder to impose higher levels of security in those environments that require it, because so many places have to be fixed.

I am not in favour of (for example) filtering HTML by default, but I am in favour of people being able to filter HTML should their peace of mind require it.

-- CrawfordCurrie - 27 Nov 2004

It is indeed a good point, and one I raised two years ago. "Code is code and data is data an never the twain shall meet", to misquote one of the poems forced on my at school. But the reality is otherwise.

Crawford, you are one of the exemplars of TWiki as an application building platform. Not "perl as an application platform" pr something like Mason or Template Builder where the application is done all in the perl code and the content is pure data.

One of the failings of many people writing about security is that they see it in black and white. Its not. Its not even shades of gray. Its a multicoloured braid, if you want to think in those terms. Reality: its about context. For example, I don't use Internet Explorer or Windows, so there are a massive number of security threats that don't impact me.

Rather then bleating about the portmanteau word "security" which means so many different things to so many people, I much prefer the approach you are taking elsewhere of aggressively decomposing and documenting the core and the plug-ins. Lets put the fuzziness of 'security' to one side and look at the value you are bringing. You are helping people understand what TWiki is, helping the people who are not perl gurus. You are helping those who can handle perl as well by better defining the interfaces and the issue, for example you analysis of performance, compatibility, listings of parameters and so forth, using your extra-ordinary expertese and skills to bring focus and to assist us lesser mortals. I can see you very shortly publishing a complete dependency tree/graph.

When evaluating risk, it is information, information like this, that is valuable. Knowing that a module makes use of a certain facility of function -- back-ticks for example -- is part of what allows decision makers to evaluate the risk of using the other perceived benefits it brings. (Ask yourself, dear reader, if Windows is so buggy, why do so many organizations use it?)

Its about risk, not security. Evey thing we do has some risk in it. What matters is can that risk be managed and do the benefits outweigh the risks. You drive a car? Have you seen the seen the statistics on road accidents? But the benefit ...

Crawford, the example you give of being able to filter HTML is a good example of managing risk. Give people the option and the understanding. I'd like to do that as a driver for part of managing the risk. Right now, too much of TWiki is heavily dependant on having HTML. To simply turn off HTML in topics would break, for example, the registration topics - RegistrationPub and the like. So we need to start with an audit: what in the core package uses HTML and how can it be avoided? We then need to document work arounds. I recall a few months back (sorry can't find it quickly) a question in support about tables. Peter's response was that it should be done in HTML. Well OK. Resort to HTML for the esoteric but TWiki should be able to deal with the common place.

And what's the biggest shortcoming? Forms. Not TWiki forms but the simple HTML forms. Like when I hit the "save" button on this edit, like in the registration topic and many other places. And its here, Crawford that you are already making great advances. Your Comment plugin hides many of the details of making a form. The only shortcoming so far is that we have fall back to HTML in the form definition in the UserTemplate; but that need not matter, your code in the plugin can verify that there is nothing untoward. So here we are, a way to purge much of the HTML form the core. Perhaps I should look at rewriting RegisterPub using %COMMENT% !

But let me look at another aspect of risk. I mentioned earlier that I didn't use Internet Explorer. That reduces my risk of cross site scripting in a whole pile of cases. But many of the risks we face are due to the shortcoming of browsers not of the web sites. Elsewhere I've described my battle trying to get JSCalendarplugin working. I found that the supposed rules that javascript and the LINK statements do not need to be in the header, they can be anywhere in the HTML BODY. So, to make one interface work, that's what I ended up coding -- sorry, writing into a topic. All the stuff that should be in the HEAD is in the BODY. This is a violation of the correct structure of a HTML page; HTML-Tidy pick it up and complains. But the fault is not with TWiki, it is with the browser. Those familiar with the Internet RFCs and spec writers such as Marshall Rose will be familiar with the the phrase "Be liberal with what you accept and careful with what you send". In the case I'm describing, TWiki reders the body of the topic quite faithfully; it is the browser being overly liberal and interpreting some stuff regardless of whether it is in the HEAD or the BODY that is the problem.

But shortcomings of the browser is why so many have migrated away from Internet Explorer ... only to find ... other risks.

Your other point about the lack of localization of functionality in TWiki is also quite valid I can see that you have been working towards addressing that too. But without centralized and authoritarian control of the development process there is nothing to force developers of plug-ins to use the core function and the defined interfaces, nothing to stop them writing their own code that violates whatever security guidelines we may promulgate. And so, reiterating my earlier point, all we can do is what you are so diligently already doing; review the code and make the risks and so forth clear.

-- AntonAylward - 27 Nov 2004

I'm on both MS's and AntonAylward's side.

I agree with MS: requiring every script to enforce security, even with careful auditing, is insecure. You want people to write lots of scripts.

I agree AntonAylward: You want people to write lots of scripts. You don't want twiki to have to implement a scripting language of its own, that restricts scripts to things supported by a putative twiki security model.

This is why I espouse using OS level mechanisms like chroot boxes and deprivileging via setuid and setgid CGI scripts. That way, a certain minimal level of security is factored out of all scripts - indeed, it is factored out of TWiki itself.

Is that minimum sufficient? Well... because I'm not going to go and do a security review of twiki, and keep doing so as code changes, it's all that I will rely on.

-- AndyGlew - 27 Dec 2004