You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by James Dailey <jd...@apache.org> on 2024/03/18 16:50:03 UTC
Keep Fineract Secure, CVEs public
Devs -
Today we are announcing that release 1.9.0 fixed a few reported CVEs.
Those should be showing up here on the listserv shortly. Version 1.8.4 and
prior were not fixed and likely contain these vulnerabilities. We are
circumspect in how we describe them - you can dig further via the PRs and
the related tickets.
The CVEs are also documented here:
https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+Security+Report
With Yash Sancheti helping, we created a How to Secure Fineract page.
Additional best practices should be shared there or on list to ensure that
all instances of Fineract are kept secure.
https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
<https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract>
I would encourage everyone to review their security practices. Fineract
should not simply be downloaded and run in production environments without
taking into account attack vectors and proper security. There are
vendors available to help with this.
Report vulnerabilities and exploits to Security AT fineract.apache.org
Thank you
James
PMC Fineract
Re: Keep Fineract Secure, reminder
Posted by James Dailey <jd...@apache.org>.
All - I think it worth highlighting a recent comment on the public mifos
slack #general channel here from Victor.
The [default] configuration only works for localhost installation. For
> protecting the services exposed to internet, please change the
> configuration of Nginx and make sure to use at least API Gateway, WAF and
> SQL Injection tool." (Victor).
We are compiling best practices at
https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract.
If you have ideas, please help by putting them there.
Also, please be aware that we are vendor neutral. While organizations like
Mifos are free to bundle the fineract system in their offering per the
terms of the license, that does not imply that Fineract has endorsed that
particular deployment approach. The Mifos front end, once tightly coupled
to the backend, is an indispensable tool for the community but it is just
one option. Please consult the Fineract FAQ.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=91554327
Keep Fineract Secure, reminder
Posted by James Dailey <jd...@apache.org>.
All - especially Mifos installations
Please be mindful of the best practices to secure and monitor your logins,
audit logs, etc
https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
On Mon, Mar 18, 2024 at 9:50 AM James Dailey <jd...@apache.org> wrote:
> Devs -
>
> Today we are announcing that release 1.9.0 fixed a few reported CVEs.
> Those should be showing up here on the listserv shortly. Version 1.8.4 and
> prior were not fixed and likely contain these vulnerabilities. We are
> circumspect in how we describe them - you can dig further via the PRs and
> the related tickets.
>
> The CVEs are also documented here:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+Security+Report
>
> With Yash Sancheti helping, we created a How to Secure Fineract page.
> Additional best practices should be shared there or on list to ensure that
> all instances of Fineract are kept secure.
>
> https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
> <https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract>
>
> I would encourage everyone to review their security practices. Fineract
> should not simply be downloaded and run in production environments without
> taking into account attack vectors and proper security. There are
> vendors available to help with this.
>
> Report vulnerabilities and exploits to Security AT fineract.apache.org
>
> Thank you
> James
> PMC Fineract
>
Re: Keep Fineract Secure, CVEs public
Posted by James Dailey <jd...@apache.org>.
Thanks - please.
Sent from Gmail Mobile
On Fri, Mar 29, 2024 at 3:37 AM Arnout Engelen <en...@apache.org> wrote:
> On Mon, Mar 18, 2024 at 5:50 PM James Dailey <jd...@apache.org> wrote:
>
>> The CVEs are also documented here:
>>
>> https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+Security+Report
>>
>
> Congratulations on releasing those fixes!
>
> The ASF vulnerability handling policy (
> https://apache.org/security/committers.html) includes publishing the
> advisories to various mailinglists (step 16). AFAICS that hasn't happened
> yet. It might be worth fixing up the version ranges and publishing those
> notification emails. Do you want me to take care of that on your behalf?
>
>
I missed that. Thought it was automatic.
Yes
> With Yash Sancheti helping, we created a How to Secure Fineract page.
>> Additional best practices should be shared there or on list to ensure that
>> all instances of Fineract are kept secure.
>>
>> https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
>>
>
> That looks really great, thanks! Perhaps the 'Security' link at the bottom
> of the website should link here instead of to the generic
> https://www.apache.org/security?
>
>
> Kind regards,
>
> --
> Arnout Engelen
> ASF Security Response
> Apache Pekko PMC member, ASF Member
> NixOS Committer
> Independent Open Source consultant
>
Re: Keep Fineract Secure, CVEs public
Posted by Arnout Engelen <en...@apache.org>.
On Mon, Mar 18, 2024 at 5:50 PM James Dailey <jd...@apache.org> wrote:
> The CVEs are also documented here:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+Security+Report
>
Congratulations on releasing those fixes!
The ASF vulnerability handling policy (
https://apache.org/security/committers.html) includes publishing the
advisories to various mailinglists (step 16). AFAICS that hasn't happened
yet. It might be worth fixing up the version ranges and publishing those
notification emails. Do you want me to take care of that on your behalf?
> With Yash Sancheti helping, we created a How to Secure Fineract page.
> Additional best practices should be shared there or on list to ensure that
> all instances of Fineract are kept secure.
>
> https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
>
That looks really great, thanks! Perhaps the 'Security' link at the bottom
of the website should link here instead of to the generic
https://www.apache.org/security?
Kind regards,
--
Arnout Engelen
ASF Security Response
Apache Pekko PMC member, ASF Member
NixOS Committer
Independent Open Source consultant
Re: Keep Fineract Secure, CVEs public
Posted by Anu Omotayo <an...@yahoo.com.INVALID>.
Well done James, Yash and everyone working making Fineract more secure!
My team and I find this documentation (https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract) helpful.
Regards
Anu Omotayo
On Monday, March 18, 2024 at 05:50:22 PM GMT+1, James Dailey <jd...@apache.org> wrote:
Devs -
Today we are announcing that release 1.9.0 fixed a few reported CVEs. Those should be showing up here on the listserv shortly. Version 1.8.4 and prior were not fixed and likely contain these vulnerabilities. We are circumspect in how we describe them - you can dig further via the PRs and the related tickets.
The CVEs are also documented here: https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+Security+Report
With Yash Sancheti helping, we created a How to Secure Fineract page. Additional best practices should be shared there or on list to ensure that all instances of Fineract are kept secure.
https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
|
|
| |
Securing Fineract - Fineract - Apache Software Foundation
|
|
|
I would encourage everyone to review their security practices. Fineract should not simply be downloaded and run in production environments without taking into account attack vectors and proper security. There are vendors available to help with this.
Report vulnerabilities and exploits to Security AT fineract.apache.org
Thank you James PMC Fineract
Re: Keep Fineract Secure, CVEs public
Posted by Aleksandar Vidakovic <ch...@monkeysintown.com>.
... @William: how about helping out or sponsor ("put your money where your
mouth is") some (or all) of the things you are missing...
On Sat, Mar 30, 2024 at 12:57 PM Javier Borkenztain <ja...@fiter.io> wrote:
> Hello William Ondenge,
>
> It is wise to ask before attacking; if you don't know how Apache works,
> you should start by asking or doing your research. The Apache Way (
> https://www.apache.org/theapacheway/) is how this community works;
> start there.
>
> This is a community effort-driven software. We always try to minimize the
> entry barriers; sometimes we make it, and sometimes we don't, and we're
> always grateful and willing to get more help.
>
> If you find opportunities to lower the entry barriers for newcomers,
> please tackle them; none will stop you, and you will start building your
> reputation in this community.
>
> Best,
> Javier
>
>
> On Fri, 29 Mar 2024 at 11:49 William Ondenge <on...@gmail.com> wrote:
>
>> Hi James,
>>
>> I think I have enough courage now to speak up.
>>
>> There is a huge barrier to entry for the Fineract project. I think your
>> reference to "vendors" even makes it worse. I do not know that this is how
>> Apache works, or maybe I am just used to CNCF with better organisation. For
>> example, the Fineract release cycles are really messed up, especially for
>> the last two releases. Almost everything is outdated, and there are people
>> who thrive in this chaos, and dis-organization. We may call them vendors.
>>
>> Can you explain the closed loop?
>>
>> For instance, I may be a Sys Ops person who wants to streamline and make
>> the project deployable on different environments without sweat. But guess
>> what? We appreciate the closed loop, and prefer vendors to do it?
>>
>> And then talking about security vulnerability fixes in this way is even
>> adding salt to the injury.
>>
>> Shame on you Apache!
>>
>> William
>>
>> On Mon, Mar 18, 2024 at 5:50 PM James Dailey <jd...@apache.org> wrote:
>>
>>> Devs -
>>>
>>> Today we are announcing that release 1.9.0 fixed a few reported CVEs.
>>> Those should be showing up here on the listserv shortly. Version 1.8.4 and
>>> prior were not fixed and likely contain these vulnerabilities. We are
>>> circumspect in how we describe them - you can dig further via the PRs and
>>> the related tickets.
>>>
>>> The CVEs are also documented here:
>>>
>>> https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+Security+Report
>>>
>>> With Yash Sancheti helping, we created a How to Secure Fineract page.
>>> Additional best practices should be shared there or on list to ensure that
>>> all instances of Fineract are kept secure.
>>>
>>> https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
>>> <https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract>
>>>
>>> I would encourage everyone to review their security practices. Fineract
>>> should not simply be downloaded and run in production environments without
>>> taking into account attack vectors and proper security. There are
>>> vendors available to help with this.
>>>
>>> Report vulnerabilities and exploits to Security AT fineract.apache.org
>>>
>>> Thank you
>>> James
>>> PMC Fineract
>>>
>>
Re: Keep Fineract Secure, CVEs public
Posted by Javier Borkenztain <ja...@fiter.io>.
Hello William Ondenge,
It is wise to ask before attacking; if you don't know how Apache works, you
should start by asking or doing your research. The Apache Way (
https://www.apache.org/theapacheway/) is how this community works;
start there.
This is a community effort-driven software. We always try to minimize the
entry barriers; sometimes we make it, and sometimes we don't, and we're
always grateful and willing to get more help.
If you find opportunities to lower the entry barriers for newcomers, please
tackle them; none will stop you, and you will start building your
reputation in this community.
Best,
Javier
On Fri, 29 Mar 2024 at 11:49 William Ondenge <on...@gmail.com> wrote:
> Hi James,
>
> I think I have enough courage now to speak up.
>
> There is a huge barrier to entry for the Fineract project. I think your
> reference to "vendors" even makes it worse. I do not know that this is how
> Apache works, or maybe I am just used to CNCF with better organisation. For
> example, the Fineract release cycles are really messed up, especially for
> the last two releases. Almost everything is outdated, and there are people
> who thrive in this chaos, and dis-organization. We may call them vendors.
>
> Can you explain the closed loop?
>
> For instance, I may be a Sys Ops person who wants to streamline and make
> the project deployable on different environments without sweat. But guess
> what? We appreciate the closed loop, and prefer vendors to do it?
>
> And then talking about security vulnerability fixes in this way is even
> adding salt to the injury.
>
> Shame on you Apache!
>
> William
>
> On Mon, Mar 18, 2024 at 5:50 PM James Dailey <jd...@apache.org> wrote:
>
>> Devs -
>>
>> Today we are announcing that release 1.9.0 fixed a few reported CVEs.
>> Those should be showing up here on the listserv shortly. Version 1.8.4 and
>> prior were not fixed and likely contain these vulnerabilities. We are
>> circumspect in how we describe them - you can dig further via the PRs and
>> the related tickets.
>>
>> The CVEs are also documented here:
>>
>> https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+Security+Report
>>
>> With Yash Sancheti helping, we created a How to Secure Fineract page.
>> Additional best practices should be shared there or on list to ensure that
>> all instances of Fineract are kept secure.
>>
>> https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
>> <https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract>
>>
>> I would encourage everyone to review their security practices. Fineract
>> should not simply be downloaded and run in production environments without
>> taking into account attack vectors and proper security. There are
>> vendors available to help with this.
>>
>> Report vulnerabilities and exploits to Security AT fineract.apache.org
>>
>> Thank you
>> James
>> PMC Fineract
>>
>
Re: Keep Fineract Secure, CVEs public
Posted by William Ondenge <on...@gmail.com>.
Hi James,
I think I have enough courage now to speak up.
There is a huge barrier to entry for the Fineract project. I think your
reference to "vendors" even makes it worse. I do not know that this is how
Apache works, or maybe I am just used to CNCF with better organisation. For
example, the Fineract release cycles are really messed up, especially for
the last two releases. Almost everything is outdated, and there are people
who thrive in this chaos, and dis-organization. We may call them vendors.
Can you explain the closed loop?
For instance, I may be a Sys Ops person who wants to streamline and make
the project deployable on different environments without sweat. But guess
what? We appreciate the closed loop, and prefer vendors to do it?
And then talking about security vulnerability fixes in this way is even
adding salt to the injury.
Shame on you Apache!
William
On Mon, Mar 18, 2024 at 5:50 PM James Dailey <jd...@apache.org> wrote:
> Devs -
>
> Today we are announcing that release 1.9.0 fixed a few reported CVEs.
> Those should be showing up here on the listserv shortly. Version 1.8.4 and
> prior were not fixed and likely contain these vulnerabilities. We are
> circumspect in how we describe them - you can dig further via the PRs and
> the related tickets.
>
> The CVEs are also documented here:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+Security+Report
>
> With Yash Sancheti helping, we created a How to Secure Fineract page.
> Additional best practices should be shared there or on list to ensure that
> all instances of Fineract are kept secure.
>
> https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract
> <https://cwiki.apache.org/confluence/display/FINERACT/Securing+Fineract>
>
> I would encourage everyone to review their security practices. Fineract
> should not simply be downloaded and run in production environments without
> taking into account attack vectors and proper security. There are
> vendors available to help with this.
>
> Report vulnerabilities and exploits to Security AT fineract.apache.org
>
> Thank you
> James
> PMC Fineract
>