incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [DISCUSS] Is it worth looking at Confluence Wiki Again?
Date Mon, 26 Sep 2011 22:28:57 GMT
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 ???


On Fri, Sep 16, 2011 at 5:27 AM, Rob Weir <robweir@apache.org> wrote:

> 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/
> >
> >
>



-- 
---------------------------------------------------------------------------------------
MzK

"There is no such thing as coincidence."
           -- Leroy Jethro Gibbs, Rule #39

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message