You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Dominic Barnes <do...@twilio.com.INVALID> on 2022/06/09 21:06:36 UTC
Patch release for Go libraries to address CVE-2022-28948
Howdy!
I'm a first-time contributor, and I just opened a PR to update a dev/test
dependency (github.com/stretchr/testify) to address a security
vulnerability being reported downstream:
https://github.com/apache/arrow/pull/13322 (more context included here)
The PR was originally opened against the release-v7.0.0 branch, but I was
then pointed towards using master instead, with the intention of
backporting the commit/change for v6.0.2, v7.0.1 and v8.0.1 releases.
While not merged yet, it sounded like I should get the ball rolling now.
Let me know how I can help get this across the finish line.
--
Dominic Barnes
he/him/his
Staff Software Engineer
[image: Twilio] <https://www.twilio.com/?utm_source=email_signature>
EMAIL dobarnes@twilio.com
TWITTER @mako281 <https://twitter.com/mako281>
GITHUB dominicbarnes <https://github.com/dominicbarnes>
Re: Patch release for Go libraries to address CVE-2022-28948
Posted by Dominic Barnes <do...@twilio.com.INVALID>.
Just following up on this, the PR has been merged for v9, but I still need
the patch backported to v6, v7 and v8.
If there's anything I can do to help get that over the finish line, let me
know. Thanks again!
On Thu, Jun 9, 2022 at 2:06 PM Dominic Barnes <do...@twilio.com> wrote:
> Howdy!
>
> I'm a first-time contributor, and I just opened a PR to update a dev/test
> dependency (github.com/stretchr/testify) to address a security
> vulnerability being reported downstream:
>
> https://github.com/apache/arrow/pull/13322 (more context included here)
>
> The PR was originally opened against the release-v7.0.0 branch, but I was
> then pointed towards using master instead, with the intention of
> backporting the commit/change for v6.0.2, v7.0.1 and v8.0.1 releases.
>
> While not merged yet, it sounded like I should get the ball rolling now.
> Let me know how I can help get this across the finish line.
>
> --
> Dominic Barnes
>
> he/him/his
> Staff Software Engineer
> [image: Twilio] <https://www.twilio.com/?utm_source=email_signature>
> EMAIL dobarnes@twilio.com
> TWITTER @mako281 <https://twitter.com/mako281>
> GITHUB dominicbarnes <https://github.com/dominicbarnes>
>
Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
It seems that there are no objections for this release plan.
I've prepared 6.0.2, 7.0.1 and 8.0.1. I'll start votes for
them.
Thanks,
--
kou
In <20...@clear-code.com>
"Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948" on Fri, 08 Jul 2022 11:01:01 +0900 (JST),
Sutou Kouhei <ko...@clear-code.com> wrote:
> Hi,
>
> It seems that there are no objections for these patch releases.
>
> I'll initiate these patch releases. Here is my plan. If
> there are any objections/concerns, please share them.
>
> * We'll release 6.0.2, 7.0.1 and 8.0.1
> * These releases only include
> https://github.com/apache/arrow/pull/13322
> * We'll create apache-arrow-6.0.2.tar.gz,
> apache-arrow-7.0.1.tar.gz and
> apache-arrow-8.0.1.tar.gz as usual
> * These tar.gz include not only go/ but also all languages
> in apache/arrow to reuse the current release script
> * We'll not create binary artifacts for 6.0.2, 7.0.1 and
> 8.0.1 because we don't have binary artifacts relate to Go
> * We'll start votes for releasing 6.0.2, 7.0.1 and 8.0.1
>
>
> Thanks,
> --
> kou
>
> In <CA...@mail.gmail.com>
> "Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948" on Mon, 13 Jun 2022 19:24:16 -0400,
> Matt Topol <zo...@gmail.com> wrote:
>
>>> I'm also not an expert but I think that we need to "release"
>>> (vote) a patch version. (I think that just doing "git tag"
>>> isn't suitable.)
>>
>> I was figuring there would need to be a vote, and as I'm not part of the
>> PMC I didn't know whether it was my place to attempt to call such a vote.
>> :) Would we need three separate votes? (One for v6.0.2, v.7.0.1, and one
>> for v8.0.1)
>>
>>> We can't mark 8.0.1 as official unless we "release" 8.0.1.
>>
>> Can we *just* "release" the Go patch releases (like the arrow-rs rust
>> library seems to be doing)? Or do we need to fully release all the
>> languages for consistency (which is what I assume is the case)?
>>
>>> Again, I'm also not an expert. I hope that others comment on
>>> this too.
>>
>> Same. This isn't exactly something I can pretend to be very familiar with
>> particularly as a policy decision. Hopefully others will comment and
>> respond to this.
>>
>> --Matt
>>
>> On Sun, Jun 12, 2022 at 10:06 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>>
>>> Hi,
>>>
>>> I'm also not an expert but I think that we need to "release"
>>> (vote) a patch version. (I think that just doing "git tag"
>>> isn't suitable.)
>>>
>>> Because we need to "release" to announce users to use
>>> "go/v8.0.1" rather than "go/v8.0.0":
>>>
>>> https://www.apache.org/legal/release-policy.html#publication
>>>
>>> > Projects SHALL publish official releases and SHALL NOT
>>> > publish unreleased materials outside the development
>>> > community.
>>>
>>> We can't mark 8.0.1 as official unless we "release" 8.0.1.
>>>
>>> (I understand that Go doesn't need released materials. Go
>>> just needs a Git tag. I understand that the ASF's release
>>> policy isn't suitable for recent languages such as Go and
>>> Julia. Micah started a discussion it in another place. The
>>> ASF's release policy may be updated in future.)
>>>
>>>
>>> But we don't need to release binary artifacts because we
>>> don't have any binary artifacts for Go. We can just release
>>> a source archive for patch releases of this.
>>>
>>>
>>> Again, I'm also not an expert. I hope that others comment on
>>> this too.
>>>
>>>
>>> Thanks,
>>> --
>>> kou
>>>
>>> In <CA...@mail.gmail.com>
>>> "Re: [Go][Release][Discussion] Patch release for Go libraries to address
>>> CVE-2022-28948" on Fri, 10 Jun 2022 11:43:26 -0400,
>>> Neal Richardson <ne...@gmail.com> wrote:
>>>
>>> > Personally, I don't have a problem with doing `git tag` just for Go. I
>>> > don't think this needs a full patch release process since we aren't
>>> > producing new artifacts that need signing, we're only adding a tag that
>>> > points to a SHA in git. But I am not an expert in this area of policy and
>>> > will defer to others who know better.
>>> >
>>> > Neal
>>> >
>>> >
>>> > On Fri, Jun 10, 2022 at 11:07 AM Matt Topol <zo...@gmail.com>
>>> wrote:
>>> >
>>> >> I've merged the PR to master and want to propose cherry-picking it to
>>> >> create patch releases. Technically, for Go, all we need to do is create
>>> the
>>> >> appropriate tags named like "go/v6.0.2", and so on. Since this
>>> >> vulnerability only affects Go we don't necessarily need to release
>>> patches
>>> >> for the other language libraries other than for consistency.
>>> >>
>>> >> So I guess I'd like others to chime in on opinions as to whether we
>>> should
>>> >> just cherry-pick and create the tags just for patch releases for Go or
>>> do
>>> >> full patch releases of everything for consistency.
>>> >>
>>> >> --Matt
>>> >>
>>> >> On Thu, Jun 9, 2022 at 5:21 PM Dominic Barnes
>>> <dobarnes@twilio.com.invalid
>>> >> >
>>> >> wrote:
>>> >>
>>> >> > Howdy!
>>> >> >
>>> >> > I'm a first-time contributor, and I just opened a PR to update a
>>> dev/test
>>> >> > dependency (github.com/stretchr/testify) to address a security
>>> >> > vulnerability being reported downstream:
>>> >> >
>>> >> > https://github.com/apache/arrow/pull/13322 (more context included
>>> here)
>>> >> >
>>> >> > The PR was originally opened against the release-v7.0.0 branch, but I
>>> was
>>> >> > then pointed towards using master instead, with the intention of
>>> >> > backporting the commit/change for v6.0.2, v7.0.1 and v8.0.1 releases.
>>> >> >
>>> >> > While not merged yet, it sounded like I should get the ball rolling
>>> now.
>>> >> > Let me know how I can help get this across the finish line.
>>> >> >
>>> >> > --
>>> >> > Dominic Barnes
>>> >> >
>>> >> > he/him/his
>>> >> > Staff Software Engineer
>>> >> > [image: Twilio] <https://www.twilio.com/?utm_source=email_signature>
>>> >> > EMAIL dobarnes@twilio.com
>>> >> > TWITTER @mako281 <https://twitter.com/mako281>
>>> >> > GITHUB dominicbarnes <https://github.com/dominicbarnes>
>>> >> >
>>> >>
>>>
Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
It seems that there are no objections for these patch releases.
I'll initiate these patch releases. Here is my plan. If
there are any objections/concerns, please share them.
* We'll release 6.0.2, 7.0.1 and 8.0.1
* These releases only include
https://github.com/apache/arrow/pull/13322
* We'll create apache-arrow-6.0.2.tar.gz,
apache-arrow-7.0.1.tar.gz and
apache-arrow-8.0.1.tar.gz as usual
* These tar.gz include not only go/ but also all languages
in apache/arrow to reuse the current release script
* We'll not create binary artifacts for 6.0.2, 7.0.1 and
8.0.1 because we don't have binary artifacts relate to Go
* We'll start votes for releasing 6.0.2, 7.0.1 and 8.0.1
Thanks,
--
kou
In <CA...@mail.gmail.com>
"Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948" on Mon, 13 Jun 2022 19:24:16 -0400,
Matt Topol <zo...@gmail.com> wrote:
>> I'm also not an expert but I think that we need to "release"
>> (vote) a patch version. (I think that just doing "git tag"
>> isn't suitable.)
>
> I was figuring there would need to be a vote, and as I'm not part of the
> PMC I didn't know whether it was my place to attempt to call such a vote.
> :) Would we need three separate votes? (One for v6.0.2, v.7.0.1, and one
> for v8.0.1)
>
>> We can't mark 8.0.1 as official unless we "release" 8.0.1.
>
> Can we *just* "release" the Go patch releases (like the arrow-rs rust
> library seems to be doing)? Or do we need to fully release all the
> languages for consistency (which is what I assume is the case)?
>
>> Again, I'm also not an expert. I hope that others comment on
>> this too.
>
> Same. This isn't exactly something I can pretend to be very familiar with
> particularly as a policy decision. Hopefully others will comment and
> respond to this.
>
> --Matt
>
> On Sun, Jun 12, 2022 at 10:06 PM Sutou Kouhei <ko...@clear-code.com> wrote:
>
>> Hi,
>>
>> I'm also not an expert but I think that we need to "release"
>> (vote) a patch version. (I think that just doing "git tag"
>> isn't suitable.)
>>
>> Because we need to "release" to announce users to use
>> "go/v8.0.1" rather than "go/v8.0.0":
>>
>> https://www.apache.org/legal/release-policy.html#publication
>>
>> > Projects SHALL publish official releases and SHALL NOT
>> > publish unreleased materials outside the development
>> > community.
>>
>> We can't mark 8.0.1 as official unless we "release" 8.0.1.
>>
>> (I understand that Go doesn't need released materials. Go
>> just needs a Git tag. I understand that the ASF's release
>> policy isn't suitable for recent languages such as Go and
>> Julia. Micah started a discussion it in another place. The
>> ASF's release policy may be updated in future.)
>>
>>
>> But we don't need to release binary artifacts because we
>> don't have any binary artifacts for Go. We can just release
>> a source archive for patch releases of this.
>>
>>
>> Again, I'm also not an expert. I hope that others comment on
>> this too.
>>
>>
>> Thanks,
>> --
>> kou
>>
>> In <CA...@mail.gmail.com>
>> "Re: [Go][Release][Discussion] Patch release for Go libraries to address
>> CVE-2022-28948" on Fri, 10 Jun 2022 11:43:26 -0400,
>> Neal Richardson <ne...@gmail.com> wrote:
>>
>> > Personally, I don't have a problem with doing `git tag` just for Go. I
>> > don't think this needs a full patch release process since we aren't
>> > producing new artifacts that need signing, we're only adding a tag that
>> > points to a SHA in git. But I am not an expert in this area of policy and
>> > will defer to others who know better.
>> >
>> > Neal
>> >
>> >
>> > On Fri, Jun 10, 2022 at 11:07 AM Matt Topol <zo...@gmail.com>
>> wrote:
>> >
>> >> I've merged the PR to master and want to propose cherry-picking it to
>> >> create patch releases. Technically, for Go, all we need to do is create
>> the
>> >> appropriate tags named like "go/v6.0.2", and so on. Since this
>> >> vulnerability only affects Go we don't necessarily need to release
>> patches
>> >> for the other language libraries other than for consistency.
>> >>
>> >> So I guess I'd like others to chime in on opinions as to whether we
>> should
>> >> just cherry-pick and create the tags just for patch releases for Go or
>> do
>> >> full patch releases of everything for consistency.
>> >>
>> >> --Matt
>> >>
>> >> On Thu, Jun 9, 2022 at 5:21 PM Dominic Barnes
>> <dobarnes@twilio.com.invalid
>> >> >
>> >> wrote:
>> >>
>> >> > Howdy!
>> >> >
>> >> > I'm a first-time contributor, and I just opened a PR to update a
>> dev/test
>> >> > dependency (github.com/stretchr/testify) to address a security
>> >> > vulnerability being reported downstream:
>> >> >
>> >> > https://github.com/apache/arrow/pull/13322 (more context included
>> here)
>> >> >
>> >> > The PR was originally opened against the release-v7.0.0 branch, but I
>> was
>> >> > then pointed towards using master instead, with the intention of
>> >> > backporting the commit/change for v6.0.2, v7.0.1 and v8.0.1 releases.
>> >> >
>> >> > While not merged yet, it sounded like I should get the ball rolling
>> now.
>> >> > Let me know how I can help get this across the finish line.
>> >> >
>> >> > --
>> >> > Dominic Barnes
>> >> >
>> >> > he/him/his
>> >> > Staff Software Engineer
>> >> > [image: Twilio] <https://www.twilio.com/?utm_source=email_signature>
>> >> > EMAIL dobarnes@twilio.com
>> >> > TWITTER @mako281 <https://twitter.com/mako281>
>> >> > GITHUB dominicbarnes <https://github.com/dominicbarnes>
>> >> >
>> >>
>>
Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948
Posted by Matt Topol <zo...@gmail.com>.
> I'm also not an expert but I think that we need to "release"
> (vote) a patch version. (I think that just doing "git tag"
> isn't suitable.)
I was figuring there would need to be a vote, and as I'm not part of the
PMC I didn't know whether it was my place to attempt to call such a vote.
:) Would we need three separate votes? (One for v6.0.2, v.7.0.1, and one
for v8.0.1)
> We can't mark 8.0.1 as official unless we "release" 8.0.1.
Can we *just* "release" the Go patch releases (like the arrow-rs rust
library seems to be doing)? Or do we need to fully release all the
languages for consistency (which is what I assume is the case)?
> Again, I'm also not an expert. I hope that others comment on
> this too.
Same. This isn't exactly something I can pretend to be very familiar with
particularly as a policy decision. Hopefully others will comment and
respond to this.
--Matt
On Sun, Jun 12, 2022 at 10:06 PM Sutou Kouhei <ko...@clear-code.com> wrote:
> Hi,
>
> I'm also not an expert but I think that we need to "release"
> (vote) a patch version. (I think that just doing "git tag"
> isn't suitable.)
>
> Because we need to "release" to announce users to use
> "go/v8.0.1" rather than "go/v8.0.0":
>
> https://www.apache.org/legal/release-policy.html#publication
>
> > Projects SHALL publish official releases and SHALL NOT
> > publish unreleased materials outside the development
> > community.
>
> We can't mark 8.0.1 as official unless we "release" 8.0.1.
>
> (I understand that Go doesn't need released materials. Go
> just needs a Git tag. I understand that the ASF's release
> policy isn't suitable for recent languages such as Go and
> Julia. Micah started a discussion it in another place. The
> ASF's release policy may be updated in future.)
>
>
> But we don't need to release binary artifacts because we
> don't have any binary artifacts for Go. We can just release
> a source archive for patch releases of this.
>
>
> Again, I'm also not an expert. I hope that others comment on
> this too.
>
>
> Thanks,
> --
> kou
>
> In <CA...@mail.gmail.com>
> "Re: [Go][Release][Discussion] Patch release for Go libraries to address
> CVE-2022-28948" on Fri, 10 Jun 2022 11:43:26 -0400,
> Neal Richardson <ne...@gmail.com> wrote:
>
> > Personally, I don't have a problem with doing `git tag` just for Go. I
> > don't think this needs a full patch release process since we aren't
> > producing new artifacts that need signing, we're only adding a tag that
> > points to a SHA in git. But I am not an expert in this area of policy and
> > will defer to others who know better.
> >
> > Neal
> >
> >
> > On Fri, Jun 10, 2022 at 11:07 AM Matt Topol <zo...@gmail.com>
> wrote:
> >
> >> I've merged the PR to master and want to propose cherry-picking it to
> >> create patch releases. Technically, for Go, all we need to do is create
> the
> >> appropriate tags named like "go/v6.0.2", and so on. Since this
> >> vulnerability only affects Go we don't necessarily need to release
> patches
> >> for the other language libraries other than for consistency.
> >>
> >> So I guess I'd like others to chime in on opinions as to whether we
> should
> >> just cherry-pick and create the tags just for patch releases for Go or
> do
> >> full patch releases of everything for consistency.
> >>
> >> --Matt
> >>
> >> On Thu, Jun 9, 2022 at 5:21 PM Dominic Barnes
> <dobarnes@twilio.com.invalid
> >> >
> >> wrote:
> >>
> >> > Howdy!
> >> >
> >> > I'm a first-time contributor, and I just opened a PR to update a
> dev/test
> >> > dependency (github.com/stretchr/testify) to address a security
> >> > vulnerability being reported downstream:
> >> >
> >> > https://github.com/apache/arrow/pull/13322 (more context included
> here)
> >> >
> >> > The PR was originally opened against the release-v7.0.0 branch, but I
> was
> >> > then pointed towards using master instead, with the intention of
> >> > backporting the commit/change for v6.0.2, v7.0.1 and v8.0.1 releases.
> >> >
> >> > While not merged yet, it sounded like I should get the ball rolling
> now.
> >> > Let me know how I can help get this across the finish line.
> >> >
> >> > --
> >> > Dominic Barnes
> >> >
> >> > he/him/his
> >> > Staff Software Engineer
> >> > [image: Twilio] <https://www.twilio.com/?utm_source=email_signature>
> >> > EMAIL dobarnes@twilio.com
> >> > TWITTER @mako281 <https://twitter.com/mako281>
> >> > GITHUB dominicbarnes <https://github.com/dominicbarnes>
> >> >
> >>
>
Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948
Posted by Sutou Kouhei <ko...@clear-code.com>.
Hi,
I'm also not an expert but I think that we need to "release"
(vote) a patch version. (I think that just doing "git tag"
isn't suitable.)
Because we need to "release" to announce users to use
"go/v8.0.1" rather than "go/v8.0.0":
https://www.apache.org/legal/release-policy.html#publication
> Projects SHALL publish official releases and SHALL NOT
> publish unreleased materials outside the development
> community.
We can't mark 8.0.1 as official unless we "release" 8.0.1.
(I understand that Go doesn't need released materials. Go
just needs a Git tag. I understand that the ASF's release
policy isn't suitable for recent languages such as Go and
Julia. Micah started a discussion it in another place. The
ASF's release policy may be updated in future.)
But we don't need to release binary artifacts because we
don't have any binary artifacts for Go. We can just release
a source archive for patch releases of this.
Again, I'm also not an expert. I hope that others comment on
this too.
Thanks,
--
kou
In <CA...@mail.gmail.com>
"Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948" on Fri, 10 Jun 2022 11:43:26 -0400,
Neal Richardson <ne...@gmail.com> wrote:
> Personally, I don't have a problem with doing `git tag` just for Go. I
> don't think this needs a full patch release process since we aren't
> producing new artifacts that need signing, we're only adding a tag that
> points to a SHA in git. But I am not an expert in this area of policy and
> will defer to others who know better.
>
> Neal
>
>
> On Fri, Jun 10, 2022 at 11:07 AM Matt Topol <zo...@gmail.com> wrote:
>
>> I've merged the PR to master and want to propose cherry-picking it to
>> create patch releases. Technically, for Go, all we need to do is create the
>> appropriate tags named like "go/v6.0.2", and so on. Since this
>> vulnerability only affects Go we don't necessarily need to release patches
>> for the other language libraries other than for consistency.
>>
>> So I guess I'd like others to chime in on opinions as to whether we should
>> just cherry-pick and create the tags just for patch releases for Go or do
>> full patch releases of everything for consistency.
>>
>> --Matt
>>
>> On Thu, Jun 9, 2022 at 5:21 PM Dominic Barnes <dobarnes@twilio.com.invalid
>> >
>> wrote:
>>
>> > Howdy!
>> >
>> > I'm a first-time contributor, and I just opened a PR to update a dev/test
>> > dependency (github.com/stretchr/testify) to address a security
>> > vulnerability being reported downstream:
>> >
>> > https://github.com/apache/arrow/pull/13322 (more context included here)
>> >
>> > The PR was originally opened against the release-v7.0.0 branch, but I was
>> > then pointed towards using master instead, with the intention of
>> > backporting the commit/change for v6.0.2, v7.0.1 and v8.0.1 releases.
>> >
>> > While not merged yet, it sounded like I should get the ball rolling now.
>> > Let me know how I can help get this across the finish line.
>> >
>> > --
>> > Dominic Barnes
>> >
>> > he/him/his
>> > Staff Software Engineer
>> > [image: Twilio] <https://www.twilio.com/?utm_source=email_signature>
>> > EMAIL dobarnes@twilio.com
>> > TWITTER @mako281 <https://twitter.com/mako281>
>> > GITHUB dominicbarnes <https://github.com/dominicbarnes>
>> >
>>
Re: [Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948
Posted by Neal Richardson <ne...@gmail.com>.
Personally, I don't have a problem with doing `git tag` just for Go. I
don't think this needs a full patch release process since we aren't
producing new artifacts that need signing, we're only adding a tag that
points to a SHA in git. But I am not an expert in this area of policy and
will defer to others who know better.
Neal
On Fri, Jun 10, 2022 at 11:07 AM Matt Topol <zo...@gmail.com> wrote:
> I've merged the PR to master and want to propose cherry-picking it to
> create patch releases. Technically, for Go, all we need to do is create the
> appropriate tags named like "go/v6.0.2", and so on. Since this
> vulnerability only affects Go we don't necessarily need to release patches
> for the other language libraries other than for consistency.
>
> So I guess I'd like others to chime in on opinions as to whether we should
> just cherry-pick and create the tags just for patch releases for Go or do
> full patch releases of everything for consistency.
>
> --Matt
>
> On Thu, Jun 9, 2022 at 5:21 PM Dominic Barnes <dobarnes@twilio.com.invalid
> >
> wrote:
>
> > Howdy!
> >
> > I'm a first-time contributor, and I just opened a PR to update a dev/test
> > dependency (github.com/stretchr/testify) to address a security
> > vulnerability being reported downstream:
> >
> > https://github.com/apache/arrow/pull/13322 (more context included here)
> >
> > The PR was originally opened against the release-v7.0.0 branch, but I was
> > then pointed towards using master instead, with the intention of
> > backporting the commit/change for v6.0.2, v7.0.1 and v8.0.1 releases.
> >
> > While not merged yet, it sounded like I should get the ball rolling now.
> > Let me know how I can help get this across the finish line.
> >
> > --
> > Dominic Barnes
> >
> > he/him/his
> > Staff Software Engineer
> > [image: Twilio] <https://www.twilio.com/?utm_source=email_signature>
> > EMAIL dobarnes@twilio.com
> > TWITTER @mako281 <https://twitter.com/mako281>
> > GITHUB dominicbarnes <https://github.com/dominicbarnes>
> >
>
[Go][Release][Discussion] Patch release for Go libraries to address CVE-2022-28948
Posted by Matt Topol <zo...@gmail.com>.
I've merged the PR to master and want to propose cherry-picking it to
create patch releases. Technically, for Go, all we need to do is create the
appropriate tags named like "go/v6.0.2", and so on. Since this
vulnerability only affects Go we don't necessarily need to release patches
for the other language libraries other than for consistency.
So I guess I'd like others to chime in on opinions as to whether we should
just cherry-pick and create the tags just for patch releases for Go or do
full patch releases of everything for consistency.
--Matt
On Thu, Jun 9, 2022 at 5:21 PM Dominic Barnes <do...@twilio.com.invalid>
wrote:
> Howdy!
>
> I'm a first-time contributor, and I just opened a PR to update a dev/test
> dependency (github.com/stretchr/testify) to address a security
> vulnerability being reported downstream:
>
> https://github.com/apache/arrow/pull/13322 (more context included here)
>
> The PR was originally opened against the release-v7.0.0 branch, but I was
> then pointed towards using master instead, with the intention of
> backporting the commit/change for v6.0.2, v7.0.1 and v8.0.1 releases.
>
> While not merged yet, it sounded like I should get the ball rolling now.
> Let me know how I can help get this across the finish line.
>
> --
> Dominic Barnes
>
> he/him/his
> Staff Software Engineer
> [image: Twilio] <https://www.twilio.com/?utm_source=email_signature>
> EMAIL dobarnes@twilio.com
> TWITTER @mako281 <https://twitter.com/mako281>
> GITHUB dominicbarnes <https://github.com/dominicbarnes>
>