You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@gmail.com> on 2022/01/04 09:45:34 UTC
Re: [ofbiz-site] branch master updated: More information about security and EOL (End Of Life)
Thank you Jacques for adding the statement: however I think it is time
to remove the entire section of 17.12.08 since we have enough releases
out of 18.12 already. The release 17.12.08 will always be available in
the archive.
Jacopo
On Sun, Jan 2, 2022 at 6:55 PM <jl...@apache.org> wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> jleroux pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/ofbiz-site.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new a69cf9f More information about security and EOL (End Of Life)
> a69cf9f is described below
>
> commit a69cf9f4cdeb1b23e3b1db30ada47b52aa7f3dd0
> Author: Jacques Le Roux <ja...@les7arts.com>
> AuthorDate: Sun Jan 2 18:55:24 2022 +0100
>
> More information about security and EOL (End Of Life)
> ---
> download.html | 2 +-
> security.html | 2 +-
> template/page/download.tpl.php | 2 +-
> template/page/security.tpl.php | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/download.html b/download.html
> index be0b541..51a7d62 100644
> --- a/download.html
> +++ b/download.html
> @@ -198,7 +198,7 @@
>
> <h2>Apache OFBiz 17.12.08</h2>
> <div class="divider"><span></span></div>
> - <p> Released on August 2021, this is the eighth and final release of the 17.12 series, that has been stabilized since December 2017.</p>
> + <p> Released on August 2021, this is the eighth and final release of the 17.12 series, that has been stabilized since December 2017. That means that the release17.12 branch has reached its End Of Life (EOL) and is no longer supported from a security perspective</p>
> <a href="https://www.apache.org/dyn/closer.lua/ofbiz/apache-ofbiz-17.12.08.zip" target="external" >Download OFBiz 17.12.08</a>
> <a href="https://downloads.apache.org/ofbiz/apache-ofbiz-17.12.08.zip.asc" target="external">[PGP]</a>
> <a href="https://downloads.apache.org/ofbiz/apache-ofbiz-17.12.08.zip.sha512" target="external">[SHA512]</a>
> diff --git a/security.html b/security.html
> index 12efce9..0a05ab9 100644
> --- a/security.html
> +++ b/security.html
> @@ -136,7 +136,7 @@
> <p>Note that we no longer create CVEs for post-auth attacks done using demo credentials, notably using the admin user.
> <strong> <a href="https://s.apache.org/dsj2p"> Rather create bugs reports in our issue tracker (Jira) for that.</a></strong></p>
>
> - <p>The main reason why we no longer create CVEs for post-auth attacks done using demo credentials is because
> + <p>The main reason we no longer create CVEs for post-auth attacks done using demo credentials is because
> <a href="https://ci.apache.org/projects/ofbiz/site/trunk/readme/html5/README.html#security"> we highly suggest to OFBiz users to not use credentials demo in production</a>
> and we expect OFBiz users to do so. We also reject post-auth vulnerabilities because we have a solid CSRF defense.</p>
>
> diff --git a/template/page/download.tpl.php b/template/page/download.tpl.php
> index d4ec4d5..892cc2f 100644
> --- a/template/page/download.tpl.php
> +++ b/template/page/download.tpl.php
> @@ -87,7 +87,7 @@
>
> <h2>Apache OFBiz 17.12.08</h2>
> <div class="divider"><span></span></div>
> - <p> Released on August 2021, this is the eighth and final release of the 17.12 series, that has been stabilized since December 2017.</p>
> + <p> Released on August 2021, this is the eighth and final release of the 17.12 series, that has been stabilized since December 2017. That means that the release17.12 branch has reached its End Of Life (EOL) and is no longer supported from a security perspective</p>
> <a href="https://www.apache.org/dyn/closer.lua/ofbiz/apache-ofbiz-17.12.08.zip" target="external" >Download OFBiz 17.12.08</a>
> <a href="https://downloads.apache.org/ofbiz/apache-ofbiz-17.12.08.zip.asc" target="external">[PGP]</a>
> <a href="https://downloads.apache.org/ofbiz/apache-ofbiz-17.12.08.zip.sha512" target="external">[SHA512]</a>
> diff --git a/template/page/security.tpl.php b/template/page/security.tpl.php
> index 532a9f7..c6ee66a 100644
> --- a/template/page/security.tpl.php
> +++ b/template/page/security.tpl.php
> @@ -25,7 +25,7 @@
> <p>Note that we no longer create CVEs for post-auth attacks done using demo credentials, notably using the admin user.
> <strong> <a href="https://s.apache.org/dsj2p"> Rather create bugs reports in our issue tracker (Jira) for that.</a></strong></p>
>
> - <p>The main reason why we no longer create CVEs for post-auth attacks done using demo credentials is because
> + <p>The main reason we no longer create CVEs for post-auth attacks done using demo credentials is because
> <a href="https://ci.apache.org/projects/ofbiz/site/trunk/readme/html5/README.html#security"> we highly suggest to OFBiz users to not use credentials demo in production</a>
> and we expect OFBiz users to do so. We also reject post-auth vulnerabilities because we have a solid CSRF defense.</p>
>
Re: [ofbiz-site] branch master updated: More information about security and EOL (End Of Life)
Posted by Jacopo Cappellato <ja...@gmail.com>.
Thank you Jacques,
I have now published the change.
Jacopo
On Tue, Jan 4, 2022 at 11:53 AM Jacques Le Roux
<ja...@les7arts.com> wrote:
>
> I agree Jacopo,
>
> Will you handle it?
>
> I made those tiny changes after an answer Mark J. Cox made to Mark Thomas in a discussion I read on security-discuss@community.apache.org :
>
> MT: <<We need to consider whether projects that are not releasing
> regularly really are healthy. Could they realistically respond to a
> security vulnerability in a reasonable time frame? If not, we need to
> move them to the attic.>>
>
> MC: <<And we need a clear way to communicate that, and EOL releases, to users so
> they know the status of what they're using. There are quite a number of
> examples where a project has responded to a vulnerability reporter that
> some version is EOL but it's not been clear enough on their pages, nor any
> real announcement ever having being made. We need a consistent policy on
> what to do about vulnerabilities that come up in EOL versions, and when to
> allocate them CVE names ('there's an unfixed issue in X") in order to help
> users with scanning tools also notice when they're using out of date and
> now insecure projects.>>
>
> There are at least 340+ TLPs*. So I guess it becomes worrying for the ASF.
>
> I don't think we are concerned by those worries. So was just a small effort in this direction.
> I think though that we should discuss about how to handle EOL announcements.
>
> * https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
>
> Jacques
>
> Le 04/01/2022 à 10:45, Jacopo Cappellato a écrit :
> > Thank you Jacques for adding the statement: however I think it is > time to remove the entire section of 17.12.08 since we have enough > releases out of 18.12 already. The release 17.12.08 will always be >
> available in the archive. > > Jacopo
Re: OFBiz releases EOL (End Of Life) announcement
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 10/01/2022 à 14:55, Jacopo Cappellato a écrit :
> On Mon, Jan 10, 2022 at 11:26 AM Jacques Le Roux
> <ja...@les7arts.com> wrote:
>> Hi Jacopo,
>>
>> Would you be available soon to start the release work?
> Yes, I can work on it later today.
Great!
>
>> Also what about freezing a 22.01 branch?
> For the freezing of 22.01, we can proceed anytime: is there a
> volunteer to create the reales branches?
Sure I can do it
Jacques
>
> Jacopo
Re: OFBiz releases EOL (End Of Life) announcement
Posted by Jacopo Cappellato <ja...@gmail.com>.
On Mon, Jan 10, 2022 at 11:26 AM Jacques Le Roux
<ja...@les7arts.com> wrote:
>
> Hi Jacopo,
>
> Would you be available soon to start the release work?
Yes, I can work on it later today.
>
> Also what about freezing a 22.01 branch?
For the freezing of 22.01, we can proceed anytime: is there a
volunteer to create the reales branches?
Jacopo
Re: OFBiz releases EOL (End Of Life) announcement
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Jacopo,
Would you be available soon to start the release work?
Also what about freezing a 22.01 branch? I'd like to then discuss the demos restart with Infra...
TIA
Jacques
Le 07/01/2022 à 17:26, Jacques Le Roux a écrit :
> Hi,
>
> Jacopo and I came to an agreement at OFBIZ-12479.
>
> You can still modify the draft if you feel so.
>
> I propose to start the release work after the weekend. It's a security issue.
>
> Jacques
>
> Le 05/01/2022 à 20:57, Jacques Le Roux a écrit :
>> Le 05/01/2022 à 09:18, Jacques Le Roux a écrit :
>>> Le 05/01/2022 à 09:14, Jacques Le Roux a écrit :
>>>> I have created https://issues.apache.org/jira/browse/OFBIZ-12479 for that
>>
>> I have updated the Jira with a draft proposal, please comment there
>>
>> TIA
>>
>> Jacques
>>
Re: OFBiz releases EOL (End Of Life) announcement
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi,
Jacopo and I came to an agreement at OFBIZ-12479.
You can still modify the draft if you feel so.
I propose to start the release work after the weekend. It's a security issue.
Jacques
Le 05/01/2022 à 20:57, Jacques Le Roux a écrit :
> Le 05/01/2022 à 09:18, Jacques Le Roux a écrit :
>> Le 05/01/2022 à 09:14, Jacques Le Roux a écrit :
>>> I have created https://issues.apache.org/jira/browse/OFBIZ-12479 for that
>
> I have updated the Jira with a draft proposal, please comment there
>
> TIA
>
> Jacques
>
Re: OFBiz releases EOL (End Of Life) announcement
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 05/01/2022 à 09:18, Jacques Le Roux a écrit :
> Le 05/01/2022 à 09:14, Jacques Le Roux a écrit :
>> I have created https://issues.apache.org/jira/browse/OFBIZ-12479 for that
I have updated the Jira with a draft proposal, please comment there
TIA
Jacques
Re: OFBiz releases EOL (End Of Life) announcement
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 05/01/2022 à 09:14, Jacques Le Roux a écrit :
> I have created https://issues.apache.org/jira/browse/OFBIZ-12479 for that
Re: OFBiz releases EOL (End Of Life) announcement
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi,
I forgot the obvious: we should make an announcement not only on user ML but also on announce@a.o
Struts is a good example: https://s.apache.org/qr8ci
They even have announcements@struts.apache.org, not sure we need that.
I'll inspire from them to create our 1st announcement for EOL of the 18.12 branch with 17.12.08. Next time we will, like Struts, announce 6 months ago
before the definitive announcement.
I have created
Jacques
Le 04/01/2022 à 16:04, Jacques Le Roux a écrit :
> Hi All,
>
> I'd like to discuss about OFBiz releases EOL (End Of Life) announcement.
>
> For instance R17.12 is EOL with 17.12.08. I suggest to make it clear on site (if that's not already enough, eg*), to send an email to user ML and
> maybe talk about it in social-media and the blog.
>
> Maybe we could also have a special site page for EOL dates and version of our releases? And some words in https://ofbiz.apache.org/security.html...
>
> * https://ofbiz.apache.org/release-notes-17.12.08.html (maybe the de facto standard term EOL (End Of Life) is missing?)
>
> Opinions?
>
> Jacques
>
> Le 04/01/2022 à 11:52, Jacques Le Roux a écrit :
>> I agree Jacopo,
>>
>> Will you handle it?
>>
>> I made those tiny changes after an answer Mark J. Cox made to Mark Thomas in a discussion I read on security-discuss@community.apache.org :
>>
>> MT: <<We need to consider whether projects that are not releasing
>> regularly really are healthy. Could they realistically respond to a
>> security vulnerability in a reasonable time frame? If not, we need to
>> move them to the attic.>>
>>
>> MC: <<And we need a clear way to communicate that, and EOL releases, to users so
>> they know the status of what they're using. There are quite a number of
>> examples where a project has responded to a vulnerability reporter that
>> some version is EOL but it's not been clear enough on their pages, nor any
>> real announcement ever having being made. We need a consistent policy on
>> what to do about vulnerabilities that come up in EOL versions, and when to
>> allocate them CVE names ('there's an unfixed issue in X") in order to help
>> users with scanning tools also notice when they're using out of date and
>> now insecure projects.>>
>>
>> There are at least 340+ TLPs*. So I guess it becomes worrying for the ASF.
>>
>> I don't think we are concerned by those worries. So was just a small effort in this direction.
>> I think though that we should discuss about how to handle EOL announcements.
>>
>> * https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
>>
>> Jacques
>>
>> Le 04/01/2022 à 10:45, Jacopo Cappellato a écrit :
>>> Thank you Jacques for adding the statement: however I think it is > time to remove the entire section of 17.12.08 since we have enough > releases
>>> out of 18.12 already. The release 17.12.08 will always be >
>> available in the archive. > > Jacopo
>
Re: OFBiz releases EOL (End Of Life) announcement [was Re: [ofbiz-site] branch master updated: More information about security and EOL (End Of Life)]
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Michael,
That sounds interesting, I propose to create a Jira of maybe even a wiki page for that, maybe a new thread to discuss?
Jacques
Le 04/01/2022 à 17:58, Michael Brohl a écrit :
> +1
>
> with a few additions: I think that the project should have a planned roadmap with more or less fixed release dates/cycles and a clear pre-planned
> EOL plan.
>
> We should also specify what EOL means for us and if there is a step between. I think of making bugfixes/backports during main support and only doing
> security fixes in a phase after that. EOL would then mean ultimately no fixes at all.
>
> For new release branches, we should als TRY to plan which features, big changes or deprecations we want to put in and work towards those goals
> (thinking about major framework changes etc. as we started to discuss recently).
>
> We should also think about another release number scheme. The inclusion of the year/month the branch was created makes the first stable release look
> outdated as we normally have a stabilization time of 2-3 years (which we also could change). Maybe that's a discussion for past-22.x....
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 04.01.22 um 16:04 schrieb Jacques Le Roux:
>> Hi All,
>>
>> I'd like to discuss about OFBiz releases EOL (End Of Life) announcement.
>>
>> For instance R17.12 is EOL with 17.12.08. I suggest to make it clear on site (if that's not already enough, eg*), to send an email to user ML and
>> maybe talk about it in social-media and the blog.
>>
>> Maybe we could also have a special site page for EOL dates and version of our releases? And some words in https://ofbiz.apache.org/security.html...
>>
>> * https://ofbiz.apache.org/release-notes-17.12.08.html (maybe the de facto standard term EOL (End Of Life) is missing?)
>>
>> Opinions?
>>
>> Jacques
>>
>> Le 04/01/2022 à 11:52, Jacques Le Roux a écrit :
>>> I agree Jacopo,
>>>
>>> Will you handle it?
>>>
>>> I made those tiny changes after an answer Mark J. Cox made to Mark Thomas in a discussion I read on security-discuss@community.apache.org :
>>>
>>> MT: <<We need to consider whether projects that are not releasing
>>> regularly really are healthy. Could they realistically respond to a
>>> security vulnerability in a reasonable time frame? If not, we need to
>>> move them to the attic.>>
>>>
>>> MC: <<And we need a clear way to communicate that, and EOL releases, to users so
>>> they know the status of what they're using. There are quite a number of
>>> examples where a project has responded to a vulnerability reporter that
>>> some version is EOL but it's not been clear enough on their pages, nor any
>>> real announcement ever having being made. We need a consistent policy on
>>> what to do about vulnerabilities that come up in EOL versions, and when to
>>> allocate them CVE names ('there's an unfixed issue in X") in order to help
>>> users with scanning tools also notice when they're using out of date and
>>> now insecure projects.>>
>>>
>>> There are at least 340+ TLPs*. So I guess it becomes worrying for the ASF.
>>>
>>> I don't think we are concerned by those worries. So was just a small effort in this direction.
>>> I think though that we should discuss about how to handle EOL announcements.
>>>
>>> * https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
>>>
>>> Jacques
>>>
>>> Le 04/01/2022 à 10:45, Jacopo Cappellato a écrit :
>>>> Thank you Jacques for adding the statement: however I think it is > time to remove the entire section of 17.12.08 since we have enough >
>>>> releases out of 18.12 already. The release 17.12.08 will always be >
>>> available in the archive. > > Jacopo
>>
Re: OFBiz releases EOL (End Of Life) announcement [was Re: [ofbiz-site] branch master updated: More information about security and EOL (End Of Life)]
Posted by Michael Brohl <mi...@ecomify.de>.
+1
with a few additions: I think that the project should have a planned
roadmap with more or less fixed release dates/cycles and a clear
pre-planned EOL plan.
We should also specify what EOL means for us and if there is a step
between. I think of making bugfixes/backports during main support and
only doing security fixes in a phase after that. EOL would then mean
ultimately no fixes at all.
For new release branches, we should als TRY to plan which features, big
changes or deprecations we want to put in and work towards those goals
(thinking about major framework changes etc. as we started to discuss
recently).
We should also think about another release number scheme. The inclusion
of the year/month the branch was created makes the first stable release
look outdated as we normally have a stabilization time of 2-3 years
(which we also could change). Maybe that's a discussion for past-22.x....
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 04.01.22 um 16:04 schrieb Jacques Le Roux:
> Hi All,
>
> I'd like to discuss about OFBiz releases EOL (End Of Life) announcement.
>
> For instance R17.12 is EOL with 17.12.08. I suggest to make it clear
> on site (if that's not already enough, eg*), to send an email to user
> ML and maybe talk about it in social-media and the blog.
>
> Maybe we could also have a special site page for EOL dates and version
> of our releases? And some words in
> https://ofbiz.apache.org/security.html...
>
> * https://ofbiz.apache.org/release-notes-17.12.08.html (maybe the de
> facto standard term EOL (End Of Life) is missing?)
>
> Opinions?
>
> Jacques
>
> Le 04/01/2022 à 11:52, Jacques Le Roux a écrit :
>> I agree Jacopo,
>>
>> Will you handle it?
>>
>> I made those tiny changes after an answer Mark J. Cox made to Mark
>> Thomas in a discussion I read on security-discuss@community.apache.org :
>>
>> MT: <<We need to consider whether projects that are not releasing
>> regularly really are healthy. Could they realistically respond to a
>> security vulnerability in a reasonable time frame? If not, we need to
>> move them to the attic.>>
>>
>> MC: <<And we need a clear way to communicate that, and EOL
>> releases, to users so
>> they know the status of what they're using. There are quite a
>> number of
>> examples where a project has responded to a vulnerability reporter
>> that
>> some version is EOL but it's not been clear enough on their pages,
>> nor any
>> real announcement ever having being made. We need a consistent
>> policy on
>> what to do about vulnerabilities that come up in EOL versions, and
>> when to
>> allocate them CVE names ('there's an unfixed issue in X") in order
>> to help
>> users with scanning tools also notice when they're using out of
>> date and
>> now insecure projects.>>
>>
>> There are at least 340+ TLPs*. So I guess it becomes worrying for the
>> ASF.
>>
>> I don't think we are concerned by those worries. So was just a small
>> effort in this direction.
>> I think though that we should discuss about how to handle EOL
>> announcements.
>>
>> *
>> https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
>>
>> Jacques
>>
>> Le 04/01/2022 à 10:45, Jacopo Cappellato a écrit :
>>> Thank you Jacques for adding the statement: however I think it is >
>>> time to remove the entire section of 17.12.08 since we have enough >
>>> releases out of 18.12 already. The release 17.12.08 will always be >
>> available in the archive. > > Jacopo
>
OFBiz releases EOL (End Of Life) announcement [was Re: [ofbiz-site] branch master updated: More information about security and EOL (End Of Life)]
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi All,
I'd like to discuss about OFBiz releases EOL (End Of Life) announcement.
For instance R17.12 is EOL with 17.12.08. I suggest to make it clear on site (if that's not already enough, eg*), to send an email to user ML and
maybe talk about it in social-media and the blog.
Maybe we could also have a special site page for EOL dates and version of our releases? And some words in https://ofbiz.apache.org/security.html...
* https://ofbiz.apache.org/release-notes-17.12.08.html (maybe the de facto standard term EOL (End Of Life) is missing?)
Opinions?
Jacques
Le 04/01/2022 à 11:52, Jacques Le Roux a écrit :
> I agree Jacopo,
>
> Will you handle it?
>
> I made those tiny changes after an answer Mark J. Cox made to Mark Thomas in a discussion I read on security-discuss@community.apache.org :
>
> MT: <<We need to consider whether projects that are not releasing
> regularly really are healthy. Could they realistically respond to a
> security vulnerability in a reasonable time frame? If not, we need to
> move them to the attic.>>
>
> MC: <<And we need a clear way to communicate that, and EOL releases, to users so
> they know the status of what they're using. There are quite a number of
> examples where a project has responded to a vulnerability reporter that
> some version is EOL but it's not been clear enough on their pages, nor any
> real announcement ever having being made. We need a consistent policy on
> what to do about vulnerabilities that come up in EOL versions, and when to
> allocate them CVE names ('there's an unfixed issue in X") in order to help
> users with scanning tools also notice when they're using out of date and
> now insecure projects.>>
>
> There are at least 340+ TLPs*. So I guess it becomes worrying for the ASF.
>
> I don't think we are concerned by those worries. So was just a small effort in this direction.
> I think though that we should discuss about how to handle EOL announcements.
>
> * https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
>
> Jacques
>
> Le 04/01/2022 à 10:45, Jacopo Cappellato a écrit :
>> Thank you Jacques for adding the statement: however I think it is > time to remove the entire section of 17.12.08 since we have enough > releases
>> out of 18.12 already. The release 17.12.08 will always be >
> available in the archive. > > Jacopo
Re: [ofbiz-site] branch master updated: More information about security and EOL (End Of Life)
Posted by Jacques Le Roux <ja...@les7arts.com>.
I agree Jacopo,
Will you handle it?
I made those tiny changes after an answer Mark J. Cox made to Mark Thomas in a discussion I read on security-discuss@community.apache.org :
MT: <<We need to consider whether projects that are not releasing
regularly really are healthy. Could they realistically respond to a
security vulnerability in a reasonable time frame? If not, we need to
move them to the attic.>>
MC: <<And we need a clear way to communicate that, and EOL releases, to users so
they know the status of what they're using. There are quite a number of
examples where a project has responded to a vulnerability reporter that
some version is EOL but it's not been clear enough on their pages, nor any
real announcement ever having being made. We need a consistent policy on
what to do about vulnerabilities that come up in EOL versions, and when to
allocate them CVE names ('there's an unfixed issue in X") in order to help
users with scanning tools also notice when they're using out of date and
now insecure projects.>>
There are at least 340+ TLPs*. So I guess it becomes worrying for the ASF.
I don't think we are concerned by those worries. So was just a small effort in this direction.
I think though that we should discuss about how to handle EOL announcements.
* https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
Jacques
Le 04/01/2022 à 10:45, Jacopo Cappellato a écrit :
> Thank you Jacques for adding the statement: however I think it is > time to remove the entire section of 17.12.08 since we have enough > releases out of 18.12 already. The release 17.12.08 will always be >
available in the archive. > > Jacopo