Re: glob resource exhaustion [CVE-2010-2632]

On 10/13/2010 05:48 PM, Bruno Haible wrote: > But the braces are a GNU extension, and the doc > > is pretty clear that {..,..} _will_ generate duplicates. As near as I can tell, this is an accident, both of the libc implementation an

Re: bug#7199: problem with Oct 10 snapshot on Solaris 10 with Sun cc

On 10/12/2010 12:58 PM, Jim Meyering wrote: > Please push that, too. OK, I pushed that here, into gnulib: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=1179fb893526296be259211c2530feb225ebefc8

Re: glob resource exhaustion [CVE-2010-2632]

Hi Paul, > I agree that applications should set reasonable memory limits, but > this is still a bug in glob, because glob should not return duplicates. > For example, the pattern {.,.} should match just ".", not two instances > of "." as it does now. POSIX describes glob() in a way that precludes

Re: [PATCH] Do not limit git-version-gen to work only under the repository root.

Hello Jim, Jim Meyering writes: > Thanks again for the quick corrections. > Here's a better version. I'll wait for review this time ;-) I have tried the new version and it seems to work well. I am going to remove the workaround I had to use and keep my copy sync'ed with the gnulib version.

Re: glob resource exhaustion [CVE-2010-2632]

On Wednesday, October 13, 2010 18:38:14 Bruno Haible wrote: > Mike Frysinger wrote: > > i havent seen any mention on glibc or gnulib lists of CVE-2010-2632. the > > report claims glibc is affected, and since the gnulib/glibc > > implementations are pretty similar, gnulib would be as well. i dont

Re: glob resource exhaustion [CVE-2010-2632]

On 10/13/10 15:38, Bruno Haible wrote: > But why should this be a bug in libc? There are many functions in libc that > can allocate an arbitrary amount of memory. I agree that applications should set reasonable memory limits, but this is still a bug in glob, because glob should not return duplicat

Re: glob resource exhaustion [CVE-2010-2632]

Mike Frysinger wrote: > i havent seen any mention on glibc or gnulib lists of CVE-2010-2632. the > report claims glibc is affected, and since the gnulib/glibc implementations > are pretty similar, gnulib would be as well. i dont suppose there is a bug > report somewhere i could follow for stat

glob resource exhaustion [CVE-2010-2632]

i havent seen any mention on glibc or gnulib lists of CVE-2010-2632. the report claims glibc is affected, and since the gnulib/glibc implementations are pretty similar, gnulib would be as well. i dont suppose there is a bug report somewhere i could follow for status on this ? http://securityr

[PATCH] termios: fix compilation on mingw

* m4/termios_h.m4 (gl_TERMIOS_H_DEFAULTS): Set default. (gl_TERMIOS_H): Adjust it on mingw. * modules/termios (Makefile.am): Substitute new key. * lib/termios.in.h (includes): Make include_next conditional. * doc/posix-headers/termios.texi (termios.h): Update documentation. Reported by Daniel P. Be

Re: [PATCH] Do not limit git-version-gen to work only under the repository root.

Jim Meyering wrote: > Giuseppe Scrivano wrote: > >> Hello, >> >> Jim Meyering writes: >> >>> Not sure about more "elegant", but here's a lower cost method: >> >> Thanks for the patch but I think the problem you have reported here: >> >> http://article.gmane.org/gmane.comp.lib.gnulib.bugs/21845

bogus warning about EXTRA_HEADERS requirement (was: [PATCH 5/7] add _HEADERS primaries to Makefile.am snippets for installable headers)

Hello, and adding bug-automake, * Gary V. Vaughan wrote on Wed, Oct 13, 2010 at 12:06:32PM CEST: > On 13 Oct 2010, at 03:55, Bruno Haible wrote: > > And what's the role or effect of EXTRA_HEADERS? Automake does not do > > anything with .h files that it doesn't do with .png files. gnulib-tool > > a

Re: [PATCH 3/7] iconv_open: reduce not-trivial repetition of file-list

Hi Gary, * Gary V. Vaughan wrote on Wed, Oct 13, 2010 at 11:45:52AM CEST: > Hmm... it's a pity that there isn't an Automake syntax for transforming > lists of filenames (that works with portable make anyway), since having > four near-identical lists of filenames bothers me a (tiny) little bit. Fo

Re: [PATCH] Do not limit git-version-gen to work only under the repository root.

Giuseppe Scrivano wrote: > Hello, > > Jim Meyering writes: > >> Not sure about more "elegant", but here's a lower cost method: > > Thanks for the patch but I think the problem you have reported here: > > http://article.gmane.org/gmane.comp.lib.gnulib.bugs/21845 > > persists. > > > Here an examp

Re: [PATCH] Do not limit git-version-gen to work only under the repository root.

Hello, Jim Meyering writes: > Not sure about more "elegant", but here's a lower cost method: Thanks for the patch but I think the problem you have reported here: http://article.gmane.org/gmane.comp.lib.gnulib.bugs/21845 persists. Here an example, where /tmp/foo is a git repository. /tmp/

Re: [PATCH] Do not limit git-version-gen to work only under the repository root.

Giuseppe Scrivano wrote: > Bruno, Jim, > > thanks for your comments. > > > Jim Meyering writes: > >> What is your use case? > > I have the git repository in myserver/, but the top_srcdir is in > myserver/myserver/. > > >> Won't this proposal cause trouble when >> running git-version-gen in a non-

Re: [libvirt] [PATCH] Conditionally include termios.h

[adding bug-gnulib] On 10/13/2010 06:22 AM, Daniel P. Berrange wrote: On Wed, Oct 13, 2010 at 06:16:03AM -0600, Eric Blake wrote: On 10/13/2010 04:34 AM, Daniel P. Berrange wrote: The configure.ac file checks for termios.h, but its use is not protected by HAVE_TERMIOS_H. This breaks the build

avoid warnings in test-select.c: addendum

Nearly forgot this. Technically you might argue that it is not really required, since ./gnulib-tool --create-testdir --with-tests --test select succeeds without it. (some dependent module pulls in that commonly required file) But it's better to make it explicit, so I've folded this in: diff --

[PATCH] test-nl_langinfo: avoid "unsigned expression >= 0 is always true" warning

Hi Bruno, Is this change ok with you? Alternatively, I'd be slightly happier simply to remove the warning-evoking tests. Here's one of the 5 warnings: test-nl_langinfo.c:56: warning: comparison of unsigned expression >= 0 \ is always true [-Wtype-limits] >From 3dd5d3a98d4f6a4fe8d693e124c

[PATCH] test-select-stdin.c: avoid warn_unused_result warnings

Hi Bruno, Is this ok with you? With this, the other changes posted here today, as well as one more in coreutils (to exempt 3 offenders I won't bother with), gnulib-tests/ now compiles with -Werror. >From 6ff0dbc6886418b68b6f19cfdaec34e751ae88ad Mon Sep 17 00:00:00 2001 From: Jim Meyering Date:

Re: [PATCH 2/7] gnulib-tool: transform hard-coded libgnu.a to $libname.l?a

On 13 Oct 2010, at 03:26, Bruno Haible wrote: >> * gnulib-tool (func_emit_lib_Makefile_am): transform hard-coded >> `libgnu.a' in Makefile.am snippets to be either `$libname.a' or >> `$libname.la', depending on whether --libtool/--no-libtool options >> were given. > > Here it's clear that we need

Re: [PATCH 3/7] iconv_open: reduce not-trivial repetition of file-list

On 13 Oct 2010, at 03:35, Bruno Haible wrote: >> By itself, this patch reduces unnecessary repetition, but also sets up >> a later patch in this series to not need to make yet another copy of >> the listed headers. >> >> * modules/iconv_open (iconv_headers): New make macro to hold list of >> iconv

Re: [PATCH] test-select: avoid warn_unused_result warnings

Paolo Bonzini wrote: > On 10/13/2010 10:19 AM, Jim Meyering wrote: >> Hi Paolo, >> >> Is this change ok with you? >> Without it, I see many warnings like this when running >> coreutils's "make check" (with --enable-gcc-warnings): >> >> test-select.c: In function 'test_pair': >> test-selec

Re: [PATCH] bootstrap: add hook for altering gnulib.mk, for Bison

Hi Paul, On 13 Oct 2010, at 03:12, Paul Eggert wrote: > On 10/11/10 18:21, Gary V. Vaughan wrote: >> As I've tweaked it to support existing users, I've found that some >> of them (bison and tar, I'm looking at you!) don't even use the >> canonical version. > > That's been fixed as of Oct 8 and Oc

[PATCH] test-select: avoid warn_unused_result warnings

Hi Paolo, Is this change ok with you? Without it, I see many warnings like this when running coreutils's "make check" (with --enable-gcc-warnings): test-select.c: In function 'test_pair': test-select.c:330: warning: ignoring return value of 'write', declared \ with attribute warn_un

Re: double inclusion guard

Hallo Bruno, On 13 Oct 2010, at 02:48, Bruno Haible wrote: >> Then I believe the only viable option to provide stable support for >> multiple gnulib directories in a single tree is to add a switch to >> gnulib-tool to rewrite gnulib #include_next lines on import, so that >> both types of compilers

Re: [PATCH] test-select: avoid warn_unused_result warnings

On 10/13/2010 10:19 AM, Jim Meyering wrote: Hi Paolo, Is this change ok with you? Without it, I see many warnings like this when running coreutils's "make check" (with --enable-gcc-warnings): test-select.c: In function 'test_pair': test-select.c:330: warning: ignoring return value of

Re: [PATCH 7/7] libposix: use git-version-gen for version numbering

On 10/12/2010 11:20 PM, Bruno Haible wrote: Gary V. Vaughan wrote: git-version-gen itself relies on the presence of .git in the current directory. I've made a quick and dirty patch to it here to also look in the parent directory... but surely there's a nicer way to determine whether the current

Re: [PATCH 6/7] libposix: raw files to import an installable libposix project

On 13 Oct 2010, at 03:59, Bruno Haible wrote: >> * libposix/bootstrap: New script to import gnulib posix modules >> and bootstrap configury so that the result is an installable >> libposix.la. >> * libposix/configure.ac: New file to configure the new libposix >> subdirectory. >> * libposix/Makefile

Re: [PATCH 5/7] add _HEADERS primaries to Makefile.am snippets for installable headers

On 13 Oct 2010, at 03:55, Bruno Haible wrote: >> Originally, I added noinst_HEADERS to the module definition files, >> and then changed them all to nobase_nodist_include_HEADERS and >> EXTRA_HEADERS in gnulib-tool if the gnulib library is installable. >> However, I think it is much more flexible to

Re: [PATCH 7/7] libposix: use git-version-gen for version numbering

Hallo Bruno, Thanks again for the speedy and thoughtful feedback on this patch series. I'm sorry that I won't have the time to actually apply any of your good advice for at least a couple of weeks, but whatever is still outstanding when I next have discretionary hacking time, I'll apply, retest a

Re: [PATCH 0/7] contents of topic/libposix for merge to master

On 13 Oct 2010, at 03:03, Bruno Haible wrote: > Hi Gary, Hallo Bruno, >> This patch series is what I've just pushed as a new topic branch to >> the savannah repo. > > Wow! You're fast. I love your initiative and appreciate your approach. Thanks. And thanks also for the fast responses. >> Okay

Re: [PATCH 6/7] libposix: raw files to import an installable libposix project

On 13 Oct 2010, at 08:18, Bruce Korb wrote: > Hi Gary, Howdy Bruce! > On 10/12/10 09:08, Gary V. Vaughan wrote: > >> +++ b/libposix/bootstrap >> @@ -0,0 +1,55 @@ >> +#! /bin/sh >> + >> +PATH=..:$PATH >> + >> +gnulib-tool --import --lib=libposix --makefile-name=gnulib.mk \ >> + --macro-prefix=LI

Re: [PATCH 1/7] gnulib-tool: transform include guards with `--macro-prefix'

On 13 Oct 2010, at 03:17, Bruno Haible wrote: >> * gnulib-tool (func_import): support multiple gllib directories: >> headers are generated for each gllib differently, depending on which >> features are actually used, so we need to be able to include all >> these generated headers without fear that

Re: [PATCH 4/7] New module `libposix'.

On 13 Oct 2010, at 03:43, Bruno Haible wrote: >> Making libposix into a module makes life considerably easier. > > Yes, it triggers the magic that tells gnulib-tool to omit the augmentation of > noinst_LIBRARIES. > > But I don't agree with putting the module list here. Who will keep it > up-to-da

[OFFTOPIC] spaces instead of tabs in vim [WAS Re: [PATCH 2/7] gnulib-tool: transform hard-coded libgnu.a to $libname.l?a]

Hmm... now I know why I prefer emacs! On 13 Oct 2010, at 16:40, Gary V. Vaughan wrote: > On 13 Oct 2010, at 03:26, Bruno Haible wrote: >> And, please, in gnulib code, we don't use tabs any more, except in pieces >> of Makefiles and ChangeLog. See the section "Indent with spaces, not TABs" >> of gn

[PATCH] test-symlinkat: remove declaration of unused local

FYI, >From 9492afb6b3850fb798d9cf83d03b0f9664a4c7b2 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 13 Oct 2010 10:06:29 +0200 Subject: [PATCH] test-symlinkat: remove declaration of unused local * tests/test-symlinkat.c (main): Remove unused local, "buf". --- ChangeLog |

[PATCH] test-inttostr: avoid shadowing warnings

Inspired by Paul's report of swapped strtol args (args 2 and 3) in a coreutils-specific test that evoked a well-deserved warning. However, I've missed it for ages because it was buried under so many others. Now I'm motivated to enable -Werror also when compiling in coreutils' gnulib-tests/ directo