From: Florian Weimer <fweimer@redhat.com>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: libc-stable@sourceware.org
Subject: Re: Backporting CVE-2016-10739
Date: Tue, 01 Jan 2019 00:00:00 -0000 [thread overview]
Message-ID: <87o97rpsgq.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20190204134254.GA13816@aurel32.net> (Aurelien Jarno's message of "Mon, 4 Feb 2019 14:42:54 +0100")
* Aurelien Jarno:
> I am looking at backporting fixes for CVE-2016-10739 (ie commit
> 108bc404) in the 2.28 branch first, and probably in the 2.24 branch
> later. I would need some guidance how to proceed:
I planned to do it last week, but didn't finish it.
> - Is it acceptable to also to backport commit 5e30b8ef ("resolv:
> Reformat inet_addr, inet_aton to GNU style")? Without this patch,
> there's a lot of conflicts that are a pain to fix.
Yes absolutely.
> - According to the commit message 6ca53a24 ("resolv: Do not send queries
> for non-host-names in nss_dns [BZ #24112]"), also needs to be
> backported. Is it fine to do so?
Yes, the queries are pointless.
> - The commit introduces a new symbol, which is something we usually do
> not want in a stable branch. However the __inet_aton_exact symbol is
> added under GLIBC_PRIVATE. Therefore I wonder if it is acceptable for
> a stable branch.
I planned to commit *another* commit which avoids the addition of the
GLIBC_PRIVATE symbol, with some code duplication. Basically, use
attribute_hidden instead of libc_hidden_proto for the declaration of
__inet_aton_exact, and also build resolv/inet_addr.c for nscd. We do
not always do that, but it seems easy enough to do it here, and it makes
our QE people happy.
If you want to do it, I can help you with that.
Thanks,
Florian
next prev parent reply other threads:[~2019-02-04 13:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-01 0:00 Aurelien Jarno
2019-01-01 0:00 ` Florian Weimer
2019-01-01 0:00 ` Carlos O'Donell
2019-01-01 0:00 ` Florian Weimer
2019-01-01 0:00 ` Carlos O'Donell
2019-01-01 0:00 ` Florian Weimer
2019-01-01 0:00 ` Carlos O'Donell
2019-01-01 0:00 ` Florian Weimer
2019-01-01 0:00 ` Carlos O'Donell
2019-01-01 0:00 ` Florian Weimer
2019-01-01 0:00 ` Carlos O'Donell
2019-01-01 0:00 ` Florian Weimer
2019-01-01 0:00 ` Carlos O'Donell
2019-01-01 0:00 ` Aurelien Jarno
2019-01-01 0:00 ` Florian Weimer [this message]
2019-01-01 0:00 ` Aurelien Jarno
2019-01-01 0:00 ` Florian Weimer
2019-01-01 0:00 ` Aurelien Jarno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o97rpsgq.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=aurelien@aurel32.net \
--cc=libc-stable@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).