<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugzilla.yoctoproject.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugzilla.yoctoproject.org/"
          
          maintainer="it-coreprojects-helpdesk@linuxfoundation.org"
>

    <bug>
          <bug_id>10140</bug_id>
          
          <creation_ts>2016-08-15 02:28:36 +0000</creation_ts>
          <short_desc>The output is strange when using unzip to extract zip file</short_desc>
          <delta_ts>2016-09-09 16:04:21 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>7</classification_id>
          <classification>Build System, Metadata &amp; Runtime</classification>
          <product>OE-Core</product>
          <component>core</component>
          <version>2.2</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Multiple</op_sys>
          <bug_status>VERIFIED</bug_status>
          <resolution>DUPLICATE</resolution>
          <dup_id>9551</dup_id>
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>Medium+</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>2.2 M3</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Yi Zhao">yi.zhao</reporter>
          <assigned_to name="Plauchu Edwin">edwin.plauchu.camacho</assigned_to>
          <cc>benjamin.esquivel</cc>
    
    <cc>edwin.plauchu.camacho</cc>
    
    <cc>jose.perez.carranza</cc>
    
    <cc>meta.mr.watcher</cc>
    
    <cc>meta.watcher</cc>
    
    <cc>sgw</cc>
          
          <qa_contact name="Yi Zhao">yi.zhao</qa_contact>
          <cf_os>---</cf_os>
          <cf_regression_type>Regression (Used to work)</cf_regression_type>
          
          <cf_docchange>No (bug/feature does not impact docs)</cf_docchange>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>65179</commentid>
    <comment_count>0</comment_count>
      <attachid>3355</attachid>
    <who name="Yi Zhao">yi.zhao</who>
    <bug_when>2016-08-15 02:28:36 +0000</bug_when>
    <thetext>Created attachment 3355
zip file for testing

Git rev: master/e274a5167ea2e495355bd1382b1388d047b845d7

When using unzip to extract a zip file, the output is very strange:  
#########################################
# unzip tst_unzip_file.zip 
Archive:  %s
   creating: tst_unzip.dir/
   creating: tst_unzip.dir/d.0/
%8sing: %-22s  %s%s
%8sing: %-22s  %s%s
   creating: tst_unzip.dir/d.0/d.1/
%8sing: %-22s  %s%s
%8sing: %-22s  %s%s
%8sing: %-22s  %s%s
   creating: tst_unzip.dir/d.0/d.1/d.2/
%8sing: %-22s  %s%s
%8sing: %-22s  %s%s
%8sing: %-22s  %s%s
%8sing: %-22s  %s%s
#########################################

I did a quick check and found this issue was introduced by the following commit:
commit 763a3d424bccf559a8d6add3dc1f2746c82f2933
Author: Edwin Plauchu &lt;edwin.plauchu.camacho@intel.com&gt;
Date:   Fri May 27 15:29:21 2016 -0500

    unzip: fix security issues
    
    This patch avoids unzip fails to compile with compiler flags which elevate common string formatting issues into an error (-Wformat -Wformat-security -Werror=format-security).
    
    [YOCTO #9551]
    
    (From OE-Core rev: 2dd1c02fbc7492002df9030f50710e242369e8b2)
    
After I revert this patch, the output looks correct:
#########################################
# unzip tst_unzip_file.zip 
Archive:  tst_unzip_file.zip
   creating: tst_unzip.dir/
   creating: tst_unzip.dir/d.0/
 extracting: tst_unzip.dir/d.0/f.2   
 extracting: tst_unzip.dir/d.0/f.1   
   creating: tst_unzip.dir/d.0/d.1/
 extracting: tst_unzip.dir/d.0/d.1/f.2  
 extracting: tst_unzip.dir/d.0/d.1/f.1  
 extracting: tst_unzip.dir/d.0/d.1/f.0  
   creating: tst_unzip.dir/d.0/d.1/d.2/
 extracting: tst_unzip.dir/d.0/d.1/d.2/f.2  
 extracting: tst_unzip.dir/d.0/d.1/d.2/f.1  
 extracting: tst_unzip.dir/d.0/d.1/d.2/f.0  
 extracting: tst_unzip.dir/d.0/f.0
#########################################  

The zip file for testing is attached.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>65184</commentid>
    <comment_count>1</comment_count>
    <who name="Ross Burton">ross.burton</who>
    <bug_when>2016-08-15 09:35:29 +0000</bug_when>
    <thetext>Jussi, can team FI fix the broken security fix?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>65259</commentid>
    <comment_count>2</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2016-08-17 08:07:50 +0000</bug_when>
    <thetext>Wow, the unzip macros are truly special... but I don&apos;t think the approach can be made to work:

+-#    define LoadFarString(x)        (char *)(x)
++#    define LoadFarString(x)        &quot;%s&quot;,(char *)(x)

LoadFarString is used in 1500 locations, most of them in situations where the sprintf format string is already used. Example:

    Info(slide, 0x201, ((char *)slide,
         LoadFarString(SymLnkWarnInvalid), FnFilter1(linkfname)))

with this Info implementation

    define Info(buf,flag,sprf_arg) 
         fputs((char *)(sprintf sprf_arg, (buf)), stdout);

ends up calling sprintf like this:

    sprintf ((char *)slide,
             LoadFarString(SymLnkWarnInvalid),
             FnFilter1(linkfname))

Changing LoadFarSting() definition like in the patch will end up printing literal &quot;%s&quot; as filename.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>65302</commentid>
    <comment_count>3</comment_count>
    <who name="Benjamin Esquivel">benjamin.esquivel</who>
    <bug_when>2016-08-18 15:11:42 +0000</bug_when>
    <thetext>bug 9551 got reopened to fix this problem.

*** This bug has been marked as a duplicate of bug 9551 ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>66007</commentid>
    <comment_count>4</comment_count>
    <who name="Jose Perez C">jose.perez.carranza</who>
    <bug_when>2016-09-09 16:04:21 +0000</bug_when>
    <thetext>verified as duplicate</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>3355</attachid>
            <date>2016-08-15 02:28:36 +0000</date>
            <delta_ts>2016-08-15 02:28:36 +0000</delta_ts>
            <desc>zip file for testing</desc>
            <filename>tst_unzip_file.zip</filename>
            <type>application/zip</type>
            <size>2296</size>
            <attacher name="Yi Zhao">yi.zhao</attacher>
            
              <data encoding="base64">UEsDBAoAAAAAAI9VDEkAAAAAAAAAAAAAAAAOABwAdHN0X3VuemlwLmRpci9VVAkAAw04rVcNOK1X
dXgLAAEEAAAAAAQAAAAAUEsDBAoAAAAAAI9VDEkAAAAAAAAAAAAAAAASABwAdHN0X3VuemlwLmRp
ci9kLjAvVVQJAAMNOK1XDTitV3V4CwABBAAAAAAEAAAAAFBLAwQKAAAAAACPVQxJAAAAAAAAAAAA
AAAAFQAcAHRzdF91bnppcC5kaXIvZC4wL2YuMlVUCQADDTitVw04rVd1eAsAAQQAAAAABAAAAABQ
SwMECgAAAAAAj1UMSQAAAAAAAAAAAAAAABUAHAB0c3RfdW56aXAuZGlyL2QuMC9mLjFVVAkAAw04
rVcNOK1XdXgLAAEEAAAAAAQAAAAAUEsDBAoAAAAAAI9VDEkAAAAAAAAAAAAAAAAWABwAdHN0X3Vu
emlwLmRpci9kLjAvZC4xL1VUCQADDTitVw04rVd1eAsAAQQAAAAABAAAAABQSwMECgAAAAAAj1UM
SQAAAAAAAAAAAAAAABkAHAB0c3RfdW56aXAuZGlyL2QuMC9kLjEvZi4yVVQJAAMNOK1XDTitV3V4
CwABBAAAAAAEAAAAAFBLAwQKAAAAAACPVQxJAAAAAAAAAAAAAAAAGQAcAHRzdF91bnppcC5kaXIv
ZC4wL2QuMS9mLjFVVAkAAw04rVcNOK1XdXgLAAEEAAAAAAQAAAAAUEsDBAoAAAAAAI9VDEkAAAAA
AAAAAAAAAAAZABwAdHN0X3VuemlwLmRpci9kLjAvZC4xL2YuMFVUCQADDTitVw04rVd1eAsAAQQA
AAAABAAAAABQSwMECgAAAAAAj1UMSQAAAAAAAAAAAAAAABoAHAB0c3RfdW56aXAuZGlyL2QuMC9k
LjEvZC4yL1VUCQADDTitVw04rVd1eAsAAQQAAAAABAAAAABQSwMECgAAAAAAj1UMSQAAAAAAAAAA
AAAAAB0AHAB0c3RfdW56aXAuZGlyL2QuMC9kLjEvZC4yL2YuMlVUCQADDTitVw04rVd1eAsAAQQA
AAAABAAAAABQSwMECgAAAAAAj1UMSQAAAAAAAAAAAAAAAB0AHAB0c3RfdW56aXAuZGlyL2QuMC9k
LjEvZC4yL2YuMVVUCQADDTitVw04rVd1eAsAAQQAAAAABAAAAABQSwMECgAAAAAAj1UMSQAAAAAA
AAAAAAAAAB0AHAB0c3RfdW56aXAuZGlyL2QuMC9kLjEvZC4yL2YuMFVUCQADDTitVw04rVd1eAsA
AQQAAAAABAAAAABQSwMECgAAAAAAj1UMSQAAAAAAAAAAAAAAABUAHAB0c3RfdW56aXAuZGlyL2Qu
MC9mLjBVVAkAAw04rVcNOK1XdXgLAAEEAAAAAAQAAAAAUEsBAh4DCgAAAAAAj1UMSQAAAAAAAAAA
AAAAAA4AGAAAAAAAAAAQAO1BAAAAAHRzdF91bnppcC5kaXIvVVQFAAMNOK1XdXgLAAEEAAAAAAQA
AAAAUEsBAh4DCgAAAAAAj1UMSQAAAAAAAAAAAAAAABIAGAAAAAAAAAAQAO1BSAAAAHRzdF91bnpp
cC5kaXIvZC4wL1VUBQADDTitV3V4CwABBAAAAAAEAAAAAFBLAQIeAwoAAAAAAI9VDEkAAAAAAAAA
AAAAAAAVABgAAAAAAAAAAACkgZQAAAB0c3RfdW56aXAuZGlyL2QuMC9mLjJVVAUAAw04rVd1eAsA
AQQAAAAABAAAAABQSwECHgMKAAAAAACPVQxJAAAAAAAAAAAAAAAAFQAYAAAAAAAAAAAApIHjAAAA
dHN0X3VuemlwLmRpci9kLjAvZi4xVVQFAAMNOK1XdXgLAAEEAAAAAAQAAAAAUEsBAh4DCgAAAAAA
j1UMSQAAAAAAAAAAAAAAABYAGAAAAAAAAAAQAO1BMgEAAHRzdF91bnppcC5kaXIvZC4wL2QuMS9V
VAUAAw04rVd1eAsAAQQAAAAABAAAAABQSwECHgMKAAAAAACPVQxJAAAAAAAAAAAAAAAAGQAYAAAA
AAAAAAAApIGCAQAAdHN0X3VuemlwLmRpci9kLjAvZC4xL2YuMlVUBQADDTitV3V4CwABBAAAAAAE
AAAAAFBLAQIeAwoAAAAAAI9VDEkAAAAAAAAAAAAAAAAZABgAAAAAAAAAAACkgdUBAAB0c3RfdW56
aXAuZGlyL2QuMC9kLjEvZi4xVVQFAAMNOK1XdXgLAAEEAAAAAAQAAAAAUEsBAh4DCgAAAAAAj1UM
SQAAAAAAAAAAAAAAABkAGAAAAAAAAAAAAKSBKAIAAHRzdF91bnppcC5kaXIvZC4wL2QuMS9mLjBV
VAUAAw04rVd1eAsAAQQAAAAABAAAAABQSwECHgMKAAAAAACPVQxJAAAAAAAAAAAAAAAAGgAYAAAA
AAAAABAA7UF7AgAAdHN0X3VuemlwLmRpci9kLjAvZC4xL2QuMi9VVAUAAw04rVd1eAsAAQQAAAAA
BAAAAABQSwECHgMKAAAAAACPVQxJAAAAAAAAAAAAAAAAHQAYAAAAAAAAAAAApIHPAgAAdHN0X3Vu
emlwLmRpci9kLjAvZC4xL2QuMi9mLjJVVAUAAw04rVd1eAsAAQQAAAAABAAAAABQSwECHgMKAAAA
AACPVQxJAAAAAAAAAAAAAAAAHQAYAAAAAAAAAAAApIEmAwAAdHN0X3VuemlwLmRpci9kLjAvZC4x
L2QuMi9mLjFVVAUAAw04rVd1eAsAAQQAAAAABAAAAABQSwECHgMKAAAAAACPVQxJAAAAAAAAAAAA
AAAAHQAYAAAAAAAAAAAApIF9AwAAdHN0X3VuemlwLmRpci9kLjAvZC4xL2QuMi9mLjBVVAUAAw04
rVd1eAsAAQQAAAAABAAAAABQSwECHgMKAAAAAACPVQxJAAAAAAAAAAAAAAAAFQAYAAAAAAAAAAAA
pIHUAwAAdHN0X3VuemlwLmRpci9kLjAvZi4wVVQFAAMNOK1XdXgLAAEEAAAAAAQAAAAAUEsFBgAA
AAANAA0AvwQAACMEAAAAAA==
</data>

          </attachment>
      

    </bug>

</bugzilla>