Re: [FYI] Jira is broken

[Pawan Verma]

Jira is down again...
-- 
Thanks & Regards
Pawan Verma
ofbiz.apache.org


On Mon, Mar 2, 2020 at 4:27 PM Jacques Le Roux 
wrote:

> As you certainly saw, ASF Jira was back around 1 hour ago
>
> Le 02/03/2020 à 10:37, Jacques Le Roux a écrit :
> > Hi,
> >
> > You may know, Jira is broken this morning: https://status.apache.org/
> >
> > Jacques
> >
>

Re: Impersonation feature, was: Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3

[Pierre Smits]

Are we confident that documentation and/or logging/audit capabilities are
up to (potential) expectations?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Fri, Feb 28, 2020 at 9:15 AM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

> You understand correctly, and moreover a specific permission must be
> granted to allow the user to impersonate another one. And we even added
> another security to not allow impersonating a user with more permission
> than ourselves.
>
> When we contributed the feature, it was discussed, and improved
> regarding the concern that were expressed. And i'm glad that was done
> this way (improvement through discussion).
>
> Gil
>
> On Fri, Feb 28, 2020 at 09:01:30AM +0100, Michael Brohl wrote:
> > *creating a new thread to leave the vote thread untouched*
> >
> >
> > In my understanding from the previous threads about the impersonation
> > features, it is disabled by default and must be enabled explicitly.
> >
> > Using this feature and dealing with the consequences is up to the user
> then.
> > So I see no valid concern to have this feature in the codebase.
> >
> > Am I missing something?
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> > Am 28.02.20 um 08:49 schrieb Gil Portenseigne:
> > > Hello Pierre,
> > >
> > > If you are talking about impersonation feature, that is not in the
> 17.12
> > > branch.
> > >
> > > In either way, administrative tools, if we got access to it, allow what
> > > your are saying. But there is no security issue that grant these
> > > privilege we are aware of. If you do, please share to the security
> list.
> > >
> > > I'm open to discuss about the "criminal" aspect of the impersonation
> > > feature, but not on this thread.
> > >
> > > Gil
> > >
> > > On Fri, Feb 28, 2020 at 02:54:01AM +0100, Pierre Smits wrote:
> > > > -1
> > > >
> > > > As this release contains software elements that will enable criminal
> > > > parties to gain access to the implemented OFBiz system of a user (a
> > > > business organisation) and impersonate valid users with the intent
> to bring
> > > > harm to the aforementioned business organisation through transactions
> > > > registered by the impersonated valid user..
> > > >
> > > > Met vriendelijke groet,
> > > >
> > > > Pierre Smits
> >
>
>
>

Re: Vetting & Testing Contributor’s Code Changes

[Pierre Smits]

Given that no objections have come forward, I assume lazy consensus and
will move forward with this.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Sat, Feb 22, 2020 at 9:50 AM Pierre Smits  wrote:

> Hi all,
>
> Currently we have Git (and GitHub) in full play for the master branch and
> the 2 active release branches. The transition to this methodology of
> distributed version control and collaboration has been adopted by our
> fellow contributors without any major impediments and/or destructions. At
> least none have been reported. It seems that everybody participating in
> this project and submitting code changes has an experience with Git and/or
> Github prior to the project’s move.
>
> In the past (during the svn era) the only option for fellow contributors
> to deliver code improvements for bug fixes and other enhancements was to
> deliver a file to a ticket in our Jira.
> Nowadays, the contributor can -besides still using that upload option- use
> the option to submit a Pull Request from his private clone or public fork
> to one of our official repositories on Github.
> In that past, and still to date, any code contribution uploaded to a Jira
> ticket needed to be downloaded by a committer and applied by him to a test
> branch (based on either the master or the active release branches) in order
> to vet the code changes and test the code changes whether these would break
> (or integrate with) the codebase. This vetting and testing was and is an
> arduous and  time consuming task, especially when the handed code changes
> span multiple components, languages and/or files. The committer must vet
> the changes with in his mind:
>
>- does it have unnecessary whitespacing
>- does it comply with checkstyle
>- is the code change to the point
>- is the code compliant to our coding and other best practices
>- does the code change pass system integration tests
>- etc., etc.
>
> Vetting and testing these manually and on the development machine, takes
> te committer away from enhancing our codebase himself. And when a vetted
> and tested code change doesn’t pass muster, the testing committer needs to
> update the ticket (but also when the change pases muster).
>
> Maybe, all of this is one of the reasons why contributors and/or committer
> lose interest and the project doesn’t get done much?
>
> However, this should not be. With code enhancements coming in via patch
> files in tickets and via Pull Request, we should adopt a method that will
> help our committers (and fellow contributors too) by offering an automated
> vetting and testing process that will deliver a report about the code and
> its compliance to technical requirements.
>
> This automated vetting and testing process can be done on arrival of a
> Pull Request in the project’s public repository on Github, as well on newly
> added patch files to a ticket. And such a report would , after the process
> has completed, be incorporated in the Pull Request or the ticket. This way
> the submitter, the potential committer and anyone else participating in
> this project and interested in the issue at hand and the solution would be
> informed in a consistent way. With such an automated process, where a
> contributor can rework the code of an initially submitted set of change(s)
> and submit again, and the vetting and testing can be done over and over
> without any burden on a committer.Currently such automated vetting and
> testing can include:
>
>- ASF license checks
>- checkstyle
>- whitespace checks
>- bug hangs (via findbugs or spotbugs)
>- javadoc compliance
>- java compilation testing
>- script validation
>- groovy compilation testing
>- system integration tests
>- etc.
>
> I have some questions for you:
>
>- What are your thoughts on this?
>- Should we adopt this for our project?
>- Before adopting this for our project, should we define a PoC and
>execute it if acceptable?
>
> Best regards,
>
> Pierre Smits
> *Proud* *contributor* (but without privileges)* of* Apache OFBiz
> , since 2008
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> Apache Steve , committer
>