From: Austin Ziegler <halostatue@...>
Date: 2019-07-30T16:12:20-04:00
Subject: [ruby-core:94060] Re: [Ruby master Bug#9529] TarHeader (Gem::Package) doesn't parse size correctly for +8GB entries

--===============0045923610==
Content-Type: multipart/alternative; boundary="0000000000003546ec058eeba14d"

--0000000000003546ec058eeba14d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This could also be addressed in [minitar](
https://github.com/halostatue/minitar) where I would happily consider a PR
for this. Using RubyGems for tar handling is an anti-pattern, as RubyGems
use of the tar format is an implementation detail, not an expected feature.

-a

On Tue, Jul 30, 2019 at 5:43 AM <hsbt@ruby-lang.org> wrote:

> Issue #9529 has been updated by hsbt (Hiroshi SHIBATA).
>
> Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN)
> Assignee changed from drbrain (Eric Hodel) to hsbt (Hiroshi SHIBATA)
> Status changed from Assigned to Third Party's Issue
>
> I'm not sure what usecase of this issue.
>
> Can you file the details into the upstream repository?
> https://github.com/rubygems/rubygems
>
> Thanks.
>
> ----------------------------------------
> Bug #9529: TarHeader (Gem::Package) doesn't parse size correctly for +8GB
> entries
> https://bugs.ruby-lang.org/issues/9529#change-80275
>
> * Author: eranhirsch (Eran Hirsch)
> * Status: Third Party's Issue
> * Priority: Normal
> * Assignee: hsbt (Hiroshi SHIBATA)
> * Target version:
> * ruby -v: ruby 1.9.3p448 (2013-06-27 revision 41675) [x86_64-darwin13.0.=
0]
> * Backport:
> ----------------------------------------
> * The current TAR header parsing code assumes the size is represented as
> an octal string
> * Because this is a 12-byte, null-terminated field, effectively this can
> represent up to 8GB (8^11).
> * For bigger files the standard allows to define the field as a 12-byte
> INTEGER instead.
> * When using this form, the first bit of the field should be turned on to
> signal that it is used.
>
> Currently, TAR files containing files larger then 8GB in this format woul=
d
> fail parsing because size would be computed as 0.
>
> (Wiki with some description of the logic, couldn't find a more "formal"
> document: http://en.wikipedia.org/wiki/Tar_(computing)#File_header)
>
> The problem is with this code:
>
> http://yard.ruby-doc.org/stdlib-2.1.0/Gem/Package/TarHeader.html#from-cla=
ss_method
>
> The line that assigns the value to size should be conditioned on the valu=
e
> of the first bit, and should treat the two cases differently
>
>
>
> --
> https://bugs.ruby-lang.org/
>
> Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=3Dunsubscrib=
e>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
>


--=20
Austin Ziegler =E2=80=A2 halostatue@gmail.com =E2=80=A2 austin@halostatue.c=
a
http://www.halostatue.ca/ =E2=80=A2 http://twitter.com/halostatue

--0000000000003546ec058eeba14d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">This could also be addressed in [minitar]=
(<a href=3D"https://github.com/halostatue/minitar">https://github.com/halos=
tatue/minitar</a>) where I would happily consider a PR for this. Using Ruby=
Gems for tar handling is an anti-pattern, as RubyGems use of the tar format=
 is an implementation detail, not an expected feature.</div><div dir=3D"ltr=
"><br></div><div>-a</div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Tue, Jul 30, 2019 at 5:43 AM &lt;<a href=3D"mai=
lto:hsbt@ruby-lang.org">hsbt@ruby-lang.org</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-l=
eft:1ex">Issue #9529 has been updated by hsbt (Hiroshi SHIBATA).<br>
<br>
Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN)<br>
Assignee changed from drbrain (Eric Hodel) to hsbt (Hiroshi SHIBATA)<br>
Status changed from Assigned to Third Party&#39;s Issue<br>
<br>
I&#39;m not sure what usecase of this issue. <br>
<br>
Can you file the details into the upstream repository? <a href=3D"https://g=
ithub.com/rubygems/rubygems" rel=3D"noreferrer" target=3D"_blank">https://g=
ithub.com/rubygems/rubygems</a><br>
<br>
Thanks.<br>
<br>
----------------------------------------<br>
Bug #9529: TarHeader (Gem::Package) doesn&#39;t parse size correctly for +8=
GB entries<br>
<a href=3D"https://bugs.ruby-lang.org/issues/9529#change-80275" rel=3D"nore=
ferrer" target=3D"_blank">https://bugs.ruby-lang.org/issues/9529#change-802=
75</a><br>
<br>
* Author: eranhirsch (Eran Hirsch)<br>
* Status: Third Party&#39;s Issue<br>
* Priority: Normal<br>
* Assignee: hsbt (Hiroshi SHIBATA)<br>
* Target version: <br>
* ruby -v: ruby 1.9.3p448 (2013-06-27 revision 41675) [x86_64-darwin13.0.0]=
<br>
* Backport: <br>
----------------------------------------<br>
* The current TAR header parsing code assumes the size is represented as an=
 octal string<br>
* Because this is a 12-byte, null-terminated field, effectively this can re=
present up to 8GB (8^11).<br>
* For bigger files the standard allows to define the field as a 12-byte INT=
EGER instead.<br>
* When using this form, the first bit of the field should be turned on to s=
ignal that it is used.<br>
<br>
Currently, TAR files containing files larger then 8GB in this format would =
fail parsing because size would be computed as 0.<br>
<br>
(Wiki with some description of the logic, couldn&#39;t find a more &quot;fo=
rmal&quot; document: <a href=3D"http://en.wikipedia.org/wiki/Tar_(computing=
)#File_header" rel=3D"noreferrer" target=3D"_blank">http://en.wikipedia.org=
/wiki/Tar_(computing)#File_header</a>)<br>
<br>
The problem is with this code:<br>
<a href=3D"http://yard.ruby-doc.org/stdlib-2.1.0/Gem/Package/TarHeader.html=
#from-class_method" rel=3D"noreferrer" target=3D"_blank">http://yard.ruby-d=
oc.org/stdlib-2.1.0/Gem/Package/TarHeader.html#from-class_method</a><br>
<br>
The line that assigns the value to size should be conditioned on the value =
of the first bit, and should treat the two cases differently<br>
<br>
<br>
<br>
-- <br>
<a href=3D"https://bugs.ruby-lang.org/" rel=3D"noreferrer" target=3D"_blank=
">https://bugs.ruby-lang.org/</a><br>
<br>
Unsubscribe: &lt;mailto:<a href=3D"mailto:ruby-core-request@ruby-lang.org" =
target=3D"_blank">ruby-core-request@ruby-lang.org</a>?subject=3Dunsubscribe=
&gt;<br>
&lt;<a href=3D"http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core=
" rel=3D"noreferrer" target=3D"_blank">http://lists.ruby-lang.org/cgi-bin/m=
ailman/options/ruby-core</a>&gt;<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature">Austin Ziegler =E2=80=A2 <a href=3D"mailto:halos=
tatue@gmail.com" target=3D"_blank">halostatue@gmail.com</a> =E2=80=A2 <a hr=
ef=3D"mailto:austin@halostatue.ca" target=3D"_blank">austin@halostatue.ca</=
a><br><a href=3D"http://www.halostatue.ca/" target=3D"_blank">http://www.ha=
lostatue.ca/</a> =E2=80=A2 <a href=3D"http://twitter.com/halostatue" target=
=3D"_blank">http://twitter.com/halostatue</a></div>

--0000000000003546ec058eeba14d--

--===============0045923610==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

--===============0045923610==--