Russ Allbery rra at debian.org writes:
(consider resource exhaustion errors in the crypt implementation, for
No, the standard said it would either always fail or never, but independent
on the input data.
Your proposed solution on libc-alpha was ingenious, but I think it breaks
the crypt
Thorsten Glaser t...@mirbsd.de writes:
Russ Allbery rra at debian.org writes:
(consider resource exhaustion errors in the crypt implementation, for
No, the standard said it would either always fail or never, but
independent on the input data.
I believe that just because POSIX only documents
On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
Thorsten Glaser t...@mirbsd.de writes:
Russ Allbery rra at debian.org writes:
Programs that don't check the return status of functions that they think
won't ever fail are a bit of a pet peeve of mine, in part because it would
make
Adam Borowski kilob...@angband.pl writes:
On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
Programs that don't check the return status of functions that they
think won't ever fail are a bit of a pet peeve of mine, in part because
it would make a lot of sense for localtime() to be
On Wed, Sep 25, 2013 at 11:43:22AM +, Thorsten Glaser wrote:
No, the standard said it would either always fail or never, but independent
on the input data.
Nope:
| Upon successful completion, crypt() shall return a pointer to the
| encoded string. The first two characters of the returned
Russ Allbery r...@debian.org writes:
Adam Borowski kilob...@angband.pl writes:
On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
Programs that don't check the return status of functions that they
think won't ever fail are a bit of a pet peeve of mine, in part
because it would
On Wed, 25 Sep 2013, Adam Borowski wrote:
On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
Thorsten Glaser t...@mirbsd.de writes:
Russ Allbery rra at debian.org writes:
Programs that don't check the return status of functions that they think
won't ever fail are a bit of a
Kees Cook kees at debian.org writes:
On Sat, Sep 21, 2013 at 02:46:34PM +0200, Bas Wijnen wrote:
On Fri, Sep 20, 2013 at 10:12:16PM -0700, Kees Cook wrote:
This is absolutely a bug in glibc. While the spec can say undefined,
it
is, in fact, not undefined. It worked in a very specific way
Thorsten Glaser t...@mirbsd.de writes:
The glibc people decision to return NULL in crypt(3) has led to several
(plural) CVEs in other software, such as cyrus-sasl2 and xlockmore,
already and breaks the GNU CVS testsuite.
crypt returning NULL transforms various obscure but more serious
On September 21, 2013 09:04:23 PM Bernhard R. Link wrote:
* Kees Cook k...@debian.org [130921 17:08]:
In a theoretical sense, sure. In this particular case, why bother breaking
it when it's a trivial 1 line fix? My original approach was to fix it in
libc and do a mass bug filing. Everyone
On Sun, 2013-09-22 at 02:09 -0500, Steve M. Robbins wrote:
On September 21, 2013 09:04:23 PM Bernhard R. Link wrote:
* Kees Cook k...@debian.org [130921 17:08]:
In a theoretical sense, sure. In this particular case, why bother breaking
it when it's a trivial 1 line fix? My original
Steve M. Robbins wrote:
On September 21, 2013 09:04:23 PM Bernhard R. Link wrote:
The whole point of undefined behaviour in C is that the
compiler/implementor/... does not have to care.
I strongly suspect the whole point of undefined behaviour is simply that at
least two parties on the
If we want to support additional semantics for sn?printf where the
standard says undefined, we should take care to specify what is going
to be promised.
I don't know whether we is Debian, or we is (e)glibc upstream.
I also don't know exactly what is being proposed. Something like
When the
On Fri, Sep 20, 2013 at 10:01:36PM -0300, Henrique de Moraes Holschuh wrote:
IMHO: fix everything gcc, llvm and the static testers complain about (which
can be quite troublesome, as you must be *sure* you're actually fixing the
issue instead of making it worse by silencing the warning without
On Fri, Sep 20, 2013 at 09:04:43PM -0400, Yaroslav Halchenko wrote:
On Fri, 20 Sep 2013, Bastian Blank wrote:
On Fri, Sep 20, 2013 at 03:05:37PM -0400, Yaroslav Halchenko wrote:
long story short -- reason was the combination of optimization (-O1 was
enough)
+ -D_FORTIFY_SOURCE=2 to
On Fri, Sep 20, 2013 at 10:12:16PM -0700, Kees Cook wrote:
This is absolutely a bug in glibc. While the spec can say undefined, it
is, in fact, not undefined. It worked in a very specific way for over a
decade, so that's pretty well defined. ;) The fortify function has no need
to change it.
I
On Sat, Sep 21, 2013 at 02:46:34PM +0200, Bas Wijnen wrote:
On Fri, Sep 20, 2013 at 10:12:16PM -0700, Kees Cook wrote:
This is absolutely a bug in glibc. While the spec can say undefined, it
is, in fact, not undefined. It worked in a very specific way for over a
decade, so that's pretty
* Kees Cook k...@debian.org [130921 17:08]:
In a theoretical sense, sure. In this particular case, why bother breaking
it when it's a trivial 1 line fix? My original approach was to fix it in
libc and do a mass bug filing. Everyone wins. If we want to reject the
undefined behavior, we should
On Sat, 21 Sep 2013, Bastian Blank wrote:
DEB_BUILD_HARDENING_FORTIFY := 0
preceding inclusion of /usr/share/hardening-includes/hardening.make
I would call code that hits such clear definitions too buggy to be
supported.
yeah -- let's burn it!!!... oh no -- I am using it, so I
On Fri, 20 Sep 2013, Kees Cook wrote:
This is absolutely a bug in glibc. While the spec can say undefined, it
is, in fact, not undefined. It worked in a very specific way for over a
decade, so that's pretty well defined. ;) The fortify function has no need
to change it.
FWIW +1
To
Yaroslav Halchenko deb...@onerussian.com writes:
long story short -- reason was the combination of optimization (-O1 was
enough) + -D_FORTIFY_SOURCE=2 to fall into the undefined darkness of C
standard(s) in s*printf() functions (man 3 sprintf, search for undefined
or NOTES).
So basically a
On Fri, 20 Sep 2013, Russ Allbery wrote:
Yaroslav Halchenko deb...@onerussian.com writes:
long story short -- reason was the combination of optimization (-O1 was
enough) + -D_FORTIFY_SOURCE=2 to fall into the undefined darkness of C
standard(s) in s*printf() functions (man 3 sprintf,
On Fri, Sep 20, 2013 at 03:05:37PM -0400, Yaroslav Halchenko wrote:
long story short -- reason was the combination of optimization (-O1 was
enough)
+ -D_FORTIFY_SOURCE=2 to fall into the undefined darkness of C standard(s)
in s*printf() functions (man 3 sprintf, search for undefined or
On 20/09/13 22:09, Bastian Blank wrote:
I would call code that hits such clear definitions too buggy to be
supported.
and what if many more existing packages are found to have similar issues?
http://debile.debian.net/sources/
One of my packages has some nice colours:
On Fri, Sep 20, 2013 at 01:08:00PM -0700, Russ Allbery wrote:
So basically a variation of the old problem of calling memcpy when one
meant to use memmove. I'm actually surprised that type of call to sprintf
ever worked reliably with optimization, even without _FORTIFY_SOURCE.
But, like memcpy
Just to share with fellow developers, in particular those who maintain
scientific software projects which still quite often come without
thorough unittests batteries.
Within NeuroDebian we have been preparing a package of AFNI (which now could
soon be uploaded to Debian proper) which,
On Sat, Sep 21, 2013 at 04:29:30AM +0600, Andrey Rahmatullin wrote:
On Sat, Sep 21, 2013 at 12:00:57AM +0200, Adam Borowski wrote:
So basically a variation of the old problem of calling memcpy when one
meant to use memmove. I'm actually surprised that type of call to sprintf
ever worked
On Sat, Sep 21, 2013 at 12:00:57AM +0200, Adam Borowski wrote:
So basically a variation of the old problem of calling memcpy when one
meant to use memmove. I'm actually surprised that type of call to sprintf
ever worked reliably with optimization, even without _FORTIFY_SOURCE.
But, like
On Fri, 20 Sep 2013, Daniel Pocock wrote:
On 20/09/13 22:09, Bastian Blank wrote:
I would call code that hits such clear definitions too buggy to be
supported.
and what if many more existing packages are found to have similar issues?
IMHO: fix everything gcc, llvm and the static testers
On Fri, 20 Sep 2013, Yaroslav Halchenko wrote:
On your code you could look for some (no multiline or more complex
expressions, no snprintf) hits in sprintf with following grep
grep -re 'sprintf(\s*\(\w\+\)\s*,[^,]\+,\s*\1\' *
unfortunately codesearch.d.n seems to not have support for
On Fri, 20 Sep 2013, Bastian Blank wrote:
On Fri, Sep 20, 2013 at 03:05:37PM -0400, Yaroslav Halchenko wrote:
long story short -- reason was the combination of optimization (-O1 was
enough)
+ -D_FORTIFY_SOURCE=2 to fall into the undefined darkness of C
standard(s)
in s*printf()
On Fri, Sep 20, 2013 at 03:05:37PM -0400, Yaroslav Halchenko wrote:
+ -D_FORTIFY_SOURCE=2 to fall into the undefined darkness of C standard(s)
in s*printf() functions (man 3 sprintf, search for undefined or NOTES).
Original report
https://sourceware.org/bugzilla/show_bug.cgi?id=7075
Yeah.
32 matches
Mail list logo
