incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [DISCUSS] Is it worth looking at Confluence Wiki Again?
Date Fri, 16 Sep 2011 12:27:23 GMT
On Fri, Sep 16, 2011 at 8:20 AM, TJ Frazier <tjfrazier@cfl.rr.com> wrote:
> On 9/15/2011 15:30, Rob Weir wrote:
>>
>> On Thu, Sep 8, 2011 at 6:11 PM, TJ Frazier<tjfrazier@cfl.rr.com>  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 help
>>>> 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 a
>>>> 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] http://markmail.org/message/b23uko3fro5ijqkz
>>
>>
>> -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/
>
>

Mime
View raw message