Re: [Proposal]: Call for donations

[Jürgen Schmidt]

On 4/5/13 12:38 AM, Joseph Schaefer wrote:
> FWIW last time I checked there was a huge increase
> in paypal donations once OpenOffice adjusted it's
> contribution page accordingly.
> 

that is what I have expected of course. I know the numbers of the past
;-) But we can do better and can benefit all from more.

Juergen

> 
> On Apr 4, 2013, at 6:21 PM, Andrea Pescetti  wrote:
> 
>> Raphael Bircher wrote:
>>> Am 04.04.13 14:22, schrieb Jürgen Schmidt:
 And opinions or further ideas how we can improve this? It shouldn't be a
 big problem for us to collect the money we need.
>>> I disagree. Yes, we can help with foundings for ASF, but please do this
>>> on ASF Level. Founding money is not the task of a ASF project, It's the
>>> task for the foundation.
>>
>> The Foundation is made by its projects, so OpenOffice should definitely help 
>> with fundraising. Consider that OpenOffice (downloads excluded!) generates 
>> as much web traffic as all the other Apache projects put together, or 
>> something reasonably close to that. Also, the OpenOffice infrastructure 
>> requirements (buildbots, management) generates additional expenses for the 
>> Foundation that only benefit the OpenOffice project.
>>
>> In short: if OpenOffice can use its web traffic and popularity to drive more 
>> donations to the Foundation, it will surely directly benefit from most of 
>> them. So I agree with Juergen that we should solicit donations.
>>
>> Regards,
>>  Andrea.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Binfilter removal - PATCH

[Pavel Janík]

> Excellent!
> 
> What should we put in the Release Notes for this?  We are started to
> collect the info here:

Changes that Impact Backwards Compatibility

Module binfilter removed -> we do no longer support old fileformats from 
StarOffice.
-- 
Pavel Janík




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Why can't I find open office 2.3 for mac osx 10.5.8 on the website?

[Raphael Bircher]

Am 04.04.13 23:40, schrieb Marcus (OOo):

Am 04/03/2013 11:52 PM, schrieb David Coldwell:

version 3.0 files won't load into version 2.3 so I have to replace 3.0
with 2.3.


If you are searching for older version of OpenOffice please have a 
look for our archive:


en-US builds:
http://archive.apache.org/dist/incubator/ooo/stable/

localized builds:
http://archive.apache.org/dist/incubator/ooo/localized/


Why aren't there any links to older versions?


First of all we would like to make sure our users are using most 
recent version to get the most of the software.


Furthermore, there is also the problem that older versions are not 
perfect for newer operating systems. So, it's not unlikely that there 
will be install or system integration problems. Not to speak of 
security issues. None of these issues will be fixed in older releases.
One example for a problem is, that java no longer runs on versions below 
3.3. This is a Mac specific problem. Mainly the setup of a new installed 
system without OOo Profile makes trubble, because the script to write 
same additional stuff after the installation is in Java.


You can run OOo itself without java with same missing functions. No 
internal Base Databank, no Assistents and same other stuff. Just for 
your information, that you are aware of the problems.


Greetings Raphael


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: OpenOffice Cases of Success

[Galileo Teco Juárez]

excelent

thanks


2013/4/4 Louis Suárez-Potts 

>
> On 13-04-04, at 22:10 , Galileo Teco Juárez  wrote:
>
> > Anyone with information on success stories of the suite
> > for example:
> > schools, governments..
> > en donde se utilice la suite
> >
>
> This is old. It needs to be updated, but could still prove useful.
>
> http://wiki.openoffice.org/wiki/Major_OpenOffice.org_Deployments
>
>
> > regards
> >
> > --
> > *Galileo Teco Juarez*
> > *Web:* http://80bits.wordpress.com
> > *Twitter:* @genitalico 
> > *Linkedin:*
> http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797
>
>
> -louis
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
*Galileo Teco Juarez*
*Web:* http://80bits.wordpress.com
*Twitter:* @genitalico 
*Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797

Re: Conversation: Pick A Logo

[Samer Mansour]

Hello Everyone,

Can I propose we move forward with this logo: http://imagebin.org/252847
I kept the current official blue for both the logo and word 'Open' in the
wordmark because the word 'Open' gets less emphasis with the lighter blue.
I also gave the text Apache a placement inside the valley made by the two
O's as many people's designs had suggested.
The font is Roboto Condensed which is Apache 2.0 Licensed.

The source file is an SVG created in Inkscape. The above is a png export.

Samer

On Sun, Mar 31, 2013 at 2:55 PM, Samer Mansour  wrote:

> Hello,
>
> I will wait a few more days but it sounds like the group will be able to
> come to a consensus on refreshing the orb in some way or another.  We can
> proceed with finalizing this logo proposal if no one objectifies.
>
> Samer
>
>
> On Sun, Mar 31, 2013 at 3:40 AM, Kadal Amutham  wrote:
>
>> A flat logo may be good for  Pepsi, Domino's, Microsoft, Skype, Twitter
>> since they have money power to promote. What AOO needs is a good looking
>> logo
>>
>> With Warm Regards
>>
>> V.Kadal Amutham
>> 919444360480
>> 914422396480
>>
>>
>> On 30 March 2013 18:17, Juergen Schmidt  wrote:
>>
>> > Am Samstag, 30. März 2013 um 03:05 schrieb Alexandro Colorado:
>> > > On 3/29/13, Robin Fowler  wrote:
>> > > > Due to the opinions I've seen so far I've decided to make a new
>> design:
>> > > >
>> > > >
>> >
>> https://cwiki.apache.org/confluence/download/attachments/27846912/OO_4_final_design_Robin-Fowler.jpg?version=1&modificationDate=1364582663662
>> > >
>> > > Here is a tweak, without the orb. Looks pretty olympic.
>> > > http://imagebin.org/252139
>> > >
>> > maybe I am confused but I thought that we want something like the orb
>> that
>> > can be used standalone with the name. For ample for buttons, stickers
>> etc.
>> >
>> > Juergen
>> > >
>> > >
>> > > >
>> > > > Overall it has a flat look and yet still some depth to make it stand
>> > out
>> > > > from the microsoft brand. I think it is also important to think
>> about
>> > the
>> > > > form itself, the silhouette should ideally be recognisable on its
>> own,
>> > which
>> > > > is one reason using the apache feather is a good idea.
>> > > >
>> > > > Some other thoughts:
>> > > >
>> > > > One of the problems i see with a lot of the proposals is the lack of
>> > thought
>> > > > given to typography. It seems the text is just slapped on as an
>> > > > afterthought, in many cases the 'apache' is floating somewhere
>> randomly
>> > > > above 'openoffice'. Think of what you want the logo to imply, it
>> > should not
>> > > > look disorganised. Another thing worth pointing out is the kerning
>> > (spacing
>> > > > between letters) which could be optimised on some of the proposals.
>> > > >
>> > >
>> > >
>> > > There was a long discussion about the typography, starting with an
>> > > open typography, and also a more artistic.
>> > >
>> > > >
>> > > > This is an extremely important aspect of the whole logo design and
>> > should be
>> > > > considered when choosing a design. After all, many logos consist of
>> > nothing
>> > > > other than text.
>> > > >
>> > > > I also want to say i really like Vasilis Xenofontos design. It might
>> > be too
>> > > > different from the current, but it's a very good logo imo.
>> > > >
>> > > > Robin
>> > > >
>> > > > On 28 Mar 2013, at 12:38, Samer Mansour  wrote:
>> > > >
>> > > > > Robin brought up a good point that we should pick a logo before we
>> > start
>> > > > > work on the application artifacts or the website as it will
>> influence
>> > > > > those.
>> > > > >
>> > > > > I initially was excited that we could have a new logo, an
>> > opportunity to
>> > > > > change the face of OpenOffice.
>> > > > >
>> > > > > But after I saw Chris R. proposal I convinced myself refreshing
>> > rather
>> > > > > than
>> > > > > re-branding was the better path.
>> > > > >
>> > > > > So I would like to start a conversation that will hopefully give
>> us
>> > > > > strong
>> > > > > arguments to picking a logo.
>> > > > >
>> > > > > I already mentioned I liked the flat logo.
>> > > > > Here are reasons:
>> > > > >
>> > > > > - It is very similar to the current logo and that logo has a
>> history
>> > of
>> > > > > being recognized.
>> > > > > - Flat is 'in', easily recognizable on and works well on social
>> > > > > platforms,
>> > > > > screens and print media. (Think corporate and product logos of
>> today,
>> > > > > recently Pepsi, Domino's, Microsoft, Skype, Twitter)
>> > > > > - This logo can be severed from the word mark to make it fit in a
>> > square
>> > > > > and still carry the branding image. Icons, site, etc.
>> > > > > - A middle ground for community members who like the current logo.
>> > Who
>> > > > > want
>> > > > > to achieve a new image of 4.0 without tossing history.
>> > > > >
>> > > > > Looking back, we had lots of ideas but it only took me a moment
>> when
>> > i
>> > > > > saw
>> > > > > Chris r.'s proposal to realize the logo didn't need to be complex
>> and
>> > >

Re: "Easy hack" for website

[Samer Mansour]

Rob could you possibly export the pages missing titles in a CSV, one per
line?
I'll check google analytics to see if there is a page visit export feature
and then prioritize.

I would also surface NL homepages for example, even if a language doesn't
as many hit, the home page should be at least titled.

I would document the output in the cWiki so that as pages are completed
volunteers can mark done in a column. Slash if I get time I would tackle
some as well.

As a side note if the goal is to improve in search results, let me talk to
some colleagues that are familiar with SEO if they have any high ROI steps.
ie. is there a meta tag like description that is highly used by search
engines.



On Thu, Apr 4, 2013 at 6:49 PM, Rob Weir  wrote:

> I just entered a BZ issue :
>
> https://issues.apache.org/ooo/show_bug.cgi?id=122003
>
> "Missing  tag on many webpages"
>
> If there are any new volunteers looking for how to get started, this is one
> easy way that does not require any programming.  We need someone to review
> a bunch of HTML pages and add titles to them.  It should help these pages
> be listed more appropriately in Google, Bing and other search engines.
>
> There are 874 pages missing titles, so this is something where we can
> divide up the work as well.
>
> Regards,
>
> -Rob
>

Re: OpenOffice Cases of Success

[Louis Suárez-Potts]

On 13-04-04, at 22:10 , Galileo Teco Juárez  wrote:

> Anyone with information on success stories of the suite
> for example:
> schools, governments..
> en donde se utilice la suite
> 

This is old. It needs to be updated, but could still prove useful.

http://wiki.openoffice.org/wiki/Major_OpenOffice.org_Deployments


> regards
> 
> -- 
> *Galileo Teco Juarez*
> *Web:* http://80bits.wordpress.com
> *Twitter:* @genitalico 
> *Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797


-louis
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Proposal]: Call for donations

[Rob Weir]

On Thu, Apr 4, 2013 at 8:23 PM, Dave Fisher  wrote:

> We can easily copy the "Donate" button from the footer to the topnav.
>
>
The pages are already so busy that making anything stand out is rather
difficult.

I'll give you an example.  We (Samer and I) did an experiment with
different placements of the social sharing links.  So we weren't asking for
money or anything like that.  We were just asking users to friend us on
Facebook.

We tracked the response rate over a two week period.

For placement up on the navbar or to the right of search, the response rate
was 0.04%.

For further down on the page, in its own section (how we have it now) the
response rate was 0.19%.

The best rate was right front and center, above the announcement with
graphics.  That had 0.34% response rate.  Though that was the best, we
opted not to go with it since it was not really appropriate for permanent
use, though it might work OK for a temporary campaign.

(We also did some variations that were text-only, but the versions with
graphics did better each time)

So with 0.34% response rate on click through, we'd get maybe 2500
clicks/day. Not sure what % of those would actually contribute, but even at
1% that adds up over a while.

Another entirely unrelated approach would be to have an Amazon Affiliate
account for the ASF and then have a listing of books related to Apache
projects.  The ASF would then get a % of each referred sale. That could be
huge, especially with the Hadoop family of projects.

-Rob


> We can request that l10n teams add a translated donate button for their
> language. If they haven't translated their brand and topnav now would a
> time to do so. We would want to translate the fundraising page, too.
>
> Is this a vehicle for incrementally starting the new web hierarchy? Some
> variation on the plans that many of us have kicked around?
>
> On Apr 4, 2013, at 4:05 PM, Daniel Shahaf wrote:
>
> > You might want to talk to fundraising@ before you do anything --- not as
> > much for permission as for ideas on how to frame the "Please donate"
> > request.
> >
> > (fundraising@ is privately-archived)
> >
> > Joseph Schaefer wrote on Thu, Apr 04, 2013 at 18:38:18 -0400:
> >> FWIW last time I checked there was a huge increase
> >> in paypal donations once OpenOffice adjusted it's
> >> contribution page accordingly.
> >>
> >>
> >> On Apr 4, 2013, at 6:21 PM, Andrea Pescetti 
> wrote:
> >>
> >>> Raphael Bircher wrote:
>  Am 04.04.13 14:22, schrieb Jürgen Schmidt:
> > And opinions or further ideas how we can improve this? It shouldn't
> be a
> > big problem for us to collect the money we need.
>  I disagree. Yes, we can help with foundings for ASF, but please do
> this
>  on ASF Level. Founding money is not the task of a ASF project, It's
> the
>  task for the foundation.
> >>>
> >>> The Foundation is made by its projects, so OpenOffice should
> definitely help with fundraising. Consider that OpenOffice (downloads
> excluded!) generates as much web traffic as all the other Apache projects
> put together, or something reasonably close to that. Also, the OpenOffice
> infrastructure requirements (buildbots, management) generates additional
> expenses for the Foundation that only benefit the OpenOffice project.
> >>>
> >>> In short: if OpenOffice can use its web traffic and popularity to
> drive more donations to the Foundation, it will surely directly benefit
> from most of them. So I agree with Juergen that we should solicit donations.
> >>>
> >>> Regards,
> >>> Andrea.
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

OpenOffice Cases of Success

[Galileo Teco Juárez]

Anyone with information on success stories of the suite
for example:
schools, governments..
en donde se utilice la suite

regards

-- 
*Galileo Teco Juarez*
*Web:* http://80bits.wordpress.com
*Twitter:* @genitalico 
*Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797

Re: [Website] Re-locate images from "download/images/" to "images/"

[Dave Fisher]

All image directories and img links can be discovered and converted in an 
offline checkout of the site.

It could be automated. Different image files of the same name can be diffed. It 
is all discoverable.

Doing it manually is a mess. I discovered this during the ooo-site port from 
Oracle's Kenai which was actually a recent port from CollabraNet that was 
rather broken.

The point is that OOo is a mess different project sites did different things. 
There are some beautiful yurts on the Mongolian site: 
http://www.openoffice.org/mn/

Regards,
Dave


On Apr 4, 2013, at 3:32 PM, Marcus (OOo) wrote:

> Am 04/05/2013 12:18 AM, schrieb Rob Weir:
>> On Thu, Apr 4, 2013 at 5:27 PM, Kay Schenk  wrote:
>> 
>>> On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo)  wrote:
>>> 
 Am 04/01/2013 03:12 AM, schrieb Rob Weir:
 
  On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)
>  wrote:
> 
>> Hi Rob,
>> 
>> I want to cleanup the structure and remove 1 of the 2 directories for
>> images.
>> 
>> Therefore I've added the images from "download/images" also to
>>> "images/"
>> and
>> updated the "download/index.html" to point to the new location.
>> 
>> Please tell me, is it save to remove the "download/images/" directory?
>>> If
>> not what else has to be updated?
>> 
>> 
> I'm not sure I like the idea of having a global images directory
> rather than having images scoped to the subtree where they are
> actually used.  Having a single global directory increases the changes
> of having accidental conflicts.  But if you want to make this change,
> 
 
 That's not what I want. Please read again. I just want to get rid of 1 of
 the 2 images directories in the "download/" sub-dir.
 
 Of course it doesn't make sense to have a single images dir for the
>>> entire
 website. ;-)
>>> 
>>> 
>>> Actually I don't think a single "images" directory for the whole site is
>>> such a bad idea. We could subdivide it by area -- e.e. images/download.
>>> Maybe worth discussing at some point?
>>> 
>>> 
>> What advantage do you see to that?  I could see that for common images that
>> were essentially "global" this might make sense.  But otherwise having
>> images contained in the subtree that uses them gives more isolation,
>> prevents name collisions, accidental side effects, etc.
>> 
>> Of course from an information standpoint foo/bar and bar/foo are equally
>> expressive. But I think we're more likely to copy, move, translate, etc.,
>> subsites as a whole, so having, e.g., /download be self-contained is a nice
>> property.
>> 
>> 
>>> 
 
  be sure to test each of the "Help spread the word" links for
> Twitter/Facebook/Google+ to make sure those applications are finding
> the right images.  I don't mean the image on our page.  I mean the
> image on the post once it is on Facebook, etc.  Since hundreds of such
> posts have already been made, we probably don't want to break any of
> those links.
> 
 
 You mean Twitter/Facebook/Google+ articles are referring to
 ".../download/images/*" files? That's bad, then we won't never be able to
 move such kind of files in the future.
 
>>> 
>> 
>> I don't know this.  I'm just suggesting that it is something we should
>> check.   We have over 7 million external links into www.openoffice.org.  So
>> it is hard to make any significant changes without breaking something.  But
>> that shouldn't prevent us from making improvements.  But if we make any big
>> changes we'll want to go back and see if any critical external sites need
>> to be notified/updated.
> 
> When I see this correct, then the files that you have checked-in into 
> "www.oo.org/download/images/" are not that old - much more recent than the 
> files in "www.oo.org/download/cachedimages/". IMHO not enough to get 
> wide-spreaded like other data on our website.
> 
> Do you remember where you have used the image files? Then I (or you) could 
> change the links to the new files in "www.oo.org/images/". And any more 
> broken links can be changed then.
> 
> So, can you help me with this?
> 
> Thanks
> 
> Marcus
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Proposal]: Call for donations

[Dave Fisher]

We can easily copy the "Donate" button from the footer to the topnav.

We can request that l10n teams add a translated donate button for their 
language. If they haven't translated their brand and topnav now would a time to 
do so. We would want to translate the fundraising page, too.

Is this a vehicle for incrementally starting the new web hierarchy? Some 
variation on the plans that many of us have kicked around?

On Apr 4, 2013, at 4:05 PM, Daniel Shahaf wrote:

> You might want to talk to fundraising@ before you do anything --- not as
> much for permission as for ideas on how to frame the "Please donate"
> request.
> 
> (fundraising@ is privately-archived)
> 
> Joseph Schaefer wrote on Thu, Apr 04, 2013 at 18:38:18 -0400:
>> FWIW last time I checked there was a huge increase
>> in paypal donations once OpenOffice adjusted it's
>> contribution page accordingly.
>> 
>> 
>> On Apr 4, 2013, at 6:21 PM, Andrea Pescetti  wrote:
>> 
>>> Raphael Bircher wrote:
 Am 04.04.13 14:22, schrieb Jürgen Schmidt:
> And opinions or further ideas how we can improve this? It shouldn't be a
> big problem for us to collect the money we need.
 I disagree. Yes, we can help with foundings for ASF, but please do this
 on ASF Level. Founding money is not the task of a ASF project, It's the
 task for the foundation.
>>> 
>>> The Foundation is made by its projects, so OpenOffice should definitely 
>>> help with fundraising. Consider that OpenOffice (downloads excluded!) 
>>> generates as much web traffic as all the other Apache projects put 
>>> together, or something reasonably close to that. Also, the OpenOffice 
>>> infrastructure requirements (buildbots, management) generates additional 
>>> expenses for the Foundation that only benefit the OpenOffice project.
>>> 
>>> In short: if OpenOffice can use its web traffic and popularity to drive 
>>> more donations to the Foundation, it will surely directly benefit from most 
>>> of them. So I agree with Juergen that we should solicit donations.
>>> 
>>> Regards,
>>> Andrea.
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Proposal: Improve security by limiting committer access in SVN

[Dave Fisher]

On Apr 4, 2013, at 12:17 PM, janI wrote:

> On 4 April 2013 21:03, Rob Weir  wrote:
> 
>> On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein  wrote:
>> 
>>> Your proposal to alter the community structure is premised upon a
>>> strawman risk. First, that it would occur. Second, that it wouldn't be
>>> noticed. Third, that it would find its way into users' hands.
>>> 
>>> 
>> So you are asserting that someone who put their name down on the Incubator
>> wiki in July 2011 and was named a committer by that act, but never ever
>> showed up after that, never joined the dev list, never posted to the dev
>> list, never contributed code or anything else other than a name on a wiki,
>> is a member of our community and it would be altering the committee
>> structure if we removed their authz to our source code, even with the
>> proviso that we would immediately restore it on request?
>> 
>> Really?
>> 
> 
> Just a stupid question from someone who have not been here for ages...the
> person just described should loose the committer role, or are we granted
> commitership for lifetime ??

Correct. The chances of committership being revoked are very, very tiny. Such 
matter is private as it is personnel.

Some people, even on this project, have been inactive for many years between 
being committers on any project. They are still a committer, just not on a 
project.

Regards,
Dave


> 
> jan I.
> 
>> 
>> -Rob
>> 
>> 
>> 
>>> In the past, the Foundation has *explicitly* said that we would accept
>>> a certain level of risk to maintain our communities.
>>> 
>>> I find your strawman at a level even *lower* than the scenario that
>>> I'm thinking about(*).
>>> 
>>> If you're worried about stale committers suddenly inserting trojans,
>>> then just use 'svn log' to find those outliers. No need to create
>>> division within the community. Run a simple histogram. There are many
>>> solutions to your purported attack vector, than to divide into groups.
>>> 
>>> Cheers,
>>> -g
>>> 
>>> (*) a certain large company's lawyer (ahem) was trying to scare the
>>> ASF ("the risk!!") into adopting certain procedures; we shut her down
>>> 
>>> On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
 On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
 
> Also, let me say one more thing:
> 
> This notion of creating divisions among committers ... it is
>> "solving"
> a problem that has never occurred here.
> 
> NEVER. OCCURRED.
> 
> 
 So frickin' what?  That is entirely irrelevant.   My house has never
>>> burnt
 down either, but I still don't leave open flames around unattended.  In
 fact you might think this is naive view, but avoidance of such risks
>>> might
 even be correlated with lack of house fires.  Hmmm
 
 
 
> In the Foundations's 14+ year history, we have never seen a trojan
> commit. Our servers have been compromised a handful of times. When we
> were back on CVS, we even had to audit source control to verify no
> trojan injection. But we have NEVER had a case of a malware commit.
> 
> 
 Again, that proves nothing.   I'm sure the first time apache.org was
>>> rooted
 that it had never happened before either, right?
 
 
 
 
> So back to IMO: dividing and partitioning and separate privilege
> levels... there is no reason. It creates a social problem to "solve"
>> a
> non-existent issue. Net result: more problems.
> 
> 
 
 Greg, we already do this.  Does every ASF Member have credential for
>>> Infra
 root?  Does ever ASF Member have access to legal-private mailing list.
>>> No.
 No. We even do this in the AOO project, with separate authz for
 openoffice-security, which by the way also includes an SVN tree.
 
 Anyone who thinks this is a question of dividing and privilege is
 expressing a knee-jerk reaction, without thinking of the risks.  We
>>> should
 avoid regurgitating platitudes.  Remember, we're talking about people
>> who
 have never committed code, who don't even know C, who are not even
 subscribed to the dev mailing list, and in some cases have never ever
 posted to our mailing lists.  They signed up in with the podling in
>> July
 2011 and then were never heard of again.  You make an extremely weak
 argument to pontificate about "privilege" here.
 
 The risks are real.  High profile open source projects attract these
>>> kinds
 of attacks.  There are those who know it, and those who don't know it
>>> yet.
 
 A good read:
 
>>> 
>> http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked
 
 As for those who think that casual review of commit messages will
>> review
 any attack, that is a dangerously naive few.  We should not expect an
 attack to be in a filed called trojan.c with comments and clear logic
 explaining what the code does.  Any hacker with a clue would send a

RE: questions about Base---do we need an embedded DB?

[Dennis E. Hamilton]

The link to OpenOffice.org Base is interesting.

I wonder if the decision about SQLite (or a variant) should be reconsidered for 
a re-engineered AOO Base.  It essentially depends on how important SQL is.  And 
of course, it would be just to furnish a default built-in DBMS.

 - Dennis

"Small. Fast. Reliable.  Choose any three."  I love the brass! 


-Original Message-
From: Kay Schenk [mailto:kay.sch...@gmail.com] 
Sent: Thursday, April 04, 2013 14:05
To: dev@openoffice.apache.org
Subject: Re: questions about Base---do we need an embedded DB?

[ ... ]


You may want to take a look at this page from Wikipedia. Not guaranteed of
course.

 http://en.wikipedia.org/wiki/Category:Free_database_management_systems

[ ... ]


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Proposal]: Call for donations

[Daniel Shahaf]

You might want to talk to fundraising@ before you do anything --- not as
much for permission as for ideas on how to frame the "Please donate"
request.

(fundraising@ is privately-archived)

Joseph Schaefer wrote on Thu, Apr 04, 2013 at 18:38:18 -0400:
> FWIW last time I checked there was a huge increase
> in paypal donations once OpenOffice adjusted it's
> contribution page accordingly.
> 
> 
> On Apr 4, 2013, at 6:21 PM, Andrea Pescetti  wrote:
> 
> > Raphael Bircher wrote:
> >> Am 04.04.13 14:22, schrieb Jürgen Schmidt:
> >>> And opinions or further ideas how we can improve this? It shouldn't be a
> >>> big problem for us to collect the money we need.
> >> I disagree. Yes, we can help with foundings for ASF, but please do this
> >> on ASF Level. Founding money is not the task of a ASF project, It's the
> >> task for the foundation.
> > 
> > The Foundation is made by its projects, so OpenOffice should definitely 
> > help with fundraising. Consider that OpenOffice (downloads excluded!) 
> > generates as much web traffic as all the other Apache projects put 
> > together, or something reasonably close to that. Also, the OpenOffice 
> > infrastructure requirements (buildbots, management) generates additional 
> > expenses for the Foundation that only benefit the OpenOffice project.
> > 
> > In short: if OpenOffice can use its web traffic and popularity to drive 
> > more donations to the Foundation, it will surely directly benefit from most 
> > of them. So I agree with Juergen that we should solicit donations.
> > 
> > Regards,
> >  Andrea.
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

"Easy hack" for website

[Rob Weir]

I just entered a BZ issue :

https://issues.apache.org/ooo/show_bug.cgi?id=122003

"Missing  tag on many webpages"

If there are any new volunteers looking for how to get started, this is one
easy way that does not require any programming.  We need someone to review
a bunch of HTML pages and add titles to them.  It should help these pages
be listed more appropriately in Google, Bing and other search engines.

There are 874 pages missing titles, so this is something where we can
divide up the work as well.

Regards,

-Rob

Re: [Proposal]: Call for donations

[Joseph Schaefer]

FWIW last time I checked there was a huge increase
in paypal donations once OpenOffice adjusted it's
contribution page accordingly.


On Apr 4, 2013, at 6:21 PM, Andrea Pescetti  wrote:

> Raphael Bircher wrote:
>> Am 04.04.13 14:22, schrieb Jürgen Schmidt:
>>> And opinions or further ideas how we can improve this? It shouldn't be a
>>> big problem for us to collect the money we need.
>> I disagree. Yes, we can help with foundings for ASF, but please do this
>> on ASF Level. Founding money is not the task of a ASF project, It's the
>> task for the foundation.
> 
> The Foundation is made by its projects, so OpenOffice should definitely help 
> with fundraising. Consider that OpenOffice (downloads excluded!) generates as 
> much web traffic as all the other Apache projects put together, or something 
> reasonably close to that. Also, the OpenOffice infrastructure requirements 
> (buildbots, management) generates additional expenses for the Foundation that 
> only benefit the OpenOffice project.
> 
> In short: if OpenOffice can use its web traffic and popularity to drive more 
> donations to the Foundation, it will surely directly benefit from most of 
> them. So I agree with Juergen that we should solicit donations.
> 
> Regards,
>  Andrea.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Website] Re-locate images from "download/images/" to "images/"

[Marcus (OOo)]

Am 04/05/2013 12:18 AM, schrieb Rob Weir:

On Thu, Apr 4, 2013 at 5:27 PM, Kay Schenk  wrote:


On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo)  wrote:


Am 04/01/2013 03:12 AM, schrieb Rob Weir:

  On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)

  wrote:


Hi Rob,

I want to cleanup the structure and remove 1 of the 2 directories for
images.

Therefore I've added the images from "download/images" also to

"images/"

and
updated the "download/index.html" to point to the new location.

Please tell me, is it save to remove the "download/images/" directory?

If

not what else has to be updated?



I'm not sure I like the idea of having a global images directory
rather than having images scoped to the subtree where they are
actually used.  Having a single global directory increases the changes
of having accidental conflicts.  But if you want to make this change,



That's not what I want. Please read again. I just want to get rid of 1 of
the 2 images directories in the "download/" sub-dir.

Of course it doesn't make sense to have a single images dir for the

entire

website. ;-)



Actually I don't think a single "images" directory for the whole site is
such a bad idea. We could subdivide it by area -- e.e. images/download.
Maybe worth discussing at some point?



What advantage do you see to that?  I could see that for common images that
were essentially "global" this might make sense.  But otherwise having
images contained in the subtree that uses them gives more isolation,
prevents name collisions, accidental side effects, etc.

Of course from an information standpoint foo/bar and bar/foo are equally
expressive. But I think we're more likely to copy, move, translate, etc.,
subsites as a whole, so having, e.g., /download be self-contained is a nice
property.






  be sure to test each of the "Help spread the word" links for

Twitter/Facebook/Google+ to make sure those applications are finding
the right images.  I don't mean the image on our page.  I mean the
image on the post once it is on Facebook, etc.  Since hundreds of such
posts have already been made, we probably don't want to break any of
those links.



You mean Twitter/Facebook/Google+ articles are referring to
".../download/images/*" files? That's bad, then we won't never be able to
move such kind of files in the future.





I don't know this.  I'm just suggesting that it is something we should
check.   We have over 7 million external links into www.openoffice.org.  So
it is hard to make any significant changes without breaking something.  But
that shouldn't prevent us from making improvements.  But if we make any big
changes we'll want to go back and see if any critical external sites need
to be notified/updated.


When I see this correct, then the files that you have checked-in into 
"www.oo.org/download/images/" are not that old - much more recent than 
the files in "www.oo.org/download/cachedimages/". IMHO not enough to get 
wide-spreaded like other data on our website.


Do you remember where you have used the image files? Then I (or you) 
could change the links to the new files in "www.oo.org/images/". And any 
more broken links can be changed then.


So, can you help me with this?

Thanks

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Proposal]: Call for donations

[Andrea Pescetti]

Raphael Bircher wrote:

Am 04.04.13 14:22, schrieb Jürgen Schmidt:

And opinions or further ideas how we can improve this? It shouldn't be a
big problem for us to collect the money we need.

I disagree. Yes, we can help with foundings for ASF, but please do this
on ASF Level. Founding money is not the task of a ASF project, It's the
task for the foundation.


The Foundation is made by its projects, so OpenOffice should definitely 
help with fundraising. Consider that OpenOffice (downloads excluded!) 
generates as much web traffic as all the other Apache projects put 
together, or something reasonably close to that. Also, the OpenOffice 
infrastructure requirements (buildbots, management) generates additional 
expenses for the Foundation that only benefit the OpenOffice project.


In short: if OpenOffice can use its web traffic and popularity to drive 
more donations to the Foundation, it will surely directly benefit from 
most of them. So I agree with Juergen that we should solicit donations.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Website] Re-locate images from "download/images/" to "images/"

[Rob Weir]

On Thu, Apr 4, 2013 at 5:27 PM, Kay Schenk  wrote:

> On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo)  wrote:
>
> > Am 04/01/2013 03:12 AM, schrieb Rob Weir:
> >
> >  On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)
> >>  wrote:
> >>
> >>> Hi Rob,
> >>>
> >>> I want to cleanup the structure and remove 1 of the 2 directories for
> >>> images.
> >>>
> >>> Therefore I've added the images from "download/images" also to
> "images/"
> >>> and
> >>> updated the "download/index.html" to point to the new location.
> >>>
> >>> Please tell me, is it save to remove the "download/images/" directory?
> If
> >>> not what else has to be updated?
> >>>
> >>>
> >> I'm not sure I like the idea of having a global images directory
> >> rather than having images scoped to the subtree where they are
> >> actually used.  Having a single global directory increases the changes
> >> of having accidental conflicts.  But if you want to make this change,
> >>
> >
> > That's not what I want. Please read again. I just want to get rid of 1 of
> > the 2 images directories in the "download/" sub-dir.
> >
> > Of course it doesn't make sense to have a single images dir for the
> entire
> > website. ;-)
>
>
> Actually I don't think a single "images" directory for the whole site is
> such a bad idea. We could subdivide it by area -- e.e. images/download.
> Maybe worth discussing at some point?
>
>
What advantage do you see to that?  I could see that for common images that
were essentially "global" this might make sense.  But otherwise having
images contained in the subtree that uses them gives more isolation,
prevents name collisions, accidental side effects, etc.

Of course from an information standpoint foo/bar and bar/foo are equally
expressive. But I think we're more likely to copy, move, translate, etc.,
subsites as a whole, so having, e.g., /download be self-contained is a nice
property.


>
> >
> >  be sure to test each of the "Help spread the word" links for
> >> Twitter/Facebook/Google+ to make sure those applications are finding
> >> the right images.  I don't mean the image on our page.  I mean the
> >> image on the post once it is on Facebook, etc.  Since hundreds of such
> >> posts have already been made, we probably don't want to break any of
> >> those links.
> >>
> >
> > You mean Twitter/Facebook/Google+ articles are referring to
> > ".../download/images/*" files? That's bad, then we won't never be able to
> > move such kind of files in the future.
> >
>

I don't know this.  I'm just suggesting that it is something we should
check.   We have over 7 million external links into www.openoffice.org.  So
it is hard to make any significant changes without breaking something.  But
that shouldn't prevent us from making improvements.  But if we make any big
changes we'll want to go back and see if any critical external sites need
to be notified/updated.

-Rob


> >
> > Marcus
> >
> >
> > --**--**-
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscr...@openoffice.apache.org>
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>
>
> --
>
> 
> MzK
>
> "Achieving happiness requires the right combination of Zen and Zin."
>

Re: [Website] Re-locate images from "download/images/" to "images/"

[Marcus (OOo)]

Am 04/04/2013 11:27 PM, schrieb Kay Schenk:

On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo)  wrote:


Am 04/01/2013 03:12 AM, schrieb Rob Weir:

  On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)

  wrote:


Hi Rob,

I want to cleanup the structure and remove 1 of the 2 directories for
images.

Therefore I've added the images from "download/images" also to "images/"
and
updated the "download/index.html" to point to the new location.

Please tell me, is it save to remove the "download/images/" directory? If
not what else has to be updated?



I'm not sure I like the idea of having a global images directory
rather than having images scoped to the subtree where they are
actually used.  Having a single global directory increases the changes
of having accidental conflicts.  But if you want to make this change,



That's not what I want. Please read again. I just want to get rid of 1 of
the 2 images directories in the "download/" sub-dir.

Of course it doesn't make sense to have a single images dir for the entire
website. ;-)



Actually I don't think a single "images" directory for the whole site is
such a bad idea. We could subdivide it by area -- e.e. images/download.


OK, maybe there are some reasons that prof that it makes sense. And my 
wording was not appropriate.


However, actually we have some wide-spreaded image directories within 
the entire website. So, if we would consolidate all images into a single 
directory someone has to fix all the broken links that would then exist. 
I've just checked-out a handfull of sub-dirs and I've counted nearly 100 
HTML files - and I've no NL websites checked or CSS files.



Maybe worth discussing at some point?


Sure, don't let me hold you back. :-)

Marcus




  be sure to test each of the "Help spread the word" links for

Twitter/Facebook/Google+ to make sure those applications are finding
the right images.  I don't mean the image on our page.  I mean the
image on the post once it is on Facebook, etc.  Since hundreds of such
posts have already been made, we probably don't want to break any of
those links.



You mean Twitter/Facebook/Google+ articles are referring to
".../download/images/*" files? That's bad, then we won't never be able to
move such kind of files in the future.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Why can't I find open office 2.3 for mac osx 10.5.8 on the website?

[Marcus (OOo)]

Am 04/03/2013 11:52 PM, schrieb David Coldwell:

version 3.0 files won't load into version 2.3 so I have to replace 3.0
with 2.3.


If you are searching for older version of OpenOffice please have a look 
for our archive:


en-US builds:
http://archive.apache.org/dist/incubator/ooo/stable/

localized builds:
http://archive.apache.org/dist/incubator/ooo/localized/


Why aren't there any links to older versions?


First of all we would like to make sure our users are using most recent 
version to get the most of the software.


Furthermore, there is also the problem that older versions are not 
perfect for newer operating systems. So, it's not unlikely that there 
will be install or system integration problems. Not to speak of security 
issues. None of these issues will be fixed in older releases.


So, it should be also of your interest to install and use the most 
recent version. But, of course, I can understand that there are edge 
cases where you really need an older or specific version.


HTH

Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Website] Re-locate images from "download/images/" to "images/"

[Kay Schenk]

On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo)  wrote:

> Am 04/01/2013 03:12 AM, schrieb Rob Weir:
>
>  On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)
>>  wrote:
>>
>>> Hi Rob,
>>>
>>> I want to cleanup the structure and remove 1 of the 2 directories for
>>> images.
>>>
>>> Therefore I've added the images from "download/images" also to "images/"
>>> and
>>> updated the "download/index.html" to point to the new location.
>>>
>>> Please tell me, is it save to remove the "download/images/" directory? If
>>> not what else has to be updated?
>>>
>>>
>> I'm not sure I like the idea of having a global images directory
>> rather than having images scoped to the subtree where they are
>> actually used.  Having a single global directory increases the changes
>> of having accidental conflicts.  But if you want to make this change,
>>
>
> That's not what I want. Please read again. I just want to get rid of 1 of
> the 2 images directories in the "download/" sub-dir.
>
> Of course it doesn't make sense to have a single images dir for the entire
> website. ;-)


Actually I don't think a single "images" directory for the whole site is
such a bad idea. We could subdivide it by area -- e.e. images/download.
Maybe worth discussing at some point?


>
>  be sure to test each of the "Help spread the word" links for
>> Twitter/Facebook/Google+ to make sure those applications are finding
>> the right images.  I don't mean the image on our page.  I mean the
>> image on the post once it is on Facebook, etc.  Since hundreds of such
>> posts have already been made, we probably don't want to break any of
>> those links.
>>
>
> You mean Twitter/Facebook/Google+ articles are referring to
> ".../download/images/*" files? That's bad, then we won't never be able to
> move such kind of files in the future.
>
>
> Marcus
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: [Lazy concensus] language merge into trunk.

[Marcus (OOo)]

Am 04/04/2013 05:21 PM, schrieb janI:

Hi.

Since we are now putting a lot of positive energy into 4.0, we have a lot
of changes in trunk and at the same time I have made language changes in
the l10n branch. This is a bad combination, that gives me quite some extra
manual work. Furthermore I would like the 4.0 language files to be clean
(whether we make them as po for sdf).

If there are no objections I will merge the language changes (NO code
changes) back into trunk.

The changes in trunk will primarely be in .src files, where language
different from en-US, as discussed in an earlier thread. This will not in
any way affect the modules or the build system. All changes are committed
in l10n branch.

If no objections I will merge into trunk, monday april 8 using lazy
consensus.


Sounds good, go for it.

*If* there will be any issues, it's IMHO still enough time for bugfixing.

Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Binfilter removal - PATCH

[Rob Weir]

On Thu, Apr 4, 2013 at 10:16 AM, Pavel Janík  wrote:

>
> >>> Anyone against the lazy approach - ie. doing this on trunk directly?
> This
> >>> could make testing much easier...
> >>
> >> +1 please do it on trunk !
> > It is already disabled by default when we build snapshots. I don't see
> any reason against doing it on trunk.
>
> Done on trunk. Module binfilter is still there though. Before removing it,
> I'd like to do some testing (I manually remove the module before the build).
> --
>

Excellent!

What should we put in the Release Notes for this?  We are started to
collect the info here:

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes

How would we explain this to end users?  What's the impact?  What do they
need to know?

Thanks!

-Rob


> Pavel Janík
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: questions about Base---do we need an embedded DB?

[Kay Schenk]

On Wed, Mar 27, 2013 at 10:48 AM, Max Merbald  wrote:

> Hello there,
>
> while the base module of AOO is not used all that often, it's the only
> free database software.


You may want to take a look at this page from Wikipedia. Not guaranteed of
course.

 http://en.wikipedia.org/wiki/Category:Free_database_management_systems

but I'm not sure of your context here.

If, for example, you want one from Microsoft you need to buy the very much
> overpriced MS Office Professional. Well, I've used Base already and I find
> it handy for my personal needs. I'm into registering all my books with it.
> I'd say the DB should be kept.
>
> By the way, Digitale Schultasche is Digital school bag, not school bar.
> While Germany is somewhat more liberal than, e. g., the US as it comes to
> alcohol they still don't open bars in schools... :-D
>
> Max
>
>
> Am 27.03.2013 18:30, schrieb Regina Henschel:
>
>  Hi Kay,
>>
>> Kay Schenk schrieb:
>>
>>> Well no doubt this may start a rather heated discussion.
>>>
>> [..]
>>
>>
>>> I don't really know who the author is, but, I too, had been giving this a
>>> great deal of thought. Does a user know what any of this really means,
>>> for
>>> example. And, including an embedded DB like HSQL puts added
>>> responsibility
>>> for that embedded DB on this project.  What if Base were strictly  a
>>> front-end?
>>>
>>> So, does anyone have any further insights into how many users, if any,
>>> directly use Base to create and use their own individual DBs as opposed
>>> to
>>> using the "front-end" capabilities?
>>>
>>>
>> I do not like the idea to drop the embedded DB. It is a nice feature,
>> when you teach pupils about database. It cannot be done with Calc or dBase
>> tables, because they have no relationships between tables, and teaching
>> foreign keys is essential. Using the embedded database has the advantage,
>> that it is portable. Pupils can have all their work on a USB stick and use
>> it at home and as school as well, without the need to install something or
>> to be online. This concept is known as "digitale Schultasche" (digital
>> schoolbar) here in Germany.
>>
>> Kind regards
>> Regina
>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@openoffice.**apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: [Proposal]: Call for donations

[Rob Weir]

On Thu, Apr 4, 2013 at 4:41 PM, Marcus (OOo)  wrote:

> Am 04/04/2013 04:29 PM, schrieb Raphael Bircher:
>
>  Am 04.04.13 14:22, schrieb Jürgen Schmidt:
>>
>>> Hi,
>>>
>>> in relation to our budget planning I asked myself if OpenOffice has any
>>> impact on the donations to the ASF? Well I don't know and we can
>>> probably figure this out but the question is what can we do ti collect
>>> more donations and use our brand more effective.
>>>
>>> When I look on our main website I found a tiny donation link in the
>>> footer only. From my point of view this is not good enough and we should
>>> think how we can improve it.
>>>
>>> I can think of a much more prominent and more visible donation link or
>>> whatever to make clear that OpenOffice will still benefit from donations
>>> to the ASF. We have more IT requirements than other ASF projects, we
>>> generate more network traffic, etc. and all this cost money.
>>>
>>> Furthermore I can think of a blog post to promote this in some way and
>>> do a public call for donation. We should of course do this more often
>>> with any public announcement.
>>>
>>> And opinions or further ideas how we can improve this? It shouldn't be a
>>> big problem for us to collect the money we need.
>>>
>> I disagree. Yes, we can help with foundings for ASF, but please do this
>> on ASF Level. Founding money is not the task of a ASF project, It's the
>> task for the foundation. It would be nice, if sameone from our project
>> work with the foundrising team from ASF. I personaly would also welcome
>> if the fundrising team use OOo to generate monay. But for my point of
>> view it's not a topic we (as Apache OpenOffice) project has to care about.
>>
>> So do this on Foundation level and not here. With other words: "Nice
>> idea, wrong place." Just my option.
>>
>
> Of course it's not our task to do/handle/manage the donations for the ASF.
> But how I understood Juergen's proposal this is not the case here.
>
> But we are profiting of these donations. So, I don't see any problems to
> support to increase them and to ask our users/contributors/friends to give
> some dollars/euros/... to the ASF.
>
> It's just a question of "what can we do to *help* the ASF as long as it's
> not a full time job".
>
>
That's a good way to think of it.  We" (AOO) don't run ApacheCon either,
but when registration gets close we're happy to send a note to our users
list and even put a button on our website to help drive greater
attendance.  If there is a fundraising drive I'm sure we can find a way to
help in similar way.

-Rob



> Marcus
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [Proposal]: Call for donations

[Marcus (OOo)]

Am 04/04/2013 04:29 PM, schrieb Raphael Bircher:

Am 04.04.13 14:22, schrieb Jürgen Schmidt:

Hi,

in relation to our budget planning I asked myself if OpenOffice has any
impact on the donations to the ASF? Well I don't know and we can
probably figure this out but the question is what can we do ti collect
more donations and use our brand more effective.

When I look on our main website I found a tiny donation link in the
footer only. From my point of view this is not good enough and we should
think how we can improve it.

I can think of a much more prominent and more visible donation link or
whatever to make clear that OpenOffice will still benefit from donations
to the ASF. We have more IT requirements than other ASF projects, we
generate more network traffic, etc. and all this cost money.

Furthermore I can think of a blog post to promote this in some way and
do a public call for donation. We should of course do this more often
with any public announcement.

And opinions or further ideas how we can improve this? It shouldn't be a
big problem for us to collect the money we need.

I disagree. Yes, we can help with foundings for ASF, but please do this
on ASF Level. Founding money is not the task of a ASF project, It's the
task for the foundation. It would be nice, if sameone from our project
work with the foundrising team from ASF. I personaly would also welcome
if the fundrising team use OOo to generate monay. But for my point of
view it's not a topic we (as Apache OpenOffice) project has to care about.

So do this on Foundation level and not here. With other words: "Nice
idea, wrong place." Just my option.


Of course it's not our task to do/handle/manage the donations for the 
ASF. But how I understood Juergen's proposal this is not the case here.


But we are profiting of these donations. So, I don't see any problems to 
support to increase them and to ask our users/contributors/friends to 
give some dollars/euros/... to the ASF.


It's just a question of "what can we do to *help* the ASF as long as 
it's not a full time job".


Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Thu, Apr 4, 2013 at 4:16 PM, Dennis E. Hamilton
wrote:

> You're *still* understating the extent of the ceremony.  They had to go
> through everything a subsequently-invited committer had to do, even though
> Sam Ruby provided the initial instructions.  But thanks for mentioning the
> iCLA.  That is an useful object to have on file in tracking down a possible
> credentials exploit.
>
>
It helps identify the person whose credentials were stolen.  This is hardly
a consultation to the user whose machine is hacked.  It doesn't prevent
anything.  But it does allow us to contact them and apologize for the
embarrassment we caused them by not taking sensible precautions to reduce
their authorization when they stopped being active with the project.



> I agree that there are those who never showed up after being established.
>  Rob apparently knows who they are.  I assume that any commits from those
> (maybe even logons anywhere) will raise vigilant eyebrows.  For double
> measure, Andrea should have the list, posted on private@ too and maybe
> filed in the PMC-private area.  That should establish adequate oversight.
>
>

I assume all checkins are reviewed, regardless of who they are from.  And
if we had supermen programmers who by their mere glance could detect every
subtle error in code that could be exploited, and do this 100% of the time
with perfect accuracy then I suppose we'd be fine.  At that point, of
course, I assume they would have found all the other bugs in OpenOffice as
well, and our perfect programmers would give us perfect software.  But none
of these things are likely.  In fact we know that is not true.  That is why
we occasionally need to issue security patches to fix *accidental* errors
that crept into code.  If we miss the accidental ones, then finding the
obfuscated ones intentionally placed would be rather more difficult.



> There are also a few committers who have announced their resignation and
> not since rescinded it.  Put those on that "watch list" also.
>
> I don't know what is to be done if any of those have used 
> @openoffice.orge-mail addresses in their iCLA and as their @a.o forwarding 
> address.  I
> suppose those are the best to attempt impersonating.  The first act to be
> accessing the profile of an user -- thus confirming the credential -- and
> changing the forwarding address.  Then opting-in should be relatively easy,
> especially if the original @a.o-holder is not watching any lists here.
>  Having done that, a malefactor can proceed to establish a PGP signature
> verified for the @a.o too.
>
> So, to lock this door, it is *really* necessary to lock-down those
> committer profiles and remove their authz everywhere.  To be reinstated, it
> is probably necessary to convince the Secretary of the ASF that the request
> is authentic.
>
>
Or do what do right now.  The last time there was concern about the Apache
ID's, Infra just reset the passwords.  Everyone had to request a new
password which was sent to their email account of record.  If their email
account is down, then they would need to provide other acceptable proof.
That might be slower.

Note that unlikely that a committer re-appears after not doing anything for
2 years and has an urgent need to check in code.  But if it does happen we
have ways of making it work.  But it should be extremely rare.

-Rob


>  - Dennis
>
> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org]
> Sent: Thursday, April 04, 2013 12:54
> To: dev@openoffice.apache.org
> Subject: Re: Proposal: Improve security by limiting committer access in SVN
>
> [ ... ]
>
> But with OpenOffice, there was a two week period of time when we rapidly
> bootstrapped the community by making people committers automatically, on
> day 1.  All they had to do is put their name on a wiki page and return an
> ICLA and they were committers.  No vetting, no vote.  Quite a few of them
> never got involved in the project in even the least degree.  So we have
> these phantom community members, with authorization to change the source
> code.
>
> Regards,
>
> -Rob
>
> [ ... ]
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

RE: Proposal: Improve security by limiting committer access in SVN

[Dennis E. Hamilton]

You're *still* understating the extent of the ceremony.  They had to go through 
everything a subsequently-invited committer had to do, even though Sam Ruby 
provided the initial instructions.  But thanks for mentioning the iCLA.  That 
is an useful object to have on file in tracking down a possible credentials 
exploit.

I agree that there are those who never showed up after being established.  Rob 
apparently knows who they are.  I assume that any commits from those (maybe 
even logons anywhere) will raise vigilant eyebrows.  For double measure, Andrea 
should have the list, posted on private@ too and maybe filed in the PMC-private 
area.  That should establish adequate oversight.

There are also a few committers who have announced their resignation and not 
since rescinded it.  Put those on that "watch list" also.

I don't know what is to be done if any of those have used @openoffice.org 
e-mail addresses in their iCLA and as their @a.o forwarding address.  I suppose 
those are the best to attempt impersonating.  The first act to be accessing the 
profile of an user -- thus confirming the credential -- and changing the 
forwarding address.  Then opting-in should be relatively easy, especially if 
the original @a.o-holder is not watching any lists here.  Having done that, a 
malefactor can proceed to establish a PGP signature verified for the @a.o too.

So, to lock this door, it is *really* necessary to lock-down those committer 
profiles and remove their authz everywhere.  To be reinstated, it is probably 
necessary to convince the Secretary of the ASF that the request is authentic.

 - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Thursday, April 04, 2013 12:54
To: dev@openoffice.apache.org
Subject: Re: Proposal: Improve security by limiting committer access in SVN

[ ... ]

But with OpenOffice, there was a two week period of time when we rapidly
bootstrapped the community by making people committers automatically, on
day 1.  All they had to do is put their name on a wiki page and return an
ICLA and they were committers.  No vetting, no vote.  Quite a few of them
never got involved in the project in even the least degree.  So we have
these phantom community members, with authorization to change the source
code.

Regards,

-Rob

[ ... ]


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Thu, Apr 4, 2013 at 3:59 PM, Joe Schaefer  wrote:

> Ah NO.  Those so-called "phantom" committers
> had their commit to this projext revoked when you graduated
>


Hi Joe,

See the list here:

http://people.apache.org/committers-by-project.html#openoffice

I've been tracking the length of that list since July 2011.  It has not
decreased.  You can see that here:

http://www.openoffice.org/stats/committers.html

Maybe you are thinking of openoffice-pmc?  I know the PPMC list was reduced
when making the TLP's PMC, but did anything happen to the committers list?



> to a TLP, but the larger point that Greg's making
> remains true- it is a false sense of security to
> rely on ACL's to pretend you don't need to vet your
> commit list.  See http://www.apache.org/dev/open-access-svn
> for more details of an ongoing debate to simplify
> our svn rules accordingly.
>


One of our issues is that being a committer enables access to multiple
systems. some controlled by LDAP, some by authz and some manually, e.g.,
access to editor rights in the blog.

I think there is room for having someone be a committer and having access
to all the systems that they want access to for the work they want to do,
without assuming that they need access to everything just because they are
committers.  This might be different in projects where 99% of the commiters
are coders.  But in our case, our demographics is far different.  I hope we
all appreciate that this difference exists.

Regards,

-Rob


>
>
>
>
>
> >
> > From: Rob Weir 
> >To: "dev@openoffice.apache.org" 
> >Sent: Thursday, April 4, 2013 3:53 PM
> >Subject: Re: Proposal: Improve security by limiting committer access in
> SVN
> >
> >On Thu, Apr 4, 2013 at 3:17 PM, janI  wrote:
> >
> >> On 4 April 2013 21:03, Rob Weir  wrote:
> >>
> >> > On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein  wrote:
> >> >
> >> > > Your proposal to alter the community structure is premised upon a
> >> > > strawman risk. First, that it would occur. Second, that it wouldn't
> be
> >> > > noticed. Third, that it would find its way into users' hands.
> >> > >
> >> > >
> >> > So you are asserting that someone who put their name down on the
> >> Incubator
> >> > wiki in July 2011 and was named a committer by that act, but never
> ever
> >> > showed up after that, never joined the dev list, never posted to the
> dev
> >> > list, never contributed code or anything else other than a name on a
> >> wiki,
> >> > is a member of our community and it would be altering the committee
> >> > structure if we removed their authz to our source code, even with the
> >> > proviso that we would immediately restore it on request?
> >> >
> >> > Really?
> >> >
> >>
> >> Just a stupid question from someone who have not been here for
> ages...the
> >> person just described should loose the committer role, or are we granted
> >> commitership for lifetime ??
> >>
> >>
> >"Typical" and "Apache OpenOffice" should never be used in the same
> sentence
> >unless mischief is intended ;-)
> >
> >But other projects, being a committer is permanent, aside from resignation
> >or extreme cases.  But for most projects becoming a committer requires
> >being involved with the project, demonstrating merit, being voted in by a
> >PMC, etc., just like you did.
> >
> >But with OpenOffice, there was a two week period of time when we rapidly
> >bootstrapped the community by making people committers automatically, on
> >day 1.  All they had to do is put their name on a wiki page and return an
> >ICLA and they were committers.  No vetting, no vote.  Quite a few of them
> >never got involved in the project in even the least degree.  So we have
> >these phantom community members, with authorization to change the source
> >code.
> >
> >Regards,
> >
> >-Rob
> >
> >
> >
> >> jan I.
> >>
> >> >
> >> > -Rob
> >> >
> >> >
> >> >
> >> > > In the past, the Foundation has *explicitly* said that we would
> accept
> >> > > a certain level of risk to maintain our communities.
> >> > >
> >> > > I find your strawman at a level even *lower* than the scenario that
> >> > > I'm thinking about(*).
> >> > >
> >> > > If you're worried about stale committers suddenly inserting trojans,
> >> > > then just use 'svn log' to find those outliers. No need to create
> >> > > division within the community. Run a simple histogram. There are
> many
> >> > > solutions to your purported attack vector, than to divide into
> groups.
> >> > >
> >> > > Cheers,
> >> > > -g
> >> > >
> >> > > (*) a certain large company's lawyer (ahem) was trying to scare the
> >> > > ASF ("the risk!!") into adopting certain procedures; we shut her
> down
> >> > >
> >> > > On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> >> > > > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein 
> wrote:
> >> > > >
> >> > > > > Also, let me say one more thing:
> >> > > > >
> >> > > > > This notion of creating divisions among committers ... it is
> >> > "solving"
> >> > > > > a problem that has 

Re: Proposal: Improve security by limiting committer access in SVN

[Joe Schaefer]

Ah NO.  Those so-called "phantom" committers
had their commit to this projext revoked when you graduated
to a TLP, but the larger point that Greg's making
remains true- it is a false sense of security to
rely on ACL's to pretend you don't need to vet your
commit list.  See http://www.apache.org/dev/open-access-svn
for more details of an ongoing debate to simplify
our svn rules accordingly.





>
> From: Rob Weir 
>To: "dev@openoffice.apache.org"  
>Sent: Thursday, April 4, 2013 3:53 PM
>Subject: Re: Proposal: Improve security by limiting committer access in SVN
> 
>On Thu, Apr 4, 2013 at 3:17 PM, janI  wrote:
>
>> On 4 April 2013 21:03, Rob Weir  wrote:
>>
>> > On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein  wrote:
>> >
>> > > Your proposal to alter the community structure is premised upon a
>> > > strawman risk. First, that it would occur. Second, that it wouldn't be
>> > > noticed. Third, that it would find its way into users' hands.
>> > >
>> > >
>> > So you are asserting that someone who put their name down on the
>> Incubator
>> > wiki in July 2011 and was named a committer by that act, but never ever
>> > showed up after that, never joined the dev list, never posted to the dev
>> > list, never contributed code or anything else other than a name on a
>> wiki,
>> > is a member of our community and it would be altering the committee
>> > structure if we removed their authz to our source code, even with the
>> > proviso that we would immediately restore it on request?
>> >
>> > Really?
>> >
>>
>> Just a stupid question from someone who have not been here for ages...the
>> person just described should loose the committer role, or are we granted
>> commitership for lifetime ??
>>
>>
>"Typical" and "Apache OpenOffice" should never be used in the same sentence
>unless mischief is intended ;-)
>
>But other projects, being a committer is permanent, aside from resignation
>or extreme cases.  But for most projects becoming a committer requires
>being involved with the project, demonstrating merit, being voted in by a
>PMC, etc., just like you did.
>
>But with OpenOffice, there was a two week period of time when we rapidly
>bootstrapped the community by making people committers automatically, on
>day 1.  All they had to do is put their name on a wiki page and return an
>ICLA and they were committers.  No vetting, no vote.  Quite a few of them
>never got involved in the project in even the least degree.  So we have
>these phantom community members, with authorization to change the source
>code.
>
>Regards,
>
>-Rob
>
>
>
>> jan I.
>>
>> >
>> > -Rob
>> >
>> >
>> >
>> > > In the past, the Foundation has *explicitly* said that we would accept
>> > > a certain level of risk to maintain our communities.
>> > >
>> > > I find your strawman at a level even *lower* than the scenario that
>> > > I'm thinking about(*).
>> > >
>> > > If you're worried about stale committers suddenly inserting trojans,
>> > > then just use 'svn log' to find those outliers. No need to create
>> > > division within the community. Run a simple histogram. There are many
>> > > solutions to your purported attack vector, than to divide into groups.
>> > >
>> > > Cheers,
>> > > -g
>> > >
>> > > (*) a certain large company's lawyer (ahem) was trying to scare the
>> > > ASF ("the risk!!") into adopting certain procedures; we shut her down
>> > >
>> > > On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
>> > > > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
>> > > >
>> > > > > Also, let me say one more thing:
>> > > > >
>> > > > > This notion of creating divisions among committers ... it is
>> > "solving"
>> > > > > a problem that has never occurred here.
>> > > > >
>> > > > > NEVER. OCCURRED.
>> > > > >
>> > > > >
>> > > > So frickin' what?  That is entirely irrelevant.   My house has never
>> > > burnt
>> > > > down either, but I still don't leave open flames around unattended.
>>  In
>> > > > fact you might think this is naive view, but avoidance of such risks
>> > > might
>> > > > even be correlated with lack of house fires.  Hmmm
>> > > >
>> > > >
>> > > >
>> > > > > In the Foundations's 14+ year history, we have never seen a trojan
>> > > > > commit. Our servers have been compromised a handful of times. When
>> we
>> > > > > were back on CVS, we even had to audit source control to verify no
>> > > > > trojan injection. But we have NEVER had a case of a malware commit.
>> > > > >
>> > > > >
>> > > > Again, that proves nothing.   I'm sure the first time apache.org was
>> > > rooted
>> > > > that it had never happened before either, right?
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > > So back to IMO: dividing and partitioning and separate privilege
>> > > > > levels... there is no reason. It creates a social problem to
>> "solve"
>> > a
>> > > > > non-existent issue. Net result: more problems.
>> > > > >
>> > > > >
>> > > >
>> > > > Greg, we already do this.  Does every ASF Member have credential for
>> > 

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Thu, Apr 4, 2013 at 3:17 PM, janI  wrote:

> On 4 April 2013 21:03, Rob Weir  wrote:
>
> > On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein  wrote:
> >
> > > Your proposal to alter the community structure is premised upon a
> > > strawman risk. First, that it would occur. Second, that it wouldn't be
> > > noticed. Third, that it would find its way into users' hands.
> > >
> > >
> > So you are asserting that someone who put their name down on the
> Incubator
> > wiki in July 2011 and was named a committer by that act, but never ever
> > showed up after that, never joined the dev list, never posted to the dev
> > list, never contributed code or anything else other than a name on a
> wiki,
> > is a member of our community and it would be altering the committee
> > structure if we removed their authz to our source code, even with the
> > proviso that we would immediately restore it on request?
> >
> > Really?
> >
>
> Just a stupid question from someone who have not been here for ages...the
> person just described should loose the committer role, or are we granted
> commitership for lifetime ??
>
>
"Typical" and "Apache OpenOffice" should never be used in the same sentence
unless mischief is intended ;-)

But other projects, being a committer is permanent, aside from resignation
or extreme cases.  But for most projects becoming a committer requires
being involved with the project, demonstrating merit, being voted in by a
PMC, etc., just like you did.

But with OpenOffice, there was a two week period of time when we rapidly
bootstrapped the community by making people committers automatically, on
day 1.  All they had to do is put their name on a wiki page and return an
ICLA and they were committers.  No vetting, no vote.  Quite a few of them
never got involved in the project in even the least degree.  So we have
these phantom community members, with authorization to change the source
code.

Regards,

-Rob



> jan I.
>
> >
> > -Rob
> >
> >
> >
> > > In the past, the Foundation has *explicitly* said that we would accept
> > > a certain level of risk to maintain our communities.
> > >
> > > I find your strawman at a level even *lower* than the scenario that
> > > I'm thinking about(*).
> > >
> > > If you're worried about stale committers suddenly inserting trojans,
> > > then just use 'svn log' to find those outliers. No need to create
> > > division within the community. Run a simple histogram. There are many
> > > solutions to your purported attack vector, than to divide into groups.
> > >
> > > Cheers,
> > > -g
> > >
> > > (*) a certain large company's lawyer (ahem) was trying to scare the
> > > ASF ("the risk!!") into adopting certain procedures; we shut her down
> > >
> > > On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> > > > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
> > > >
> > > > > Also, let me say one more thing:
> > > > >
> > > > > This notion of creating divisions among committers ... it is
> > "solving"
> > > > > a problem that has never occurred here.
> > > > >
> > > > > NEVER. OCCURRED.
> > > > >
> > > > >
> > > > So frickin' what?  That is entirely irrelevant.   My house has never
> > > burnt
> > > > down either, but I still don't leave open flames around unattended.
>  In
> > > > fact you might think this is naive view, but avoidance of such risks
> > > might
> > > > even be correlated with lack of house fires.  Hmmm
> > > >
> > > >
> > > >
> > > > > In the Foundations's 14+ year history, we have never seen a trojan
> > > > > commit. Our servers have been compromised a handful of times. When
> we
> > > > > were back on CVS, we even had to audit source control to verify no
> > > > > trojan injection. But we have NEVER had a case of a malware commit.
> > > > >
> > > > >
> > > > Again, that proves nothing.   I'm sure the first time apache.org was
> > > rooted
> > > > that it had never happened before either, right?
> > > >
> > > >
> > > >
> > > >
> > > > > So back to IMO: dividing and partitioning and separate privilege
> > > > > levels... there is no reason. It creates a social problem to
> "solve"
> > a
> > > > > non-existent issue. Net result: more problems.
> > > > >
> > > > >
> > > >
> > > > Greg, we already do this.  Does every ASF Member have credential for
> > > Infra
> > > > root?  Does ever ASF Member have access to legal-private mailing
> list.
> > >  No.
> > > > No. We even do this in the AOO project, with separate authz for
> > > > openoffice-security, which by the way also includes an SVN tree.
> > > >
> > > > Anyone who thinks this is a question of dividing and privilege is
> > > > expressing a knee-jerk reaction, without thinking of the risks.  We
> > > should
> > > > avoid regurgitating platitudes.  Remember, we're talking about people
> > who
> > > > have never committed code, who don't even know C, who are not even
> > > > subscribed to the dev mailing list, and in some cases have never ever
> > > > posted to our mailing lists.  They signed up in with the podli

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Thu, Apr 4, 2013 at 3:30 PM, Dennis E. Hamilton
wrote:

> OK, I will speak further.
>
> There are no such people among the current committers.  It took *more*
> than being on the June 2011 proposal to become established as an initial
> committer.  And you know that.  There was considerable activity to on-board
> the willing and have them be established as committers and PPMC members.
>  Those who did not show up that much did have their invitations revoked.
>  That was over one year ago.  (There were also some who declined
> straight-away.)
>


Actually there are people like this.  You should check.  I did.I
appreciate that you and others did additional work to onboard people,
tracking their ID's and ICLA's, making spreadsheets, etc.  But some of them
never did anything since then, never subscribing or posting to the mailing
list.

>
> (At the time, of course, it was apparently in the interests of some to
> crow about the number of committers there were.)
>
> I already commented that "restoration on request" is, without some other
> measures, easy to spoof by someone who has obtained the necessary
> credentials, especially if those credentials are for someone not subscribed
> to the dev list.
>
>
Maybe you want to suggest some additional measures?



> I still consider it far more likely that someone will use an avenue that
> provides more protection against discovery (of either the attacker or the
> exploit) and has more direct rewards.  Even for a compromised bad password
> that happens to go with an @a.o credential.  I claim that the risk
> management here is being distorted by some sort of absolutism.  I must
> remember that the next time I am told that a pass-the-hash attack on an
> encrypted ODF document is infeasible despite it being comparatively trivial
> and defies detection.
>
>
The inability to do everything is not an excuse for avoiding to take
reasonable precautions to reduce our exposure.  Giving write access to
source code for a product that millions of users install to people who are
not by any meaning of the word members of our community is ridiculous.  To
suggest otherwise is absolutism, of a "Community Ueber Alles" type that
discredits any understanding of what community means.  Someone who is not
here and never was is not a member of the community.  Why exactly we should
leave the gates open to them is an unanswered question.

-Rob



>  - Dennis
>
> PS: I suspect that the protective action will be taken as the only way to
> stop this conversation.  That will be its only achievement.
>
> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org]
> Sent: Thursday, April 04, 2013 12:03
> To: dev@openoffice.apache.org
> Subject: Re: Proposal: Improve security by limiting committer access in SVN
>
> On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein  wrote:
>
> > Your proposal to alter the community structure is premised upon a
> > strawman risk. First, that it would occur. Second, that it wouldn't be
> > noticed. Third, that it would find its way into users' hands.
> >
> >
> So you are asserting that someone who put their name down on the Incubator
> wiki in July 2011 and was named a committer by that act, but never ever
> showed up after that, never joined the dev list, never posted to the dev
> list, never contributed code or anything else other than a name on a wiki,
> is a member of our community and it would be altering the committee
> structure if we removed their authz to our source code, even with the
> proviso that we would immediately restore it on request?
>
> Really?
>
> -Rob
>
>
>
> > In the past, the Foundation has *explicitly* said that we would accept
> > a certain level of risk to maintain our communities.
> >
> > I find your strawman at a level even *lower* than the scenario that
> > I'm thinking about(*).
> >
> > If you're worried about stale committers suddenly inserting trojans,
> > then just use 'svn log' to find those outliers. No need to create
> > division within the community. Run a simple histogram. There are many
> > solutions to your purported attack vector, than to divide into groups.
> >
> > Cheers,
> > -g
> >
> > (*) a certain large company's lawyer (ahem) was trying to scare the
> > ASF ("the risk!!") into adopting certain procedures; we shut her down
> >
> > On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> > > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
> > >
> > > > Also, let me say one more thing:
> > > >
> > > > This notion of creating divisions among committers ... it is
> "solving"
> > > > a problem that has never occurred here.
> > > >
> > > > NEVER. OCCURRED.
> > > >
> > > >
> > > So frickin' what?  That is entirely irrelevant.   My house has never
> > burnt
> > > down either, but I still don't leave open flames around unattended.  In
> > > fact you might think this is naive view, but avoidance of such risks
> > might
> > > even be correlated with lack of house fires.  Hmmm
> > >
> > >
> > >
> > > > In the Foundati

RE: Proposal: Improve security by limiting committer access in SVN

[Dennis E. Hamilton]

OK, I will speak further.  

There are no such people among the current committers.  It took *more* than 
being on the June 2011 proposal to become established as an initial committer.  
And you know that.  There was considerable activity to on-board the willing and 
have them be established as committers and PPMC members.  Those who did not 
show up that much did have their invitations revoked.  That was over one year 
ago.  (There were also some who declined straight-away.)

(At the time, of course, it was apparently in the interests of some to crow 
about the number of committers there were.)

I already commented that "restoration on request" is, without some other 
measures, easy to spoof by someone who has obtained the necessary credentials, 
especially if those credentials are for someone not subscribed to the dev list.

I still consider it far more likely that someone will use an avenue that 
provides more protection against discovery (of either the attacker or the 
exploit) and has more direct rewards.  Even for a compromised bad password that 
happens to go with an @a.o credential.  I claim that the risk management here 
is being distorted by some sort of absolutism.  I must remember that the next 
time I am told that a pass-the-hash attack on an encrypted ODF document is 
infeasible despite it being comparatively trivial and defies detection.

 - Dennis

PS: I suspect that the protective action will be taken as the only way to stop 
this conversation.  That will be its only achievement.

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Thursday, April 04, 2013 12:03
To: dev@openoffice.apache.org
Subject: Re: Proposal: Improve security by limiting committer access in SVN

On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein  wrote:

> Your proposal to alter the community structure is premised upon a
> strawman risk. First, that it would occur. Second, that it wouldn't be
> noticed. Third, that it would find its way into users' hands.
>
>
So you are asserting that someone who put their name down on the Incubator
wiki in July 2011 and was named a committer by that act, but never ever
showed up after that, never joined the dev list, never posted to the dev
list, never contributed code or anything else other than a name on a wiki,
is a member of our community and it would be altering the committee
structure if we removed their authz to our source code, even with the
proviso that we would immediately restore it on request?

Really?

-Rob



> In the past, the Foundation has *explicitly* said that we would accept
> a certain level of risk to maintain our communities.
>
> I find your strawman at a level even *lower* than the scenario that
> I'm thinking about(*).
>
> If you're worried about stale committers suddenly inserting trojans,
> then just use 'svn log' to find those outliers. No need to create
> division within the community. Run a simple histogram. There are many
> solutions to your purported attack vector, than to divide into groups.
>
> Cheers,
> -g
>
> (*) a certain large company's lawyer (ahem) was trying to scare the
> ASF ("the risk!!") into adopting certain procedures; we shut her down
>
> On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
> >
> > > Also, let me say one more thing:
> > >
> > > This notion of creating divisions among committers ... it is "solving"
> > > a problem that has never occurred here.
> > >
> > > NEVER. OCCURRED.
> > >
> > >
> > So frickin' what?  That is entirely irrelevant.   My house has never
> burnt
> > down either, but I still don't leave open flames around unattended.  In
> > fact you might think this is naive view, but avoidance of such risks
> might
> > even be correlated with lack of house fires.  Hmmm
> >
> >
> >
> > > In the Foundations's 14+ year history, we have never seen a trojan
> > > commit. Our servers have been compromised a handful of times. When we
> > > were back on CVS, we even had to audit source control to verify no
> > > trojan injection. But we have NEVER had a case of a malware commit.
> > >
> > >
> > Again, that proves nothing.   I'm sure the first time apache.org was
> rooted
> > that it had never happened before either, right?
> >
> >
> >
> >
> > > So back to IMO: dividing and partitioning and separate privilege
> > > levels... there is no reason. It creates a social problem to "solve" a
> > > non-existent issue. Net result: more problems.
> > >
> > >
> >
> > Greg, we already do this.  Does every ASF Member have credential for
> Infra
> > root?  Does ever ASF Member have access to legal-private mailing list.
>  No.
> > No. We even do this in the AOO project, with separate authz for
> > openoffice-security, which by the way also includes an SVN tree.
> >
> > Anyone who thinks this is a question of dividing and privilege is
> > expressing a knee-jerk reaction, without thinking of the risks.  We
> should
> > avoid regurgitating platitudes.  Remember, we'

Re: [Lazy concensus] language merge into trunk.

[janI]

On 4 April 2013 20:58, Rob Weir  wrote:

> On Thu, Apr 4, 2013 at 11:21 AM, janI  wrote:
>
> > Hi.
> >
> > Since we are now putting a lot of positive energy into 4.0, we have a lot
> > of changes in trunk and at the same time I have made language changes in
> > the l10n branch. This is a bad combination, that gives me quite some
> extra
> > manual work. Furthermore I would like the 4.0 language files to be clean
> > (whether we make them as po for sdf).
> >
> > If there are no objections I will merge the language changes (NO code
> > changes) back into trunk.
> >
> > The changes in trunk will primarely be in .src files, where language
> > different from en-US, as discussed in an earlier thread. This will not in
> > any way affect the modules or the build system. All changes are committed
> > in l10n branch.
> >
> > If no objections I will merge into trunk, monday april 8 using lazy
> > consensus.
> >
> >
> So we had translations in Pootle, in the 3.4 branch and in the trunk.  I
> assume you're able to get us all back together?  If so, this is a big step
> forward.  Thanks!
>

Yes if you look in branches/l10n/solenv/lang you will find a consolidated
set of po files (which cannot be used for 4.0, before I get genLang
integrated in build)

A message with a non en-US languages  in the source code "overrule" a real
translation (comming from pootle or elsewhere) of that message (by simple
order of presence).

These messages are wrong, and the new genLang does not allow them.

rgds
jan I




>
> -Rob
>
>
>
> > rgds
> > Jan I.
> >
>

Re: Proposal: Improve security by limiting committer access in SVN

[janI]

On 4 April 2013 21:03, Rob Weir  wrote:

> On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein  wrote:
>
> > Your proposal to alter the community structure is premised upon a
> > strawman risk. First, that it would occur. Second, that it wouldn't be
> > noticed. Third, that it would find its way into users' hands.
> >
> >
> So you are asserting that someone who put their name down on the Incubator
> wiki in July 2011 and was named a committer by that act, but never ever
> showed up after that, never joined the dev list, never posted to the dev
> list, never contributed code or anything else other than a name on a wiki,
> is a member of our community and it would be altering the committee
> structure if we removed their authz to our source code, even with the
> proviso that we would immediately restore it on request?
>
> Really?
>

Just a stupid question from someone who have not been here for ages...the
person just described should loose the committer role, or are we granted
commitership for lifetime ??

jan I.

>
> -Rob
>
>
>
> > In the past, the Foundation has *explicitly* said that we would accept
> > a certain level of risk to maintain our communities.
> >
> > I find your strawman at a level even *lower* than the scenario that
> > I'm thinking about(*).
> >
> > If you're worried about stale committers suddenly inserting trojans,
> > then just use 'svn log' to find those outliers. No need to create
> > division within the community. Run a simple histogram. There are many
> > solutions to your purported attack vector, than to divide into groups.
> >
> > Cheers,
> > -g
> >
> > (*) a certain large company's lawyer (ahem) was trying to scare the
> > ASF ("the risk!!") into adopting certain procedures; we shut her down
> >
> > On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> > > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
> > >
> > > > Also, let me say one more thing:
> > > >
> > > > This notion of creating divisions among committers ... it is
> "solving"
> > > > a problem that has never occurred here.
> > > >
> > > > NEVER. OCCURRED.
> > > >
> > > >
> > > So frickin' what?  That is entirely irrelevant.   My house has never
> > burnt
> > > down either, but I still don't leave open flames around unattended.  In
> > > fact you might think this is naive view, but avoidance of such risks
> > might
> > > even be correlated with lack of house fires.  Hmmm
> > >
> > >
> > >
> > > > In the Foundations's 14+ year history, we have never seen a trojan
> > > > commit. Our servers have been compromised a handful of times. When we
> > > > were back on CVS, we even had to audit source control to verify no
> > > > trojan injection. But we have NEVER had a case of a malware commit.
> > > >
> > > >
> > > Again, that proves nothing.   I'm sure the first time apache.org was
> > rooted
> > > that it had never happened before either, right?
> > >
> > >
> > >
> > >
> > > > So back to IMO: dividing and partitioning and separate privilege
> > > > levels... there is no reason. It creates a social problem to "solve"
> a
> > > > non-existent issue. Net result: more problems.
> > > >
> > > >
> > >
> > > Greg, we already do this.  Does every ASF Member have credential for
> > Infra
> > > root?  Does ever ASF Member have access to legal-private mailing list.
> >  No.
> > > No. We even do this in the AOO project, with separate authz for
> > > openoffice-security, which by the way also includes an SVN tree.
> > >
> > > Anyone who thinks this is a question of dividing and privilege is
> > > expressing a knee-jerk reaction, without thinking of the risks.  We
> > should
> > > avoid regurgitating platitudes.  Remember, we're talking about people
> who
> > > have never committed code, who don't even know C, who are not even
> > > subscribed to the dev mailing list, and in some cases have never ever
> > > posted to our mailing lists.  They signed up in with the podling in
> July
> > > 2011 and then were never heard of again.  You make an extremely weak
> > > argument to pontificate about "privilege" here.
> > >
> > > The risks are real.  High profile open source projects attract these
> > kinds
> > > of attacks.  There are those who know it, and those who don't know it
> > yet.
> > >
> > > A good read:
> > >
> >
> http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked
> > >
> > > As for those who think that casual review of commit messages will
> review
> > > any attack, that is a dangerously naive few.  We should not expect an
> > > attack to be in a filed called trojan.c with comments and clear logic
> > > explaining what the code does.  Any hacker with a clue would send a
> patch
> > > backed by a reasonable defect report in Bugzilla that would be
> innocuous
> > to
> > > casual inspection.  All you need is a buffer or stack overwrite in a
> > > well-placed area to cause the problem.  This might even be done in two
> > > stages, spread out over time, so the impact is not detectable without
> > > looking at 

Re: [RELEASE]: proposed schedule for AOO 4.0

[Juergen Schmidt]

Am Donnerstag, 4. April 2013 um 19:40 schrieb Kay Schenk:
> On Thu, Apr 4, 2013 at 4:07 AM, Jürgen Schmidt wrote:
>  
> > On 4/4/13 11:27 AM, mengualjean...@free.fr wrote:
> > > Hi,
> > >  
> > > Does some cycle exist about releasing of OOo? Because since the
> > schedule, it seems that OOo 4.0 will not include current work about
> > accessibility. It is a pitty as I think it is a major contribution and it
> > would be a pitty if we should wait for end of 2014 to see it. It seems
> > things could be ready for novembre. Do you think we can hope progress
> > during 1st six months 2014? In a 4.1 release I get?
> > >  
> >  
> >  
> > we had 2 releases last year and I don't see any reason why we should not
> > have 2 releases this year. It really depends on what we have for a new
> > release. We don't want release something only to have a new release.
> >  
> > The accessibility work is a big and major task and takes some time. It
> > can't be finished in time for 4.0 but we will see how the development
> > moves forward. It can be a good candidate for a 4.1.
> >  
> > Juergen
>  
> I think the last update we got on the accessibility work indicated end of
> June for completion...
>  
> http://markmail.org/message/ipdmx3scax4umc2s
>  
> so, do we think we shouldn't wait on this for 4.0?
I believe this is a misunderstanding but I am open to learn something else... 
;-)

Juergen  
>  
>  
> >  
> > > Regards,
> > >  
> > > - Mail d'origine -
> > > De: Jürgen Schmidt 
> > > À: dev@openoffice.apache.org
> > > Envoyé: Thu, 04 Apr 2013 10:46:16 +0200 (CEST)
> > > Objet: Re: [RELEASE]: proposed schedule for AOO 4.0
> > >  
> > > On 2/20/13 11:32 AM, Jürgen Schmidt wrote:
> > > > On 2/20/13 10:46 AM, Jürgen Schmidt wrote:
> > > > > Hi,
> > > > >  
> > > > > we make good progress with the sidebar work which is done on the
> > branch.
> > > > > The sidebar will be the most visible and important change for 4.0 (by
> > > > > the way I like what I have seen so far). We come closer to the point
> > > > > where we should talk about a more detailed schedule.
> > > > >  
> > > > > I would like to start with the following proposal and still many steps
> > > > > have to be defined in more detail.
> > > > >  
> > > > > 03/01 function verification test will start, define test case, prepare
> > > > > tests etc.
> > > > > 04/04 integrate sidebar branch in trunk, other new features should be
> > > > > finished by this date as well.
> > > > >  
> > > >  
> > > >  
> > > > I missed to add that the art work (logo, icons, etc. should be finished
> > > > at this date as well)
> > > >  
> > > > > 04/05 - 05/15 regression testing will be start on trunk
> > > > > 04/05 - 05/15 bugfix and stabilization, no feature development
> > > > > 04/08 - 05/15 translation -> I guessed ~5 weeks for updating the new
> > > > > strings. This can change when we know exactly how many new strings we
> > > > > will have. But translation for new languages can already work on the
> > > > > existing po files for 3.4.1.
> > > > > 05/21 RC1
> > > > > 06/04 RC2
> > > > > 06/18 RC3 (optional), can be GA already
> > > > > 06/25 GA -> this should be our final target
> > > > >  
> > > > >  
> > > > > This is a proposal based on the ongoing work that I no. Please let me
> > > > > know if I missed something important.
> > > > >  
> > > > > Regular developer builds 1/week + nightly builds
> > > > >  
> > > > > Based on feedback and potential changes I will put this in the wiki
> > later.
> > > > >  
> > > > > Important is from my pov that we start talking about the improvements
> > > > > that we make in public. It should be very clear for anybody where the
> > > > > real important features and improvement for OpenOffice or derivatives
> > > > > are coming from ;-)
> > > > >  
> > > >  
> > >  
> > >  
> > > I will try to give n update on the current plan.
> > >  
> > > The sidebar branch is not yet integrated but I expect that it will be
> > > finished next week latest. That means we will have a delay of some days
> > > here. As soon as I have concrete dates I will update the plan in the
> > >  
> >  
> > wiki.
> > >  
> > > Some further things are ongoing and we should try to finish this work
> > > soon (2 weeks) to have the stuff in place and can start or concentrate
> > > on bug fixing and stabilization.
> > >  
> > > Juergen
> > >  
> > >  
> > >  
> > >  
> > >  
> > > > >  
> > > > >  
> > > > > Juergen
> > >  
> > >  
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >  
> > >  
> > >  
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >  
> >  
> >  
> >  
> > -

Re: [Proposal]: Call for donations

[Juergen Schmidt]

Hi,  

sorry for my top posting but I always fail to quote emails like this correct.

It is no big thing here, the ASF had a pay pal account and people can donate 
whatever they want. We simply have to encourage people to do it and gave to 
make clear that donations are made for ASF and not only AOO. Nothing more and 
nothing less, quite straight forward and transparent to everybody.

@Raphael, I don't have a problem to use our popular brand to collect money for 
the ASF in general. It' s gone for me if other good open source projects can 
benefit as well. It simply have to be clear from the beginning.  


Am Donnerstag, 4. April 2013 um 18:04 schrieb Dennis E. Hamilton:

> The PPMC went through this some time ago, because there were OO.o-specific 
> donation mechanisms that had to be either retired or redirected to ASF 
> donations. (There is a small-donation place for ASF donations. I used it once 
> to see how it worked.)  
>  
> Start here: .
>  
> As I recall: Short answer: the project can't solicit donations for 
> project-specific purposes. Longer answer: (1) Outside parties can raise funds 
> *and*disburse*them* for whatever they want to support, such as student 
> attendance at conferences, whatever. GSoC provides funding to the GSoC 
> "interns." (2) That party can't claim any affiliation with ASF or an Apache 
> Project and there had better be no confusion about that.
> - Dennis
>  
> PS: There was also a complex process to transfer an account balance from a 
> project-targeting fund raiser to the ASF. Ross Gardler should remember the 
> details. Louis Suárez-Potts knows more about the actual deal also.
>  
> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org]  
> Sent: Thursday, April 04, 2013 07:21
> To: dev@openoffice.apache.org
> Subject: Re: [Proposal]: Call for donations
>  
> On Thu, Apr 4, 2013 at 8:22 AM, Jürgen Schmidt wrote:
>  
> [ ... ]
> > I can think of a much more prominent and more visible donation link or
> > whatever to make clear that OpenOffice will still benefit from donations
> > to the ASF. We have more IT requirements than other ASF projects, we
> > generate more network traffic, etc. and all this cost money.
> >  
>  
> [ ... ]
> > And opinions or further ideas how we can improve this? It shouldn't be a
> > big problem for us to collect the money we need.
> >  
>  
>  
> I generally like the idea, and it would be easy to implement. But we
> should check with appropriate ASF officers (treasurer?) or committees to
> make sure this would work, and to see if there are any rules we must follow
> with regards to solicitations. For example, it isn't clear to me whether
> we're equipped to handle many small donations, or whether the ASF mainly
> works with large corporate donations. It could be an administrative
> problem to get thousands of 20 euro donations if they need to be processed
> manually, for example.
>  
> -Rob
>  
>  
> > Juergen
> >  
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >  
>  
>  
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>  
>  

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein  wrote:

> Your proposal to alter the community structure is premised upon a
> strawman risk. First, that it would occur. Second, that it wouldn't be
> noticed. Third, that it would find its way into users' hands.
>
>
So you are asserting that someone who put their name down on the Incubator
wiki in July 2011 and was named a committer by that act, but never ever
showed up after that, never joined the dev list, never posted to the dev
list, never contributed code or anything else other than a name on a wiki,
is a member of our community and it would be altering the committee
structure if we removed their authz to our source code, even with the
proviso that we would immediately restore it on request?

Really?

-Rob



> In the past, the Foundation has *explicitly* said that we would accept
> a certain level of risk to maintain our communities.
>
> I find your strawman at a level even *lower* than the scenario that
> I'm thinking about(*).
>
> If you're worried about stale committers suddenly inserting trojans,
> then just use 'svn log' to find those outliers. No need to create
> division within the community. Run a simple histogram. There are many
> solutions to your purported attack vector, than to divide into groups.
>
> Cheers,
> -g
>
> (*) a certain large company's lawyer (ahem) was trying to scare the
> ASF ("the risk!!") into adopting certain procedures; we shut her down
>
> On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
> >
> > > Also, let me say one more thing:
> > >
> > > This notion of creating divisions among committers ... it is "solving"
> > > a problem that has never occurred here.
> > >
> > > NEVER. OCCURRED.
> > >
> > >
> > So frickin' what?  That is entirely irrelevant.   My house has never
> burnt
> > down either, but I still don't leave open flames around unattended.  In
> > fact you might think this is naive view, but avoidance of such risks
> might
> > even be correlated with lack of house fires.  Hmmm
> >
> >
> >
> > > In the Foundations's 14+ year history, we have never seen a trojan
> > > commit. Our servers have been compromised a handful of times. When we
> > > were back on CVS, we even had to audit source control to verify no
> > > trojan injection. But we have NEVER had a case of a malware commit.
> > >
> > >
> > Again, that proves nothing.   I'm sure the first time apache.org was
> rooted
> > that it had never happened before either, right?
> >
> >
> >
> >
> > > So back to IMO: dividing and partitioning and separate privilege
> > > levels... there is no reason. It creates a social problem to "solve" a
> > > non-existent issue. Net result: more problems.
> > >
> > >
> >
> > Greg, we already do this.  Does every ASF Member have credential for
> Infra
> > root?  Does ever ASF Member have access to legal-private mailing list.
>  No.
> > No. We even do this in the AOO project, with separate authz for
> > openoffice-security, which by the way also includes an SVN tree.
> >
> > Anyone who thinks this is a question of dividing and privilege is
> > expressing a knee-jerk reaction, without thinking of the risks.  We
> should
> > avoid regurgitating platitudes.  Remember, we're talking about people who
> > have never committed code, who don't even know C, who are not even
> > subscribed to the dev mailing list, and in some cases have never ever
> > posted to our mailing lists.  They signed up in with the podling in July
> > 2011 and then were never heard of again.  You make an extremely weak
> > argument to pontificate about "privilege" here.
> >
> > The risks are real.  High profile open source projects attract these
> kinds
> > of attacks.  There are those who know it, and those who don't know it
> yet.
> >
> > A good read:
> >
> http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked
> >
> > As for those who think that casual review of commit messages will review
> > any attack, that is a dangerously naive few.  We should not expect an
> > attack to be in a filed called trojan.c with comments and clear logic
> > explaining what the code does.  Any hacker with a clue would send a patch
> > backed by a reasonable defect report in Bugzilla that would be innocuous
> to
> > casual inspection.  All you need is a buffer or stack overwrite in a
> > well-placed area to cause the problem.  This might even be done in two
> > stages, spread out over time, so the impact is not detectable without
> > looking at the pieces together.
> >
> > Now if someone did that in the name of an active committer it would be
> > *immediately* detected.  "WTF!?  I didn't check that in!"  But when done
> in
> > the name of an unactive committer it would be less likely to be noticed
> for
> > what it is.  We might check twice, but that doesn't mean we'd catch all
> or
> > even most deliberate attacks.   But whatever detection rate we would have
> > there it would be far less than the pr

Re: Proposal: Improve security by limiting committer access in SVN

[Greg Stein]

Sarcasm accepted. Thank you.

On Thu, Apr 04, 2013 at 02:54:41PM -0400, Rob Weir wrote:
> Sorry for talk posting.  I get it now.  If AOO is more secure than other
> Apache projects than this may give the impression that the other projects
> are less secure because they do not take these precautions.  No project can
> be better than others since that implies some are worse.  So any attempt to
> improve must be resisted since it reflects poorly on the projects that
> don't.
> 
> I apologize for not noticing this before.  I understand completely.  It is
> a very human reaction.   I guess I'll just wait for the time to come for
> other projects to figure this out, through whatever painful lessons await
> them, so we can then move forward together, at the same pace.
> 
> -Rob
> 
> 
> On Thu, Apr 4, 2013 at 2:33 PM, Rob Weir  wrote:
> 
> >
> >
> >
> > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
> >
> >> Also, let me say one more thing:
> >>
> >> This notion of creating divisions among committers ... it is "solving"
> >> a problem that has never occurred here.
> >>
> >> NEVER. OCCURRED.
> >>
> >>
> > So frickin' what?  That is entirely irrelevant.   My house has never burnt
> > down either, but I still don't leave open flames around unattended.  In
> > fact you might think this is naive view, but avoidance of such risks might
> > even be correlated with lack of house fires.  Hmmm
> >
> >
> >
> >> In the Foundations's 14+ year history, we have never seen a trojan
> >> commit. Our servers have been compromised a handful of times. When we
> >> were back on CVS, we even had to audit source control to verify no
> >> trojan injection. But we have NEVER had a case of a malware commit.
> >>
> >>
> > Again, that proves nothing.   I'm sure the first time apache.org was
> > rooted that it had never happened before either, right?
> >
> >
> >
> >
> >> So back to IMO: dividing and partitioning and separate privilege
> >> levels... there is no reason. It creates a social problem to "solve" a
> >> non-existent issue. Net result: more problems.
> >>
> >>
> >
> > Greg, we already do this.  Does every ASF Member have credential for Infra
> > root?  Does ever ASF Member have access to legal-private mailing list.  No.
> > No. We even do this in the AOO project, with separate authz for
> > openoffice-security, which by the way also includes an SVN tree.
> >
> > Anyone who thinks this is a question of dividing and privilege is
> > expressing a knee-jerk reaction, without thinking of the risks.  We should
> > avoid regurgitating platitudes.  Remember, we're talking about people who
> > have never committed code, who don't even know C, who are not even
> > subscribed to the dev mailing list, and in some cases have never ever
> > posted to our mailing lists.  They signed up in with the podling in July
> > 2011 and then were never heard of again.  You make an extremely weak
> > argument to pontificate about "privilege" here.
> >
> > The risks are real.  High profile open source projects attract these kinds
> > of attacks.  There are those who know it, and those who don't know it yet.
> >
> > A good read:
> > http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked
> >
> > As for those who think that casual review of commit messages will review
> > any attack, that is a dangerously naive few.  We should not expect an
> > attack to be in a filed called trojan.c with comments and clear logic
> > explaining what the code does.  Any hacker with a clue would send a patch
> > backed by a reasonable defect report in Bugzilla that would be innocuous to
> > casual inspection.  All you need is a buffer or stack overwrite in a
> > well-placed area to cause the problem.  This might even be done in two
> > stages, spread out over time, so the impact is not detectable without
> > looking at the pieces together.
> >
> > Now if someone did that in the name of an active committer it would be
> > *immediately* detected.  "WTF!?  I didn't check that in!"  But when done in
> > the name of an unactive committer it would be less likely to be noticed for
> > what it is.  We might check twice, but that doesn't mean we'd catch all or
> > even most deliberate attacks.   But whatever detection rate we would have
> > there it would be far less than the presentation rate for not having
> > authorization enabled at all.  The prevention rate there is 100%
> >
> > Regards,
> >
> > -Rob
> >
> >
> >
> >
> >
> >> Cheers,
> >> -g
> >>
> >> On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote:
> >> > Speaking as one of those "old-hands", Dennis is absolutely spot-on.
> >> >
> >> > Partitions, barriers, sub-groups... I call those "divisive" mechanisms
> >> > which serve to divide the community. Such divisions are rarely needed.
> >> >
> >> > As Andrea points out, in Subversion's 13 year history, we have only
> >> > *requested* people observe certain fences. We have never had a
> >> > problem. We have never had to take sanctions. A stray co

Re: [Lazy concensus] language merge into trunk.

[Rob Weir]

On Thu, Apr 4, 2013 at 11:21 AM, janI  wrote:

> Hi.
>
> Since we are now putting a lot of positive energy into 4.0, we have a lot
> of changes in trunk and at the same time I have made language changes in
> the l10n branch. This is a bad combination, that gives me quite some extra
> manual work. Furthermore I would like the 4.0 language files to be clean
> (whether we make them as po for sdf).
>
> If there are no objections I will merge the language changes (NO code
> changes) back into trunk.
>
> The changes in trunk will primarely be in .src files, where language
> different from en-US, as discussed in an earlier thread. This will not in
> any way affect the modules or the build system. All changes are committed
> in l10n branch.
>
> If no objections I will merge into trunk, monday april 8 using lazy
> consensus.
>
>
So we had translations in Pootle, in the 3.4 branch and in the trunk.  I
assume you're able to get us all back together?  If so, this is a big step
forward.  Thanks!

-Rob



> rgds
> Jan I.
>

Re: Proposal: Improve security by limiting committer access in SVN

[Greg Stein]

Your proposal to alter the community structure is premised upon a
strawman risk. First, that it would occur. Second, that it wouldn't be
noticed. Third, that it would find its way into users' hands.

In the past, the Foundation has *explicitly* said that we would accept
a certain level of risk to maintain our communities.

I find your strawman at a level even *lower* than the scenario that
I'm thinking about(*).

If you're worried about stale committers suddenly inserting trojans,
then just use 'svn log' to find those outliers. No need to create
division within the community. Run a simple histogram. There are many
solutions to your purported attack vector, than to divide into groups.

Cheers,
-g

(*) a certain large company's lawyer (ahem) was trying to scare the
ASF ("the risk!!") into adopting certain procedures; we shut her down

On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
> 
> > Also, let me say one more thing:
> >
> > This notion of creating divisions among committers ... it is "solving"
> > a problem that has never occurred here.
> >
> > NEVER. OCCURRED.
> >
> >
> So frickin' what?  That is entirely irrelevant.   My house has never burnt
> down either, but I still don't leave open flames around unattended.  In
> fact you might think this is naive view, but avoidance of such risks might
> even be correlated with lack of house fires.  Hmmm
> 
> 
> 
> > In the Foundations's 14+ year history, we have never seen a trojan
> > commit. Our servers have been compromised a handful of times. When we
> > were back on CVS, we even had to audit source control to verify no
> > trojan injection. But we have NEVER had a case of a malware commit.
> >
> >
> Again, that proves nothing.   I'm sure the first time apache.org was rooted
> that it had never happened before either, right?
> 
> 
> 
> 
> > So back to IMO: dividing and partitioning and separate privilege
> > levels... there is no reason. It creates a social problem to "solve" a
> > non-existent issue. Net result: more problems.
> >
> >
> 
> Greg, we already do this.  Does every ASF Member have credential for Infra
> root?  Does ever ASF Member have access to legal-private mailing list.  No.
> No. We even do this in the AOO project, with separate authz for
> openoffice-security, which by the way also includes an SVN tree.
> 
> Anyone who thinks this is a question of dividing and privilege is
> expressing a knee-jerk reaction, without thinking of the risks.  We should
> avoid regurgitating platitudes.  Remember, we're talking about people who
> have never committed code, who don't even know C, who are not even
> subscribed to the dev mailing list, and in some cases have never ever
> posted to our mailing lists.  They signed up in with the podling in July
> 2011 and then were never heard of again.  You make an extremely weak
> argument to pontificate about "privilege" here.
> 
> The risks are real.  High profile open source projects attract these kinds
> of attacks.  There are those who know it, and those who don't know it yet.
> 
> A good read:
> http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked
> 
> As for those who think that casual review of commit messages will review
> any attack, that is a dangerously naive few.  We should not expect an
> attack to be in a filed called trojan.c with comments and clear logic
> explaining what the code does.  Any hacker with a clue would send a patch
> backed by a reasonable defect report in Bugzilla that would be innocuous to
> casual inspection.  All you need is a buffer or stack overwrite in a
> well-placed area to cause the problem.  This might even be done in two
> stages, spread out over time, so the impact is not detectable without
> looking at the pieces together.
> 
> Now if someone did that in the name of an active committer it would be
> *immediately* detected.  "WTF!?  I didn't check that in!"  But when done in
> the name of an unactive committer it would be less likely to be noticed for
> what it is.  We might check twice, but that doesn't mean we'd catch all or
> even most deliberate attacks.   But whatever detection rate we would have
> there it would be far less than the presentation rate for not having
> authorization enabled at all.  The prevention rate there is 100%
> 
> Regards,
> 
> -Rob
> 
> 
> 
> 
> 
> > Cheers,
> > -g
> >
> > On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote:
> > > Speaking as one of those "old-hands", Dennis is absolutely spot-on.
> > >
> > > Partitions, barriers, sub-groups... I call those "divisive" mechanisms
> > > which serve to divide the community. Such divisions are rarely needed.
> > >
> > > As Andrea points out, in Subversion's 13 year history, we have only
> > > *requested* people observe certain fences. We have never had a
> > > problem. We have never had to take sanctions. A stray commit here and
> > > there? Sure, it has happened, with the best intent, so we just po

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

Sorry for talk posting.  I get it now.  If AOO is more secure than other
Apache projects than this may give the impression that the other projects
are less secure because they do not take these precautions.  No project can
be better than others since that implies some are worse.  So any attempt to
improve must be resisted since it reflects poorly on the projects that
don't.

I apologize for not noticing this before.  I understand completely.  It is
a very human reaction.   I guess I'll just wait for the time to come for
other projects to figure this out, through whatever painful lessons await
them, so we can then move forward together, at the same pace.

-Rob


On Thu, Apr 4, 2013 at 2:33 PM, Rob Weir  wrote:

>
>
>
> On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:
>
>> Also, let me say one more thing:
>>
>> This notion of creating divisions among committers ... it is "solving"
>> a problem that has never occurred here.
>>
>> NEVER. OCCURRED.
>>
>>
> So frickin' what?  That is entirely irrelevant.   My house has never burnt
> down either, but I still don't leave open flames around unattended.  In
> fact you might think this is naive view, but avoidance of such risks might
> even be correlated with lack of house fires.  Hmmm
>
>
>
>> In the Foundations's 14+ year history, we have never seen a trojan
>> commit. Our servers have been compromised a handful of times. When we
>> were back on CVS, we even had to audit source control to verify no
>> trojan injection. But we have NEVER had a case of a malware commit.
>>
>>
> Again, that proves nothing.   I'm sure the first time apache.org was
> rooted that it had never happened before either, right?
>
>
>
>
>> So back to IMO: dividing and partitioning and separate privilege
>> levels... there is no reason. It creates a social problem to "solve" a
>> non-existent issue. Net result: more problems.
>>
>>
>
> Greg, we already do this.  Does every ASF Member have credential for Infra
> root?  Does ever ASF Member have access to legal-private mailing list.  No.
> No. We even do this in the AOO project, with separate authz for
> openoffice-security, which by the way also includes an SVN tree.
>
> Anyone who thinks this is a question of dividing and privilege is
> expressing a knee-jerk reaction, without thinking of the risks.  We should
> avoid regurgitating platitudes.  Remember, we're talking about people who
> have never committed code, who don't even know C, who are not even
> subscribed to the dev mailing list, and in some cases have never ever
> posted to our mailing lists.  They signed up in with the podling in July
> 2011 and then were never heard of again.  You make an extremely weak
> argument to pontificate about "privilege" here.
>
> The risks are real.  High profile open source projects attract these kinds
> of attacks.  There are those who know it, and those who don't know it yet.
>
> A good read:
> http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked
>
> As for those who think that casual review of commit messages will review
> any attack, that is a dangerously naive few.  We should not expect an
> attack to be in a filed called trojan.c with comments and clear logic
> explaining what the code does.  Any hacker with a clue would send a patch
> backed by a reasonable defect report in Bugzilla that would be innocuous to
> casual inspection.  All you need is a buffer or stack overwrite in a
> well-placed area to cause the problem.  This might even be done in two
> stages, spread out over time, so the impact is not detectable without
> looking at the pieces together.
>
> Now if someone did that in the name of an active committer it would be
> *immediately* detected.  "WTF!?  I didn't check that in!"  But when done in
> the name of an unactive committer it would be less likely to be noticed for
> what it is.  We might check twice, but that doesn't mean we'd catch all or
> even most deliberate attacks.   But whatever detection rate we would have
> there it would be far less than the presentation rate for not having
> authorization enabled at all.  The prevention rate there is 100%
>
> Regards,
>
> -Rob
>
>
>
>
>
>> Cheers,
>> -g
>>
>> On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote:
>> > Speaking as one of those "old-hands", Dennis is absolutely spot-on.
>> >
>> > Partitions, barriers, sub-groups... I call those "divisive" mechanisms
>> > which serve to divide the community. Such divisions are rarely needed.
>> >
>> > As Andrea points out, in Subversion's 13 year history, we have only
>> > *requested* people observe certain fences. We have never had a
>> > problem. We have never had to take sanctions. A stray commit here and
>> > there? Sure, it has happened, with the best intent, so we just point
>> > out that they need a bit more caution. No harm done.
>> >
>> > Back to Dennis' point: the solution here is proper review of the
>> > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the
>> > potential contri

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Thu, Apr 4, 2013 at 2:27 PM, Dennis E. Hamilton
wrote:

> If the problem is that there are abandoned Apache credentials out there
> for the taking, the solution is to deal with the inactive committers and
> revocation of those credentials.  And to assume that some sudden
> resuscitation can go unnoticed strikes me as not very plausible.  (It
> strikes me as far more likely that such committers have
> lost/forgotten/mislaid their credentials and having them fall into the
> wrong hands is probably not a material risk.)  The claim that there is
> automatic inclusion of malicious code introduced by a previously silent
> committer seems unsupportable.
>
>
Again, you are showing ignorance of the likely attack vectors.  Just
because I do not use or have forgotted my Apache password does not mean my
account is secure.  I could have an easily guessed password, or a password
that is identical to one used another another system that is comprised.  In
fact the later is one of the most-likely attack-vectors.  I set my Apache
password to something that is the same as some online retailer or other
service.  Their password hashes are compromised.  They reset their
passwords and send out a note to their users advising them to reset all
passwords on sites that used the same password.  But the inactive committer
neglects to do that.  Simple correlation of names or email addresses leads
them directly to Apache.

See for example:
http://thenextweb.com/socialmedia/2012/06/06/bad-day-for-linkedin-6-5-million-hashed-passwords-reportedly-leaked-change-yours-now/

Now how many inactive committers do you think have LinkedIn accounts?
Hmm... maybe *alll of them*.



> Whatever is done has to work without injury to "the Apache Way."
>
>
Properly understood, yes.  Misunderstood it can be used as an excuse for
any form of ossification.


> Furthermore, modifications to code on the SVN are always reversible.  That
> is considered the main line of defense for inappropriate commits to the
> SVN.  (Use of the web site to create an exploit against browsers is a
> different problem that might need to be looked into.  That's more immediate
> than attempting to get a patch by a watchful release manager.  And, as far
> as I know, all web site updates also show up on the commit logs.)
>
>
Again, you are assuming that the attack is seen for what it is.  That does
not seem like what an purposeful hacker would do, does it?


> We've been taken through this rationale before.  Why is it being raised
> anew?  Has there been an actual exploit?
>
>

Again, my house has not burned down either, so why should I care about fire
safety?



> I am having trouble accepting that there is a plausible risk of undetected
> exploit here, versus the kinds of attacks that could have far more serious
> consequences.  There are exploits that are already far easier without
> anything happening at the ASF end of things.  Having reliable code
> signatures would give us a way to discourage and repudiate the continuing
> reliance on exploit-vulnerable downloads that folks are now being exposed
> to.  There are places in AOO worthy of investigation to limit the ways an
> AOO install might be an exploit enabler that are probably more important
> than the proposed defense of the SVN by requiring committer opt-in.  I
> assume the opt-in should be requested using the apache @a.o e-mail (will
> that be part of the rules)?  Will there be some e-mail confirmation
> requirement to protect against the account *already* having been
> compromised?  Otherwise, this is all self-prescribed placebo.
>
>
I believe that Infra is less-likely to accept code signing if we're not
taking reasonable precautions to ensure that our SVN tree is secure. My
opinion.  If I were in their shoes I certainly would want these extra
precautions to cover the extra risks that come with code signing.   Since
signed code can slip onto a machine more easily, without triggering
warnings from the OS, anti-virus or browser, this makes our SVN tree a
bigger target, not a smaller one.



> I shall not say anything further about whether or not this is done.  While
> it may set some minds at ease, I think it is not doing much in terms of
> where the plausible threats already are and where opportunistic exploits
> may already be happening.
>
>
As you know, we find vulnerabilities in AOO on a regular basis, and fix
them.  I think that proves my point.  Every single one of these
vulnerabilities passed through the eyes of at least one developer, and
perhaps more, and escaped unnoticed.  And these were accidental.  So we
should be far more humble about our ability to notice an
intentionally-placed vulnerability.  If we don't catch 100% of the
accidents, what makes us think we'd catch the hacker?  Something to think
about...



Regards,

-Rob




>  - Dennis
>
> PS: It seems to me that the special authz arrangements and SVN areas for
> security fixes has to do with avoiding premature disclosure of a known
> vulnerability tha

Re: [RELEASE]: proposed schedule for AOO 4.0

[Regina Henschel]

Guy Waterval schrieb:

Hi Jürgen,
Hi all,

Is there an official terminology to describe the sidebar and its different
parts ?

A+



Yes, look at http://wiki.openoffice.org/wiki/Sidebar section "Glossary" 
and the picture on the right side there.


Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

tpcolor.cxx

[jorge ivan poot diaz]

Hello

I've made changes to the module cui (tpcolor.cxx):

http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/cui/source/tabpages/tpcolor.cxx#465

I want to know which modules should I build or explain me what modules are
built by editing the file tpcolor.cxx and why?

Regards.

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein  wrote:

> Also, let me say one more thing:
>
> This notion of creating divisions among committers ... it is "solving"
> a problem that has never occurred here.
>
> NEVER. OCCURRED.
>
>
So frickin' what?  That is entirely irrelevant.   My house has never burnt
down either, but I still don't leave open flames around unattended.  In
fact you might think this is naive view, but avoidance of such risks might
even be correlated with lack of house fires.  Hmmm



> In the Foundations's 14+ year history, we have never seen a trojan
> commit. Our servers have been compromised a handful of times. When we
> were back on CVS, we even had to audit source control to verify no
> trojan injection. But we have NEVER had a case of a malware commit.
>
>
Again, that proves nothing.   I'm sure the first time apache.org was rooted
that it had never happened before either, right?




> So back to IMO: dividing and partitioning and separate privilege
> levels... there is no reason. It creates a social problem to "solve" a
> non-existent issue. Net result: more problems.
>
>

Greg, we already do this.  Does every ASF Member have credential for Infra
root?  Does ever ASF Member have access to legal-private mailing list.  No.
No. We even do this in the AOO project, with separate authz for
openoffice-security, which by the way also includes an SVN tree.

Anyone who thinks this is a question of dividing and privilege is
expressing a knee-jerk reaction, without thinking of the risks.  We should
avoid regurgitating platitudes.  Remember, we're talking about people who
have never committed code, who don't even know C, who are not even
subscribed to the dev mailing list, and in some cases have never ever
posted to our mailing lists.  They signed up in with the podling in July
2011 and then were never heard of again.  You make an extremely weak
argument to pontificate about "privilege" here.

The risks are real.  High profile open source projects attract these kinds
of attacks.  There are those who know it, and those who don't know it yet.

A good read:
http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked

As for those who think that casual review of commit messages will review
any attack, that is a dangerously naive few.  We should not expect an
attack to be in a filed called trojan.c with comments and clear logic
explaining what the code does.  Any hacker with a clue would send a patch
backed by a reasonable defect report in Bugzilla that would be innocuous to
casual inspection.  All you need is a buffer or stack overwrite in a
well-placed area to cause the problem.  This might even be done in two
stages, spread out over time, so the impact is not detectable without
looking at the pieces together.

Now if someone did that in the name of an active committer it would be
*immediately* detected.  "WTF!?  I didn't check that in!"  But when done in
the name of an unactive committer it would be less likely to be noticed for
what it is.  We might check twice, but that doesn't mean we'd catch all or
even most deliberate attacks.   But whatever detection rate we would have
there it would be far less than the presentation rate for not having
authorization enabled at all.  The prevention rate there is 100%

Regards,

-Rob





> Cheers,
> -g
>
> On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote:
> > Speaking as one of those "old-hands", Dennis is absolutely spot-on.
> >
> > Partitions, barriers, sub-groups... I call those "divisive" mechanisms
> > which serve to divide the community. Such divisions are rarely needed.
> >
> > As Andrea points out, in Subversion's 13 year history, we have only
> > *requested* people observe certain fences. We have never had a
> > problem. We have never had to take sanctions. A stray commit here and
> > there? Sure, it has happened, with the best intent, so we just point
> > out that they need a bit more caution. No harm done.
> >
> > Back to Dennis' point: the solution here is proper review of the
> > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the
> > potential contributions of others.
> >
> > Cheers,
> > -g
> >
> > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote:
> > > In previous generations of this kind of discussion, the ASF old-hands
> will point out that the social process works quite well, folks don't do
> commits unless they feel qualified to do so, and it is often the case that
> committers will request RTC (i.e., submit patches rather than update the
> SVN) in contributing where they are not experienced or don't consider
> themselves expert.
> > >
> > > At the ASF this appears to be one of those, "if it is not broken,
> don't fix it."
> > >
> > > There is still the concern about stolen credentials used to perform
> undetected malicious acts.  If the oversight that the project naturally
> brings to bear on visible changes to the code base is insufficient, I think
> the problem is greater t

RE: Proposal: Improve security by limiting committer access in SVN

[Dennis E. Hamilton]

If the problem is that there are abandoned Apache credentials out there for the 
taking, the solution is to deal with the inactive committers and revocation of 
those credentials.  And to assume that some sudden resuscitation can go 
unnoticed strikes me as not very plausible.  (It strikes me as far more likely 
that such committers have lost/forgotten/mislaid their credentials and having 
them fall into the wrong hands is probably not a material risk.)  The claim 
that there is automatic inclusion of malicious code introduced by a previously 
silent committer seems unsupportable.  

Whatever is done has to work without injury to "the Apache Way."

Furthermore, modifications to code on the SVN are always reversible.  That is 
considered the main line of defense for inappropriate commits to the SVN.  (Use 
of the web site to create an exploit against browsers is a different problem 
that might need to be looked into.  That's more immediate than attempting to 
get a patch by a watchful release manager.  And, as far as I know, all web site 
updates also show up on the commit logs.)

We've been taken through this rationale before.  Why is it being raised anew?  
Has there been an actual exploit?  

I am having trouble accepting that there is a plausible risk of undetected 
exploit here, versus the kinds of attacks that could have far more serious 
consequences.  There are exploits that are already far easier without anything 
happening at the ASF end of things.  Having reliable code signatures would give 
us a way to discourage and repudiate the continuing reliance on 
exploit-vulnerable downloads that folks are now being exposed to.  There are 
places in AOO worthy of investigation to limit the ways an AOO install might be 
an exploit enabler that are probably more important than the proposed defense 
of the SVN by requiring committer opt-in.  I assume the opt-in should be 
requested using the apache @a.o e-mail (will that be part of the rules)?  Will 
there be some e-mail confirmation requirement to protect against the account 
*already* having been compromised?  Otherwise, this is all self-prescribed 
placebo. 

I shall not say anything further about whether or not this is done.  While it 
may set some minds at ease, I think it is not doing much in terms of where the 
plausible threats already are and where opportunistic exploits may already be 
happening.

 - Dennis

PS: It seems to me that the special authz arrangements and SVN areas for 
security fixes has to do with avoiding premature disclosure of a known 
vulnerability that is already in released code.  The list is private and 
moderated for obvious reasons.  Likewise, the private @oo.a.o is for preserving 
the confidentiality of certain conversations (and that authz is for related 
material on the SVN).  There is no confidentiality to protect in the public 
code base.  That's the point.
 
-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Thursday, April 04, 2013 09:44
To: dev@openoffice.apache.org
Subject: Re: Proposal: Improve security by limiting committer access in SVN

On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote:

> Dave Fisher wrote:
>
>> Let's focus only on adding one new authz list for the code tree.
>> Call it openoffice-coders and populate it with those who HAVE any
>> commit activity in the current code tree.
>>
>
> I checked feasibility with Infra. Summary:
>
> 1) LDAP is not the solution. Rule it out.
>
> 2) The only possible solution would be an authz rule like suggested by
> Dave here; however, Infra quite discourages it, mainly for maintenance
> reasons. This leads me to think we would need some good justifications for
> implementing this.
>
>
Would Infra need to maintain the authz , or would that be something that
you do?

Note: we already have a separate authz for openoffice-security and
openoffice-pmc, for the same reasons -- there are some things that should
not be authorized for all committers.  Going from 3 authz's to 4 is not
unreasonable, IMHO.


> 3) If the justification is security, then there are other privileges to
> monitor. Namely, every committer has shell access to people.apache.org,
> authenticated access to the Apache SMTP server and CMS privileges for the
> openoffice.org website, including publish operations.
>
>

None of these get automatically included in releases that are installed on
tens of millions of machines.  So I would not ask for additional controls
here.  I'm asking only for additional controls on source code.


> For the record, the Subversion project has complex rules like Rob pointed
> out; but it's only a "social enforcement", i.e., all committers respect
> those limitations by their own choice; if you look at the technical level,
> every committer (all Apache committers) can commit code to the Subversion
> subtree.
>
>
I'm not concerned with things where social enforcement would work.  It is
not a concern that someone unqualified makes a change to the source cod

Re: Proposal: Improve security by limiting committer access in SVN

[Greg Stein]

Also, let me say one more thing:

This notion of creating divisions among committers ... it is "solving"
a problem that has never occurred here.

NEVER. OCCURRED.

In the Foundations's 14+ year history, we have never seen a trojan
commit. Our servers have been compromised a handful of times. When we
were back on CVS, we even had to audit source control to verify no
trojan injection. But we have NEVER had a case of a malware commit.

So back to IMO: dividing and partitioning and separate privilege
levels... there is no reason. It creates a social problem to "solve" a
non-existent issue. Net result: more problems.

Cheers,
-g

On Thu, Apr 04, 2013 at 05:59:31PM +, Greg Stein wrote:
> Speaking as one of those "old-hands", Dennis is absolutely spot-on.
> 
> Partitions, barriers, sub-groups... I call those "divisive" mechanisms
> which serve to divide the community. Such divisions are rarely needed.
> 
> As Andrea points out, in Subversion's 13 year history, we have only
> *requested* people observe certain fences. We have never had a
> problem. We have never had to take sanctions. A stray commit here and
> there? Sure, it has happened, with the best intent, so we just point
> out that they need a bit more caution. No harm done.
> 
> Back to Dennis' point: the solution here is proper review of the
> commits that occur. (IMO) NOT a way to *exclude* or to *limit* the
> potential contributions of others.
> 
> Cheers,
> -g
> 
> On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote:
> > In previous generations of this kind of discussion, the ASF old-hands will 
> > point out that the social process works quite well, folks don't do commits 
> > unless they feel qualified to do so, and it is often the case that 
> > committers will request RTC (i.e., submit patches rather than update the 
> > SVN) in contributing where they are not experienced or don't consider 
> > themselves expert.
> > 
> > At the ASF this appears to be one of those, "if it is not broken, don't fix 
> > it."
> > 
> > There is still the concern about stolen credentials used to perform 
> > undetected malicious acts.  If the oversight that the project naturally 
> > brings to bear on visible changes to the code base is insufficient, I think 
> > the problem is greater than there being a possible exploit of that 
> > inattention.  Mechanical solutions may be part of the disease, not the cure 
> > [;<).
> > 
> >  - Dennis
> > 
> > -Original Message-
> > From: Andrea Pescetti [mailto:pesce...@apache.org] 
> > Sent: Thursday, April 04, 2013 08:57
> > To: dev@openoffice.apache.org
> > Subject: Re: Proposal: Improve security by limiting committer access in SVN
> > 
> > Dave Fisher wrote:
> > > Let's focus only on adding one new authz list for the code tree.
> > > Call it openoffice-coders and populate it with those who HAVE any
> > > commit activity in the current code tree.
> > 
> > I checked feasibility with Infra. Summary:
> > 
> > 1) LDAP is not the solution. Rule it out.
> > 
> > 2) The only possible solution would be an authz rule like suggested by 
> > Dave here; however, Infra quite discourages it, mainly for maintenance 
> > reasons. This leads me to think we would need some good justifications 
> > for implementing this.
> > 
> > 3) If the justification is security, then there are other privileges to 
> > monitor. Namely, every committer has shell access to people.apache.org, 
> > authenticated access to the Apache SMTP server and CMS privileges for 
> > the openoffice.org website, including publish operations.
> > 
> > For the record, the Subversion project has complex rules like Rob 
> > pointed out; but it's only a "social enforcement", i.e., all committers 
> > respect those limitations by their own choice; if you look at the 
> > technical level, every committer (all Apache committers) can commit code 
> > to the Subversion subtree.
> > 
> > Regards,
> >Andrea.
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Proposal: Improve security by limiting committer access in SVN

[Greg Stein]

Speaking as one of those "old-hands", Dennis is absolutely spot-on.

Partitions, barriers, sub-groups... I call those "divisive" mechanisms
which serve to divide the community. Such divisions are rarely needed.

As Andrea points out, in Subversion's 13 year history, we have only
*requested* people observe certain fences. We have never had a
problem. We have never had to take sanctions. A stray commit here and
there? Sure, it has happened, with the best intent, so we just point
out that they need a bit more caution. No harm done.

Back to Dennis' point: the solution here is proper review of the
commits that occur. (IMO) NOT a way to *exclude* or to *limit* the
potential contributions of others.

Cheers,
-g

On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote:
> In previous generations of this kind of discussion, the ASF old-hands will 
> point out that the social process works quite well, folks don't do commits 
> unless they feel qualified to do so, and it is often the case that committers 
> will request RTC (i.e., submit patches rather than update the SVN) in 
> contributing where they are not experienced or don't consider themselves 
> expert.
> 
> At the ASF this appears to be one of those, "if it is not broken, don't fix 
> it."
> 
> There is still the concern about stolen credentials used to perform 
> undetected malicious acts.  If the oversight that the project naturally 
> brings to bear on visible changes to the code base is insufficient, I think 
> the problem is greater than there being a possible exploit of that 
> inattention.  Mechanical solutions may be part of the disease, not the cure 
> [;<).
> 
>  - Dennis
> 
> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org] 
> Sent: Thursday, April 04, 2013 08:57
> To: dev@openoffice.apache.org
> Subject: Re: Proposal: Improve security by limiting committer access in SVN
> 
> Dave Fisher wrote:
> > Let's focus only on adding one new authz list for the code tree.
> > Call it openoffice-coders and populate it with those who HAVE any
> > commit activity in the current code tree.
> 
> I checked feasibility with Infra. Summary:
> 
> 1) LDAP is not the solution. Rule it out.
> 
> 2) The only possible solution would be an authz rule like suggested by 
> Dave here; however, Infra quite discourages it, mainly for maintenance 
> reasons. This leads me to think we would need some good justifications 
> for implementing this.
> 
> 3) If the justification is security, then there are other privileges to 
> monitor. Namely, every committer has shell access to people.apache.org, 
> authenticated access to the Apache SMTP server and CMS privileges for 
> the openoffice.org website, including publish operations.
> 
> For the record, the Subversion project has complex rules like Rob 
> pointed out; but it's only a "social enforcement", i.e., all committers 
> respect those limitations by their own choice; if you look at the 
> technical level, every committer (all Apache committers) can commit code 
> to the Subversion subtree.
> 
> Regards,
>Andrea.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Proposal: Improve security by limiting committer access in SVN

[janI]

On 4 April 2013 19:44, Andrea Pescetti  wrote:

> Rob Weir wrote:
>
>> On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote:
>>
>>> 2) The only possible solution would be an authz rule like suggested by
>>> Dave here; however, Infra quite discourages it, mainly for maintenance
>>> reasons. This leads me to think we would need some good justifications
>>> for
>>> implementing this.
>>>
>> Would Infra need to maintain the authz , or would that be something that
>> you do?
>>
>
> According to Infra, it's something that I can manage directly, even though
> I've never looked into this recently (I just needed to make some changes
> immediately after graduation). And I'm available to take care of this if
> there is consensus on making write access to /trunk (and other subtrees)
> optional.
>

+1 when it something we can manage ourself. and we should start by limiting
to committers that have committed the last 6 month.


> Regards,
>   Andrea.
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Proposal: Improve security by limiting committer access in SVN

[Andrea Pescetti]

Rob Weir wrote:

On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote:

2) The only possible solution would be an authz rule like suggested by
Dave here; however, Infra quite discourages it, mainly for maintenance
reasons. This leads me to think we would need some good justifications for
implementing this.

Would Infra need to maintain the authz , or would that be something that
you do?


According to Infra, it's something that I can manage directly, even 
though I've never looked into this recently (I just needed to make some 
changes immediately after graduation). And I'm available to take care of 
this if there is consensus on making write access to /trunk (and other 
subtrees) optional.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Re : Re: [RELEASE]: proposed schedule for AOO 4.0

[Kay Schenk]

On Thu, Apr 4, 2013 at 4:07 AM, Jürgen Schmidt wrote:

> On 4/4/13 11:27 AM, mengualjean...@free.fr wrote:
> > Hi,
> >
> > Does some cycle exist about releasing of OOo? Because since the
> schedule, it seems that OOo 4.0 will not include current work about
> accessibility. It is a pitty as I think it is a major contribution and it
> would be a pitty if we should wait for end of 2014 to see it. It seems
> things could be ready for novembre. Do you think we can hope progress
> during 1st six months 2014? In a 4.1 release I get?
> >
>
> we had 2 releases last year and I don't see any reason why we should not
> have 2 releases this year. It really depends on what we have for a new
> release. We don't want release something only to have a new release.
>
> The accessibility work is a big and major task and takes some time. It
> can't be finished in time for 4.0 but we will see how the development
> moves forward. It can be a good candidate for a 4.1.
>
> Juergen
>

I think the last update we got on the accessibility work indicated end of
June for completion...

 http://markmail.org/message/ipdmx3scax4umc2s

so, do we think we shouldn't wait on this for 4.0?


>
> > Regards,
> >
> > - Mail d'origine -
> > De: Jürgen Schmidt 
> > À: dev@openoffice.apache.org
> > Envoyé: Thu, 04 Apr 2013 10:46:16 +0200 (CEST)
> > Objet: Re: [RELEASE]: proposed schedule for AOO 4.0
> >
> > On 2/20/13 11:32 AM, Jürgen Schmidt wrote:
> >> On 2/20/13 10:46 AM, Jürgen Schmidt wrote:
> >>> Hi,
> >>>
> >>> we make good progress with the sidebar work which is done on the
> branch.
> >>> The sidebar will be the most visible and important change for 4.0 (by
> >>> the way I like what I have seen so far). We come closer to the point
> >>> where we should talk about a more detailed schedule.
> >>>
> >>> I would like to start with the following proposal and still many steps
> >>> have to be defined in more detail.
> >>>
> >>> 03/01 function verification test will start, define test case, prepare
> >>> tests etc.
> >>> 04/04 integrate sidebar branch in trunk, other new features should be
> >>> finished by this date as well.
> >>
> >> I missed to add that the art work (logo, icons, etc. should be finished
> >> at this date as well)
> >>
> >>> 04/05 - 05/15 regression testing will be start on trunk
> >>> 04/05 - 05/15 bugfix and stabilization, no feature development
> >>> 04/08 - 05/15 translation -> I guessed ~5 weeks for updating the new
> >>> strings. This can change when we know exactly how many new strings we
> >>> will have. But translation for new languages can already work on the
> >>> existing po files for 3.4.1.
> >>> 05/21 RC1
> >>> 06/04 RC2
> >>> 06/18 RC3 (optional), can be GA already
> >>> 06/25 GA -> this should be our final target
> >>>
> >>>
> >>> This is a proposal based on the ongoing work that I no. Please let me
> >>> know if I missed something important.
> >>>
> >>> Regular developer builds 1/week + nightly builds
> >>>
> >>> Based on feedback and potential changes I will put this in the wiki
> later.
> >>>
> >>> Important is from my pov that we start talking about the improvements
> >>> that we make in public. It should be very clear for anybody where the
> >>> real important features and improvement for OpenOffice or derivatives
> >>> are coming from ;-)
> >
> > I will try to give n update on the current plan.
> >
> > The sidebar branch is not yet integrated but I expect that it will be
> > finished next week latest. That means we will have a delay of some days
> > here. As soon as I have concrete dates I will update the plan in the
> wiki.
> >
> > Some further things are ongoing and we should try to finish this work
> > soon (2 weeks) to have the stuff in place and can start or concentrate
> > on bug fixing and stabilization.
> >
> > Juergen
> >
> >
> >
> >
> >
> >>>
> >>>
> >>> Juergen
> >>>
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: [RELEASE]: proposed schedule for AOO 4.0

[Guy Waterval]

Hi Jürgen,
Hi all,

Is there an official terminology to describe the sidebar and its different
parts ?

A+
-- 
gw


2013/4/4 Jürgen Schmidt 

> On 2/20/13 11:32 AM, Jürgen Schmidt wrote:
> > On 2/20/13 10:46 AM, Jürgen Schmidt wrote:
> >> Hi,
> >>
> >> we make good progress with the sidebar work which is done on the branch.
> >> The sidebar will be the most visible and important change for 4.0 (by
> >> the way I like what I have seen so far). We come closer to the point
> >> where we should talk about a more detailed schedule.
> >>
> >> I would like to start with the following proposal and still many steps
> >> have to be defined in more detail.
> >>
> >> 03/01 function verification test will start, define test case, prepare
> >> tests etc.
> >> 04/04 integrate sidebar branch in trunk, other new features should be
> >> finished by this date as well.
> >
> > I missed to add that the art work (logo, icons, etc. should be finished
> > at this date as well)
> >
> >> 04/05 - 05/15 regression testing will be start on trunk
> >> 04/05 - 05/15 bugfix and stabilization, no feature development
> >> 04/08 - 05/15 translation -> I guessed ~5 weeks for updating the new
> >> strings. This can change when we know exactly how many new strings we
> >> will have. But translation for new languages can already work on the
> >> existing po files for 3.4.1.
> >> 05/21 RC1
> >> 06/04 RC2
> >> 06/18 RC3 (optional), can be GA already
> >> 06/25 GA -> this should be our final target
> >>
> >>
> >> This is a proposal based on the ongoing work that I no. Please let me
> >> know if I missed something important.
> >>
> >> Regular developer builds 1/week + nightly builds
> >>
> >> Based on feedback and potential changes I will put this in the wiki
> later.
> >>
> >> Important is from my pov that we start talking about the improvements
> >> that we make in public. It should be very clear for anybody where the
> >> real important features and improvement for OpenOffice or derivatives
> >> are coming from ;-)
>
> I will try to give n update on the current plan.
>
> The sidebar branch is not yet integrated but I expect that it will be
> finished next week latest. That means we will have a delay of some days
> here. As soon as I have concrete dates I will update the plan in the wiki.
>
> Some further things are ongoing and we should try to finish this work
> soon (2 weeks) to have the stuff in place and can start or concentrate
> on bug fixing and stabilization.
>
> Juergen
>
>
>
>
>
> >>
> >>
> >> Juergen
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [Lazy concensus] language merge into trunk.

[Kay Schenk]

On Thu, Apr 4, 2013 at 8:21 AM, janI  wrote:

> Hi.
>
> Since we are now putting a lot of positive energy into 4.0, we have a lot
> of changes in trunk and at the same time I have made language changes in
> the l10n branch. This is a bad combination, that gives me quite some extra
> manual work. Furthermore I would like the 4.0 language files to be clean
> (whether we make them as po for sdf).
>
> If there are no objections I will merge the language changes (NO code
> changes) back into trunk.
>
> The changes in trunk will primarely be in .src files, where language
> different from en-US, as discussed in an earlier thread. This will not in
> any way affect the modules or the build system. All changes are committed
> in l10n branch.
>
> If no objections I will merge into trunk, monday april 8 using lazy
> consensus.
>
> rgds
> Jan I.
>

Please proceed! :)


-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote:

> Dave Fisher wrote:
>
>> Let's focus only on adding one new authz list for the code tree.
>> Call it openoffice-coders and populate it with those who HAVE any
>> commit activity in the current code tree.
>>
>
> I checked feasibility with Infra. Summary:
>
> 1) LDAP is not the solution. Rule it out.
>
> 2) The only possible solution would be an authz rule like suggested by
> Dave here; however, Infra quite discourages it, mainly for maintenance
> reasons. This leads me to think we would need some good justifications for
> implementing this.
>
>
Would Infra need to maintain the authz , or would that be something that
you do?

Note: we already have a separate authz for openoffice-security and
openoffice-pmc, for the same reasons -- there are some things that should
not be authorized for all committers.  Going from 3 authz's to 4 is not
unreasonable, IMHO.


> 3) If the justification is security, then there are other privileges to
> monitor. Namely, every committer has shell access to people.apache.org,
> authenticated access to the Apache SMTP server and CMS privileges for the
> openoffice.org website, including publish operations.
>
>

None of these get automatically included in releases that are installed on
tens of millions of machines.  So I would not ask for additional controls
here.  I'm asking only for additional controls on source code.


> For the record, the Subversion project has complex rules like Rob pointed
> out; but it's only a "social enforcement", i.e., all committers respect
> those limitations by their own choice; if you look at the technical level,
> every committer (all Apache committers) can commit code to the Subversion
> subtree.
>
>
I'm not concerned with things where social enforcement would work.  It is
not a concern that someone unqualified makes a change to the source code
merely because they have permissions.  The issue is that the product is so
well-known and so broadly installed that it is automatically a target for
hackers, and with so many authorized user accounts from committers who are
not actively coding, or never were, that these authoriziations are
particularly vulnerable to compromise.

I believe this a serious issue and we act irresponsibly and do a disservice
to our users if we treat this merely as an inconvenience or a social faux
pas.

-Rob


> Regards,
>   Andrea.
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Thu, Apr 4, 2013 at 12:23 PM, Dennis E. Hamilton  wrote:

> In previous generations of this kind of discussion, the ASF old-hands will
> point out that the social process works quite well, folks don't do commits
> unless they feel qualified to do so, and it is often the case that
> committers will request RTC (i.e., submit patches rather than update the
> SVN) in contributing where they are not experienced or don't consider
> themselves expert.
>
> At the ASF this appears to be one of those, "if it is not broken, don't
> fix it."
>
>
If it is visibly and publicly broken then it is too late to do anything
about it.

I'd like to think that there is room within the Apache Way for prevention,
foresight and reasonable precaution.



> There is still the concern about stolen credentials used to perform
> undetected malicious acts.  If the oversight that the project naturally
> brings to bear on visible changes to the code base is insufficient, I think
> the problem is greater than there being a possible exploit of that
> inattention.  Mechanical solutions may be part of the disease, not the cure
> [;<).
>

The project does bear responsibility to review changes.  But we also bear
responsibility for having reasonable access controls.   It is hard to argue
that giving authorization for code changes to someone who showed a pulse in
July 2011 but has never been heard of since is a reasonable policy.

-Rob


>
>  - Dennis
>
> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Thursday, April 04, 2013 08:57
> To: dev@openoffice.apache.org
> Subject: Re: Proposal: Improve security by limiting committer access in SVN
>
> Dave Fisher wrote:
> > Let's focus only on adding one new authz list for the code tree.
> > Call it openoffice-coders and populate it with those who HAVE any
> > commit activity in the current code tree.
>
> I checked feasibility with Infra. Summary:
>
> 1) LDAP is not the solution. Rule it out.
>
> 2) The only possible solution would be an authz rule like suggested by
> Dave here; however, Infra quite discourages it, mainly for maintenance
> reasons. This leads me to think we would need some good justifications
> for implementing this.
>
> 3) If the justification is security, then there are other privileges to
> monitor. Namely, every committer has shell access to people.apache.org,
> authenticated access to the Apache SMTP server and CMS privileges for
> the openoffice.org website, including publish operations.
>
> For the record, the Subversion project has complex rules like Rob
> pointed out; but it's only a "social enforcement", i.e., all committers
> respect those limitations by their own choice; if you look at the
> technical level, every committer (all Apache committers) can commit code
> to the Subversion subtree.
>
> Regards,
>Andrea.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

RE: Proposal: Improve security by limiting committer access in SVN

[Dennis E. Hamilton]

In previous generations of this kind of discussion, the ASF old-hands will 
point out that the social process works quite well, folks don't do commits 
unless they feel qualified to do so, and it is often the case that committers 
will request RTC (i.e., submit patches rather than update the SVN) in 
contributing where they are not experienced or don't consider themselves expert.

At the ASF this appears to be one of those, "if it is not broken, don't fix it."

There is still the concern about stolen credentials used to perform undetected 
malicious acts.  If the oversight that the project naturally brings to bear on 
visible changes to the code base is insufficient, I think the problem is 
greater than there being a possible exploit of that inattention.  Mechanical 
solutions may be part of the disease, not the cure [;<).

 - Dennis

-Original Message-
From: Andrea Pescetti [mailto:pesce...@apache.org] 
Sent: Thursday, April 04, 2013 08:57
To: dev@openoffice.apache.org
Subject: Re: Proposal: Improve security by limiting committer access in SVN

Dave Fisher wrote:
> Let's focus only on adding one new authz list for the code tree.
> Call it openoffice-coders and populate it with those who HAVE any
> commit activity in the current code tree.

I checked feasibility with Infra. Summary:

1) LDAP is not the solution. Rule it out.

2) The only possible solution would be an authz rule like suggested by 
Dave here; however, Infra quite discourages it, mainly for maintenance 
reasons. This leads me to think we would need some good justifications 
for implementing this.

3) If the justification is security, then there are other privileges to 
monitor. Namely, every committer has shell access to people.apache.org, 
authenticated access to the Apache SMTP server and CMS privileges for 
the openoffice.org website, including publish operations.

For the record, the Subversion project has complex rules like Rob 
pointed out; but it's only a "social enforcement", i.e., all committers 
respect those limitations by their own choice; if you look at the 
technical level, every committer (all Apache committers) can commit code 
to the Subversion subtree.

Regards,
   Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [UX] Design Exploration - AOO 4.0 Sidebar Specific Content Panel Design

[Xin Li]

Hi  all ,

We have updated a new version of design proposal after redefining some
detail issues. Please find the design proposal by the link:
http://wiki.openoffice.org/wiki/AOO_UX_Design_Exploration_-_Task_Pane_Content_Panel_-_User_Interface_Design_Proposals#Sidebar_Content_Panel_-_UX_Design_propoals

Thanks.


2013/3/30 Andrea Pescetti 

> On 27/03/2013 Xin Li wrote:
> > The sidebar design proposal for AOO 4.0 has been uploaded to AOO UX wiki：
> >
> http://wiki.openoffice.org/wiki/AOO_UX_Design_Exploration_-_Task_Pane_Content_Panel_-_User_Interface_Design_Proposals#Sidebar_Content_Panel_-_UX_Design_propoals
>
> This is really impressive. And I'm tempted to lock the wiki page to
> force developers to put this stuff on the blog... just joking, but
> really, each of these three images could become a blog post, if we want
> some more feedback.
>
> Coming to minor comments, I have some localization concerns, like in "6.
> Alignment": "Wrap text" and "Merge Cells". The former in Italian would
> be "A capo automatico" and wouldn't fit the space. This might suggest
> avoiding text in narrow spaces and preferring icons to it (we do have
> one for "Merge Cells", I'm not sure about "Wrap text"). This improvement
> can also come after 4.0, but cut text in 4.0 would not be very nice, so
> the few problematic cases (possibly, only this one) should maybe use a
> different layout.
>
> Regards,
>   Andrea.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
Best regards,
Xin Li   李欣
UX designer

RE: [Proposal]: Call for donations

[Dennis E. Hamilton]

The PPMC went through this some time ago, because there were OO.o-specific 
donation mechanisms that had to be either retired or redirected to ASF 
donations.  (There is a small-donation place for ASF donations.  I used it once 
to see how it worked.)  

Start here: .

As I recall: Short answer: the project can't solicit donations for 
project-specific purposes.  Longer answer: (1) Outside parties can raise funds 
*and*disburse*them* for whatever they want to support, such as student 
attendance at conferences, whatever.  GSoC provides funding to the GSoC 
"interns."  (2) That party can't claim any affiliation with ASF or an Apache 
Project and there had better be no confusion about that.
 
 - Dennis

PS: There was also a complex process to transfer an account balance from a 
project-targeting fund raiser to the ASF.  Ross Gardler should remember the 
details.  Louis Suárez-Potts knows more about the actual deal also.

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Thursday, April 04, 2013 07:21
To: dev@openoffice.apache.org
Subject: Re: [Proposal]: Call for donations

On Thu, Apr 4, 2013 at 8:22 AM, Jürgen Schmidt wrote:

[ ... ]
> I can think of a much more prominent and more visible donation link or
> whatever to make clear that OpenOffice will still benefit from donations
> to the ASF. We have more IT requirements than other ASF projects, we
> generate more network traffic, etc. and all this cost money.
[ ... ]
> And opinions or further ideas how we can improve this? It shouldn't be a
> big problem for us to collect the money we need.
>
>

I generally like the idea, and it would be easy to implement.  But we
should check with appropriate ASF officers (treasurer?) or committees to
make sure this would work, and to see if there are any rules we must follow
with regards to solicitations.   For example, it isn't clear to me whether
we're equipped to handle many small donations, or whether the ASF mainly
works with large corporate donations.  It could be an administrative
problem to get thousands of 20 euro donations if they need to be processed
manually, for example.

-Rob


> Juergen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Proposal: Improve security by limiting committer access in SVN

[Andrea Pescetti]

Dave Fisher wrote:

Let's focus only on adding one new authz list for the code tree.
Call it openoffice-coders and populate it with those who HAVE any
commit activity in the current code tree.


I checked feasibility with Infra. Summary:

1) LDAP is not the solution. Rule it out.

2) The only possible solution would be an authz rule like suggested by 
Dave here; however, Infra quite discourages it, mainly for maintenance 
reasons. This leads me to think we would need some good justifications 
for implementing this.


3) If the justification is security, then there are other privileges to 
monitor. Namely, every committer has shell access to people.apache.org, 
authenticated access to the Apache SMTP server and CMS privileges for 
the openoffice.org website, including publish operations.


For the record, the Subversion project has complex rules like Rob 
pointed out; but it's only a "social enforcement", i.e., all committers 
respect those limitations by their own choice; if you look at the 
technical level, every committer (all Apache committers) can commit code 
to the Subversion subtree.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[Lazy concensus] language merge into trunk.

[janI]

Hi.

Since we are now putting a lot of positive energy into 4.0, we have a lot
of changes in trunk and at the same time I have made language changes in
the l10n branch. This is a bad combination, that gives me quite some extra
manual work. Furthermore I would like the 4.0 language files to be clean
(whether we make them as po for sdf).

If there are no objections I will merge the language changes (NO code
changes) back into trunk.

The changes in trunk will primarely be in .src files, where language
different from en-US, as discussed in an earlier thread. This will not in
any way affect the modules or the build system. All changes are committed
in l10n branch.

If no objections I will merge into trunk, monday april 8 using lazy
consensus.

rgds
Jan I.

Re: [Proposal]: Call for donations

[Raphael Bircher]

Am 04.04.13 14:22, schrieb Jürgen Schmidt:

Hi,

in relation to our budget planning I asked myself if OpenOffice has any
impact on the donations to the ASF? Well I don't know and we can
probably figure this out but the question is what can we do ti collect
more donations and use our brand more effective.

When I look on our main website I found a tiny donation link in the
footer only. From my point of view this is not good enough and we should
think how we can improve it.

I can think of a much more prominent and more visible donation link or
whatever to make clear that OpenOffice will still benefit from donations
to the ASF. We have more IT requirements than other ASF projects, we
generate more network traffic, etc. and all this cost money.

Furthermore I can think of a blog post to promote this in some way and
do a public call for donation. We should of course do this more often
with any public announcement.

And opinions or further ideas how we can improve this? It shouldn't be a
big problem for us to collect the money we need.
I disagree. Yes, we can help with foundings for ASF, but please do this 
on ASF Level. Founding money is not the task of a ASF project, It's the 
task for the foundation. It would be nice, if sameone from our project 
work with the foundrising team from ASF. I personaly would also welcome 
if the fundrising team use OOo to generate monay. But for my point of 
view it's not a topic we (as Apache OpenOffice) project has to care about.


So do this on Foundation level and not here. With other words: "Nice 
idea, wrong place."  Just my option.


Greetings Raphael


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Proposal]: Call for donations

[Rob Weir]

On Thu, Apr 4, 2013 at 8:22 AM, Jürgen Schmidt wrote:

> Hi,
>
> in relation to our budget planning I asked myself if OpenOffice has any
> impact on the donations to the ASF? Well I don't know and we can
> probably figure this out but the question is what can we do ti collect
> more donations and use our brand more effective.
>
> When I look on our main website I found a tiny donation link in the
> footer only. From my point of view this is not good enough and we should
> think how we can improve it.
>
> I can think of a much more prominent and more visible donation link or
> whatever to make clear that OpenOffice will still benefit from donations
> to the ASF. We have more IT requirements than other ASF projects, we
> generate more network traffic, etc. and all this cost money.
>
> Furthermore I can think of a blog post to promote this in some way and
> do a public call for donation. We should of course do this more often
> with any public announcement.
>
> And opinions or further ideas how we can improve this? It shouldn't be a
> big problem for us to collect the money we need.
>
>

I generally like the idea, and it would be easy to implement.  But we
should check with appropriate ASF officers (treasurer?) or committees to
make sure this would work, and to see if there are any rules we must follow
with regards to solicitations.   For example, it isn't clear to me whether
we're equipped to handle many small donations, or whether the ASF mainly
works with large corporate donations.  It could be an administrative
problem to get thousands of 20 euro donations if they need to be processed
manually, for example.

-Rob


> Juergen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Binfilter removal - PATCH

[Pavel Janík]

>>> Anyone against the lazy approach - ie. doing this on trunk directly? This
>>> could make testing much easier...
>> 
>> +1 please do it on trunk !
> It is already disabled by default when we build snapshots. I don't see any 
> reason against doing it on trunk.  

Done on trunk. Module binfilter is still there though. Before removing it, I'd 
like to do some testing (I manually remove the module before the build).
-- 
Pavel Janík




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Proposal]: Call for donations

[Jürgen Schmidt]

On 4/4/13 2:46 PM, Rory O'Farrell wrote:
> On Thu, 04 Apr 2013 14:22:33 +0200
> Jürgen Schmidt  wrote:
> 
>> Hi,
>>
>> in relation to our budget planning I asked myself if OpenOffice has any
>> impact on the donations to the ASF? Well I don't know and we can
>> probably figure this out but the question is what can we do ti collect
>> more donations and use our brand more effective.
>>
>> When I look on our main website I found a tiny donation link in the
>> footer only. From my point of view this is not good enough and we should
>> think how we can improve it.
>>
>> I can think of a much more prominent and more visible donation link or
>> whatever to make clear that OpenOffice will still benefit from donations
>> to the ASF. We have more IT requirements than other ASF projects, we
>> generate more network traffic, etc. and all this cost money.
>>
>> Furthermore I can think of a blog post to promote this in some way and
>> do a public call for donation. We should of course do this more often
>> with any public announcement.
>>
>> And opinions or further ideas how we can improve this? It shouldn't be a
>> big problem for us to collect the money we need.
>>
>> Juergen
>>
> 
> While I understand and agree with a call for donations, do I remember that a 
> very early discussion on this list mentioned that donations to Apache could 
> not be project specific, or am I misremembering and that the mentioned 
> restriction was only flaw specific? That is, that one could donate, but could 
> not specify that the donation was to be applied to fix flaw X.
> 

yes that is true but we can explain how AOO benefit from this donations
to ASF. I don't see this really as a big problem. But of course we have
to make this very clear.

Juergen

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Proposal]: Call for donations

[Rory O'Farrell]

On Thu, 04 Apr 2013 14:22:33 +0200
Jürgen Schmidt  wrote:

> Hi,
> 
> in relation to our budget planning I asked myself if OpenOffice has any
> impact on the donations to the ASF? Well I don't know and we can
> probably figure this out but the question is what can we do ti collect
> more donations and use our brand more effective.
> 
> When I look on our main website I found a tiny donation link in the
> footer only. From my point of view this is not good enough and we should
> think how we can improve it.
> 
> I can think of a much more prominent and more visible donation link or
> whatever to make clear that OpenOffice will still benefit from donations
> to the ASF. We have more IT requirements than other ASF projects, we
> generate more network traffic, etc. and all this cost money.
> 
> Furthermore I can think of a blog post to promote this in some way and
> do a public call for donation. We should of course do this more often
> with any public announcement.
> 
> And opinions or further ideas how we can improve this? It shouldn't be a
> big problem for us to collect the money we need.
> 
> Juergen
> 

While I understand and agree with a call for donations, do I remember that a 
very early discussion on this list mentioned that donations to Apache could not 
be project specific, or am I misremembering and that the mentioned restriction 
was only flaw specific? That is, that one could donate, but could not specify 
that the donation was to be applied to fix flaw X.

-- 
Rory O'Farrell 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[Proposal]: Call for donations

[Jürgen Schmidt]

Hi,

in relation to our budget planning I asked myself if OpenOffice has any
impact on the donations to the ASF? Well I don't know and we can
probably figure this out but the question is what can we do ti collect
more donations and use our brand more effective.

When I look on our main website I found a tiny donation link in the
footer only. From my point of view this is not good enough and we should
think how we can improve it.

I can think of a much more prominent and more visible donation link or
whatever to make clear that OpenOffice will still benefit from donations
to the ASF. We have more IT requirements than other ASF projects, we
generate more network traffic, etc. and all this cost money.

Furthermore I can think of a blog post to promote this in some way and
do a public call for donation. We should of course do this more often
with any public announcement.

And opinions or further ideas how we can improve this? It shouldn't be a
big problem for us to collect the money we need.

Juergen

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Proposal: Improve security by limiting committer access in SVN

[Rob Weir]

On Wed, Apr 3, 2013 at 11:30 PM, Louis Suárez-Potts wrote:

> Thanks, Rob, et al.,
>
> On 13-04-03, at 22:22 , Peter Junge  wrote:
>
> 
>  One way of implementing this would be to look at all commits for the
> >>> past 6
>  months (or 1 year?) and remove authorization on /trunk, /tag and
> >>> /branches
>  for those who have not made commits.  But preserve authorization for
> the
>  website directories.
> 
>  Thoughts?
> 
>  -Rob
> 
> >
>
> In OOo we used SSH2. We also limited actual inclusion to code that had
> been reviewed by a small coterie of project managers. This last part—that
> that group of elites was another way of saying, "Sun" or, later, "Oracle,"
> led to displeasure. But not exactly because of the hierarchical system but
> because it was perceived that that system allowed Sun to control things
> while claiming open source openness.
>
> Whatever the merits of the critiques, having multiple layers of review and
> using SSH2 (which I rather like, as I don't like passwords at all, having
> read far too much Schneier) is one step. I'd also concur with the idea of
> scrubbing the lists of nonactive committers. That set would include me. I
> have not made any commits to the code (or anything) in the last year, at
> least.
>
>

I generally agree, but it will be important that we describe this in an
accurate way.   A "committer" is someone who contributes to the project and
has demonstrated merit and then has been voted in as a committer by the
PMC.  Some will be coders.  But many will be contributing in other ways.
All committers get an Apache ID and password.  These give automatic access
to things like: a personal home directory on people.apache.org, the ability
to send email from an apache.org email address, etc.  There are other
things that committers are entitled to, but which a separate request must
be made, like a blog editor account or being a list moderator.  What we're
suggesting is that write access to the source code be one of those things
that a committer must request separately.  It would not be automatically
enabled.

So we're not talking about "inactive committers", since they may be active
in the project in ways other than coding.  I'd just describe it by saying
we have committers that are involved in all areas of the project and each
committer has the permissions they need to do the tasks they want to do.
But we avoid giving automatic SVN permissions to everyone.  This is not for
hierarchical, or burocratic reasons, but purely for security reasons.  We
take security very importantly, as befits a product installed and used by
many millions of users.

-Rob


The point here is not to diminish any kind of democratic spirit or
> innovation but rather to ensure that the code we call ours (AOO) is really
> just ours and not a trap for the unwary—malware. The problem with traps
> like that is that rumour of their existence is almost as bad as their
> presence. I've had more than one discussion with government officials who
> said they could not use OO because they could not absolutely guarantee the
> license or sanctity of the code. I was able to convince them of both, but
> the point is that this sort of anxiety, fuelled by vicious minds, can only
> be dismissed with facts. And if you have doubts, just look to see how
> BlackDuck earns its profits. Enterprise adoption of open source is not seen
> as risk free.
>
> BTW, in OOo, Web directories were treated a little differently, than code
> but I argued for even stronger differentiation.
>
> -louis
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Re : Re: [RELEASE]: proposed schedule for AOO 4.0

[Jürgen Schmidt]

On 4/4/13 11:27 AM, mengualjean...@free.fr wrote:
> Hi,
> 
> Does some cycle exist about releasing of OOo? Because since the schedule, it 
> seems that OOo 4.0 will not include current work about accessibility. It is a 
> pitty as I think it is a major contribution and it would be a pitty if we 
> should wait for end of 2014 to see it. It seems things could be ready for 
> novembre. Do you think we can hope progress during 1st six months 2014? In a 
> 4.1 release I get?
> 

we had 2 releases last year and I don't see any reason why we should not
have 2 releases this year. It really depends on what we have for a new
release. We don't want release something only to have a new release.

The accessibility work is a big and major task and takes some time. It
can't be finished in time for 4.0 but we will see how the development
moves forward. It can be a good candidate for a 4.1.

Juergen


> Regards,
> 
> - Mail d'origine -
> De: Jürgen Schmidt 
> À: dev@openoffice.apache.org
> Envoyé: Thu, 04 Apr 2013 10:46:16 +0200 (CEST)
> Objet: Re: [RELEASE]: proposed schedule for AOO 4.0
> 
> On 2/20/13 11:32 AM, Jürgen Schmidt wrote:
>> On 2/20/13 10:46 AM, Jürgen Schmidt wrote:
>>> Hi,
>>>
>>> we make good progress with the sidebar work which is done on the branch.
>>> The sidebar will be the most visible and important change for 4.0 (by
>>> the way I like what I have seen so far). We come closer to the point
>>> where we should talk about a more detailed schedule.
>>>
>>> I would like to start with the following proposal and still many steps
>>> have to be defined in more detail.
>>>
>>> 03/01 function verification test will start, define test case, prepare
>>> tests etc.
>>> 04/04 integrate sidebar branch in trunk, other new features should be
>>> finished by this date as well.
>>
>> I missed to add that the art work (logo, icons, etc. should be finished
>> at this date as well)
>>
>>> 04/05 - 05/15 regression testing will be start on trunk
>>> 04/05 - 05/15 bugfix and stabilization, no feature development
>>> 04/08 - 05/15 translation -> I guessed ~5 weeks for updating the new
>>> strings. This can change when we know exactly how many new strings we
>>> will have. But translation for new languages can already work on the
>>> existing po files for 3.4.1.
>>> 05/21 RC1
>>> 06/04 RC2
>>> 06/18 RC3 (optional), can be GA already
>>> 06/25 GA -> this should be our final target
>>>
>>>
>>> This is a proposal based on the ongoing work that I no. Please let me
>>> know if I missed something important.
>>>
>>> Regular developer builds 1/week + nightly builds
>>>
>>> Based on feedback and potential changes I will put this in the wiki later.
>>>
>>> Important is from my pov that we start talking about the improvements
>>> that we make in public. It should be very clear for anybody where the
>>> real important features and improvement for OpenOffice or derivatives
>>> are coming from ;-)
> 
> I will try to give n update on the current plan.
> 
> The sidebar branch is not yet integrated but I expect that it will be
> finished next week latest. That means we will have a delay of some days
> here. As soon as I have concrete dates I will update the plan in the wiki.
> 
> Some further things are ongoing and we should try to finish this work
> soon (2 weeks) to have the stuff in place and can start or concentrate
> on bug fixing and stabilization.
> 
> Juergen
> 
> 
> 
> 
> 
>>>
>>>
>>> Juergen
>>>
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Where are the eastereggs

[Jürgen Schmidt]

On 4/4/13 11:18 AM, Jörg Schmidt wrote:
> Hello Jürgen, *, 
> 
>> From: Jürgen Schmidt [mailto:jogischm...@gmail.com] 
> 
>> hopefully removed all but haven't checked this
> 
> What do you mean exactly? Future there will be no more eastereggs?
> 
> OK, eastereggs are a gimmick, but at least "=Game("StarWars")" I found quite 
> nice.
> 

exactly, it's fun and not more and I don't think it should be part of
the code

> 
> greetings,
> Jörg
> 
> 
> Note:
> I do not know if CTRL + SDT (I think that stands for 'star development 
> team'), under the help information, a easteregg is, but that still works in 
> AOO 3.4.1.
> 

I don't know, haven't used it for a long time but yes this could be
removed as well because it is outdated anyway.

Juergen

> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re : Re: [RELEASE]: proposed schedule for AOO 4.0

[mengualjeanphi]

Hi,

Does some cycle exist about releasing of OOo? Because since the schedule, it 
seems that OOo 4.0 will not include current work about accessibility. It is a 
pitty as I think it is a major contribution and it would be a pitty if we 
should wait for end of 2014 to see it. It seems things could be ready for 
novembre. Do you think we can hope progress during 1st six months 2014? In a 
4.1 release I get?

Regards,

- Mail d'origine -
De: Jürgen Schmidt 
À: dev@openoffice.apache.org
Envoyé: Thu, 04 Apr 2013 10:46:16 +0200 (CEST)
Objet: Re: [RELEASE]: proposed schedule for AOO 4.0

On 2/20/13 11:32 AM, Jürgen Schmidt wrote:
> On 2/20/13 10:46 AM, Jürgen Schmidt wrote:
>> Hi,
>>
>> we make good progress with the sidebar work which is done on the branch.
>> The sidebar will be the most visible and important change for 4.0 (by
>> the way I like what I have seen so far). We come closer to the point
>> where we should talk about a more detailed schedule.
>>
>> I would like to start with the following proposal and still many steps
>> have to be defined in more detail.
>>
>> 03/01 function verification test will start, define test case, prepare
>> tests etc.
>> 04/04 integrate sidebar branch in trunk, other new features should be
>> finished by this date as well.
> 
> I missed to add that the art work (logo, icons, etc. should be finished
> at this date as well)
> 
>> 04/05 - 05/15 regression testing will be start on trunk
>> 04/05 - 05/15 bugfix and stabilization, no feature development
>> 04/08 - 05/15 translation -> I guessed ~5 weeks for updating the new
>> strings. This can change when we know exactly how many new strings we
>> will have. But translation for new languages can already work on the
>> existing po files for 3.4.1.
>> 05/21 RC1
>> 06/04 RC2
>> 06/18 RC3 (optional), can be GA already
>> 06/25 GA -> this should be our final target
>>
>>
>> This is a proposal based on the ongoing work that I no. Please let me
>> know if I missed something important.
>>
>> Regular developer builds 1/week + nightly builds
>>
>> Based on feedback and potential changes I will put this in the wiki later.
>>
>> Important is from my pov that we start talking about the improvements
>> that we make in public. It should be very clear for anybody where the
>> real important features and improvement for OpenOffice or derivatives
>> are coming from ;-)

I will try to give n update on the current plan.

The sidebar branch is not yet integrated but I expect that it will be
finished next week latest. That means we will have a delay of some days
here. As soon as I have concrete dates I will update the plan in the wiki.

Some further things are ongoing and we should try to finish this work
soon (2 weeks) to have the stuff in place and can start or concentrate
on bug fixing and stabilization.

Juergen





>>
>>
>> Juergen
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Where are the eastereggs

[Jörg Schmidt]

Hello Jürgen, *, 

> From: Jürgen Schmidt [mailto:jogischm...@gmail.com] 

> hopefully removed all but haven't checked this

What do you mean exactly? Future there will be no more eastereggs?

OK, eastereggs are a gimmick, but at least "=Game("StarWars")" I found quite 
nice.


greetings,
Jörg


Note:
I do not know if CTRL + SDT (I think that stands for 'star development team'), 
under the help information, a easteregg is, but that still works in AOO 3.4.1.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [RELEASE]: proposed schedule for AOO 4.0

[Jürgen Schmidt]

On 2/20/13 11:32 AM, Jürgen Schmidt wrote:
> On 2/20/13 10:46 AM, Jürgen Schmidt wrote:
>> Hi,
>>
>> we make good progress with the sidebar work which is done on the branch.
>> The sidebar will be the most visible and important change for 4.0 (by
>> the way I like what I have seen so far). We come closer to the point
>> where we should talk about a more detailed schedule.
>>
>> I would like to start with the following proposal and still many steps
>> have to be defined in more detail.
>>
>> 03/01 function verification test will start, define test case, prepare
>> tests etc.
>> 04/04 integrate sidebar branch in trunk, other new features should be
>> finished by this date as well.
> 
> I missed to add that the art work (logo, icons, etc. should be finished
> at this date as well)
> 
>> 04/05 - 05/15 regression testing will be start on trunk
>> 04/05 - 05/15 bugfix and stabilization, no feature development
>> 04/08 - 05/15 translation -> I guessed ~5 weeks for updating the new
>> strings. This can change when we know exactly how many new strings we
>> will have. But translation for new languages can already work on the
>> existing po files for 3.4.1.
>> 05/21 RC1
>> 06/04 RC2
>> 06/18 RC3 (optional), can be GA already
>> 06/25 GA -> this should be our final target
>>
>>
>> This is a proposal based on the ongoing work that I no. Please let me
>> know if I missed something important.
>>
>> Regular developer builds 1/week + nightly builds
>>
>> Based on feedback and potential changes I will put this in the wiki later.
>>
>> Important is from my pov that we start talking about the improvements
>> that we make in public. It should be very clear for anybody where the
>> real important features and improvement for OpenOffice or derivatives
>> are coming from ;-)

I will try to give n update on the current plan.

The sidebar branch is not yet integrated but I expect that it will be
finished next week latest. That means we will have a delay of some days
here. As soon as I have concrete dates I will update the plan in the wiki.

Some further things are ongoing and we should try to finish this work
soon (2 weeks) to have the stuff in place and can start or concentrate
on bug fixing and stabilization.

Juergen





>>
>>
>> Juergen
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Where are the eastereggs

[Jürgen Schmidt]

On 4/4/13 10:28 AM, Jörg Schmidt wrote:
> Hello,
> 
> Where are the eastereggs in OpenOffice.org (> 3.2.1) or Apache OpenOffice 
> versions?
> 
> Until version of OOo 3.2.1, there was eastereggs following:
> http://ooo42.de/ooo42-eastereggs.odt
> 

hopefully removed all but haven't checked this

Juergen


> 
> greetings,
> Jörg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Where are the eastereggs

[Jörg Schmidt]

Hello,

Where are the eastereggs in OpenOffice.org (> 3.2.1) or Apache OpenOffice 
versions?

Until version of OOo 3.2.1, there was eastereggs following:
http://ooo42.de/ooo42-eastereggs.odt


greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: OS for main AOO buildbots

[Oliver-Rainer Wittmann]

Hi,

On 03.04.2013 00:37, Andrea Pescetti wrote:

Andrew Rist wrote:

What version of CentOS do we want on this machine? We want the snapshot
builds to be fully usable.


I'll write here the reasoning behind this, so that it can be corrected
if needed.

Ariel's special version available at http://www.openoffice.org/porting/
uses glibc 2.5. It satisfies all users, including Red Hat 5 (and, fully
compatible, CentOS 5) users. So adopting this as a baseline should
guarantee that our binaries run on almost all vendor-supported
distributions. Red Hat 5 and CentOS 5 are quite old but still supported
from their vendors, and reasonably common in corporate environments.



Ariel's input would be very valuable here as I agree to Andrea that we 
should try to statisfy as much user's environments as possible.



Best regards, Oliver.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: update service for not released languages [was: Re: Registration]

[Jürgen Schmidt]

On 4/4/13 8:26 AM, janI wrote:
> On 4 April 2013 06:19, Juergen Schmidt  wrote:
> 
>> Am Mittwoch, 3. April 2013 um 22:46 schrieb Rob Weir:
>>> On Sat, Mar 9, 2013 at 6:52 AM, Andrea Pescetti 
>> wrote:
>>>
 On 03/03/2013 janI wrote:

> On 3 March 2013 17:47, Andrea Pescetti wrote:
>
>> 1) Check on the Pootle 2.5 release date and features.
> I would like to see it running on other sites the translate itself,
>> but I
>
> am just a negative (have been too long in support). My rule of thumb
>> is
> release date + 1 month, in order not to fight fight with start
>> problems.
>


 Here I agree with Rob that we need to set a deadline. A natural one is
>> the
 translation period set at https://cwiki.apache.org/**
 confluence/display/OOOUSERS/**AOO+4.0+Release+Planning<
>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Planning>(beginning
>> in one month). So, considering installation and testing, we
 would need Pootle 2.5 to be available soon. I've asked the developers
>> if
 they have a timeline, just to get an idea.

>>>
>>> Almost a month has passed since I made this proposal. Do we have a sense
>>> now whether the Pootle upgrade will occur in time for AOO 4.0
>>> translations? Or I should I go ahead with the a call for translations for
>>> AOO 4.0 using POEdit and similar off-line tools? This would include
>>> reaching out to users via the update notification mechanism.
>>>
>>>
>>
>> I will try to figure it out today...
>> But it is to early and we don't have the new translation files in place
>> yet. We have to merge the sidebar branch first and that is already in
>> preparation.
>>
>> 2.5 is not released and will most problaly not make it before we need it.
> BUT the translation interface have not changed, it is inner working and
> download possibilities.
> 
> I think we need offline tools, I would not to mass translation on the
> server.
> 
> To me the bigger question is, do we start translation with our current file
> structure, or will genLang be in place (heavely reduced file count).
> Integration into build system has been a lot more difficult than i
> expected, especially for helpcontent2. I have concentrated on helpcontent2,
> and are very close with that, so I expect us to take a discussion/vote next
> week, whether or not to integrate it in trunk.

Hi Jan,

having the new tooling in place would be great but we don't have
pressure. We should take all the time that we need to make it final and
complete and well tested. Before we integrate it we should test your
branch with some languages in detail on at least 3 platforms (Linux,
windows, MacOS).

You did a fantastic job and it will be a huge step forward. We can
integrate it probably at any time when it is ready.

On the other hand it is a very important part of our build system and my
experience told me that we should test it deeply. Don't get me wrong I
am sure you made a good job here, it's simply that I have seen too often
that we got many problems with less.

Don't put yourself under pressure.

I can build your branch on MacOS. What do I have to do exactly to
trigger your new tooling? I will ping you on IRC ...

Juergen




> 
> rgds
> Jan I
> 
>> Juergen
>>>
>>> -Rob
>>>
>>>
>>>
>>>
 2) Check that policy-wise it's fine to authenticate committers on LDAP
>> and
>> all other volunteers on a local backend. ...
>
> infra (gmcdonald) was not positive, but I still think we
> have a case and should go for it...I do however think a compromise
>> could
> be
> a signed ICLA.
>


 This has been clarified in the meantime on the Incubator lists (in a
 discussion otherwise unrelated to OpenOffice). No ICLA needed.
 http://mail-archives.apache.**org/mod_mbox/incubator-**

>> general/201303.mbox/%3CCAAS6%**3D7hybut%**3DLGZQRkuuJPXKK4KPS6CiXDYE5-**
 QTmvguYHOVFA%40mail.gmail.com%**3E<
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201303.mbox/%3CCAAS6%3D7hybut%3DLGZQRkuuJPXKK4KPS6CiXDYE5-QTmvguYHOVFA%40mail.gmail.com%3E
>>>

 3) Optimize performance so that Pootle is actually usable by several
>> users.
>
> That is something on my list of todos, and infra ask me regulary
>> when I do
> it. ...a bottle of good italian wine when if finally works,
> together with genLang.
>


 OK. And OK for the bottle too!

 Regards,
 Andrea.


>> --**--**-
 To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> dev-unsubscr...@openoffice.apache.org>
 For additional commands, e-mail: dev-h...@openoffice.apache.org

>>>
>>>
>>>
>>
>>
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org