Bug#1144080: gnutls28: mismege of CVE-2025-13151

Andreas Metzler <[email protected]>
Newsgroups gmane.linux.debian.devel.bugs.rc
Message-ID <antYiW7FY0A7ZYxQ__15741.633348965$1786468637$gmane$org@argenau.bebt.de>
Control: severity -1 normal

On 2026-08-11 Bastien Roucaries <[email protected]> wrote:
> Le mardi 11 août 2026, 07:57:30 heure d’été d’Europe centrale Salvatore Bonaccorso a écrit :
> > On Tue, Aug 11, 2026 at 01:52:05AM -0300, Carlos Henrique Lima Melara wrote:
[...] 
> > > Although it has the minitasn1 code embedded, I don't think it's being
> > > used. Looking closer, the configure script is using the distro version
> > > [1]:

> > > checking for libtasn1 >= 4.9... yes
> > > checking whether to use the included minitasn1... no

> > > Same goes for sid/forky [2], trixie [3], bookworm [1], bullseye [4],
> > > buster[5] and stretch [6]. So I think this is a case where the
> > > vulnerability is only in the source code and not in the built binary
> > > (provided libtasn1 shared library has been updated with the fix).

> > Generally: If the embedded source is not used at all it has no
> > security impact, so our usual approach here is to not even list
> > src:gnutsl28 in the respective CVE entry for the libtasn1-6 issue.  If
> > an embedded source OTOH is used and has a security impact on the
> > embedding source, then it can/should be listed.
> > 
> > So I guess #1144080 can be closed (or if Andreas wants to track the
> > update to the embeded copy then RC level is defintively not warranted,
> > and the bug can be downgraded to minor and then closed once the
> > embedded copy is updated upstream to include the fix. But TBH I do not
> > think this overhead is needed here).

> Please report upstream or coordinate with upstream here, or let me
> report upstream.

Hello Bastian,

if you can find the time feel free to report upstream, if not please tell
me.

> I was also burned a long time ago by embeded code copy that is
> compiled due to upstream change, so for lib it is interesting
> sometimes to repack in order to avoid upstream change that get
> vendoring compiled by accident

I have verified that we indeed do not (accidentally) use the embedded
copy. The respective c-files are not compiled.

While doing that I found a minor issue though, libgnutls-dane uses the
.h-files from minitasn. https://gitlab.com/gnutls/gnutls/-/work_items/1931

cu Andreas
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.