From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 Description of problem: dos2unix does not strip away ^M properly and when compiling from source there are compiler warnings. Version-Release number of selected component (if applicable): dos2unix-3.1-21 How reproducible: Always Steps to Reproduce: 1. dos2unix "ANY FILE" 2. make clean && make [ on RPM source ] 3. Additional info: I have the fix
Created attachment 112366 [details] new patch that will get rid of extra characters after #endif This patch will get rid of extra characters after #endif in dos2unix.h
Created attachment 112367 [details] new patch that will get rid of extra characters after the #endif statements This is a new patch that will get rid of the extra characters after the #endif statements in dos2unix.c. This will get rid of compiler warnings when compiling from source.
Created attachment 112368 [details] This is update to an existing patch that strips away ^M This is an update to a patch that will strip away ^M from a file.
Created attachment 112369 [details] Simple script to apply patches This is a simple script that will apply patches in the proper order
There is an issue that needs to be fixed as well .. when using dos2unix as an privileged user on a file owned by root dos2unix overwrites the file anyway without printing, dos2unix: problems converting file filetoconvert.txt
This is my fault .. it corrects the dos2unix inconversion issue but introduces unprivileged user conversion of privileged files.
Comment on attachment 112368 [details] This is update to an existing patch that strips away ^M This is a BAD patch the introduces a security issue
Comment on attachment 112368 [details] This is update to an existing patch that strips away ^M >* Fix http://bugzilla.redhat.com/57508 (make dos2unix not modify Mac > files unless in mac2unix mode) >* Make mac2unix mode not create duplicate Unix line delimiters when > run on a DOS file. (mschwendt.net) >* Remove extra directive arguments on #endif DEBUG > statements causing compiler warnings (thesource) > >diff -Nur dos2unix-3.1-orig/dos2unix.c dos2unix-3.1/dos2unix.c >--- dos2unix-3.1-orig/dos2unix.c 1998-11-19 13:19:25.000000000 +0100 >+++ dos2unix-3.1/dos2unix.c 2004-09-26 20:57:41.606587616 +0200 >@@ -153,6 +153,24 @@ > } > > >+void StripDelimiter(FILE* ipInF, FILE* ipOutF, CFlag *ipFlag, int CurChar) >+{ >+ int TempNextChar; >+ /* Don't modify Mac files when in dos2unix mode. */ >+ if ( (TempNextChar = getc(ipInF)) != EOF) { >+ ungetc( TempNextChar, ipInF ); /* put back peek char */ >+ if ( TempNextChar != '\x0a' ) { >+ putc( CurChar, ipOutF ); /* Mac line, put back CR */ >+ } >+ } >+ else if ( CurChar == '\x0d' ) { /* EOF: last Mac line delimiter (CR)? */ >+ putc( CurChar, ipOutF ); >+ } >+ if (!ipFlag->NewLine) { /* add additional LF? */ >+ putc('\n', ipOutF); >+ } >+} >+ > /* converts stream ipInF to UNIX format text and write to stream ipOutF > * RetVal: 0 if success > * -1 otherwise >@@ -161,6 +179,7 @@ > { > int RetVal = 0; > int TempChar; >+ int TempNextChar; > > if ( macmode ) > ipFlag->ConvMode = 3; >@@ -177,9 +196,7 @@ > break; > } > } else { >- if (ipFlag->NewLine) { >- putc('\n', ipOutF); >- } >+ StripDelimiter( ipInF, ipOutF, ipFlag, TempChar ); > } > } > break; >@@ -193,9 +210,7 @@ > break; > } > } else { >- if (ipFlag->NewLine) { >- putc('\n', ipOutF); >- } >+ StripDelimiter( ipInF, ipOutF, ipFlag, TempChar ); > } > } > break; >@@ -209,9 +224,7 @@ > break; > } > } else { >- if (ipFlag->NewLine) { >- putc('\n', ipOutF); >- } >+ StripDelimiter( ipInF, ipOutF, ipFlag, TempChar ); > } > } > break; >@@ -227,6 +240,13 @@ > } > } > else{ >+ if ( (TempNextChar = getc(ipInF)) != EOF) { >+ ungetc( TempNextChar, ipInF ); /* put back peek char */ >+ /* Don't touch this delimiter if it's a CR,LF pair. */ >+ if ( TempNextChar == '\x0a' ) { >+ continue; >+ } >+ } > if (putc('\x0a', ipOutF) == EOF) > { > RetVal = -1;
(In reply to comment #6) > This is my fault .. it corrects the dos2unix inconversion issue but introduces > unprivileged user conversion of privileged files. I have seemingly fixed it the security issue I created
(In reply to comment #7) > (From update of attachment 112368 [details] [edit]) > This is a BAD patch the introduces a security issue > I will load the patch that will obsolete attachment #112368 [details]
(In reply to comment #7) > (From update of attachment 112368 [details] [edit]) > This is a BAD patch the introduces a security issue > I will upload the patch that will obsolete attachment #112368 [details]
Created attachment 112371 [details] redo of previous update to an existing patch due security issue that strips away ^M
Completely confused by this. Is this patch still needed?
Fedora Core 3 is not maintained anymore. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release please reopen this bug and assign it to the corresponding Fedora version.