[core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)

[core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)

[Leo Famulari]

See <https://issues.guix.gnu.org/issue/49817>, which was never applied
anywhere. Like I said in that thread, I no longer understand the patch,
but I guess it's enough to update libsndfile to 1.1.0 on core-updates.

Re: [core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Leo,

On Tue, Apr 4, 2023 at 7:49 PM Leo Famulari <leo@famulari.name> wrote:
>
> See <https://issues.guix.gnu.org/issue/49817>, which was never applied
> anywhere.

According to the Debian Bug for this issue [1] the upstream commit
with the fix is here. [2]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991496#5
[2] https://github.com/libsndfile/libsndfile/commit/deb669ee8be55a94565f6f8a6b60890c2e7c6f32

> I guess it's enough to update libsndfile to 1.1.0 on core-updates.

The upstream commit [2] shows that the issue was fixed in libsndfile's
master branch as part of their merge request #713, which made it into
these versions:

1.2.0
1.1.0
1.1.0beta2
1.1.0beta1

It may therefore be better to upgrade directly to 1.2.0, except I
think there was an understanding that no new features should be
allowed on our core-updates branch at this time.

In that context, I will mention that Repology shows Guix as shipping a
defective version [3] while NIST scored the vulnerability as "8.8
HIGH" [4] although we seem to have company.

Kind regards
Felix Lechner

[3] https://repology.org/project/libsndfile/versions
[4] https://nvd.nist.gov/vuln/detail/CVE-2021-3246

Re: [core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)

[Josselin Poiret]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

Hi everyone,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> writes:

> Hi Leo,
>
> On Tue, Apr 4, 2023 at 7:49 PM Leo Famulari <leo@famulari.name> wrote:
>>
>> See <https://issues.guix.gnu.org/issue/49817>, which was never applied
>> anywhere.
>
> According to the Debian Bug for this issue [1] the upstream commit
> with the fix is here. [2]
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991496#5
> [2] https://github.com/libsndfile/libsndfile/commit/deb669ee8be55a94565f6f8a6b60890c2e7c6f32
>
>> I guess it's enough to update libsndfile to 1.1.0 on core-updates.
>
> The upstream commit [2] shows that the issue was fixed in libsndfile's
> master branch as part of their merge request #713, which made it into
> these versions:
>
> 1.2.0
> 1.1.0
> 1.1.0beta2
> 1.1.0beta1
>
> It may therefore be better to upgrade directly to 1.2.0, except I
> think there was an understanding that no new features should be
> allowed on our core-updates branch at this time.
>
> In that context, I will mention that Repology shows Guix as shipping a
> defective version [3] while NIST scored the vulnerability as "8.8
> HIGH" [4] although we seem to have company.
>
> Kind regards
> Felix Lechner
>
> [3] https://repology.org/project/libsndfile/versions
> [4] https://nvd.nist.gov/vuln/detail/CVE-2021-3246

Maybe we could graft it on master, and ungraft it after core-updates has
been merged?

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

Re: [core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)

[Andreas Enge]

Am Tue, Apr 04, 2023 at 08:13:19PM -0700 schrieb Felix Lechner via Development of GNU Guix and the GNU System distribution.:
> On Tue, Apr 4, 2023 at 7:49 PM Leo Famulari <leo@famulari.name> wrote:
> > See <https://issues.guix.gnu.org/issue/49817>, which was never applied
> > anywhere.
> > I guess it's enough to update libsndfile to 1.1.0 on core-updates.
> The upstream commit [2] shows that the issue was fixed in libsndfile's
> master branch as part of their merge request #713, which made it into
> these versions:
> 1.2.0
> 1.1.0
> 1.1.0beta2
> 1.1.0beta1
> It may therefore be better to upgrade directly to 1.2.0, except I
> think there was an understanding that no new features should be
> allowed on our core-updates branch at this time.

Well, an update causes a lot of rebuilds anyway. The NEWS of 1.2.0 look
like it is in fact only a bugfix release, so I took the risk to update to
this latest version. pulseaudio still compiles, and pavucontrol still works
on my machine.

The update is pushed to core-updates, but I would suggest to keep the bug
open until it is merged to master.

Thanks for the heads-up!

Andreas

Re: [core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)

[Leo Famulari]

On Wed, Apr 05, 2023 at 10:46:05AM +0200, Andreas Enge wrote:
> Well, an update causes a lot of rebuilds anyway. The NEWS of 1.2.0 look
> like it is in fact only a bugfix release, so I took the risk to update to
> this latest version. pulseaudio still compiles, and pavucontrol still works
> on my machine.
> 
> The update is pushed to core-updates, but I would suggest to keep the bug
> open until it is merged to master.

Thank you Andreas!

Re: [core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi everyone,

On Wed, Apr 5, 2023 at 1:46 AM Andreas Enge <andreas@enge.fr> wrote:
>
> I would suggest to keep the bug
> open until it is merged to master.

Do we have a hook that closes such bugs automatically via instructions
in commit messages?

If not, I'd be happy to look into writing such a thing. It would also
help to tie commits to bug reports, which can be good for research
after the fact.

Kind regards,
Felix

Commits and bug closing (was: something else)

[Andreas Enge]

Hello,

Am Wed, Apr 05, 2023 at 09:19:43AM -0700 schrieb Felix Lechner:
> Do we have a hook that closes such bugs automatically via instructions
> in commit messages?
> If not, I'd be happy to look into writing such a thing. It would also
> help to tie commits to bug reports, which can be good for research
> after the fact.

we do not as far as I know, and I agree that it would be useful to add
a two-way link between bug reports and commits (for "real" bugs, not
"issues" created from the patches list).

I do not know if there is a general convention on how this should be done;
supposedly it would need a bit of discussion to come to a consensus.

Andreas

Re: Commits and bug closing (was: something else)

[Simon Tournier]

Hi,

On jeu., 06 avril 2023 at 21:11, Andreas Enge <andreas@enge.fr> wrote:

>> Do we have a hook that closes such bugs automatically via instructions
>> in commit messages?
>> If not, I'd be happy to look into writing such a thing. It would also
>> help to tie commits to bug reports, which can be good for research
>> after the fact.
>
> we do not as far as I know, and I agree that it would be useful to add
> a two-way link between bug reports and commits (for "real" bugs, not
> "issues" created from the patches list).
>
> I do not know if there is a general convention on how this should be done;
> supposedly it would need a bit of discussion to come to a consensus.

For example,

--8<---------------cut here---------------start------------->8---
substitute: Gracefully handle TLS termination while fetching narinfos.

Fixes <https://issues.guix.gnu.org/62476>.
--8<---------------cut here---------------end--------------->8---

or 

--8<---------------cut here---------------start------------->8---
services: mpd: Use proper records for user and group fields.

Deprecate using strings for these fields and prefer user-account
(resp. user-group) instead to avoid duplication within account-service-type.

Fixes #61570 <https://issues.guix.gnu.org/61570>.
--8<---------------cut here---------------end--------------->8---

Somehow, the current informal “convention” is to add,

    Fixes <https://issues.guix.gnu.org/12345>.

in the commit message that closes specific bug.  However, it is not
fully uniform,

--8<---------------cut here---------------start------------->8---
gnu: openjdk10: Build from hg.

* gnu/packages/java.scm (openjdk10)[source]: Use HG-DOWNLOAD.

This fixes <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62071>
for OpenJDK 10.
--8<---------------cut here---------------end--------------->8---

or

--8<---------------cut here---------------start------------->8---
gnu: icecat: Fix Kerberos support.

Fixes <https://bugs.gnu.org/48959>.
--8<---------------cut here---------------end--------------->8---


Cheers,
simon

Re: Commits and bug closing

[Maxim Cournoyer]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

> Somehow, the current informal “convention” is to add,
>
>     Fixes <https://issues.guix.gnu.org/12345>.
>
> in the commit message that closes specific bug.  However, it is not
> fully uniform,
>
> gnu: openjdk10: Build from hg.
>
> * gnu/packages/java.scm (openjdk10)[source]: Use HG-DOWNLOAD.
>
> This fixes <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62071>
> for OpenJDK 10.
>
>
> or
>
> gnu: icecat: Fix Kerberos support.
>
> Fixes <https://bugs.gnu.org/48959>.

I'd say the more correct one is the later, assuming a GNU change log
followed, since the change log should appear after the descriptive
commit message, if any.

-- 
Thanks,
Maxim