Re: CVS commit: src/lib/libc
On Sun, Mar 04, 2012 at 10:31:01PM +, David Laight wrote: > > > That could be used as a compile-time substitute when the buffer > > > size is known - ie when 'sizeof buffer != sizeof (char *)' > > > > I don't think that makes too much sense. If you want to read a full > > line, use getline. If you don't, loop with fgets until the full line is > > read. > > I was thinging of a header file fix to allow code to compile > without changing the source and with miminal 'security' issues. Every program that matters was patched 20+ years ago. It is a nonissue. (BTW, the reason it's hard to check pkgsrc is not that you can't tell if an executable uses gets; nm will do that. It's that you have to unpack all the output packages to inspect them. Or unpack all the sources. It's much easier to just run a build in a modified chroot.) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch/i386/i386
On 5 March 2012 02:14, Manuel Bouyer wrote: > Module Name: src > Committed By: bouyer > Date: Sun Mar 4 20:44:17 UTC 2012 > > Modified Files: > src/sys/arch/i386/i386: machdep.c > > Log Message: > Don't try to uvm_page_physload() the tmpgdt page: this always fails because > only one physical segment is configured for Xen, and it's probably not > worth it to create a second physseg with a single page (uvm has optimisations > for the VM_PHYSSEG_MAX == 1 case) > > ic, so we're potentially leaking 2 pages at boot now -- ~Cherry
Re: CVS commit: src/lib/libc
On Sun, Mar 04, 2012 at 09:42:21PM +0100, Joerg Sonnenberger wrote: > On Sun, Mar 04, 2012 at 08:20:20PM +, David Laight wrote: > > I wonder it it would be worth adding a function that is like gets, > > but takes a buffer length (ie discards the \n - and maybe the rest of the > > line). > > > > That could be used as a compile-time substitute when the buffer > > size is known - ie when 'sizeof buffer != sizeof (char *)' > > I don't think that makes too much sense. If you want to read a full > line, use getline. If you don't, loop with fgets until the full line is > read. I was thinging of a header file fix to allow code to compile without changing the source and with miminal 'security' issues. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libc
On Sun, Mar 04, 2012 at 10:38:19PM +0200, Alan Barrett wrote: > On Sun, 04 Mar 2012, David Laight wrote: > >I wonder it it would be worth adding a function that is like > >gets, but takes a buffer length (ie discards the \n - and maybe > >the rest of the line). > > C2011 has char *gets_s(char *s, rsize_t n); > > It discards the \n, but does not discard the rest of the line, so > you can't tell the difference between a line that was exactly the > maximum length (followed by a \n which is discarded) or a line > that was too long. fgets() can tell the difference, however. Not checking that allowed users to get root privs. IIRC it was very long fields in the password file causing an entry to be split. (fixed long long ago) So that '_s' form isn't 'secure' (or whatever _s is supposed to mean). David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libc
On Sun, Mar 04, 2012 at 08:20:20PM +, David Laight wrote: > I wonder it it would be worth adding a function that is like gets, > but takes a buffer length (ie discards the \n - and maybe the rest of the > line). > > That could be used as a compile-time substitute when the buffer > size is known - ie when 'sizeof buffer != sizeof (char *)' I don't think that makes too much sense. If you want to read a full line, use getline. If you don't, loop with fgets until the full line is read. Joerg
Re: CVS commit: src/lib/libc
On Sun, 04 Mar 2012, David Laight wrote: I wonder it it would be worth adding a function that is like gets, but takes a buffer length (ie discards the \n - and maybe the rest of the line). C2011 has char *gets_s(char *s, rsize_t n); It discards the \n, but does not discard the rest of the line, so you can't tell the difference between a line that was exactly the maximum length (followed by a \n which is discarded) or a line that was too long. fgets() can tell the difference, however. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc
On Sun, Mar 04, 2012 at 01:06:03PM -0700, Warner Losh wrote: > > On Mar 3, 2012, at 5:55 PM, David Holland wrote: > > > On Thu, Mar 01, 2012 at 11:14:16AM -0700, Warner Losh wrote: > >> Maybe somebody can look at a full pkgsrc build to see how many > >> instances of gets are in it? > > > > Given the way bulk builds work, and various logistical reasons that is > > unlikely to change, the only practical way to check this is to remove > > gets locally before doing a build. > > > > Perhaps I'll do this. Any such program is broken and needs to be > > patched. Your example is unpersuasive. > > So there's no way to troll through the build binaries for references > to gets, at least in the dynamically linked binaries? That's unfortunate. > > My example was a place where it was completely safe to use. > I offered only to counter those that said it is never safe, > which is factually untrue. > > But given the extreme ease with which it is unsafe to use, > I'm with the 'get it out' crowd, but only if it doesn't provoke > wide-spread chaos. > without data, it is hard to say for sure the level of chaos. Running 'objdump -D' and grepping for '\' will probably find them. I wonder it it would be worth adding a function that is like gets, but takes a buffer length (ie discards the \n - and maybe the rest of the line). That could be used as a compile-time substitute when the buffer size is known - ie when 'sizeof buffer != sizeof (char *)' David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libc
On Mar 3, 2012, at 5:55 PM, David Holland wrote: > On Thu, Mar 01, 2012 at 11:14:16AM -0700, Warner Losh wrote: >> Maybe somebody can look at a full pkgsrc build to see how many >> instances of gets are in it? > > Given the way bulk builds work, and various logistical reasons that is > unlikely to change, the only practical way to check this is to remove > gets locally before doing a build. > > Perhaps I'll do this. Any such program is broken and needs to be > patched. Your example is unpersuasive. So there's no way to troll through the build binaries for references to gets, at least in the dynamically linked binaries? That's unfortunate. My example was a place where it was completely safe to use. I offered only to counter those that said it is never safe, which is factually untrue. But given the extreme ease with which it is unsafe to use, I'm with the 'get it out' crowd, but only if it doesn't provoke wide-spread chaos. without data, it is hard to say for sure the level of chaos. Warner
Re: CVS commit: src
On Sun, Mar 04, 2012 at 04:12:25PM +, Matthias Scheler wrote: > Module Name: src > Committed By: tron > Date: Sun Mar 4 16:12:25 UTC 2012 > > Modified Files: > src/distrib/sets/lists/man: mi > src/external/ibm-public/postfix: Makefile.inc > src/external/ibm-public/postfix/lib/global: Makefile > src/external/ibm-public/postfix/man/man5: Makefile > src/sys/sys: cdefs_elf.h > > Log Message: > Add support for SQLite look-up tables to postfix(1), see sqlite_table(5) > for more details. > > While here stop installation of pcre_table(5) as this table type > is not supported. The change to "src/sys/sys/cdefs_elf.h" has nothing to do with this feature and was committed by accident. I've revert that change and updated the commit message in the repository. Sorry ... Kind regards -- Matthias Scheler http://zhadum.org.uk/
