Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 085927509 for ; Fri, 16 Sep 2011 12:27:25 +0000 (UTC) Received: (qmail 391 invoked by uid 500); 16 Sep 2011 12:27:24 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 333 invoked by uid 500); 16 Sep 2011 12:27:24 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 325 invoked by uid 99); 16 Sep 2011 12:27:24 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Sep 2011 12:27:24 +0000 Received: from localhost (HELO mail-gx0-f175.google.com) (127.0.0.1) (smtp-auth username robweir, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Sep 2011 12:27:24 +0000 Received: by gxk4 with SMTP id 4so4131642gxk.6 for ; Fri, 16 Sep 2011 05:27:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.161.136 with SMTP id t8mr2208642icx.177.1316176043273; Fri, 16 Sep 2011 05:27:23 -0700 (PDT) Received: by 10.42.230.138 with HTTP; Fri, 16 Sep 2011 05:27:23 -0700 (PDT) In-Reply-To: <4E733EF1.9040805@cfl.rr.com> References: <4E693D9C.7040809@cfl.rr.com> <4E733EF1.9040805@cfl.rr.com> Date: Fri, 16 Sep 2011 08:27:23 -0400 Message-ID: Subject: Re: [DISCUSS] Is it worth looking at Confluence Wiki Again? From: Rob Weir To: ooo-dev@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =C2=A0w= rote: >>> >>> On 9/6/2011 18:12, Rob Weir wrote: > >>> >>>> >>>> Another option to consider is that of content translation: MediaWiki >>>> to Confluence. =C2=A0Remember. Confluence is fully supported by Apache >>>> Infra. =C2=A0We would also find a lot of people on the list who could = help >>>> write and test wiki text conversion code. =C2=A0It is just string >>>> manipulation, right? =C2=A0How hard can that be? =C2=A0Even I can help= with >>>> that. >>>> >>>> But seriously, the MW plans were always precarious. =C2=A0We did not h= ave a >>>> deep bench of expertise on the sys admin side of that package. =C2=A0E= ven >>>> if we have a volunteer or two step in now, aren't we still rather >>>> thin? =C2=A0Wouldn't we still be one "life change" away from being bac= k >>>> where we are now? =C2=A0But if we can figure out a content-level migra= tion >>>> 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. =C2=A0Remember, we no longer have Oracle's full-time web admi= n >> staff to mind the OOo severs. =C2=A0We'll soon be independent of that an= d >> Apache will be responsible for routine maintenance, upgrades as well >> as responding to problems. >> >> And we must not underestimate the potential for problems. =C2=A0Apache i= s 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. =C2=A0The question is "when?". >> >> I don't say that to scare you. =C2=A0Just to point out reality. > > But is it reality? > > Apache has no big lists of credit-card numbers, no treasure-trove of secr= et > 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 ideologic= al > controversies. We should not draw fanatics, either. > > The one credible threat I see is the possibility of inserting malware int= o > an Apache distro. That should not be possible through the wiki =E2=80=94 = 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 da= ta. > (Not to mention that any target on our backs wouldn't even fill the ten-r= ing > of the target on Wikipedia =E2=80=93 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 =E2=80=93 witness the recent flap over digital > certificates =E2=80=93 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 backgrou= nd, > 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. =C2=A0And that moving to MWiki will be faster. =C2=A0But we only nee= d to >> migrate once, right? =C2=A0But we need to maintain this for the next 10 >> years. =C2=A0That is why I talked about CWiki being "more sustainable". >> Sure, it is pain now. =C2=A0But we'll have much more help at Apache goin= g >> forward if we're using the same software that everyone else uses. =C2=A0= 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. =C2=A0But 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. =C2=A0Not just he= lp >> migrating, but longer term. =C2=A0And 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. =C2=A0It was at the center of how the project was run. =C2= =A0Having >> a sustainable wiki is essential for the AOOo project. >> >> [1] http://markmail.org/message/b23uko3fro5ijqkz >> >> >> -Rob >> > > 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, ma= ybe > 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 nee= d > some feature, we can add it; python expertise should be widely available. > -- > /tj/ > >