date:20130403

On 3 April 2013 10:22, Pavel Janík pa...@janik.cz wrote:

 Hi,

 http://tmp.janik.cz/AO/binfilter-removal.diff

 This is the first attempt to remove module binfilter. To add more to this,
 we should remove directories binfilter and scp2/source/binfilter.


+1 to remove directories,

Are there other directories (modules) in main that are antique ?

I have been wonding a lot about who/what uses toolkit/src2xml.

rgds
Jan I

 --
 Pavel Janík




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

draft blog post: press@ - It's easy to get first hand information

Hi,

I am a little bit annoyed about the often bad researched articles about
OpenOffice or at least articles spreading wrong information about
OpenOffice. I don't know exactly why authors do such a poor job with
their research of correct information where it is so easy on the other
hand to get first information. The idea is to raise some awareness that
the info found in the web is not always true and it is much better to
get first hand information from the project and the people behind it
directly. Nobody have to rely on third party information found somewhere
when first hand information can be get so so easy.


Well the wording can and should be improved and I am sure others will
have further ideas to improve it or make it even better to send out the
right signal. Se please review the draft and your feedback is welcome.
It's mainly an idea and I am not sure if it is the best way to address
this.

https://blogs.apache.org/preview/OOo/?previewEntry=press_it_s_easy_to

Juergen

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

Re: May I join the OOo?

Welcome, please mention your skillset and we can provide ideas on
where in OO would you feel more confortable.

On 4/2/13, Sand Wen sand.fj@gmail.com wrote:
 Hey guys, I have learned some of the OOo history and the OOo Architecture,
 and I think maybe I can do something for OpenOffice, hope getting more
 information from OOo.



 Best Wishes!

 Sand Wen




-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org

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

Re: draft blog post: press@ - It's easy to get first hand information

On Wed, Apr 3, 2013 at 8:10 AM, Jürgen Schmidt jogischm...@gmail.comwrote:

 Hi,

 I am a little bit annoyed about the often bad researched articles about
 OpenOffice or at least articles spreading wrong information about
 OpenOffice. I don't know exactly why authors do such a poor job with
 their research of correct information where it is so easy on the other
 hand to get first information. The idea is to raise some awareness that
 the info found in the web is not always true and it is much better to
 get first hand information from the project and the people behind it
 directly. Nobody have to rely on third party information found somewhere
 when first hand information can be get so so easy.


 Well the wording can and should be improved and I am sure others will
 have further ideas to improve it or make it even better to send out the
 right signal. Se please review the draft and your feedback is welcome.
 It's mainly an idea and I am not sure if it is the best way to address
 this.


If we wait a little longer we might be able to achieve the safe effect but
with a more positive message.  I've been slowly updating the old press kit
page:

http://www.openoffice.org/marketing/press_kit.html

I also started to look at preparing new screenshots for AOO 3.4.1 and AOO
4.0, so there is easy to use material for articles.

And as you know, we now have the press@o.a.o email address.

Once that is done, then we could have a positive message about how we're
helping the press.

What is the saying? You catch more flies with honey than vinegar?


-Rob



 https://blogs.apache.org/preview/OOo/?previewEntry=press_it_s_easy_to

 Juergen

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

Re: draft blog post: press@ - It's easy to get first hand information

On Wed, Apr 3, 2013 at 8:42 AM, Regina Henschel rb.hensc...@t-online.dewrote:

 Hi Jürgen,

 we have a mailing list pr...@openoffice.apache.org?


It is not a mailing list.  It is an alias for priv...@openoffice.apache.org.


-Rob



 It is neither listed at 
 http://openoffice.apache.org/**mailing-lists.htmlhttp://openoffice.apache.org/mailing-lists.htmlnor
  at
 http://mail-archives.apache.**org/mod_mbox/http://mail-archives.apache.org/mod_mbox/

 If the list exists, then a blog post announcing it, is a good idea. (And
 adding the address in the lists)

 Kind regards
 Regina

 Jürgen Schmidt schrieb:

  Hi,

 I am a little bit annoyed about the often bad researched articles about
 OpenOffice or at least articles spreading wrong information about
 OpenOffice. I don't know exactly why authors do such a poor job with
 their research of correct information where it is so easy on the other
 hand to get first information. The idea is to raise some awareness that
 the info found in the web is not always true and it is much better to
 get first hand information from the project and the people behind it
 directly. Nobody have to rely on third party information found somewhere
 when first hand information can be get so so easy.


 Well the wording can and should be improved and I am sure others will
 have further ideas to improve it or make it even better to send out the
 right signal. Se please review the draft and your feedback is welcome.
 It's mainly an idea and I am not sure if it is the best way to address
 this.

 https://blogs.apache.org/**preview/OOo/?previewEntry=**press_it_s_easy_tohttps://blogs.apache.org/preview/OOo/?previewEntry=press_it_s_easy_to

 Juergen

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




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

I think restricting this would be a horrible idea, since we still have
a shortage of developers. Limiting it by permissions and creating a
red tape would be even more problematic. I think the key here is about
the aproved releases. I don't really use windows, so I am not very
familiar with the topic and whole process at hand when installing and
testing. However I would focus more on the final QA than the initial
access/commit to the code.

On 4/3/13, Rob Weir robw...@apache.org wrote:
 We're starting to take a deeper look at what is required to integrate code
 signing into the OpenOffice build and release process. As you probably know
 operating systems, especially Windows and MacOS, are now checking for
 digital signatures and by default prevent users from installing programs
 that are not signed.  We see similar checks being integrated into
 anti-virus scanners and even web browsers now.

 One of the things that has come out in discussions is how large a target
 OpenOffice is, to hackers.  We're on track to have 50 million downloads in
 our first year.  If someone is able to get a virus or a trojan into our
 code, they have the ability to cause a huge amount of damage.  And if we
 are also signing our code, then this damage can propagate even faster,
 since the OS's let down their guard somewhat when dealing with signed
 code.  (Signed code == trust).

 Of course, none of this has ever happened with OpenOffice, but with the
 stature and reach we have, it is reasonable to believe that we could be a
 target of opportunity for someone wishing to cause trouble.  We should
 always keep this in mind and make sure that we are taking reasonable
 precautions to prevent this from happening.

 One vulnerability, in theory, is that we have over 100 committers (123 to
 be exact) who have permission to modify the source code in Subversion.
 Each account is protected by a self-selected passcode.  It is not clear to
 me that we even have requirements on password complexity or expiration
 policies.   In any case, the weakness of this approach is not necessarily
 what you might think -- brute force attack on the password.  If someone
 wants to initiate a spear phishing attack against a committer, it would
 be something like:

 1) Standard phishing: a spoofed note from Apache Infra, with some invented
 story that asks you to change your password but first enter your old one
 for confirmation.  It leads you to a fake, non-Apache website.

 2) If you use the same passcode on multiple web services and one of them is
 compromised, say by retrieving the passcode hashes, then it is easy to do
 offline dictionary attacks (rainbow tables, etc.) and figure out your
 Apache password.

 3) If you lose control of your laptop, at a conference, bar, hotel,
 whatever, even temporarily, someone can gain access to your Subversion
 account, via applications that cache credentials, like TortoiseSVN.

 4) Similar to #3, but by taking control of your laptop via remote means,
 i.e., via a virus loaded on to your machine via another vulnerability.

 None of these things have happened to us yet, but all of these things are
 possible.

 So how do we reduce this risk?  There are a few things we do or should be
 doing already.

 1) Be careful on the machines that you use Subversion from.  Treat it like
 a machine where you access your bank account from.  If you are visiting
 risky sites or downloading and installing software from dubious places,
 then you are putting your Apache account at risk.

 2) Use a high-complexity Apache passcode, one not used by you on any other
 service.

 3) Change your passcode periodically, say every 90 days.

 4) On laptops be sure to set a strong login password, but also where
 available also a separate harddrive password.  These should also be strong
 passwords, not reused, and should be periodically changed.

 For those who are building binaries for distribution, the above guidance is
 even more critical.

 Of course, we also protect the code through our CTR process.  All active
 coders should be subscribed to the commits list and should be reviewing the
 changes that are made there.  Trust the code, not the person.  Remember, if
 we ever are attacked then it will be through someone's compromised
 account.  So if you see an odd check-in, say, from Juergen, don't just
 accept it saying Juergen knows what he is doing.  If it is odd, then it
 should be challenged.

 All of the above should already be going on today.  But I'd like to propose
 one change to our current process that will, I think, greatly increase
 security.  This would be to restrict SVN authorization for the code to only
 the subset of committers who are actively coding.  We should give this
 authorization freely to committers who request it.  But today we have 123
 committers, some of whom have never used Subversion, and some (like me) who
 edit /site and /ooo-site but never touch the code.  So we probably have 90
 or more accounts that don't need

Error 1 module(s): odk

2013-04-03 Thread jorge ivan poot diaz

Hello,

I'm building in AOO source code, but I have a error in the module odk:

Here the error:

Entering /home/ivan/aoo/main/odk/util

dmake:  Error: --
`../examples/cpp/StatusbarController/WordCountStatusbarController/WordCountDispatch.hxx'
not found, and can't be made

1 module(s):
odk
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making /home/ivan/aoo/main/odk/util

When you have fixed the errors in that module you can resume the build by
running:

build --all:odk

ivan@ivan-Presario-CQ43-Notebook-PC:~/aoo/main/instsetoo_native$


I'm building on Ubuntu 12.04
Help me, regards.

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

On Wed, Apr 3, 2013 at 8:57 AM, Alexandro Colorado j...@oooes.org wrote:

 I think restricting this would be a horrible idea, since we still have
 a shortage of developers. Limiting it by permissions and creating a
 red tape would be even more problematic. I think the key here is about
 the aproved releases. I don't really use windows, so I am not very
 familiar with the topic and whole process at hand when installing and
 testing. However I would focus more on the final QA than the initial
 access/commit to the code.


I'm talking about restricting access for non-programmers, those who have
permissions currently, but who have never ever contributed a single line of
code.  No actual programmer would be restricted.

For the kinds of risks I'm describing QA would accomplish nothing.  Any
hacker worth the name would delay activation of an attack until after
millions of copies had already been installed, and then they would activate
the code remotely.

-Rob



 On 4/3/13, Rob Weir robw...@apache.org wrote:
  We're starting to take a deeper look at what is required to integrate
 code
  signing into the OpenOffice build and release process. As you probably
 know
  operating systems, especially Windows and MacOS, are now checking for
  digital signatures and by default prevent users from installing programs
  that are not signed.  We see similar checks being integrated into
  anti-virus scanners and even web browsers now.
 
  One of the things that has come out in discussions is how large a target
  OpenOffice is, to hackers.  We're on track to have 50 million downloads
 in
  our first year.  If someone is able to get a virus or a trojan into our
  code, they have the ability to cause a huge amount of damage.  And if we
  are also signing our code, then this damage can propagate even faster,
  since the OS's let down their guard somewhat when dealing with signed
  code.  (Signed code == trust).
 
  Of course, none of this has ever happened with OpenOffice, but with the
  stature and reach we have, it is reasonable to believe that we could be a
  target of opportunity for someone wishing to cause trouble.  We should
  always keep this in mind and make sure that we are taking reasonable
  precautions to prevent this from happening.
 
  One vulnerability, in theory, is that we have over 100 committers (123 to
  be exact) who have permission to modify the source code in Subversion.
  Each account is protected by a self-selected passcode.  It is not clear
 to
  me that we even have requirements on password complexity or expiration
  policies.   In any case, the weakness of this approach is not necessarily
  what you might think -- brute force attack on the password.  If someone
  wants to initiate a spear phishing attack against a committer, it would
  be something like:
 
  1) Standard phishing: a spoofed note from Apache Infra, with some
 invented
  story that asks you to change your password but first enter your old one
  for confirmation.  It leads you to a fake, non-Apache website.
 
  2) If you use the same passcode on multiple web services and one of them
 is
  compromised, say by retrieving the passcode hashes, then it is easy to do
  offline dictionary attacks (rainbow tables, etc.) and figure out your
  Apache password.
 
  3) If you lose control of your laptop, at a conference, bar, hotel,
  whatever, even temporarily, someone can gain access to your Subversion
  account, via applications that cache credentials, like TortoiseSVN.
 
  4) Similar to #3, but by taking control of your laptop via remote means,
  i.e., via a virus loaded on to your machine via another vulnerability.
 
  None of these things have happened to us yet, but all of these things are
  possible.
 
  So how do we reduce this risk?  There are a few things we do or should be
  doing already.
 
  1) Be careful on the machines that you use Subversion from.  Treat it
 like
  a machine where you access your bank account from.  If you are visiting
  risky sites or downloading and installing software from dubious places,
  then you are putting your Apache account at risk.
 
  2) Use a high-complexity Apache passcode, one not used by you on any
 other
  service.
 
  3) Change your passcode periodically, say every 90 days.
 
  4) On laptops be sure to set a strong login password, but also where
  available also a separate harddrive password.  These should also be
 strong
  passwords, not reused, and should be periodically changed.
 
  For those who are building binaries for distribution, the above guidance
 is
  even more critical.
 
  Of course, we also protect the code through our CTR process.  All active
  coders should be subscribed to the commits list and should be reviewing
 the
  changes that are made there.  Trust the code, not the person.  Remember,
 if
  we ever are attacked then it will be through someone's compromised
  account.  So if you see an odd check-in, say, from Juergen, don't just
  accept it saying Juergen knows what he is

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

On 3 April 2013 14:39, Rob Weir robw...@apache.org wrote:

 We're starting to take a deeper look at what is required to integrate code
 signing into the OpenOffice build and release process. As you probably know
 operating systems, especially Windows and MacOS, are now checking for
 digital signatures and by default prevent users from installing programs
 that are not signed.  We see similar checks being integrated into
 anti-virus scanners and even web browsers now.

 One of the things that has come out in discussions is how large a target
 OpenOffice is, to hackers.  We're on track to have 50 million downloads in
 our first year.  If someone is able to get a virus or a trojan into our
 code, they have the ability to cause a huge amount of damage.  And if we
 are also signing our code, then this damage can propagate even faster,
 since the OS's let down their guard somewhat when dealing with signed
 code.  (Signed code == trust).

 Of course, none of this has ever happened with OpenOffice, but with the
 stature and reach we have, it is reasonable to believe that we could be a
 target of opportunity for someone wishing to cause trouble.  We should
 always keep this in mind and make sure that we are taking reasonable
 precautions to prevent this from happening.

 One vulnerability, in theory, is that we have over 100 committers (123 to
 be exact) who have permission to modify the source code in Subversion.
 Each account is protected by a self-selected passcode.  It is not clear to
 me that we even have requirements on password complexity or expiration
 policies.   In any case, the weakness of this approach is not necessarily
 what you might think -- brute force attack on the password.  If someone
 wants to initiate a spear phishing attack against a committer, it would
 be something like:

 1) Standard phishing: a spoofed note from Apache Infra, with some invented
 story that asks you to change your password but first enter your old one
 for confirmation.  It leads you to a fake, non-Apache website.

 2) If you use the same passcode on multiple web services and one of them is
 compromised, say by retrieving the passcode hashes, then it is easy to do
 offline dictionary attacks (rainbow tables, etc.) and figure out your
 Apache password.

 3) If you lose control of your laptop, at a conference, bar, hotel,
 whatever, even temporarily, someone can gain access to your Subversion
 account, via applications that cache credentials, like TortoiseSVN.

 4) Similar to #3, but by taking control of your laptop via remote means,
 i.e., via a virus loaded on to your machine via another vulnerability.


None of these things have happened to us yet, but all of these things are
 possible.

 So how do we reduce this risk?  There are a few things we do or should be
 doing already.

 1) Be careful on the machines that you use Subversion from.  Treat it like
 a machine where you access your bank account from.  If you are visiting
 risky sites or downloading and installing software from dubious places,
 then you are putting your Apache account at risk.

 2) Use a high-complexity Apache passcode, one not used by you on any other
 service.

 3) Change your passcode periodically, say every 90 days.


4) On laptops be sure to set a strong login password, but also where
 available also a separate harddrive password.  These should also be strong
 passwords, not reused, and should be periodically changed.

 For those who are building binaries for distribution, the above guidance is
 even more critical.

 Of course, we also protect the code through our CTR process.  All active
 coders should be subscribed to the commits list and should be reviewing the
 changes that are made there.  Trust the code, not the person.  Remember, if
 we ever are attacked then it will be through someone's compromised
 account.  So if you see an odd check-in, say, from Juergen, don't just
 accept it saying Juergen knows what he is doing.  If it is odd, then it
 should be challenged.

 All of the above should already be going on today.  But I'd like to propose
 one change to our current process that will, I think, greatly increase
 security.  This would be to restrict SVN authorization for the code to only
 the subset of committers who are actively coding.  We should give this
 authorization freely to committers who request it.  But today we have 123
 committers, some of whom have never used Subversion, and some (like me) who
 edit /site and /ooo-site but never touch the code.  So we probably have 90
 or more accounts that don't need access to the source code tree.  Since
 such used accounts are unlikely to be following the best practices outlined
 above (changing passwords periodically, etc.) then they are even more
 risky.  We lose nothing by removing authorization for those users, in order
 to reduce the risk profile.  Of course, on request we can easily restore
 access.  But the idea would be to keep the bullets separate from the gun by
 default, to reduce

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

On Wed, Apr 3, 2013 at 9:06 AM, janI j...@apache.org wrote:

 On 3 April 2013 14:39, Rob Weir robw...@apache.org wrote:

  We're starting to take a deeper look at what is required to integrate
 code
  signing into the OpenOffice build and release process. As you probably
 know
  operating systems, especially Windows and MacOS, are now checking for
  digital signatures and by default prevent users from installing programs
  that are not signed.  We see similar checks being integrated into
  anti-virus scanners and even web browsers now.
 
  One of the things that has come out in discussions is how large a target
  OpenOffice is, to hackers.  We're on track to have 50 million downloads
 in
  our first year.  If someone is able to get a virus or a trojan into our
  code, they have the ability to cause a huge amount of damage.  And if we
  are also signing our code, then this damage can propagate even faster,
  since the OS's let down their guard somewhat when dealing with signed
  code.  (Signed code == trust).
 
  Of course, none of this has ever happened with OpenOffice, but with the
  stature and reach we have, it is reasonable to believe that we could be a
  target of opportunity for someone wishing to cause trouble.  We should
  always keep this in mind and make sure that we are taking reasonable
  precautions to prevent this from happening.
 
  One vulnerability, in theory, is that we have over 100 committers (123 to
  be exact) who have permission to modify the source code in Subversion.
  Each account is protected by a self-selected passcode.  It is not clear
 to
  me that we even have requirements on password complexity or expiration
  policies.   In any case, the weakness of this approach is not necessarily
  what you might think -- brute force attack on the password.  If someone
  wants to initiate a spear phishing attack against a committer, it would
  be something like:
 
  1) Standard phishing: a spoofed note from Apache Infra, with some
 invented
  story that asks you to change your password but first enter your old one
  for confirmation.  It leads you to a fake, non-Apache website.
 
  2) If you use the same passcode on multiple web services and one of them
 is
  compromised, say by retrieving the passcode hashes, then it is easy to do
  offline dictionary attacks (rainbow tables, etc.) and figure out your
  Apache password.
 
  3) If you lose control of your laptop, at a conference, bar, hotel,
  whatever, even temporarily, someone can gain access to your Subversion
  account, via applications that cache credentials, like TortoiseSVN.
 
  4) Similar to #3, but by taking control of your laptop via remote means,
  i.e., via a virus loaded on to your machine via another vulnerability.
 

 None of these things have happened to us yet, but all of these things are
  possible.
 
  So how do we reduce this risk?  There are a few things we do or should be
  doing already.
 
  1) Be careful on the machines that you use Subversion from.  Treat it
 like
  a machine where you access your bank account from.  If you are visiting
  risky sites or downloading and installing software from dubious places,
  then you are putting your Apache account at risk.
 
  2) Use a high-complexity Apache passcode, one not used by you on any
 other
  service.
 
  3) Change your passcode periodically, say every 90 days.
 

 4) On laptops be sure to set a strong login password, but also where
  available also a separate harddrive password.  These should also be
 strong
  passwords, not reused, and should be periodically changed.
 
  For those who are building binaries for distribution, the above guidance
 is
  even more critical.
 
  Of course, we also protect the code through our CTR process.  All active
  coders should be subscribed to the commits list and should be reviewing
 the
  changes that are made there.  Trust the code, not the person.  Remember,
 if
  we ever are attacked then it will be through someone's compromised
  account.  So if you see an odd check-in, say, from Juergen, don't just
  accept it saying Juergen knows what he is doing.  If it is odd, then it
  should be challenged.
 
  All of the above should already be going on today.  But I'd like to
 propose
  one change to our current process that will, I think, greatly increase
  security.  This would be to restrict SVN authorization for the code to
 only
  the subset of committers who are actively coding.  We should give this
  authorization freely to committers who request it.  But today we have 123
  committers, some of whom have never used Subversion, and some (like me)
 who
  edit /site and /ooo-site but never touch the code.  So we probably have
 90
  or more accounts that don't need access to the source code tree.  Since
  such used accounts are unlikely to be following the best practices
 outlined
  above (changing passwords periodically, etc.) then they are even more
  risky.  We lose nothing by removing authorization for those users, in
 order

Re: Error 1 module(s): odk

2013-04-03 Thread jorge ivan poot diaz

Here is a picture:
http://imagebin.org/252637


2013/4/3 jorge ivan poot diaz ivan.pootd...@gmail.com

 Hello,

 I'm building in AOO source code, but I have a error in the module odk:

 Here the error:

 Entering /home/ivan/aoo/main/odk/util

 dmake:  Error: --
 `../examples/cpp/StatusbarController/WordCountStatusbarController/WordCountDispatch.hxx'
 not found, and can't be made

 1 module(s):
 odk
 need(s) to be rebuilt

 Reason(s):

 ERROR: error 65280 occurred while making /home/ivan/aoo/main/odk/util

 When you have fixed the errors in that module you can resume the build by
 running:

 build --all:odk

 ivan@ivan-Presario-CQ43-Notebook-PC:~/aoo/main/instsetoo_native$


 I'm building on Ubuntu 12.04
 Help me, regards.

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

On 4/3/13 3:13 PM, Rob Weir wrote:
 On Wed, Apr 3, 2013 at 9:06 AM, janI j...@apache.org wrote:
 
 On 3 April 2013 14:39, Rob Weir robw...@apache.org wrote:

 We're starting to take a deeper look at what is required to integrate
 code
 signing into the OpenOffice build and release process. As you probably
 know
 operating systems, especially Windows and MacOS, are now checking for
 digital signatures and by default prevent users from installing programs
 that are not signed.  We see similar checks being integrated into
 anti-virus scanners and even web browsers now.

 One of the things that has come out in discussions is how large a target
 OpenOffice is, to hackers.  We're on track to have 50 million downloads
 in
 our first year.  If someone is able to get a virus or a trojan into our
 code, they have the ability to cause a huge amount of damage.  And if we
 are also signing our code, then this damage can propagate even faster,
 since the OS's let down their guard somewhat when dealing with signed
 code.  (Signed code == trust).

 Of course, none of this has ever happened with OpenOffice, but with the
 stature and reach we have, it is reasonable to believe that we could be a
 target of opportunity for someone wishing to cause trouble.  We should
 always keep this in mind and make sure that we are taking reasonable
 precautions to prevent this from happening.

 One vulnerability, in theory, is that we have over 100 committers (123 to
 be exact) who have permission to modify the source code in Subversion.
 Each account is protected by a self-selected passcode.  It is not clear
 to
 me that we even have requirements on password complexity or expiration
 policies.   In any case, the weakness of this approach is not necessarily
 what you might think -- brute force attack on the password.  If someone
 wants to initiate a spear phishing attack against a committer, it would
 be something like:

 1) Standard phishing: a spoofed note from Apache Infra, with some
 invented
 story that asks you to change your password but first enter your old one
 for confirmation.  It leads you to a fake, non-Apache website.

 2) If you use the same passcode on multiple web services and one of them
 is
 compromised, say by retrieving the passcode hashes, then it is easy to do
 offline dictionary attacks (rainbow tables, etc.) and figure out your
 Apache password.

 3) If you lose control of your laptop, at a conference, bar, hotel,
 whatever, even temporarily, someone can gain access to your Subversion
 account, via applications that cache credentials, like TortoiseSVN.

 4) Similar to #3, but by taking control of your laptop via remote means,
 i.e., via a virus loaded on to your machine via another vulnerability.


 None of these things have happened to us yet, but all of these things are
 possible.

 So how do we reduce this risk?  There are a few things we do or should be
 doing already.

 1) Be careful on the machines that you use Subversion from.  Treat it
 like
 a machine where you access your bank account from.  If you are visiting
 risky sites or downloading and installing software from dubious places,
 then you are putting your Apache account at risk.

 2) Use a high-complexity Apache passcode, one not used by you on any
 other
 service.

 3) Change your passcode periodically, say every 90 days.


 4) On laptops be sure to set a strong login password, but also where
 available also a separate harddrive password.  These should also be
 strong
 passwords, not reused, and should be periodically changed.

 For those who are building binaries for distribution, the above guidance
 is
 even more critical.

 Of course, we also protect the code through our CTR process.  All active
 coders should be subscribed to the commits list and should be reviewing
 the
 changes that are made there.  Trust the code, not the person.  Remember,
 if
 we ever are attacked then it will be through someone's compromised
 account.  So if you see an odd check-in, say, from Juergen, don't just
 accept it saying Juergen knows what he is doing.  If it is odd, then it
 should be challenged.

 All of the above should already be going on today.  But I'd like to
 propose
 one change to our current process that will, I think, greatly increase
 security.  This would be to restrict SVN authorization for the code to
 only
 the subset of committers who are actively coding.  We should give this
 authorization freely to committers who request it.  But today we have 123
 committers, some of whom have never used Subversion, and some (like me)
 who
 edit /site and /ooo-site but never touch the code.  So we probably have
 90
 or more accounts that don't need access to the source code tree.  Since
 such used accounts are unlikely to be following the best practices
 outlined
 above (changing passwords periodically, etc.) then they are even more
 risky.  We lose nothing by removing authorization for those users, in
 order
 to reduce the risk profile.  Of course, on request

Re: FISL14, in Brazil

2013-04-03 Thread Albino B Neto

 De: Louis Suárez-Potts lsuarezpo...@gmail.com

 Enviadas: Terça-feira, 2 de Abril de 2013 22:42

 I certainly hope to make it there again, as I have nearly every year. But
 this time, unlike last year, it would be *great* to have an AOO presence.
 Last year, the OO presence there was under the flag of LibreOffice, and so
 was the ODF identity.

Every year, I and Claudio and others, were in the event #fis13.

The Claudio gave a lacture of AOO.


In the #FISL14 I'm probably will not.

Albino

-
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/3/13, Rob Weir robw...@apache.org wrote:
 On Wed, Apr 3, 2013 at 8:57 AM, Alexandro Colorado j...@oooes.org wrote:

 I think restricting this would be a horrible idea, since we still have
 a shortage of developers. Limiting it by permissions and creating a
 red tape would be even more problematic. I think the key here is about
 the aproved releases. I don't really use windows, so I am not very
 familiar with the topic and whole process at hand when installing and
 testing. However I would focus more on the final QA than the initial
 access/commit to the code.


 I'm talking about restricting access for non-programmers, those who have
 permissions currently, but who have never ever contributed a single line of
 code.  No actual programmer would be restricted.

 For the kinds of risks I'm describing QA would accomplish nothing.  Any
 hacker worth the name would delay activation of an attack until after
 millions of copies had already been installed, and then they would activate
 the code remotely.


I think this needs to be solved upstream. Apache could handle this
disucssions and then recomend what to do.

This sign issue affects not only openoffice but most of the Apache
projects. I dont think we should solve it in a vacum.

 -Rob



 On 4/3/13, Rob Weir robw...@apache.org wrote:
  We're starting to take a deeper look at what is required to integrate
 code
  signing into the OpenOffice build and release process. As you probably
 know
  operating systems, especially Windows and MacOS, are now checking for
  digital signatures and by default prevent users from installing
  programs
  that are not signed.  We see similar checks being integrated into
  anti-virus scanners and even web browsers now.
 
  One of the things that has come out in discussions is how large a
  target
  OpenOffice is, to hackers.  We're on track to have 50 million downloads
 in
  our first year.  If someone is able to get a virus or a trojan into our
  code, they have the ability to cause a huge amount of damage.  And if
  we
  are also signing our code, then this damage can propagate even faster,
  since the OS's let down their guard somewhat when dealing with signed
  code.  (Signed code == trust).
 
  Of course, none of this has ever happened with OpenOffice, but with the
  stature and reach we have, it is reasonable to believe that we could be
  a
  target of opportunity for someone wishing to cause trouble.  We should
  always keep this in mind and make sure that we are taking reasonable
  precautions to prevent this from happening.
 
  One vulnerability, in theory, is that we have over 100 committers (123
  to
  be exact) who have permission to modify the source code in Subversion.
  Each account is protected by a self-selected passcode.  It is not clear
 to
  me that we even have requirements on password complexity or expiration
  policies.   In any case, the weakness of this approach is not
  necessarily
  what you might think -- brute force attack on the password.  If someone
  wants to initiate a spear phishing attack against a committer, it
  would
  be something like:
 
  1) Standard phishing: a spoofed note from Apache Infra, with some
 invented
  story that asks you to change your password but first enter your old
  one
  for confirmation.  It leads you to a fake, non-Apache website.
 
  2) If you use the same passcode on multiple web services and one of
  them
 is
  compromised, say by retrieving the passcode hashes, then it is easy to
  do
  offline dictionary attacks (rainbow tables, etc.) and figure out your
  Apache password.
 
  3) If you lose control of your laptop, at a conference, bar, hotel,
  whatever, even temporarily, someone can gain access to your Subversion
  account, via applications that cache credentials, like TortoiseSVN.
 
  4) Similar to #3, but by taking control of your laptop via remote
  means,
  i.e., via a virus loaded on to your machine via another vulnerability.
 
  None of these things have happened to us yet, but all of these things
  are
  possible.
 
  So how do we reduce this risk?  There are a few things we do or should
  be
  doing already.
 
  1) Be careful on the machines that you use Subversion from.  Treat it
 like
  a machine where you access your bank account from.  If you are visiting
  risky sites or downloading and installing software from dubious places,
  then you are putting your Apache account at risk.
 
  2) Use a high-complexity Apache passcode, one not used by you on any
 other
  service.
 
  3) Change your passcode periodically, say every 90 days.
 
  4) On laptops be sure to set a strong login password, but also where
  available also a separate harddrive password.  These should also be
 strong
  passwords, not reused, and should be periodically changed.
 
  For those who are building binaries for distribution, the above
  guidance
 is
  even more critical.
 
  Of course, we also protect the code through our CTR process.  All
  active
  coders should be

Re: Binfilter removal - PATCH

On 4/3/13 10:45 AM, janI wrote:
 On 3 April 2013 10:22, Pavel Janík pa...@janik.cz wrote:
 
 Hi,

 http://tmp.janik.cz/AO/binfilter-removal.diff

 This is the first attempt to remove module binfilter. To add more to this,
 we should remove directories binfilter and scp2/source/binfilter.

 
 +1 to remove directories,

+1 for removal of binfilter

 
 Are there other directories (modules) in main that are antique ?
 

many contains antique code ;-)

Juergen

 I have been wonding a lot about who/what uses toolkit/src2xml.
 
 rgds
 Jan I
 
 --
 Pavel Janík




 -
 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: Error 1 module(s): odk

On 4/3/13 3:55 PM, jorge ivan poot diaz wrote:
 have you check if the file is there?
 The file does not exist on my local directory.
 
 It seems to be a new file and maybe you have to remove the output
 directory and have to make clean fresh build of the odk.
 How I can do this?

remove the unxlng* output directory in the odk module

Juergen

 
 
 Certainly the number of revision:
 Revision: 1461840
 
 Regards
 
 
 2013/4/3 Jürgen Schmidt jogischm...@gmail.com
 
 On 4/3/13 3:00 PM, jorge ivan poot diaz wrote:
 Hello,

 I'm building in AOO source code, but I have a error in the module odk:

 Here the error:

 Entering /home/ivan/aoo/main/odk/util

 dmake:  Error: --

 `../examples/cpp/StatusbarController/WordCountStatusbarController/WordCountDispatch.hxx'
 not found, and can't be made

 1 module(s):
 odk
 need(s) to be rebuilt

 Reason(s):

 ERROR: error 65280 occurred while making /home/ivan/aoo/main/odk/util

 When you have fixed the errors in that module you can resume the build by
 running:

 build --all:odk

 ivan@ivan-Presario-CQ43-Notebook-PC:~/aoo/main/instsetoo_native$


 I'm building on Ubuntu 12.04
 Help me, regards.

 have you check if the file is there? It seems to be a new file and maybe
 you have to remove the output directory and have to make clean fresh
 build of the odk.

 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: FISL14, in Brazil

2013-04-03 Thread Louis Suárez-Potts


On 13-04-03, at 09:39 , Albino B Neto bitf...@yahoo.com wrote:

 De: Albino B Neto bitf...@yahoo.com
 
 Para: dev@openoffice.apache.org dev@openoffice.apache.org
 Enviadas: Quarta-feira, 3 de Abril de 2013 10:36
 
 Every year, I and Claudio and others, were in the event #fis13.
 
 
 Sorry
 
 * Last year * ,  I and Claudio and others, were in the event #fis13. ;-)

So was I. 

I just sent a note to Rodgrigo T. about another option, independent of AOO: to 
see about an ODF plugfest at the event. It's been debated for years, but 
Brazil's physical distance from Europe has prevented realization, despite the 
desire of us all.

I doubt if all on the ODF TCs could do it—but it's a proposal I do want to have 
considered.

As to Fisl 14, let's discuss this directly? I do want a strong presence there, 
with you, Claudio, others. It would be independent of any ODF plugfest.


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

best
louis


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

Working with nightly builds parallel to standard releases

Hi is there any tutorial on working with parallel builds of OpenOffice?

Before there was the ooo-dev/ and the OpenOffice3/ folders, I wonder
if the nightly builds work the same way...

Regards.

-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.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

2013-04-03 Thread Thorsten Behrens

janI wrote:
 But we have to very carefull not make it even harder to become/be
 committer, compare us a bit with LO, there I can have commit access
 within less than a day.
 
Hi Jan,

just to get this straight - we try hard to have your patch committed /
initial feedback provided in a day. Getting you actual commit access
to the core repos needs consistent, good patches over some time
though, and happens after review by several other hackers.

Cheers,

-- Thorsten


signature.asc
Description: Digital signature

Re: draft blog post: press@ - It's easy to get first hand information

On 4/3/13 4:15 PM, Rob Weir wrote:
 On Wed, Apr 3, 2013 at 9:33 AM, Jürgen Schmidt jogischm...@gmail.comwrote:
 
 On 4/3/13 2:45 PM, Rob Weir wrote:
 On Wed, Apr 3, 2013 at 8:10 AM, Jürgen Schmidt jogischm...@gmail.com
 wrote:

 Hi,

 I am a little bit annoyed about the often bad researched articles about
 OpenOffice or at least articles spreading wrong information about
 OpenOffice. I don't know exactly why authors do such a poor job with
 their research of correct information where it is so easy on the other
 hand to get first information. The idea is to raise some awareness that
 the info found in the web is not always true and it is much better to
 get first hand information from the project and the people behind it
 directly. Nobody have to rely on third party information found somewhere
 when first hand information can be get so so easy.


 Well the wording can and should be improved and I am sure others will
 have further ideas to improve it or make it even better to send out the
 right signal. Se please review the draft and your feedback is welcome.
 It's mainly an idea and I am not sure if it is the best way to address
 this.


 If we wait a little longer we might be able to achieve the safe effect
 but
 with a more positive message.  I've been slowly updating the old press
 kit
 page:

 http://www.openoffice.org/marketing/press_kit.html

 I also started to look at preparing new screenshots for AOO 3.4.1 and AOO
 4.0, so there is easy to use material for articles.

 And as you know, we now have the press@o.a.o email address.

 Once that is done, then we could have a positive message about how we're
 helping the press.

 What is the saying? You catch more flies with honey than vinegar?

 sure and as I mentioned before I am not sure if it would be the best
 way. I thought I could address two things in one blog. First that it is
 easy to contact the project and get first hand information. And second
 to raise some awareness that it is not really clever to use bad
 researched or wrong material. But is probably useless anyway.


 It may be useless, unfortunately.  The fact is that not everyone who writes
 articles is a journalist.  Much if it is opinion or editorial content
 and has far lower standards.  So some articles are little more than blogs
 with a prestigious address.  They are not held to journalistic standards.
 So if you complain that they are biased, or that they don't confirm
 information, or they don't seek balancing points of view, it means nothing
 to them.  It is not their goal to be journalists.  The have opinions and
 push their point of view, and if that drives traffic and eyeballs to the
 website, then the editors and owners are happy.
 
 But there are many real journalists out there, who do take the time to
 check facts, etc.  They are the minority, but they exist.  A good
 journalist does not just take a LibreOffice blog post and turn it into an
 article.  But they won't just take an AOO blog post and run with that
 either.  They need real news, something worth writing about, not just
 vaporware, speculation or inflated claims.
 
 I'm starting to create a list of real journalists who cover this area and
 who have given neutral to positive coverage of AOO, along with their
 contact information.  It will be important to reach out to them when we
 have real news that may be interesting to them.  We need to do the leg
 work.  We can't depend on them coming to us.   For obvious reasons I'm not
 sharing the details of my list on the mailing list, but if anyone wants to
 help in this effort, let me know and I can share the information.

I agree that we have to become more active and do our part of the story
well. If we don't talk about what we are doing and don't let people know
about it, it is of course our problem.

Juergen



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

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

2013-04-03 Thread Issac Goldstand

On 03/04/2013 16:13, Rob Weir wrote:
 On Wed, Apr 3, 2013 at 9:06 AM, janI j...@apache.org wrote:

 On 3 April 2013 14:39, Rob Weir robw...@apache.org wrote:

 We're starting to take a deeper look at what is required to integrate
 code
 signing into the OpenOffice build and release process. As you probably
 know
 operating systems, especially Windows and MacOS, are now checking for
 digital signatures and by default prevent users from installing programs
 that are not signed.  We see similar checks being integrated into
 anti-virus scanners and even web browsers now.

 One of the things that has come out in discussions is how large a target
 OpenOffice is, to hackers.  We're on track to have 50 million downloads
 in
 our first year.  If someone is able to get a virus or a trojan into our
 code, they have the ability to cause a huge amount of damage.  And if we
 are also signing our code, then this damage can propagate even faster,
 since the OS's let down their guard somewhat when dealing with signed
 code.  (Signed code == trust).

 Of course, none of this has ever happened with OpenOffice, but with the
 stature and reach we have, it is reasonable to believe that we could be a
 target of opportunity for someone wishing to cause trouble.  We should
 always keep this in mind and make sure that we are taking reasonable
 precautions to prevent this from happening.

 One vulnerability, in theory, is that we have over 100 committers (123 to
 be exact) who have permission to modify the source code in Subversion.
 Each account is protected by a self-selected passcode.  It is not clear
 to
 me that we even have requirements on password complexity or expiration
 policies.   In any case, the weakness of this approach is not necessarily
 what you might think -- brute force attack on the password.  If someone
 wants to initiate a spear phishing attack against a committer, it would
 be something like:

 1) Standard phishing: a spoofed note from Apache Infra, with some
 invented
 story that asks you to change your password but first enter your old one
 for confirmation.  It leads you to a fake, non-Apache website.

 2) If you use the same passcode on multiple web services and one of them
 is
 compromised, say by retrieving the passcode hashes, then it is easy to do
 offline dictionary attacks (rainbow tables, etc.) and figure out your
 Apache password.

 3) If you lose control of your laptop, at a conference, bar, hotel,
 whatever, even temporarily, someone can gain access to your Subversion
 account, via applications that cache credentials, like TortoiseSVN.

 4) Similar to #3, but by taking control of your laptop via remote means,
 i.e., via a virus loaded on to your machine via another vulnerability.

 None of these things have happened to us yet, but all of these things are
 possible.

 So how do we reduce this risk?  There are a few things we do or should be
 doing already.

 1) Be careful on the machines that you use Subversion from.  Treat it
 like
 a machine where you access your bank account from.  If you are visiting
 risky sites or downloading and installing software from dubious places,
 then you are putting your Apache account at risk.

 2) Use a high-complexity Apache passcode, one not used by you on any
 other
 service.

 3) Change your passcode periodically, say every 90 days.

 4) On laptops be sure to set a strong login password, but also where
 available also a separate harddrive password.  These should also be
 strong
 passwords, not reused, and should be periodically changed.

 For those who are building binaries for distribution, the above guidance
 is
 even more critical.

 Of course, we also protect the code through our CTR process.  All active
 coders should be subscribed to the commits list and should be reviewing
 the
 changes that are made there.  Trust the code, not the person.  Remember,
 if
 we ever are attacked then it will be through someone's compromised
 account.  So if you see an odd check-in, say, from Juergen, don't just
 accept it saying Juergen knows what he is doing.  If it is odd, then it
 should be challenged.

 All of the above should already be going on today.  But I'd like to
 propose
 one change to our current process that will, I think, greatly increase
 security.  This would be to restrict SVN authorization for the code to
 only
 the subset of committers who are actively coding.  We should give this
 authorization freely to committers who request it.  But today we have 123
 committers, some of whom have never used Subversion, and some (like me)
 who
 edit /site and /ooo-site but never touch the code.  So we probably have
 90
 or more accounts that don't need access to the source code tree.  Since
 such used accounts are unlikely to be following the best practices
 outlined
 above (changing passwords periodically, etc.) then they are even more
 risky.  We lose nothing by removing authorization for those users, in
 order
 to reduce the risk profile.  Of course, on request

Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1

On 3/27/13 3:23 PM, Ariel Constenla-Haile wrote:
 On Wed, Mar 27, 2013 at 11:12:39AM +0100, Jürgen Schmidt wrote:
 Different opinions came up and we had some discussion and you
 pointed out that you can live with feedback. Where is exactly
 your problem now?
 
 I don't have any problem at all.
 
 I don't think that it will help us if we react this way.
 
 I am not reacting. Please don't turn this into a circus like the
 one with the 0^0.
 
 Really nobody wanted that you revert anything here.
 
 I am no native English speaker, but for the content, and the tone,
 of Andre mails, I understood he wanted his extension back:
 
 I don't see why this change should be a good thing.
 
 I was hoping that I would find the time in the future to fix
 this
 
 Including the pre-bundled extensions into the core is a
 workaround not a fix.
 
 We are still able (well until your changes) to release the
 presenter console under Apache license
 
 I still don' t see the benefit of the change.
 
 [...] This is something that I have used several times in the
 past and always was very glad that I had it.
 
 And he got it back (together with the Presentation Minimizer, as
 it makes no sense to have one pre-registered extension and the
 other integrated).
 
 Again, I don't have any problem at all, nor then, nor now :)

Just a short question before I lose it out of focus, do you plan to
revert your revert? Or can/should we revert it? I really think it was
a misunderstanding and nothing else.

Juergen


 
 
 Regards
 


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

Re: Working with nightly builds parallel to standard releases

BTW trying to untar it, it spew some error:
tar -xzvf 
Apache_OpenOffice_4.0.0_Linux_x86_install-rpm_en-US.tar.gz_2013-03-12_04\:29\:29_1455404.tar.gz
tar (child): Cannot connect to
Apache_OpenOffice_4.0.0_Linux_x86_install-rpm_en-US.tar.gz_2013-03-12_04:
resolve failed

gzip: stdin: unexpected end of file
tar: Child returned status 128
tar: Error is not recoverable: exiting now

Seems some integrity missing on the file, I download it several time
and experience the same issue.

On 4/3/13, Alexandro Colorado j...@oooes.org wrote:
 Hi is there any tutorial on working with parallel builds of OpenOffice?

 Before there was the ooo-dev/ and the OpenOffice3/ folders, I wonder
 if the nightly builds work the same way...

 Regards.

 --
 Alexandro Colorado
 Apache OpenOffice Contributor
 http://es.openoffice.org



-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org

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

Re: May I join the OOo?

Forwarding the answer below to Sand Wen who is not subscribed. Sand Wen: 
welcome and please read http://openoffice.apache.org/orientation/ too. 
Andrea.


Alexandro Colorado wrote:

Welcome, please mention your skillset and we can provide ideas on
where in OO would you feel more confortable.

On 4/2/13, Sand Wensand.fj@gmail.com  wrote:

Hey guys, I have learned some of the OOo history and the OOo Architecture,
and I think maybe I can do something for OpenOffice, hope getting more
information from OOo.



Best Wishes!

Sand Wen







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

Re: Working with nightly builds parallel to standard releases

2013-04-03 Thread Pavel Janík


On Apr 3, 2013, at 4:59 PM, Alexandro Colorado wrote:

 BTW trying to untar it, it spew some error:
 tar -xzvf 
 Apache_OpenOffice_4.0.0_Linux_x86_install-rpm_en-US.tar.gz_2013-03-12_04\:29\:29_1455404.tar.gz
 tar (child): Cannot connect to

Looks like it thinks it is a hostname. Use tar ...Apache...gz instead.
-- 
Pavel Janík




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

Re: Shell access to LAMP machines


On 01/04/2013 janI wrote:

A volunteer does not need to be an expert, that can be learned, possibility
to react swiftly to alers in your TZ is the key. General knowledge about
mysql/php is a clear advantage. In general we talk about 1-2 hours work pr
month, not including upgrades.


Adding to what Jan wrote: we now have more granular access levels, so 
that we can have a class of volunteers who can only restart services 
(which is often enough in case of a sudden problem). This means you 
shouldn't be scared of having too many privileges and possibly break the 
setup, since privileges will be exactly enough to do what is needed.


We can give these privileges a couple of volunteers if available, don't 
be shy! You need to be an OpenOffice committer and have a reasonable 
knowledge of Linux system administration (not much, but at least being 
able to manage services from the command line). Again, American 
timezones are not covered at the moment so it's best to have volunteers 
from there, but any help is welcome. Anyone?


Regards,
  Andrea.

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

Re: [Wiki]Trouble with math extension on one particular page

2013-04-03 Thread RGB ES

2013/4/3 janI j...@apache.org

On 3 April 2013 01:27, RGB ES rgb.m...@gmail.com wrote:

2013/3/29 Ariel Constenla-Haile arie...@apache.org

On Thu, Mar 28, 2013 at 07:27:30PM +0100, RGB ES wrote:
If you look at this page

http://wiki.openoffice.org/wiki/ES/Manuales/GuiaAOO/TemasAvanzados/Macros/StarBasic/TrabajandoConCalc/FuncionesPersonalizadas

you'll see that all math objects are failing to parse. That's quite
strange
because other pages using the same extension are working just
perfectly.

Any idea?

It seems a recurrent problem, described in the manual:

http://www.mediawiki.org/wiki/Manual:Enable_TeX/problems#Error_:_Failed_to_parse_.28Missing_texvc_executable.29
(that said, I've no idea about all this stuff, it's just the first
search result in Google).

I just tried to create a new page with math objects and they fail too. It
seems old pages are displayed right because of the heavy use of cache on
mwiki, but any new page gives the failed to parse error. I filled a bug
report for this:

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

Regards
Ricardo

Just saw the bugzilla report. We have no php error to that subject so it
is something within mwiki, I will investigate when I come around to doing
the mwiki bugs.

Thanks!

Is it real urgent ?

Well, at least on the ES wiki there are a couple of pages that are not easy
to understand right now. The problem is important, but maybe not critical.

Regards
Ricardo

rgds
Jan I.

Regards
--
Ariel Constenla-Haile
La Plata, Argentina

Re: draft blog post: press@ - It's easy to get first hand information


Rob Weir wrote:

On Wed, Apr 3, 2013 at 8:10 AM, Jürgen Schmidt wrote:

I am a little bit annoyed about the often bad researched articles about
OpenOffice or at least articles spreading wrong information about
OpenOffice. ...

If we wait a little longer we might be able to achieve the safe effect but
with a more positive message.  I've been slowly updating the old press kit
page: http://www.openoffice.org/marketing/press_kit.html


OK to merge the two messages, and I agree it's good to address this 
issue. A few notes on Juergen's current draft (that will anyway be 
partly rewritten):


- We should list the official project channels: announce mailing list, 
blog, social media presence...


- We should also mention that some resources are not completely 
up-to-date (the wiki for example)


- It is frequent to see links to this list's archives purported to be 
official project statements. We might think about embedding a link to 
the new resources, or a disclaimer, in the message footer. It would also 
appear in the archives.


Regards,
  Andrea.

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

Re: FISL14, in Brazil

2013-04-03 Thread Albino B Neto

 De: Louis Suárez-Potts lui...@gmail.com

 Enviadas: Quarta-feira, 3 de Abril de 2013 11:24
 
 As to Fisl 14, let's discuss this directly?

Yes, no problem. :-)

 I do want a strong presence 
 there, with you, Claudio, others. It would be independent of any ODF plugfest.


The FISL [1] is a comprehensive environment.


1 - http://fisl.org.br

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

Re: draft blog post: press@ - It's easy to get first hand information

2013-04-03 Thread Kay Schenk

On Wed, Apr 3, 2013 at 9:36 AM, Andrea Pescetti pesce...@apache.org wrote:

Rob Weir wrote:

On Wed, Apr 3, 2013 at 8:10 AM, Jürgen Schmidt wrote:

I am a little bit annoyed about the often bad researched articles about
OpenOffice or at least articles spreading wrong information about
OpenOffice. ...

If we wait a little longer we might be able to achieve the safe effect but
with a more positive message. I've been slowly updating the old press
kit
page:
http://www.openoffice.org/**marketing/press_kit.htmlhttp://www.openoffice.org/marketing/press_kit.html

I'm mystified like many others about why/how this misinformation continues
to live. We have accurate and readily available information about the
project from a variety of sources.

OK to merge the two messages, and I agree it's good to address this issue.
A few notes on Juergen's current draft (that will anyway be partly
rewritten):

- We should list the official project channels: announce mailing list,
blog, social media presence...

I would include the project website -- openoffice.apache.org -- in this
as well.

- We should also mention that some resources are not completely up-to-date
(the wiki for example)

- It is frequent to see links to this list's archives purported to be
official project statements. We might think about embedding a link to the
new resources, or a disclaimer, in the message footer. It would also appear
in the archives.

h...apparently a disconnect between discussion items and those that
are put forth in proposals and voted on. Yes, sort of disclaimer in the
mail archives might be in order.

and, finally, what IS the best way to disseminate accurate information?

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

MzK

Achieving happiness requires the right combination of Zen and Zin.

Re: Shell access to LAMP machines

2013-04-03 Thread Kay Schenk

On Wed, Apr 3, 2013 at 8:22 AM, Andrea Pescetti pesce...@apache.org wrote:

 On 01/04/2013 janI wrote:

 A volunteer does not need to be an expert, that can be learned,
 possibility
 to react swiftly to alers in your TZ is the key. General knowledge about
 mysql/php is a clear advantage. In general we talk about 1-2 hours work pr
 month, not including upgrades.


 Adding to what Jan wrote: we now have more granular access levels, so that
 we can have a class of volunteers who can only restart services (which is
 often enough in case of a sudden problem). This means you shouldn't be
 scared of having too many privileges and possibly break the setup, since
 privileges will be exactly enough to do what is needed.

 We can give these privileges a couple of volunteers if available, don't be
 shy! You need to be an OpenOffice committer and have a reasonable knowledge
 of Linux system administration (not much, but at least being able to manage
 services from the command line). Again, American timezones are not covered
 at the moment so it's best to have volunteers from there, but any help is
 welcome. Anyone?

 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



Can you elaborate on what specific services, and what might be involved?


-- 

MzK

Achieving happiness requires the right combination of Zen and Zin.

Re: FISL14, in Brazil

2013-04-03 Thread Claudio Filho

Hi

We can *try* to organize some thing there. Subscription of talks is opened.

IMHO, we can try to bring some key people to present the ecosystem of AOO
and its evolution. I will contact the organization and to know what we can
do.

In my way, i will submit the same talk that i did in a gov event[1] in last
month (unhappyly, only in portuguese).
[1]http://assiste.serpro.gov.br/cisl/apacheopenoffice.html

Regards,
Claudio

2013/4/3 Albino B Neto bitf...@yahoo.com

  De: Louis Suárez-Potts lui...@gmail.com

  Enviadas: Quarta-feira, 3 de Abril de 2013 11:24
 
  As to Fisl 14, let's discuss this directly?

 Yes, no problem. :-)

  I do want a strong presence
  there, with you, Claudio, others. It would be independent of any ODF
 plugfest.


 The FISL [1] is a comprehensive environment.


 1 - http://fisl.org.br

Re: FISL14, in Brazil

2013-04-03 Thread Louis Suárez-Potts

Hi Claudio, et a.

On 13-04-03, at 13:22 , Claudio Filho filh...@gmail.com wrote:

 Hi
 
 We can *try* to organize some thing there. Subscription of talks is opened.
 
 IMHO, we can try to bring some key people to present the ecosystem of AOO
 and its evolution. I will contact the organization and to know what we can
 do.

let's. If this means holding out olive branches and also distinguishing ODF 
from AOO from LO, that's fine with me.


 
 In my way, i will submit the same talk that i did in a gov event[1] in last
 month (unhappyly, only in portuguese).
 [1]http://assiste.serpro.gov.br/cisl/apacheopenoffice.html

Google translate works fine for those who's Pt is deficient, like me. 

But I would love to see—and I think others, too—a meaningful presence of AOO 
and ODF there. 

I've sent Rodrigo T. a note and will try with others. The plugfest organizers 
(I'm one of them) are interested in Brazil; that would be for an ODF plugfest, 
a different and distinct discussion from any related to AOO.


 
 Regards,
 Claudio

best
Louis


 
 2013/4/3 Albino B Neto bitf...@yahoo.com
 
 De: Louis Suárez-Potts lui...@gmail.com
 
 Enviadas: Quarta-feira, 3 de Abril de 2013 11:24
 
 As to Fisl 14, let's discuss this directly?
 
 Yes, no problem. :-)
 
 I do want a strong presence
 there, with you, Claudio, others. It would be independent of any ODF
 plugfest.
 
 
 The FISL [1] is a comprehensive environment.
 
 
 1 - http://fisl.org.br
 


-
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


Jürgen Schmidt wrote: [...]

On 3 April 2013 14:39, Rob Weirrobw...@apache.org  wrote:

one change to our current process that will, I think, greatly increase
security.  This would be to restrict SVN authorization for the code


I don't think this would greatly increase security, since the current 
review model would still be the better defense. But surely this doesn't 
decrease security and doesn't impact on people who are not using it.



I see also no problem if we handle it more careful and give svn access
to the code on demand only. Nobody should take it personal


Before we manage again to make simple discussions complex, let's see:
- All committers have the right to have write access to the source code
- By default 3 subtrees (trunk, tags, branches) are read-only
- Any committer can receive write access to the 3 subtrees immediately, 
by sending an e-mail here


This could be fine for me, provided that:

1) We have the right way to manage this (another LDAP group does not 
look like the right solution: people who don't want to understand 
correctly will invent that this is a multi-level hierarchy while it 
would simply be a permission that we enable on demand)


2) Enabling write access is extremely simple, especially if this is 
something that I must take care of! Something like the current 
modify_unix_group.pl scripts currently used for the committers group.


Regards,
  Andrea.

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

Re: Binfilter removal - PATCH

2013-04-03 Thread Pavel Janík


On Apr 3, 2013, at 4:04 PM, Jürgen Schmidt wrote:

 On 4/3/13 10:45 AM, janI wrote:
 On 3 April 2013 10:22, Pavel Janík pa...@janik.cz wrote:
 
 Hi,
 
 http://tmp.janik.cz/AO/binfilter-removal.diff
 
 This is the first attempt to remove module binfilter. To add more to this,
 we should remove directories binfilter and scp2/source/binfilter.
 
 
 +1 to remove directories,
 
 +1 for removal of binfilter

Anyone against the lazy approach - ie. doing this on trunk directly? This could 
make testing much easier...
-- 
Pavel Janík




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

Pinterest AOO

2013-04-03 Thread Albino B Neto

Hi

The link on home page openoffce.org is broken to pinterest.

Correct: http://pinterest.com/openoffice/

Albino

-
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

2013-04-03 Thread Dennis E. Hamilton

I'm not clear why a non-LDAP solution is required:

 1. Being a committer is specific to a project.  What it means to be a 
committer on a project is very well-defined.

 2. The SVN repositories of the public ASF projects are publicly read-only.  
That's a no-brainer.  They are only writable to those who have SVN permission 
by virtue of being committers on this project.  That's project specific.  
There's an authz file that does it.

Some other SVN repositories are also writeable by virtue of being committers at 
the ASF.  That seems to be ASF-specific.

It makes no sense for a committer who is established as a committer of this 
project to *not* have committer privileges on the SVN. It's what committer 
*means.*

The necessary ceremony was the acceptance of a committer invitation (or being 
grandfathered as an initial committer who completed the necessary steps).

If there are now trust issues, I think the proposed solution is ineffective.  
If there is a concern about inactive committers, address that.

 - Dennis

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

Jürgen Schmidt wrote: [...]
 On 3 April 2013 14:39, Rob Weirrobw...@apache.org  wrote:
 one change to our current process that will, I think, greatly increase
 security.  This would be to restrict SVN authorization for the code

I don't think this would greatly increase security, since the current 
review model would still be the better defense. But surely this doesn't 
decrease security and doesn't impact on people who are not using it.

 I see also no problem if we handle it more careful and give svn access
 to the code on demand only. Nobody should take it personal

Before we manage again to make simple discussions complex, let's see:
- All committers have the right to have write access to the source code
- By default 3 subtrees (trunk, tags, branches) are read-only
- Any committer can receive write access to the 3 subtrees immediately, 
by sending an e-mail here

This could be fine for me, provided that:

1) We have the right way to manage this (another LDAP group does not 
look like the right solution: people who don't want to understand 
correctly will invent that this is a multi-level hierarchy while it 
would simply be a permission that we enable on demand)

2) Enabling write access is extremely simple, especially if this is 
something that I must take care of! Something like the current 
modify_unix_group.pl scripts currently used for the committers group.

Regards,
   Andrea.

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


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

Re: Pinterest AOO

On Wed, Apr 3, 2013 at 2:36 PM, Albino B Neto bitf...@yahoo.com wrote:

 Hi

 The link on home page openoffce.org is broken to pinterest.

 Correct: http://pinterest.com/openoffice/



Fixed.  Thanks!

-Rob


 Albino

 -
 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 4:08 PM, Dennis E. Hamilton orc...@apache.orgwrote:

 I'm not clear why a non-LDAP solution is required:

  1. Being a committer is specific to a project.  What it means to be a
 committer on a project is very well-defined.


And in some Apache projects they do exactly what I am proposing.  For
example, Subversion has full committers, partial committers and dormant
committers:

https://svn.apache.org/repos/asf/subversion/trunk/COMMITTERS


  2. The SVN repositories of the public ASF projects are publicly
 read-only.  That's a no-brainer.  They are only writable to those who have
 SVN permission by virtue of being committers on this project.  That's
 project specific.  There's an authz file that does it.

 Some other SVN repositories are also writeable by virtue of being
 committers at the ASF.  That seems to be ASF-specific.


Sort of.  They are writable because of the authz.  How exactly that is
connected to committership is up to the project and is what is under
discussion here.


 It makes no sense for a committer who is established as a committer of
 this project to *not* have committer privileges on the SVN. It's what
 committer *means.*


Actually, it makes no sense to be in the authz file unless you intent to
change files in Subversion.  If you have the permission but never intent to
use it, then you are merely raising the security risk for the project.


 The necessary ceremony was the acceptance of a committer invitation (or
 being grandfathered as an initial committer who completed the necessary
 steps).

 If there are now trust issues, I think the proposed solution is
 ineffective.  If there is a concern about inactive committers, address that.


It is not about trusting the committers.  It is about reducing the
exposures to hackers.  Trust of the committer has nothing to do with it.
Every active authorization in SVN is a vulnerable opening for a hacker, who
can gain access, via any number of phishing methods in common use today.
It us only prudent that a committer not have that authorization unless they
are using it.

-Rob


  - Dennis

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

 Jürgen Schmidt wrote: [...]
  On 3 April 2013 14:39, Rob Weirrobw...@apache.org  wrote:
  one change to our current process that will, I think, greatly increase
  security.  This would be to restrict SVN authorization for the code

 I don't think this would greatly increase security, since the current
 review model would still be the better defense. But surely this doesn't
 decrease security and doesn't impact on people who are not using it.

  I see also no problem if we handle it more careful and give svn access
  to the code on demand only. Nobody should take it personal

 Before we manage again to make simple discussions complex, let's see:
 - All committers have the right to have write access to the source code
 - By default 3 subtrees (trunk, tags, branches) are read-only
 - Any committer can receive write access to the 3 subtrees immediately,
 by sending an e-mail here

 This could be fine for me, provided that:

 1) We have the right way to manage this (another LDAP group does not
 look like the right solution: people who don't want to understand
 correctly will invent that this is a multi-level hierarchy while it
 would simply be a permission that we enable on demand)

 2) Enabling write access is extremely simple, especially if this is
 something that I must take care of! Something like the current
 modify_unix_group.pl scripts currently used for the committers group.

 Regards,
Andrea.

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


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

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

On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti pesce...@apache.org wrote:

 Jürgen Schmidt wrote: [...]

 On 3 April 2013 14:39, Rob Weirrobw...@apache.org  wrote:

 one change to our current process that will, I think, greatly increase

 security.  This would be to restrict SVN authorization for the code


 I don't think this would greatly increase security, since the current
 review model would still be the better defense. But surely this doesn't
 decrease security and doesn't impact on people who are not using it.


Good to think in layers of security.  An account that is not authorized is
an account we don't need to worry about at all.

Note:  we have people currently authorized for our source code, who have
*never* checked in code and who have *never* posted on the mailing list.  I
have a heard time believing that they are following best practices to avoid
losing control of their Apache login credentials.



  I see also no problem if we handle it more careful and give svn access
 to the code on demand only. Nobody should take it personal


 Before we manage again to make simple discussions complex, let's see:
 - All committers have the right to have write access to the source code



Yes, though the right is a de jure right, not exactly equivalent to the
technical authorization.  But one should lead to the other on demand.



 - By default 3 subtrees (trunk, tags, branches) are read-only
 - Any committer can receive write access to the 3 subtrees immediately, by
 sending an e-mail here

 This could be fine for me, provided that:

 1) We have the right way to manage this (another LDAP group does not look
 like the right solution: people who don't want to understand correctly will
 invent that this is a multi-level hierarchy while it would simply be a
 permission that we enable on demand)

 2) Enabling write access is extremely simple, especially if this is
 something that I must take care of! Something like the current 
 modify_unix_group.pl scripts currently used for the committers group.


I'd do it like this:

0) Call it active and dormant statuses.  This doesn't change status as
a committer, just status of SVN authorization.

1) By default the active list includes only those who have made commits to
those trees in the last 12 months (or some other suitable time period).
Ever would be a fine time period as well.

2) Everyone else has authorization for /site, /ooo-site and /devtools

3) Any committer can be added to the active list on demand.

4) New committers are explained this when they are voted in and asked if
they want to be on the active list for Subversion.

Regards,

-Rob

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: update service for not released languages [was: Re: Registration]

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+Planninghttps://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.

-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%**3Ehttp://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.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

On 3 April 2013 22:30, Rob Weir robw...@apache.org wrote:

 On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti pesce...@apache.org
 wrote:

  Jürgen Schmidt wrote: [...]
 
  On 3 April 2013 14:39, Rob Weirrobw...@apache.org  wrote:
 
  one change to our current process that will, I think, greatly
 increase
 
  security.  This would be to restrict SVN authorization for the code
 
 
  I don't think this would greatly increase security, since the current
  review model would still be the better defense. But surely this doesn't
  decrease security and doesn't impact on people who are not using it.
 
 
 Good to think in layers of security.  An account that is not authorized is
 an account we don't need to worry about at all.

 Note:  we have people currently authorized for our source code, who have
 *never* checked in code and who have *never* posted on the mailing list.  I
 have a heard time believing that they are following best practices to avoid
 losing control of their Apache login credentials.


 
   I see also no problem if we handle it more careful and give svn access
  to the code on demand only. Nobody should take it personal
 
 
  Before we manage again to make simple discussions complex, let's see:
  - All committers have the right to have write access to the source code
 


 Yes, though the right is a de jure right, not exactly equivalent to the
 technical authorization.  But one should lead to the other on demand.



  - By default 3 subtrees (trunk, tags, branches) are read-only
  - Any committer can receive write access to the 3 subtrees immediately,
 by
  sending an e-mail here
 
  This could be fine for me, provided that:
 
  1) We have the right way to manage this (another LDAP group does not look
  like the right solution: people who don't want to understand correctly
 will
  invent that this is a multi-level hierarchy while it would simply be a
  permission that we enable on demand)

Hmmm that I think ldap would be the normal way of handling it, but it is
pure technical and not something the user sees.


 
  2) Enabling write access is extremely simple, especially if this is
  something that I must take care of! Something like the current 
  modify_unix_group.pl scripts currently used for the committers group.
 

Yes, that is how I understand subprojects. PMC can grant write access.


 
 I'd do it like this:

 0) Call it active and dormant statuses.  This doesn't change status as
 a committer, just status of SVN authorization.

+1


 1) By default the active list includes only those who have made commits to
 those trees in the last 12 months (or some other suitable time period).
 Ever would be a fine time period as well.

+1, I would prefer 6 month.


 2) Everyone else has authorization for /site, /ooo-site and /devtools

Are you sure about devtools, they they are equal to source in my opinion.


 3) Any committer can be added to the active list on demand.

+1 with emphasis on demaend, default is read-only


 4) New committers are explained this when they are voted in and asked if
 they want to be on the active list for Subversion.

 +1

rgds
Jan I


 Regards,

 -Rob

 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: Shell access to LAMP machines

On 3 April 2013 19:19, Kay Schenk kay.sch...@gmail.com wrote:

 On Wed, Apr 3, 2013 at 8:22 AM, Andrea Pescetti pesce...@apache.org
 wrote:

  On 01/04/2013 janI wrote:
 
  A volunteer does not need to be an expert, that can be learned,
  possibility
  to react swiftly to alers in your TZ is the key. General knowledge about
  mysql/php is a clear advantage. In general we talk about 1-2 hours work
 pr
  month, not including upgrades.
 
 
  Adding to what Jan wrote: we now have more granular access levels, so
 that
  we can have a class of volunteers who can only restart services (which is
  often enough in case of a sudden problem). This means you shouldn't be
  scared of having too many privileges and possibly break the setup, since
  privileges will be exactly enough to do what is needed.
 
  We can give these privileges a couple of volunteers if available, don't
 be
  shy! You need to be an OpenOffice committer and have a reasonable
 knowledge
  of Linux system administration (not much, but at least being able to
 manage
  services from the command line). Again, American timezones are not
 covered
  at the moment so it's best to have volunteers from there, but any help is
  welcome. Anyone?
 
  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
 
 

 Can you elaborate on what specific services, and what might be involved?


the services are: wiki, forum, translate.

the main task is to act when nagios gives an alert (meaning problems),
normal reaction would be to reboot, secondary to log at logs, third to pass
the incident on to someone (might be yourself) that have the skills to
solve a complicated breakdown.

In essence, what we really need are voluenterrs who are able to react
swiftly on a nagios mail.

have a nice day.
jan I.

Ps: what is your TZ.





 --

 
 MzK

 Achieving happiness requires the right combination of Zen and Zin.

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

2013-04-03 Thread Dennis E. Hamilton

My sense of this is that there is a desire to reduce the threat surface of 
the SVN by requiring committers to opt-in.  (I assume there is some way to 
decide which committers to grandfather.)  Apparently, that is a one-time act 
and it doesn't alter being relatively inactive.  So I guess this will have to 
be a periodic ceremonial requirement.

I take it that this means an attacker breaks into an existing committer's 
account in some manner, impersonating that committer in a manner that (1) the 
committer doesn't notice (possible) and that (2) it doesn't attract attention 
on the commit logs (i.e., CTR fails at R).  It seems to me that new activity by 
an inactive committer (that orcmid fellow, for example) would be noticed and it 
would be difficult to do anything that looked suspicious.  (Orcmid did make a 
commit recently, but it was to fix something on the web site and it was done 
via the CMS.)

I also don't understand how phishing would work.  I can't imagine receiving 
anything that requires me to use my @apache credentials anywhere without 
attracting great concern.  If there's a successful Man-in-the-Middle exploit 
against the SVN, it is not the inactive committers that are going to be hacked. 

As far as I know, the only successful attacks against the ASF (and Apache 
committers) involved compromising servers and stealing password hashes, making 
them vulnerable to off-line password discovery.  The mitigation seems to have 
worked.  

I think an use it or lose it approach to committer authorization might be more 
effective.  It won't get the account off the books (as far as I know), but it 
would shrink the authz surface of the individual project code base.  
Fortunately, that will not disturb the bugzilla or authorization to edit on 
Planet Apache, afaik.

 - Dennis

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

[ ... ]
It is not about trusting the committers.  It is about reducing the
exposures to hackers.  Trust of the committer has nothing to do with it.
Every active authorization in SVN is a vulnerable opening for a hacker, who
can gain access, via any number of phishing methods in common use today.
It us only prudent that a committer not have that authorization unless they
are using it.

-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 Wed, Apr 3, 2013 at 5:02 PM, Dennis E. Hamilton orc...@apache.orgwrote:

 My sense of this is that there is a desire to reduce the threat surface
 of the SVN by requiring committers to opt-in.  (I assume there is some way
 to decide which committers to grandfather.)  Apparently, that is a one-time
 act and it doesn't alter being relatively inactive.  So I guess this will
 have to be a periodic ceremonial requirement.

 I take it that this means an attacker breaks into an existing committer's
 account in some manner, impersonating that committer in a manner that (1)
 the committer doesn't notice (possible) and that (2) it doesn't attract
 attention on the commit logs (i.e., CTR fails at R).  It seems to me that
 new activity by an inactive committer (that orcmid fellow, for example)
 would be noticed and it would be difficult to do anything that looked
 suspicious.  (Orcmid did make a commit recently, but it was to fix
 something on the web site and it was done via the CMS.)

 I also don't understand how phishing would work.  I can't imagine
 receiving anything that requires me to use my @apache credentials anywhere
 without attracting great concern.  If there's a successful
 Man-in-the-Middle exploit against the SVN, it is not the inactive
 committers that are going to be hacked.



And I can't imagine that you would fall for a phishing attack either. I'm
not thinking of you. But remember, when we first started as a poding we
handed out a committer rights to anyone who had a pulse.  Every one of
their accounts has exactly the same permission set yours does.

This is not the place to teach hacking, but getting 5-10% of committers to
enter their Apache credentials into a webform linked to by a spoofed email
purporting to come from a trusted party would be rather easy,

-Rob



 As far as I know, the only successful attacks against the ASF (and Apache
 committers) involved compromising servers and stealing password hashes,
 making them vulnerable to off-line password discovery.  The mitigation
 seems to have worked.

 I think an use it or lose it approach to committer authorization might be
 more effective.  It won't get the account off the books (as far as I know),
 but it would shrink the authz surface of the individual project code base.
  Fortunately, that will not disturb the bugzilla or authorization to edit
 on Planet Apache, afaik.

  - Dennis

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

 [ ... ]
 It is not about trusting the committers.  It is about reducing the
 exposures to hackers.  Trust of the committer has nothing to do with it.
 Every active authorization in SVN is a vulnerable opening for a hacker, who
 can gain access, via any number of phishing methods in common use today.
 It us only prudent that a committer not have that authorization unless they
 are using it.

 -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

2013-04-03 Thread Hagar Delest


Le 03/04/2013 15:13, Rob Weir a écrit :

3) We have those who are voted in as committers and might access other, non
SVN systems.  They use their Apache ID's to write blog posts, access Pootle
directly, or maybe even just the SMTP servers.  But they never touch SVN at
all.


I'm one of these committers (initially to have a blog account). I said I 
resigned several months ago but I don't know if I've been removed from the 
system (I still receive the mail to committers). That would be one inactive 
account less.

Hagar

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

Re: Shell access to LAMP machines

On Mon, Apr 1, 2013 at 2:46 AM, janI j...@apache.org wrote:

 On 1 April 2013 01:16, Andrea Pescetti pesce...@apache.org wrote:

  The OpenOffice project maintains a few machines with different people
  responsible for them. One step forward for better maintenance would be to
  build a small team of LAMP administrators here, common to the two LAMP
  machines because problems tend to be common: for example, the forum MySQL
  problems are similar to those already solved by Jan on the wiki.
 
  The two machines, ooo-wiki2 (wiki.openoffice.org) and ooo-forums (
  forum.openoffice.org) are unsupported by Infra (they help, but with low
  priority) and here is the situation:
 
  - imacat has already access to both (with sudo rights); no changes needed
  here.
 
  - jani has already sudo access to ooo-wiki2 and is available to receive
 it
  at ooo-forums too, and I propose he is granted access
 
  - rbircher used to have access but the machines were reconfigured, so he
  probably doesn't have it now: Raphael, if you are available please let us
  know (and I recommend that whatever you choose is common to both
 ooo-wiki2
  and ooo-forums)
 
  - I, as already proposed here, have now got access to ooo-forums and I'll
  ask access to ooo-wiki2 too; however, if we have a new volunteer (needs
 to
  be an OpenOffice committer) willing to join, especially in the American
  timezone (but any timezone will be OK!), I'll very happily step back and
  remain only as a backup, to avoid building an unnecessarily large team.
 
  This does not include the translate-vm machine, which should be home to
  the new Pootle, and which is managed by Infra, jani and jsc.
 

 Thanks andrea for a very precise summary of our LAMP park, which of course
 does not include my/our current infra discussion, I would like to add a
 note about the work needed by a new volunteer, since it might sound more
 scary than it actually is.

 The top work of the team is being able to respond swiftly to breakdowns.
 we need people in different TZ (imacat is taiwan, and I am spain). In case
 of a breakdown, we have the initative, most quick responses are quite
 simple, and for the complicated ones infra is there to help.

 We need to regulary look at the logs, and take apropriate action, like
 tuning a table, or finding a php problem. However this is not time critical
 and can be done by a team member who master it or one who wants to learn.

 We need to update the OS regulary, apply package fixes approx. once every
 month, this is all standard ubuntu, and is typically done in 1/2 hours.

 Last we try to keep the server upgraded, in regards of the applications we
 use. This is something normally carefully planned so we are sure not only
 to be able to do the upgrade, but also have a higher alert level the first
 24 hours after the upgrade.



What about data backup?  How is that currently handled?

-Rob



 I have a dream, to make the 3 lamp´s have a identical setup (but of course
 different application). Mwiki today uses mysql, php with fast-cgi, httpd
 and ats. Especially the forum would benefit from fast-cgi and problaly a
 tuned mysql.

 A volunteer does not need to be an expert, that can be learned, possibility
 to react swiftly to alers in your TZ is the key. General knowledge about
 mysql/php is a clear advantage. In general we talk about 1-2 hours work pr
 month, not including upgrades.

 rgds
 Jan I

 
  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

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

2013-04-03 Thread David Coldwell

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

Why aren't there any links to older versions?


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

Re: Shell access to LAMP machines

2013-04-03 Thread Andrew Rist



On 4/3/2013 8:22 AM, Andrea Pescetti wrote:

On 01/04/2013 janI wrote:
A volunteer does not need to be an expert, that can be learned, 
possibility

to react swiftly to alers in your TZ is the key. General knowledge about
mysql/php is a clear advantage. In general we talk about 1-2 hours 
work pr

month, not including upgrades.


Adding to what Jan wrote: we now have more granular access levels, so 
that we can have a class of volunteers who can only restart services 
(which is often enough in case of a sudden problem). This means you 
shouldn't be scared of having too many privileges and possibly break 
the setup, since privileges will be exactly enough to do what is needed.


We can give these privileges a couple of volunteers if available, 
don't be shy! You need to be an OpenOffice committer and have a 
reasonable knowledge of Linux system administration (not much, but at 
least being able to manage services from the command line). Again, 
American timezones are not covered at the moment so it's best to have 
volunteers from there, but any help is welcome. Anyone?


Regards,
  Andrea.

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



I'll raise my hand for US TZ - though that doesn't there isn't plenty of 
room for others here to step up.

Who else is willing to help?   (don't be shy!)
Remember - as a project, we said that the Wiki, Forums, and Translate 
were needed on their existing platforms, and that we would help.

Now's the time, as they need some TLC.

Andrew


(my joining the effort may or may not have come about through some 
fairly effective lobbying on the part of JanIV - I'll never tell)




-
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

2013-04-03 Thread Marcus (OOo)


Am 04/03/2013 10:58 PM, schrieb janI:

On 3 April 2013 22:30, Rob Weirrobw...@apache.org  wrote:


On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescettipesce...@apache.org
wrote:


Jürgen Schmidt wrote: [...]


On 3 April 2013 14:39, Rob Weirrobw...@apache.org   wrote:



one change to our current process that will, I think, greatly

increase


security.  This would be to restrict SVN authorization for the code




I don't think this would greatly increase security, since the current
review model would still be the better defense. But surely this doesn't
decrease security and doesn't impact on people who are not using it.



Good to think in layers of security.  An account that is not authorized is
an account we don't need to worry about at all.

Note:  we have people currently authorized for our source code, who have
*never* checked in code and who have *never* posted on the mailing list.  I
have a heard time believing that they are following best practices to avoid
losing control of their Apache login credentials.




  I see also no problem if we handle it more careful and give svn access

to the code on demand only. Nobody should take it personal



Before we manage again to make simple discussions complex, let's see:
- All committers have the right to have write access to the source code




Yes, though the right is a de jure right, not exactly equivalent to the
technical authorization.  But one should lead to the other on demand.




- By default 3 subtrees (trunk, tags, branches) are read-only
- Any committer can receive write access to the 3 subtrees immediately,

by

sending an e-mail here

This could be fine for me, provided that:

1) We have the right way to manage this (another LDAP group does not look
like the right solution: people who don't want to understand correctly

will

invent that this is a multi-level hierarchy while it would simply be a
permission that we enable on demand)



Hmmm that I think ldap would be the normal way of handling it, but it is
pure technical and not something the user sees.




2) Enabling write access is extremely simple, especially if this is
something that I must take care of! Something like the current 
modify_unix_group.pl scripts currently used for the committers group.




Yes, that is how I understand subprojects. PMC can grant write access.





I'd do it like this:

0) Call it active and dormant statuses.  This doesn't change status as
a committer, just status of SVN authorization.


+1



1) By default the active list includes only those who have made commits to
those trees in the last 12 months (or some other suitable time period).
Ever would be a fine time period as well.


+1, I would prefer 6 month.



2) Everyone else has authorization for /site, /ooo-site and /devtools


Are you sure about devtools, they they are equal to source in my opinion.



3) Any committer can be added to the active list on demand.


+1 with emphasis on demaend, default is read-only



4) New committers are explained this when they are voted in and asked if
they want to be on the active list for Subversion.

+1


rgds
Jan I


I'm one of them who would loose commit permission to the core code. But 
for me it would be OK.


As my knowledge is not big enough to play with you in this premier 
league of C++/C, Java, etc. it doesn't make any difference for me if I 
could or could not commit. So, if it helps to increase the security a 
bit, then I'm fine with it.


Marcus


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

Re: [Mirror file structure][DISCUSS] Wanted: New mirror file structure for AOO 4.0

2013-04-03 Thread Marcus (OOo)

Am 04/01/2013 03:39 PM, schrieb Rob Weir:

On Mon, Apr 1, 2013 at 9:12 AM, Marcus (OOo)marcus.m...@wtnet.de wrote:

Am 04/01/2013 01:49 PM, schrieb Rob Weir:

On Apr 1, 2013, at 3:54 AM, Marcus (OOo)marcus.m...@wtnet.de wrote:

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

On Sun, Mar 31, 2013 at 12:07 PM, Marcus (OOo)marcus.m...@wtnet.de
wrote:

Many months ago we agreed to create a new file structure for the
mirrors to
get rid of some historical grown limitations and complexity.

I want to continue this and come to a final result.

Current situation:

- Mostly it's about to differenciate the files between stable for
en-US
files only and localized for all other languages.

- Due to Apache policy the source files must not be distributed by
mirrors,
but have to be offered from Apache servers only.

Is that actually true? I thought it was fine to distribute our source
tarballs via the Apache mirror network. The things that must be
distributed from the Apache dist server are the hash files and
detached signature files.

You are right, I've checked this with the current downloads. So, it can
stay as it is now.

New naming structure:

- A new structure could look like the following:

path_on_the_mirror/release_**version/file_type/**
language_code/install_file

Some examples to make it more realistic:

http://sourceforge.net/**projects/openofficeorg.mirror/http://sourceforge.net/projects/openofficeorg.mirror/
4.0.0/binaries/en-US/Apache_**OpenOffice_4.0.0_Win_x86_**
install_en-US.exe

http://sourceforge.net/**projects/openofficeorg.mirror/http://sourceforge.net/projects/openofficeorg.mirror/
4.0.0/binaries/it/Apache_**OpenOffice_4.0.0_Win_x86_**langpack_it.exe

http://sourceforge.net/**projects/openofficeorg.mirror/http://sourceforge.net/projects/openofficeorg.mirror/
4.0.0/binaries/SDK/Apache_**OpenOffice-SDK_4.0.0_Win_x86_**
install_en-US.exe

This does not match your pattern. There is nolanguage-code
component to the path?

It is, have a look for the en-US it, and SDK pattern.

Maybe a typo in you example? I see SDK (and binaries) but no
language. Surely pretending that SDK is a language would only
complicate the logic.

As the SDK is distributed as en-US files we can put them also into this
dir. However, don't worry about the logic. ;-)

But I do care, since my statistics gathering tools rely on a consistent
directory structure.

Better, IMHO, to havefile-type be more meaningful, e.g.,
full-install, lang-pack, SDK, source, etc. Pretending that the
SDK is merely another form of en-US binary is suboptimal.

Sure, SDK could be also a file-type instead of a language.

Marcus

http://www.apache.org/dyn/aoo-**closer.cgi/ooo/http://www.apache.org/dyn/aoo-closer.cgi/ooo/

4.0.0/source/aoo-4.0.0-src.**tar.bz2

What do you think?

This is fine. Could even do without thefile_typedirectory. If
you do then directly to thelanguage_codedirectory, everything is
clear by the file name.

Sure, but someone (or more people) wanted to have another sub-dir. But I
don't remember who it was.

Otherwise we end up with many directories

with only a very small number of files in them.

I don't think so. When you look at the following I wouldn't call it a
small number of files:

http://sourceforge.net/**projects/openofficeorg.mirror/**
files/localized/ar/3.4.1/http://sourceforge.net/projects/openofficeorg.mirror/files/localized/ar/3.4.1/

However, I don't care. Of course we could elleminate file_type from
the pattern when we could come to an agreeement.

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?

On Wed, Apr 3, 2013 at 5:52 PM, David Coldwell class1d...@aol.com wrote:

 version 3.0 files won't load into version 2.3 so I have to replace 3.0
 with 2.3.
 Why aren't there any links to older versions?


They are in the archived releases folders.  For example, the 2.3 versions
are here:

http://archive.services.openoffice.org/pub/openoffice-archive/stable/2.3.0/


-Rob




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

2013-04-03 Thread Dave Fisher

I'm going to top-post. I agree that this is a good idea, but I want to define 
it expansively as a positive.

(1) The current authz that defines all of the AOO committers must be preserved. 
This is used to generate foundation information like:

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

(2) 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. With ta coders authz everyone knows who is on the list 
by checking:

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

People can then really know who to bug to get their patch committed.

(3) Andrea as PMC Chair or any Apache Member has karma to add or remove people 
on the coders authz. 

We can debate the rules, but those don't effect the structure implied.

Let's look for Consensus on the structure first. Once that is out of the way we 
can easily describe how this new structure is a significant improvement and 
that it is a win all around without a real downside. (Some will spin a downside 
and parrying that is a different discussion.) 

Regards,
Dave

On Apr 3, 2013, at 1:30 PM, Rob Weir wrote:

 On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti pesce...@apache.org wrote:
 
 Jürgen Schmidt wrote: [...]
 
 On 3 April 2013 14:39, Rob Weirrobw...@apache.org  wrote:
 
 one change to our current process that will, I think, greatly increase
 
 security.  This would be to restrict SVN authorization for the code
 
 
 I don't think this would greatly increase security, since the current
 review model would still be the better defense. But surely this doesn't
 decrease security and doesn't impact on people who are not using it.
 
 
 Good to think in layers of security.  An account that is not authorized is
 an account we don't need to worry about at all.
 
 Note:  we have people currently authorized for our source code, who have
 *never* checked in code and who have *never* posted on the mailing list.  I
 have a heard time believing that they are following best practices to avoid
 losing control of their Apache login credentials.
 
 
 
 I see also no problem if we handle it more careful and give svn access
 to the code on demand only. Nobody should take it personal
 
 
 Before we manage again to make simple discussions complex, let's see:
 - All committers have the right to have write access to the source code
 
 
 
 Yes, though the right is a de jure right, not exactly equivalent to the
 technical authorization.  But one should lead to the other on demand.
 
 
 
 - By default 3 subtrees (trunk, tags, branches) are read-only
 - Any committer can receive write access to the 3 subtrees immediately, by
 sending an e-mail here
 
 This could be fine for me, provided that:
 
 1) We have the right way to manage this (another LDAP group does not look
 like the right solution: people who don't want to understand correctly will
 invent that this is a multi-level hierarchy while it would simply be a
 permission that we enable on demand)
 
 2) Enabling write access is extremely simple, especially if this is
 something that I must take care of! Something like the current 
 modify_unix_group.pl scripts currently used for the committers group.
 
 
 I'd do it like this:
 
 0) Call it active and dormant statuses.  This doesn't change status as
 a committer, just status of SVN authorization.
 
 1) By default the active list includes only those who have made commits to
 those trees in the last 12 months (or some other suitable time period).
 Ever would be a fine time period as well.
 
 2) Everyone else has authorization for /site, /ooo-site and /devtools
 
 3) Any committer can be added to the active list on demand.
 
 4) New committers are explained this when they are voted in and asked if
 they want to be on the active list for Subversion.
 
 Regards,
 
 -Rob
 
 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
 
 


-
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