From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12616 Path: news.gmane.org!.POSTED!not-for-mail From: "dgutson ." Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: #define __MUSL__ in features.h Date: Thu, 15 Mar 2018 16:00:37 -0300 Message-ID: References: <20180315183939.GI1436@brightrain.aerifal.cx> <20180315185358.GJ1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11449d7e7b5d790567781b7c" X-Trace: blaine.gmane.org 1521140341 11365 195.159.176.226 (15 Mar 2018 18:59:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 18:59:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12630-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 19:58:56 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ewY5Y-0002sU-5Y for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 19:58:56 +0100 Original-Received: (qmail 29839 invoked by uid 550); 15 Mar 2018 19:00:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 29770 invoked from network); 15 Mar 2018 19:00:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=QyfBlwwBGHwayOplpYxZBliq+6uQ8q8DuYRy5caVXrQ=; b=lRdbG08o1PCp+N1VRw7FgIQ5DfX3iBQQyVQ5usTTnWnT8jM+o/JsWCrE2c9O7/gpvc kZJQUOfwOvx+WDlzva3u0meUJX8sGEpqfTDsCHX07KYErpo7vS1ulgP3mFnl/u3U/Utq sRnKIesbYLT4I5f/GV3tLL9POPJnpYAJwYFWSKlnbkfvPDBfzSR6rf2di3Mh6Pz8YicC SdVdQRBnuZiQaWIoSNpQQ4dTQuL05HmWJ7cG0fM/rokvYWAPkaOgKrhzCKORS/l0sAkf hTN08DvGc5BDAnFwK2jpD5OqHIUn4jDTWZ3xdl8liVZmwPQKUlJl8JeMqiq1H0JMcdjo wHIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=QyfBlwwBGHwayOplpYxZBliq+6uQ8q8DuYRy5caVXrQ=; b=KPZJOxtLk+mfcJ64KkL6kBixEqAcCzDpyI4a0XHgAq4xTfW5P0pO60vk0N483m8872 wF+Ih+uYtrbtTIiW0D7TyB9HTTVUAsefTmvJk5jIpN0nwuWQS5ZLKrGw1CMiuhkyMiSX DyIY9nIeeII+d/NNy38C0SZfEsbD0RELNgka12rPwYOJIne0cV4yH+OiBfugkurlUQbT 38V569o5FHFmBHuGNCzL0f08ekxEcv67+S5e+glAH/B7zNPZbIdkq+FPT7uevLUxQc5z 9LbRlXVkixP3JZsuyyOAPzz0vSo/PI4nM45fyi9XUsRw0Df/ERefYYi1JxI/GYe/ws/J 3s3A== X-Gm-Message-State: AElRT7H3GOVvE6QDSjIzdRw3XK1I4HknoRGNO8F/KKnYTt9awNfU6QVO 4wlH9dZbvbRI3Q40Oui7X1nJxxTizqxMkWYcqsOhxQ== X-Google-Smtp-Source: AG47ELvujQD0/nEFqhum1/cq26OJVrf6OFaCQMKzuyv/Pk2vwyMIhkO/8BWAbR+YzX7/qnGECkBHd6enM1Q7iL5ZB7s= X-Received: by 10.55.2.140 with SMTP id v12mr13915873qkg.251.1521140438357; Thu, 15 Mar 2018 12:00:38 -0700 (PDT) In-Reply-To: <20180315185358.GJ1436@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12616 Archived-At: --001a11449d7e7b5d790567781b7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2018 at 3:53 PM, Rich Felker wrote: > On Thu, Mar 15, 2018 at 03:48:32PM -0300, Martin Galvan wrote: > > 2018-03-15 15:39 GMT-03:00 Rich Felker : > > >> (e.g. the FD* issue reported by Martin Galvan). > > > > > > That's not a bug. It's compiler warnings being wrongly produced for a > > > system header, probably because someone added -I/usr/include or > > > similar (normally GCC suppresses these). > > > > I'm certain we didn't add -I/usr/include or something similar. Could > > you test this yourself to confirm it's not a bug? > > In any case it's not a bug in musl. The code is perfectly valid C. If > the compiler is producing a warning for it, either ignore it or ask > the compiler to stop. > > > The compiler warnings aren't being wrongly produced. musl will indeed > > perform a signed-to-unsigned conversion here. > > Because that's how the C language works. > it is a potential vulnerability: https://cwe.mitre.org/data/definitions/195.html https://wiki.sei.cmu.edu/confluence/display/c/INT31-C.+Ensure+that+integer+= conversions+do+not+result+in+lost+or+misinterpreted+data https://wiki.sei.cmu.edu/confluence/display/c/INT30-C.+Ensure+that+unsigned= +integer+operations+do+not+wrap Can you ensure it is rocksolid and the signed integer will NEVER be a negative value? > > > > The musl policy regarding not having a macro like __MUSL__ is doing > > > exactly what it's intended to do: encouraging developers and package > > > maintainers to come to us (or investigate on their own) and fix the > > > underlying portability problems (and sometimes musl bugs) rather than > > > writing hacks to a specific version of musl that will be wrong a few > > > versions later. > > > > So whenever we find a bug on musl we should just stop all our > > development until you've fixed the bug? > > No. As noted above, if you need to support systems that might have bug > X, you write a test (configure-time or run-time as appropriate) to > detect bug X and handle it. > > Rich > --=20 Who=E2=80=99s got the sweetest disposition? One guess, that=E2=80=99s who? Who=E2=80=99d never, ever start an argument? Who never shows a bit of temperament? Who's never wrong but always right? Who'd never dream of starting a fight? Who get stuck with all the bad luck? --001a11449d7e7b5d790567781b7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 15, 2018 at 3:53 PM, Rich Felker <dalias@libc.org> wrote:
On Thu, Mar 15, 2018 at 03:48:32PM -0300, Martin Galvan wrote:=
> 2018-03-15 15:39 GMT-03:00 Rich Felker <dalias@libc.org>:
> >> (e.g. the FD* issue reported by Martin Galvan).
> >
> > That's not a bug. It's compiler warnings being wrongly pr= oduced for a
> > system header, probably because someone added -I/usr/include or > > similar (normally GCC suppresses these).
>
> I'm certain we didn't add -I/usr/include or something similar.= Could
> you test this yourself to confirm it's not a bug?

In any case it's not a bug in musl. The code is perfectly valid = C. If
the compiler is producing a warning for it, either ignore it or ask
the compiler to stop.

> The compiler warnings aren't being wrongly produced. musl will ind= eed
> perform a signed-to-unsigned conversion here.

Because that's how the C language works.
it is a potential vulnerability:

Can you ensure = it is rocksolid and the signed integer will NEVER be a negative value?
=C2=A0

> > The musl policy regarding not having a macro like __MUSL__ is doi= ng
> > exactly what it's intended to do: encouraging developers and = package
> > maintainers to come to us (or investigate on their own) and fix t= he
> > underlying portability problems (and sometimes musl bugs) rather = than
> > writing hacks to a specific version of musl that will be wrong a = few
> > versions later.
>
> So whenever we find a bug on musl we should just stop all our
> development until you've fixed the bug?

No. As noted above, if you need to support systems that might have b= ug
X, you write a test (configure-time or run-time as appropriate) to
detect bug X and handle it.

Rich



--
Who=E2=80=99s got the sweetest disposition= ?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an a= rgument?
Who never shows a bit of temperament?
Who's never wrong = but always right?
Who'd never dream of starting a fight?
Who get = stuck with all the bad luck?
--001a11449d7e7b5d790567781b7c--