Re: update service for not released languages [was: Re: Registration]
On 4 April 2013 06:19, Juergen Schmidt jogischm...@gmail.com wrote: Am Mittwoch, 3. April 2013 um 22:46 schrieb Rob Weir: On Sat, Mar 9, 2013 at 6:52 AM, Andrea Pescetti pesce...@apache.org 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. 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
Re: update service for not released languages [was: Re: Registration]
On 4/4/13 8:26 AM, janI wrote: On 4 April 2013 06:19, Juergen Schmidt jogischm...@gmail.com wrote: Am Mittwoch, 3. April 2013 um 22:46 schrieb Rob Weir: On Sat, Mar 9, 2013 at 6:52 AM, Andrea Pescetti pesce...@apache.org 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
Re: OS for main AOO buildbots
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
Where are the eastereggs
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: Where are the eastereggs
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
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
Re: Where are the eastereggs
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 : Re: [RELEASE]: proposed schedule for AOO 4.0
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 jogischm...@gmail.com À: 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
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 : Re: [RELEASE]: proposed schedule for AOO 4.0
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 jogischm...@gmail.com À: 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: Proposal: Improve security by limiting committer access in SVN
On Wed, Apr 3, 2013 at 11:30 PM, Louis Suárez-Potts lui...@gmail.comwrote: Thanks, Rob, et al., On 13-04-03, at 22:22 , Peter Junge peter.ju...@gmx.org 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
[Proposal]: Call for donations
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]: Call for donations
On Thu, 04 Apr 2013 14:22:33 +0200 Jürgen Schmidt jogischm...@gmail.com 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 ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Proposal]: Call for donations
On 4/4/13 2:46 PM, Rory O'Farrell wrote: On Thu, 04 Apr 2013 14:22:33 +0200 Jürgen Schmidt jogischm...@gmail.com 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
On Thu, Apr 4, 2013 at 8:22 AM, Jürgen Schmidt jogischm...@gmail.comwrote: 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: [Proposal]: Call for donations
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: Improve security by limiting committer access in SVN
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: Proposal: Improve security by limiting committer access in SVN
On 4 April 2013 19:44, Andrea Pescetti pesce...@apache.org 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.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN
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
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
On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein gst...@gmail.com 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 than there being a possible exploit of that inattention. Mechanical solutions may
tpcolor.cxx
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
On Thu, Apr 4, 2013 at 2:27 PM, Dennis E. Hamilton dennis.hamil...@acm.orgwrote: 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 that is already in released code.
Re: Proposal: Improve security by limiting committer access in SVN
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 robw...@apache.org wrote: On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein gst...@gmail.com 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
Re: Proposal: Improve security by limiting committer access in SVN
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 gst...@gmail.com 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
Re: [Lazy concensus] language merge into trunk.
On Thu, Apr 4, 2013 at 11:21 AM, janI j...@apache.org 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
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 robw...@apache.org wrote: On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein gst...@gmail.com 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
Re: Proposal: Improve security by limiting committer access in SVN
On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein gst...@gmail.com 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 gst...@gmail.com 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
Re: [Proposal]: Call for donations
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: http://www.apache.org/foundation/contributing.html. 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 jogischm...@gmail.comwrote: [ ... ] 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: [RELEASE]: proposed schedule for AOO 4.0
Am Donnerstag, 4. April 2013 um 19:40 schrieb Kay Schenk: On Thu, Apr 4, 2013 at 4:07 AM, Jürgen Schmidt jogischm...@gmail.comwrote: 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 jogischm...@gmail.com À: 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: Proposal: Improve security by limiting committer access in SVN
On 4 April 2013 21:03, Rob Weir robw...@apache.org wrote: On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein gst...@gmail.com 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 gst...@gmail.com 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
Re: Proposal: Improve security by limiting committer access in SVN
On Thu, Apr 4, 2013 at 3:30 PM, Dennis E. Hamilton dennis.hamil...@acm.orgwrote: 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 gst...@gmail.com 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 gst...@gmail.com 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
Re: Proposal: Improve security by limiting committer access in SVN
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 robw...@apache.org To: dev@openoffice.apache.org 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 j...@apache.org wrote: On 4 April 2013 21:03, Rob Weir robw...@apache.org wrote: On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein gst...@gmail.com 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 gst...@gmail.com 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
Re: Proposal: Improve security by limiting committer access in SVN
On Thu, Apr 4, 2013 at 3:59 PM, Joe Schaefer joe_schae...@yahoo.com 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 robw...@apache.org To: dev@openoffice.apache.org 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 j...@apache.org wrote: On 4 April 2013 21:03, Rob Weir robw...@apache.org wrote: On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein gst...@gmail.com 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 gst...@gmail.com 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
RE: Proposal: Improve security by limiting committer access in SVN
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
On Thu, Apr 4, 2013 at 4:16 PM, Dennis E. Hamilton dennis.hamil...@acm.orgwrote: 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]: Call for donations
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]: Call for donations
On Thu, Apr 4, 2013 at 4:41 PM, Marcus (OOo) marcus.m...@wtnet.de 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.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Binfilter removal - PATCH
On Thu, Apr 4, 2013 at 10:16 AM, Pavel Janík pa...@janik.cz 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: [Lazy concensus] language merge into trunk.
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: Why can't I find open office 2.3 for mac osx 10.5.8 on the website?
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/
Am 04/04/2013 11:27 PM, schrieb Kay Schenk: On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 04/01/2013 03:12 AM, schrieb Rob Weir: On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)marcus.m...@wtnet.de 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: [Website] Re-locate images from download/images/ to images/
On Thu, Apr 4, 2013 at 5:27 PM, Kay Schenk kay.sch...@gmail.com wrote: On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 04/01/2013 03:12 AM, schrieb Rob Weir: On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)marcus.m...@wtnet.de 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: [Proposal]: Call for donations
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/
Am 04/05/2013 12:18 AM, schrieb Rob Weir: On Thu, Apr 4, 2013 at 5:27 PM, Kay Schenkkay.sch...@gmail.com wrote: On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 04/01/2013 03:12 AM, schrieb Rob Weir: On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)marcus.m...@wtnet.de 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
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 pesce...@apache.org 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
Easy hack for website
I just entered a BZ issue : https://issues.apache.org/ooo/show_bug.cgi?id=122003 Missing title 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
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 pesce...@apache.org 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: Proposal: Improve security by limiting committer access in SVN
On Apr 4, 2013, at 12:17 PM, janI wrote: On 4 April 2013 21:03, Rob Weir robw...@apache.org wrote: On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein gst...@gmail.com 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 gst...@gmail.com 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
Re: [Proposal]: Call for donations
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 pesce...@apache.org 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: [Website] Re-locate images from download/images/ to images/
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 Schenkkay.sch...@gmail.com wrote: On Mon, Apr 1, 2013 at 3:52 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 04/01/2013 03:12 AM, schrieb Rob Weir: On Sun, Mar 31, 2013 at 11:12 AM, Marcus (OOo)marcus.m...@wtnet.de 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
On Thu, Apr 4, 2013 at 8:23 PM, Dave Fisher dave2w...@comcast.net 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 pesce...@apache.org 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: OpenOffice Cases of Success
On 13-04-04, at 22:10 , Galileo Teco Juárez genital...@gmail.com 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 http://twitter.com/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: Conversation: Pick A Logo
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 samer...@gmail.com 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 vka...@gmail.com 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 jogischm...@gmail.com wrote: Am Samstag, 30. März 2013 um 03:05 schrieb Alexandro Colorado: On 3/29/13, Robin Fowler robin.fow...@outlook.com 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=1modificationDate=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 samer...@gmail.com 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 completely new. That simple was actually beautiful. Thoughts? Agree? Disagree (and your solution is)? Samer Mansour - To unsubscribe, e-mail: marketing-unsubscr...@openoffice.apache.org For additional commands, e-mail: marketing-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice
Re: Why can't I find open office 2.3 for mac osx 10.5.8 on the website?
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
