incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TJ Frazier <>
Subject Re: [DISCUSS] Is it worth looking at Confluence Wiki Again?
Date Mon, 26 Sep 2011 23:37:06 GMT
Hi, Kay,
On 9/26/2011 18:28, Kay Schenk wrote:
> Hi. I just posted (really asked a question) on this same subject on another
> thread -- vis a vis what's going on with the wiki.
> So, what IS going on? Anybody?
> I think (thought?) Pedro was kind of coordinating the test of Confluence
> with the infra folks but ???
AFAIK, there is nothing going on with the wiki. My objections to Cwiki 
are posted below; briefly, conversion would be too big and too messy to 
cope with.

Moin-moin might be a better candidate. Like Confluence, moin-moin is 
supported by infra (good), and lacks some facilities of Mwiki (bad). 
However, it has two distinct advantages:
* It is FOSS. If we decide that we need to extend it, whether for 
conversion or for permanent enhancements, we can do that.
* It is Python-powered. Python expertise should be available. I think I 
could learn enough to be useful, very quickly, without becoming a 
potential single-point-of-failure personnel problem.

I'm not the kind of person who can drive a project. We need someone who 
is. --/tj/

> On Fri, Sep 16, 2011 at 5:27 AM, Rob Weir<>  wrote:
>> On Fri, Sep 16, 2011 at 8:20 AM, TJ Frazier<>  wrote:
>>> On 9/15/2011 15:30, Rob Weir wrote:
>>>> On Thu, Sep 8, 2011 at 6:11 PM, TJ Frazier<>
>>   wrote:
>>>>> On 9/6/2011 18:12, Rob Weir wrote:
>>>>> <snip>
>>>>>> Another option to consider is that of content translation: MediaWiki
>>>>>> to Confluence.  Remember. Confluence is fully supported by Apache
>>>>>> Infra.  We would also find a lot of people on the list who could
>>>>>> write and test wiki text conversion code.  It is just string
>>>>>> manipulation, right?  How hard can that be?  Even I can help with
>>>>>> that.
>>>>>> But seriously, the MW plans were always precarious.  We did not have
>>>>>> deep bench of expertise on the sys admin side of that package.  Even
>>>>>> if we have a volunteer or two step in now, aren't we still rather
>>>>>> thin?  Wouldn't we still be one "life change" away from being back
>>>>>> where we are now?  But if we can figure out a content-level migration
>>>>>> to Confluence wiki, then we would have something much more sustainable
>>>>>> long term.
>>>>>> Just an idea.
>>>>>> -Rob
>>>>> My question is, "Is it worth looking at Confluence Wiki /at all?/ "
>>>>> Q: Why does everybody use Cwiki?
>>>>> A: Infra supports it.
>>>>> Q: Why does Infra support Cwiki?
>>>>> A: Everybody uses it.
>>>>> Hmm. "Very interesting," as Arte Johnson used to say.
>>>> This is true, but there is more here than may be immediately evident.
>>>> The fact that a service is widely supported by Apache Infra is very
>>>> important.  Remember, we no longer have Oracle's full-time web admin
>>>> staff to mind the OOo severs.  We'll soon be independent of that and
>>>> Apache will be responsible for routine maintenance, upgrades as well
>>>> as responding to problems.
>>>> And we must not underestimate the potential for problems.  Apache is a
>>>> high profile target. So is OpenOffice. Mix them together and the
>>>> question is not "if" someone will attack our website and try to take
>>>> it down.  The question is "when?".
>>>> I don't say that to scare you.  Just to point out reality.
>>> But is it reality?
>>> Apache has no big lists of credit-card numbers, no treasure-trove of
>> secret
>>> diplomatic cables, no maps of nuclear weapons targets or locations. What
>> we
>>> do have is software source, and that's free for the asking. In short, we
>>> have nothing that's worth a "commercial" (money-seeking) cracker's time.
>>> AFAIK, the ASF takes no stand on political, religious, or other
>> ideological
>>> controversies. We should not draw fanatics, either.
>>> The one credible threat I see is the possibility of inserting malware
>> into
>>> an Apache distro. That should not be possible through the wiki — any
>> brand
>>> of wiki.
>> If you look at recent attacks, the trend appears to be to exploit a
>> XSS vulnerability (or other0) to get root access, get the user account
>> data, typically user name, email address and hashed password, then do
>> an offline rainbow table attack on the hashed passwords, and use that
>> information to break into other accounts on other systems, since many
>> users use identical login/password on multiple systems.
>> It isn't really about the content of the wiki per se.  It is the account
>> data.
>>> (Not to mention that any target on our backs wouldn't even fill the
>> ten-ring
>>> of the target on Wikipedia – one of the most popular sites in the world.
>>> Their code may not be bullet-proof, but it's close.)
>>>> It is worth looking back at the note from Mark Thomas [1] sent to the
>>>> list back in July, to understand what it means to be using an
>>>> unsupported server app at Apache:
>>>> "The much more important question is who will support it. There have
>>>> been far too many examples of projects requesting a service, promising
>>>> to help support it and then never being heard from again when it needs
>>>> maintenance. If the current maintenance is performed by Oracle rather
>>>> than the community there will be concerns about the viability of that
>>>> model.
>>>> On a related note, infrastructure will not tolerate project managed
>>>> systems that are insecure. We will shut them down first and ask
>>>> questions later. Projects are expected to keep on top of security for
>>>> the services that they manage. We do arrange things so projects can
>>>> only shoot themselves in the foot but will still expect security to be
>>>> maintained. "
>>> I *assume* that the issue here is the timely installation of
>>> security-related updates, a high-priority maintenance task. Such updates
>> for
>>> FOSS components do happen – witness the recent flap over digital
>>> certificates – but they are quite rare. With the exception of the
>> MediaWiki
>>> code itself, updating the other components should be a cookbook task for
>>> anyone with sufficient karma and fu to have root access. It is generally
>>> simple enough that even I would take a crack at it (working slowly and
>>> carefully, and reading the instructions *first*. And not taking any
>>> "obvious" short-cuts ;-) ).
>>> Updating the MW code is a problem, with extensions, local mods, and
>>> leading-edge policy to consider. While there is expertise in the
>> background,
>>> we have not identified any active contributor (apparently including
>> Infra)
>>> with the expertise to JFDI.
>>>> I fully acknowledge that moving to CWiki would result in an imperfect
>>>> translation of the content that will take additional effort to clean
>>>> up.  And that moving to MWiki will be faster.  But we only need to
>>>> migrate once, right?  But we need to maintain this for the next 10
>>>> years.  That is why I talked about CWiki being "more sustainable".
>>>> Sure, it is pain now.  But we'll have much more help at Apache going
>>>> forward if we're using the same software that everyone else uses.  If
>>>> we use MWiki, we may migrate faster, but we'll be shut down at the
>>>> first sign of a problem.
>>>> I'm not saying the MWiki is unworkable.  But if we really want this to
>>>> work, long term, then we should be looking to have a solid base of
>>>> admin experience to help maintain it in the long term.  Not just help
>>>> migrating, but longer term.  And not just one person, but maybe 3
>>>> people who know it well and another 2 who can start learning it now.
>>>> Remember, the OOo wiki was not just a little thing on the fringes of
>>>> the project.  It was at the center of how the project was run.  Having
>>>> a sustainable wiki is essential for the AOOo project.
>>>> [1]
>>>> -Rob
>>> <snip>
>>> Long-term sustainability is definitely a problem. Fortunately, it is a
>>> long-term problem: we have time to find a solution. For instance, maybe
>>> someone(s) at MWF would be pleased to take an active role at ASF. (Or,
>> maybe
>>> not.) We could ask.
>>> Personally, I am only one of the "start learning" folks. I don't want to
>> be
>>> in a single-point-of-failure position; I am pushing 70, and 70 is pushing
>>> back.
>>> Should conversion ultimately be required, it is worth taking a look at
>>> moin-moin. That /is/ supported by Infra, and it is FOSS. If we really
>> need
>>> some feature, we can add it; python expertise should be widely available.
>>> --
>>> /tj/

View raw message