You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by Mike Beckerle <mb...@apache.org> on 2021/12/15 13:02:49 UTC
Need to create daffodil 3.2.1 ?
I think we're going to need to create a Daffodil 3.2.1 release.
We have this current critical bug
https://issues.apache.org/jira/browse/DAFFODIL-2608 which is a flaw in
unparsing associated with a primary 3.2.0 feature. I'll take the blame
for inadequate testing there. I hope to work on this today.
There is also a urgent CVE about Log4J. The cybersecurity community,
which uses Daffodil quite a bit, is insisting on updates to software
using Log4J within 15 days. The update for this is already in the
3.3.0-SNAPSHOT branch.
There have been a number of other changes made on the 3.3.0-SNAPSHOT
branch since the official 3.2.0 release.
Are there any thoughts on whether we should just release
3.3.0-SNAPSHOT branch as 3.2.1, or whether we should fork from 3.2.0
and apply the minimum amount of fixes?
RE: [DISCUSS] release 3.2.1 - was: Re: Need to create daffodil 3.2.1 ?
Posted by "Interrante, John A (GE Research, US)" <Jo...@ge.com>.
Agreed, although let's base release 3.2.1 on git hash 5303d86fba8e9e1d3daa36fed405e507857fde1f, in order to eliminate another transitive dependency CVE (JDOM) as well as Mike's layering fix:
Update jdom2 to 2.0.6.1
#699 was merged 1 hour ago
Change layering to pass and use state
#707 was merged 2 hours ago
John
-----Original Message-----
From: Mike Beckerle <mb...@apache.org>
Sent: Wednesday, December 15, 2021 12:57 PM
To: dev@daffodil.apache.org
Subject: EXT: [DISCUSS] release 3.2.1 - was: Re: Need to create daffodil 3.2.1 ?
WARNING: This email originated from outside of GE. Please validate the sender's email address before clicking on links or attachments as they may not be safe.
Official discussion thread. Proposing release 3.2.1 based on git hash
b48db8d7f3ad20e7df7a1452793ac49686f8e119
This has the urgent log4j change, and fixes bug DAFFODIL-2608 which was a critical bug in 3.2.0.
On Wed, Dec 15, 2021 at 9:33 AM Interrante, John A (GE Research, US) <Jo...@ge.com> wrote:
>
> I agree too. Let's do the normal release workflow, only calling the release 3.2.1 instead of 3.3.0 because of how little time has passed since we released 3.2.0. In that period of time (9 days), we've merged 10 pull requests:
>
> Update sbt to 1.5.7
> #706 merged 9 minutes ago
>
> Update os-lib to 0.8.0
> #704 merged yesterday
>
> Update log4j-api, log4j-core to 2.16.0
> #705 merged yesterday
>
> Update log4j-api, log4j-core to 2.15.0
> #702 merged 5 days ago
>
> Update sbt to 1.5.6
> #703 merged 5 days ago
>
> Rename version.h to daffodil_version.h
> #701 merged 6 days ago
>
> Add test to illustrate checksum/layer bug
> #700 merged 6 days ago
>
> Use same version for both log4j-api and log4j-core
> #697 merged 9 days ago
>
> Ensure we use UTF-8 when outputting and comparing SAX output
> #696 merged 8 days ago
>
> setup for 3.3.0-SNAPSHOT development
> #695 merged 9 days ago
>
> All of these are relatively tiny safe changes except for the UTF-8 change (https://github.com/apache/daffodil/pull/696/files), and even that change shouldn't raise the risk of regressions very much (you can look at its changes yourself).
>
> John
>
> -----Original Message-----
> From: Steve Lawrence <sl...@apache.org>
> Sent: Wednesday, December 15, 2021 8:21 AM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: Need to create daffodil 3.2.1 ?
>
> WARNING: This email originated from outside of GE. Please validate the sender's email address before clicking on links or attachments as they may not be safe.
>
> I feel the changes to the main branch since v3.2.0 are small enough that the risk of regressions is pretty low. So I'd lean towards keeping things simple and base the 3.2.1 release off of the main branch without a fork.
>
> On 12/15/21 8:02 AM, Mike Beckerle wrote:
> > I think we're going to need to create a Daffodil 3.2.1 release.
> >
> > We have this current critical bug
> > https://issues.apache.org/jira/browse/DAFFODIL-2608 which is a flaw
> > in unparsing associated with a primary 3.2.0 feature. I'll take the
> > blame for inadequate testing there. I hope to work on this today.
> >
> > There is also a urgent CVE about Log4J. The cybersecurity community,
> > which uses Daffodil quite a bit, is insisting on updates to software
> > using Log4J within 15 days. The update for this is already in the
> > 3.3.0-SNAPSHOT branch.
> >
> > There have been a number of other changes made on the 3.3.0-SNAPSHOT
> > branch since the official 3.2.0 release.
> >
> > Are there any thoughts on whether we should just release
> > 3.3.0-SNAPSHOT branch as 3.2.1, or whether we should fork from 3.2.0
> > and apply the minimum amount of fixes?
> >
>
Re: [DISCUSS] release 3.2.1 - was: Re: Need to create daffodil 3.2.1 ?
Posted by Steve Lawrence <sl...@apache.org>.
Sounds good to me!
On 12/15/21 12:56 PM, Mike Beckerle wrote:
> Official discussion thread. Proposing release 3.2.1 based on git hash
> b48db8d7f3ad20e7df7a1452793ac49686f8e119
>
> This has the urgent log4j change, and fixes bug DAFFODIL-2608 which
> was a critical bug in 3.2.0.
>
> On Wed, Dec 15, 2021 at 9:33 AM Interrante, John A (GE Research, US)
> <Jo...@ge.com> wrote:
>>
>> I agree too. Let's do the normal release workflow, only calling the release 3.2.1 instead of 3.3.0 because of how little time has passed since we released 3.2.0. In that period of time (9 days), we've merged 10 pull requests:
>>
>> Update sbt to 1.5.7
>> #706 merged 9 minutes ago
>>
>> Update os-lib to 0.8.0
>> #704 merged yesterday
>>
>> Update log4j-api, log4j-core to 2.16.0
>> #705 merged yesterday
>>
>> Update log4j-api, log4j-core to 2.15.0
>> #702 merged 5 days ago
>>
>> Update sbt to 1.5.6
>> #703 merged 5 days ago
>>
>> Rename version.h to daffodil_version.h
>> #701 merged 6 days ago
>>
>> Add test to illustrate checksum/layer bug
>> #700 merged 6 days ago
>>
>> Use same version for both log4j-api and log4j-core
>> #697 merged 9 days ago
>>
>> Ensure we use UTF-8 when outputting and comparing SAX output
>> #696 merged 8 days ago
>>
>> setup for 3.3.0-SNAPSHOT development
>> #695 merged 9 days ago
>>
>> All of these are relatively tiny safe changes except for the UTF-8 change (https://github.com/apache/daffodil/pull/696/files), and even that change shouldn't raise the risk of regressions very much (you can look at its changes yourself).
>>
>> John
>>
>> -----Original Message-----
>> From: Steve Lawrence <sl...@apache.org>
>> Sent: Wednesday, December 15, 2021 8:21 AM
>> To: dev@daffodil.apache.org
>> Subject: EXT: Re: Need to create daffodil 3.2.1 ?
>>
>> WARNING: This email originated from outside of GE. Please validate the sender's email address before clicking on links or attachments as they may not be safe.
>>
>> I feel the changes to the main branch since v3.2.0 are small enough that the risk of regressions is pretty low. So I'd lean towards keeping things simple and base the 3.2.1 release off of the main branch without a fork.
>>
>> On 12/15/21 8:02 AM, Mike Beckerle wrote:
>>> I think we're going to need to create a Daffodil 3.2.1 release.
>>>
>>> We have this current critical bug
>>> https://issues.apache.org/jira/browse/DAFFODIL-2608 which is a flaw in
>>> unparsing associated with a primary 3.2.0 feature. I'll take the blame
>>> for inadequate testing there. I hope to work on this today.
>>>
>>> There is also a urgent CVE about Log4J. The cybersecurity community,
>>> which uses Daffodil quite a bit, is insisting on updates to software
>>> using Log4J within 15 days. The update for this is already in the
>>> 3.3.0-SNAPSHOT branch.
>>>
>>> There have been a number of other changes made on the 3.3.0-SNAPSHOT
>>> branch since the official 3.2.0 release.
>>>
>>> Are there any thoughts on whether we should just release
>>> 3.3.0-SNAPSHOT branch as 3.2.1, or whether we should fork from 3.2.0
>>> and apply the minimum amount of fixes?
>>>
>>
[DISCUSS] release 3.2.1 - was: Re: Need to create daffodil 3.2.1 ?
Posted by Mike Beckerle <mb...@apache.org>.
Official discussion thread. Proposing release 3.2.1 based on git hash
b48db8d7f3ad20e7df7a1452793ac49686f8e119
This has the urgent log4j change, and fixes bug DAFFODIL-2608 which
was a critical bug in 3.2.0.
On Wed, Dec 15, 2021 at 9:33 AM Interrante, John A (GE Research, US)
<Jo...@ge.com> wrote:
>
> I agree too. Let's do the normal release workflow, only calling the release 3.2.1 instead of 3.3.0 because of how little time has passed since we released 3.2.0. In that period of time (9 days), we've merged 10 pull requests:
>
> Update sbt to 1.5.7
> #706 merged 9 minutes ago
>
> Update os-lib to 0.8.0
> #704 merged yesterday
>
> Update log4j-api, log4j-core to 2.16.0
> #705 merged yesterday
>
> Update log4j-api, log4j-core to 2.15.0
> #702 merged 5 days ago
>
> Update sbt to 1.5.6
> #703 merged 5 days ago
>
> Rename version.h to daffodil_version.h
> #701 merged 6 days ago
>
> Add test to illustrate checksum/layer bug
> #700 merged 6 days ago
>
> Use same version for both log4j-api and log4j-core
> #697 merged 9 days ago
>
> Ensure we use UTF-8 when outputting and comparing SAX output
> #696 merged 8 days ago
>
> setup for 3.3.0-SNAPSHOT development
> #695 merged 9 days ago
>
> All of these are relatively tiny safe changes except for the UTF-8 change (https://github.com/apache/daffodil/pull/696/files), and even that change shouldn't raise the risk of regressions very much (you can look at its changes yourself).
>
> John
>
> -----Original Message-----
> From: Steve Lawrence <sl...@apache.org>
> Sent: Wednesday, December 15, 2021 8:21 AM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: Need to create daffodil 3.2.1 ?
>
> WARNING: This email originated from outside of GE. Please validate the sender's email address before clicking on links or attachments as they may not be safe.
>
> I feel the changes to the main branch since v3.2.0 are small enough that the risk of regressions is pretty low. So I'd lean towards keeping things simple and base the 3.2.1 release off of the main branch without a fork.
>
> On 12/15/21 8:02 AM, Mike Beckerle wrote:
> > I think we're going to need to create a Daffodil 3.2.1 release.
> >
> > We have this current critical bug
> > https://issues.apache.org/jira/browse/DAFFODIL-2608 which is a flaw in
> > unparsing associated with a primary 3.2.0 feature. I'll take the blame
> > for inadequate testing there. I hope to work on this today.
> >
> > There is also a urgent CVE about Log4J. The cybersecurity community,
> > which uses Daffodil quite a bit, is insisting on updates to software
> > using Log4J within 15 days. The update for this is already in the
> > 3.3.0-SNAPSHOT branch.
> >
> > There have been a number of other changes made on the 3.3.0-SNAPSHOT
> > branch since the official 3.2.0 release.
> >
> > Are there any thoughts on whether we should just release
> > 3.3.0-SNAPSHOT branch as 3.2.1, or whether we should fork from 3.2.0
> > and apply the minimum amount of fixes?
> >
>
Need to create daffodil 3.2.1 ?
Posted by "Interrante, John A (GE Research, US)" <Jo...@ge.com>.
I agree too. Let's do the normal release workflow, only calling the release 3.2.1 instead of 3.3.0 because of how little time has passed since we released 3.2.0. In that period of time (9 days), we've merged 10 pull requests:
Update sbt to 1.5.7
#706 merged 9 minutes ago
Update os-lib to 0.8.0
#704 merged yesterday
Update log4j-api, log4j-core to 2.16.0
#705 merged yesterday
Update log4j-api, log4j-core to 2.15.0
#702 merged 5 days ago
Update sbt to 1.5.6
#703 merged 5 days ago
Rename version.h to daffodil_version.h
#701 merged 6 days ago
Add test to illustrate checksum/layer bug
#700 merged 6 days ago
Use same version for both log4j-api and log4j-core
#697 merged 9 days ago
Ensure we use UTF-8 when outputting and comparing SAX output
#696 merged 8 days ago
setup for 3.3.0-SNAPSHOT development
#695 merged 9 days ago
All of these are relatively tiny safe changes except for the UTF-8 change (https://github.com/apache/daffodil/pull/696/files), and even that change shouldn't raise the risk of regressions very much (you can look at its changes yourself).
John
-----Original Message-----
From: Steve Lawrence <sl...@apache.org>
Sent: Wednesday, December 15, 2021 8:21 AM
To: dev@daffodil.apache.org
Subject: EXT: Re: Need to create daffodil 3.2.1 ?
WARNING: This email originated from outside of GE. Please validate the sender's email address before clicking on links or attachments as they may not be safe.
I feel the changes to the main branch since v3.2.0 are small enough that the risk of regressions is pretty low. So I'd lean towards keeping things simple and base the 3.2.1 release off of the main branch without a fork.
On 12/15/21 8:02 AM, Mike Beckerle wrote:
> I think we're going to need to create a Daffodil 3.2.1 release.
>
> We have this current critical bug
> https://issues.apache.org/jira/browse/DAFFODIL-2608 which is a flaw in
> unparsing associated with a primary 3.2.0 feature. I'll take the blame
> for inadequate testing there. I hope to work on this today.
>
> There is also a urgent CVE about Log4J. The cybersecurity community,
> which uses Daffodil quite a bit, is insisting on updates to software
> using Log4J within 15 days. The update for this is already in the
> 3.3.0-SNAPSHOT branch.
>
> There have been a number of other changes made on the 3.3.0-SNAPSHOT
> branch since the official 3.2.0 release.
>
> Are there any thoughts on whether we should just release
> 3.3.0-SNAPSHOT branch as 3.2.1, or whether we should fork from 3.2.0
> and apply the minimum amount of fixes?
>
RE: Need to create daffodil 3.2.1 ?
Posted by "Sood, Harinder" <hs...@owlcyberdefense.com>.
To adhere to configuration management paradigm, it may be good to fork off 3.2.
The information contained in this transmission is for the personal and confidential use of the individual or entity to which it is addressed. If the reader is not the intended recipient, you are hereby notified that any review, dissemination, or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify the sender immediately
-----Original Message-----
From: Steve Lawrence <sl...@apache.org>
Sent: Wednesday, December 15, 2021 8:21 AM
To: dev@daffodil.apache.org
Subject: Re: Need to create daffodil 3.2.1 ?
I feel the changes to the main branch since v3.2.0 are small enough that the risk of regressions is pretty low. So I'd lean towards keeping things simple and base the 3.2.1 release off of the main branch without a fork.
On 12/15/21 8:02 AM, Mike Beckerle wrote:
> I think we're going to need to create a Daffodil 3.2.1 release.
>
> We have this current critical bug
> https://issues.apache.org/jira/browse/DAFFODIL-2608 which is a flaw in
> unparsing associated with a primary 3.2.0 feature. I'll take the blame
> for inadequate testing there. I hope to work on this today.
>
> There is also a urgent CVE about Log4J. The cybersecurity community,
> which uses Daffodil quite a bit, is insisting on updates to software
> using Log4J within 15 days. The update for this is already in the
> 3.3.0-SNAPSHOT branch.
>
> There have been a number of other changes made on the 3.3.0-SNAPSHOT
> branch since the official 3.2.0 release.
>
> Are there any thoughts on whether we should just release
> 3.3.0-SNAPSHOT branch as 3.2.1, or whether we should fork from 3.2.0
> and apply the minimum amount of fixes?
>
Re: Need to create daffodil 3.2.1 ?
Posted by Steve Lawrence <sl...@apache.org>.
I feel the changes to the main branch since v3.2.0 are small enough that
the risk of regressions is pretty low. So I'd lean towards keeping
things simple and base the 3.2.1 release off of the main branch without
a fork.
On 12/15/21 8:02 AM, Mike Beckerle wrote:
> I think we're going to need to create a Daffodil 3.2.1 release.
>
> We have this current critical bug
> https://issues.apache.org/jira/browse/DAFFODIL-2608 which is a flaw in
> unparsing associated with a primary 3.2.0 feature. I'll take the blame
> for inadequate testing there. I hope to work on this today.
>
> There is also a urgent CVE about Log4J. The cybersecurity community,
> which uses Daffodil quite a bit, is insisting on updates to software
> using Log4J within 15 days. The update for this is already in the
> 3.3.0-SNAPSHOT branch.
>
> There have been a number of other changes made on the 3.3.0-SNAPSHOT
> branch since the official 3.2.0 release.
>
> Are there any thoughts on whether we should just release
> 3.3.0-SNAPSHOT branch as 3.2.1, or whether we should fork from 3.2.0
> and apply the minimum amount of fixes?
>