[Bug binutils/26960] New: QueryRi
https://sourceware.org/bugzilla/show_bug.cgi?id=26960 Bug ID: 26960 Summary: QueryRi Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: queryzura at gmail dot com Target Milestone: --- Created attachment 13001 --> https://sourceware.org/bugzilla/attachment.cgi?id=13001&action=edit QueryRi -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26961] New: QueryRi
https://sourceware.org/bugzilla/show_bug.cgi?id=26961 Bug ID: 26961 Summary: QueryRi Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: queryzura at gmail dot com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 Nick Clifton changed: What|Removed |Added Attachment #12999|0 |1 is obsolete|| --- Comment #5 from Nick Clifton --- Created attachment 13002 --> https://sourceware.org/bugzilla/attachment.cgi?id=13002&action=edit Proposed patch Well that was embarrassing. I really should test my patches before posting them. So - here is a better patch for you to try. This one definitely compiles, but I have not actually tested it myself as I do not have a mingw test environment. Please let me know if this one works. :-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26907] objcopy gives memsiz to segment containing empty SHT_NOBITS section
https://sourceware.org/bugzilla/show_bug.cgi?id=26907 --- Comment #3 from Jozef Lawrynowicz --- (In reply to Alan Modra from comment #2) > It's not just the objcopy going wrong here. ld shouldn't be creating two > PT_LOAD headers where one would suffice. Is it intended that empty .bss sections are considered part of a segment's contents in the first place? Other types of empty section are simply ignored and don't affect segment layout. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 --- Comment #6 from katayama.hirofumi.mz at gmail dot com --- It causes abnormal termination. $ ./windres.exe "--preprocessor=/mingw32/bin/c pp.exe" a.rc -o a_res.o && echo "OK" $ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 --- Comment #7 from katayama.hirofumi.mz at gmail dot com --- $ ./windres.exe b.rc -o b_res.o && echo "OK" Also doesn't work. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 --- Comment #8 from katayama.hirofumi.mz at gmail dot com --- Sorry, my envirnment was broken. Now your patch works. OK. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 --- Comment #9 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=21c33bcbe36377abf01614fb1b9be439a3b6de20 commit 21c33bcbe36377abf01614fb1b9be439a3b6de20 Author: Nick Clifton Date: Fri Nov 27 14:18:20 2020 + Allow spaces in the name of the external preprocessor used by windres. PR 26865 * windres.c (main): If the preprocessor name includes spaces, ensure that it is quoted. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26865] windres: --preprocessor option won't respect space in file path
https://sourceware.org/bugzilla/show_bug.cgi?id=26865 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Nick Clifton --- Phew! Patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 --- Comment #3 from Nick Clifton --- Created attachment 13003 --> https://sourceware.org/bugzilla/attachment.cgi?id=13003&action=edit Proposed patch Hi Rich, Ok - here is my first attempt at creating a patch. Please could you give it a look over ? There is one place where smart_rename() is called without having a previous call to make_tempname(): arsup.c:ar_save(). I am not sure if represents a possible attack vector, so any advice would be appreciated. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 --- Comment #4 from Rich Felker --- That's a lot to review without being familiar with the code, but a couple things I can tell you right off: 1. make_tempname with fd_return==NULL is *always* a bug, and defeats the whole purpose of mkstemp. It's the same as if you were using the deprecated insecure mktemp. Except in a directory that nobody else can write, or with sticky bit, you can never again be sure the name refers to the file you created. 2. smart_rename needs(*) *two* fds, not just one. It needs the fd of the file you're replacing, to get the ownership and mode from it via fstat, and the fd of the temp file it will be renaming over top of the old name, to set the ownership and mode via fchown and fchmod. If either of these is unavailable it can't safely copy ownership or mode information. * Technically the caller could have called fstat on the original file being replaced already, and pass the owner/mode information (or the whole stat structure) into smart_rename rather than passing the fd, but I think it makes more sense to just pass the fd. -- You are receiving this mail because: You are on the CC list for the bug.
