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

[Bastien Roucaries]

Le mardi 11 août 2026, 19:14:49 heure d’été d’Europe centrale Andreas Metzler a écrit :
> Control: severity -1 normal
> 
> On 2026-08-11 Bastien Roucaries <rouca at debian.org> 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

Thanks

That why i believe vendoring is bad. 

Could I add this issue to a wiki for rembering ?

I will report upstream.

rouca
> 
> cu Andreas
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnutls-maint/attachments/20260811/ac5a7ec8/attachment.sig>