site_archiver(a)lists.apple.com
Delivered-To: darwin-dev(a)lists.apple.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=P8waPumWnnBStl3gsFZNFaLeQm99DpY3JFgiLzglNxk=; b=q+sIm8R/l4Uy72f4MO7uS4gE8QgHw6n+MtJCSH89UInDm0di4ps4cHEhMgtYkOobma Yk7TY2iMan4qT+4ej7nBPM7VAyVTS+HTpex0sCYHlKqrOcsChUj9PPzcuo6ZZ1sgPsk7 cIGm5s6OlLaQ3t05QsESmyhCV7zMug1LMnby3iXZDcbZXRHfwPCgM/ofDWPuQI9Ce0ge ERv0vmx+ZEzv8Bxau6D2XJbyDF/LDqTGOUnTe3X+TD9rD+KOUmdQius8lCd7MfB0FZDu uJH6RxNaRXD5HQAMFEXEwv54CObv7h+8Eu9VMOHPKD5A9IfjeDiFojQ5WdXgQ2qGzrvr jJKA==
To be more accurate, the name of the file or folder is encoded during
the xar_add call inside the "name" property when the UTF-8
representation of the name can not be converted to ISO Latin 1 (don't
ask me why, I would have assumed that UTF-8 is a better encoding
solution). Checking the compatibility with ISO Latin 1 is performed
via a libxml2 API that is successful or not for the "same" string
depending on its mapping.
And it just happens that the mapping used by HFS+ for file names is
going to make this check fail and so file names with accented
characters will be encoded using base64 via a libxml2 API but decoded
via some custom (buggy) code from the xar lib.
This also explains, for instance, why productbuild produces .pkg
archives that will fail during decompression if one of the packages'
name contains accented characters.
Of course, there is at least another bug in the macOS installation
framework that would prevent such a flat distribution from working
correctly.
On Mon, Feb 12, 2018 at 10:46 AM, dev.iceberg <dev.iceberg(a)gmail.com> wrote:
> I would tend to believe it does at a higher level. Because, IIRC what I saw
> during step debugging, if you don't have characters outside the ASCII range,
> the name of the file is not encoded during the creation of the archive. So
> the base64 branch is not invoked when unarchving or listing the contents of
> the archive.
>
> Envoyé de mon iPhone
>
>> Le 11 févr. 2018 à 11:11, Jean-Daniel <mailing(a)xenonium.com> a écrit :
>>
>>
>>
>>> Le 11 févr. 2018 à 01:10, Stephane Sudre <dev.iceberg(a)gmail.com> a écrit :
>>>
>>> Just for info.
>>>
>>> There's a bug in the xar_from_base64 function of the b64.c file of the
>>> xar project (which is used in pkgutil and probably in
>>> PackageKit.framework).
>>>
>>> The output of the function can be incorrect because the output array
>>> of unsigned chars is is not set to 0.
>>>
>>> This is the bug:
>>>
>>> output = malloc(3 * (inputLength / 4 + 1));
>>>
>>> So in case output is allocated to some location that was previously
>>> used, the contents of output will not be a bunch of zeroes (so no
>>> terminating NULL char after the last decoded character). And anyway,
>>> it should not be assumed to be a bunch of zeroes.
>>>
>>> It just happens that having a distribution package (.pkg) containing a
>>> Package name with some accented characters (such as é) will trigger
>>> the bug every single time when using pkgutil --expand or xar -tc
>>
>> I’m not sure the accented char has anything to do with that.
>> I would rather guess this is because your package malloc small enough space
>> that the system don’t have to use the big malloc zone (which usually provide
>> fresh pages that are zeroed lazily).
>>
>>>
>>> This problem can be reproduced on Mac OS X 10.10.5 and 10.11.6 with
>>> the Apple built binaries and it can be reproduced using the latest xar
>>> source code available on opensource.apple.com (xar-400). And based on
>>> what I see in xar-28, the problem is apparently there since Mac OS X
>>> 10.5.0.
>>>
>>> Problem# 37427477
>>
>>
--
Packaging Resources - http://s.sudre.free.fr/Packaging.html
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (Darwin-dev(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap…
This email sent to site_archiver(a)lists.apple.com
site_archiver(a)lists.apple.com
Delivered-To: darwin-dev(a)lists.apple.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pW42HLXeYTvuwtoYvlZscP5oZXDPqpLxnRdetHMsrXY=; b=GQehROK8hFfe7nywDWxBZ2AkdbtJjrFCz5jrIaxS3Anew2KMMcNELXdmFT7BdYGtJa ka9dw0gZxVktiiYhepv4qpxOAG5SXY4IZElznEW+5tr+tTOIenu5Nzo1ppjEOBWUzf+e +4H8Yaq8Nh9OTklyAvwmHmAR1DrqTkjrE8nRTOZcJ3VpasRI4nDF7zYd7KdzZXWneIF4 KTrQESmyOuQHZOFEvW52MXBeYbD5wTT9qegFhQDV3JuGX42qExecDHYpEWKOJIuo1uvb V2XEmCmiFPDBDcjJtQQ/mttnqgRATkuEXgePTumgWD+fONRFVnSqt0MUDmj3QFZtGPpq sx2w==
I would tend to believe it does at a higher level. Because, IIRC what I saw
during step debugging, if you don't have characters outside the ASCII range,
the name of the file is not encoded during the creation of the archive. So the
base64 branch is not invoked when unarchving or listing the contents of the
archive.
Envoyé de mon iPhone
> Le 11 févr. 2018 à 11:11, Jean-Daniel <mailing(a)xenonium.com> a écrit :
>
>
>
>> Le 11 févr. 2018 à 01:10, Stephane Sudre <dev.iceberg(a)gmail.com> a écrit :
>>
>> Just for info.
>>
>> There's a bug in the xar_from_base64 function of the b64.c file of the
>> xar project (which is used in pkgutil and probably in
>> PackageKit.framework).
>>
>> The output of the function can be incorrect because the output array
>> of unsigned chars is is not set to 0.
>>
>> This is the bug:
>>
>> output = malloc(3 * (inputLength / 4 + 1));
>>
>> So in case output is allocated to some location that was previously
>> used, the contents of output will not be a bunch of zeroes (so no
>> terminating NULL char after the last decoded character). And anyway,
>> it should not be assumed to be a bunch of zeroes.
>>
>> It just happens that having a distribution package (.pkg) containing a
>> Package name with some accented characters (such as é) will trigger
>> the bug every single time when using pkgutil --expand or xar -tc
>
> I’m not sure the accented char has anything to do with that.
> I would rather guess this is because your package malloc small enough space
> that the system don’t have to use the big malloc zone (which usually provide
> fresh pages that are zeroed lazily).
>
>>
>> This problem can be reproduced on Mac OS X 10.10.5 and 10.11.6 with
>> the Apple built binaries and it can be reproduced using the latest xar
>> source code available on opensource.apple.com (xar-400). And based on
>> what I see in xar-28, the problem is apparently there since Mac OS X
>> 10.5.0.
>>
>> Problem# 37427477
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (Darwin-dev(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap…
This email sent to site_archiver(a)lists.apple.com
site_archiver(a)lists.apple.com
Delivered-To: darwin-dev(a)lists.apple.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xenonium.com; s=201801; t=1518343904; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=l6sUhyPIYtwvE7Cd9zDYB0nXrlOblKkNNIDkfB4PRz4=; b=HIjE5si6GPKy3A+vBRvBs75L+gatdfl/FqhteRERDBhi3KFrvHG3sVv17fMkrsINh+04Go JkTkadRS4KF6YRvrw+pdO3FnsTDra+bR8GBOTUKhqExS09/mKI8FiTPjDwGC243g4snrR1 wYjKUq9Q0P6mqE0XXnPJjycGeKI8eLM=
> Le 11 févr. 2018 à 01:10, Stephane Sudre <dev.iceberg(a)gmail.com> a écrit :
>
> Just for info.
>
> There's a bug in the xar_from_base64 function of the b64.c file of the
> xar project (which is used in pkgutil and probably in
> PackageKit.framework).
>
> The output of the function can be incorrect because the output array
> of unsigned chars is is not set to 0.
>
> This is the bug:
>
> output = malloc(3 * (inputLength / 4 + 1));
>
> So in case output is allocated to some location that was previously
> used, the contents of output will not be a bunch of zeroes (so no
> terminating NULL char after the last decoded character). And anyway,
> it should not be assumed to be a bunch of zeroes.
>
> It just happens that having a distribution package (.pkg) containing a
> Package name with some accented characters (such as é) will trigger
> the bug every single time when using pkgutil --expand or xar -tc
I’m not sure the accented char has anything to do with that.
I would rather guess this is because your package malloc small enough space
that the system don’t have to use the big malloc zone (which usually provide
fresh pages that are zeroed lazily).
>
> This problem can be reproduced on Mac OS X 10.10.5 and 10.11.6 with
> the Apple built binaries and it can be reproduced using the latest xar
> source code available on opensource.apple.com (xar-400). And based on
> what I see in xar-28, the problem is apparently there since Mac OS X
> 10.5.0.
>
> Problem# 37427477
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (Darwin-dev(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap…
This email sent to site_archiver(a)lists.apple.com
site_archiver(a)lists.apple.com
Delivered-To: darwin-dev(a)lists.apple.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=NVE2BhyIXhAAfLCilBcoFqg05wInwIPTkwk2ti6p4Hc=; b=JcbeiywBmVxpO4qFbEMXj0m1TBXiVA7Bd9jaFltQARYnxHKFKVr98cbFhV7OaT3pwX w+WgFzH8iXmabs43bDlvITKVRB5aM7albwxK6QeKt2g+qWIyW81tiTg6gFXroPVJ/6uk DCKBy9JGOVkEvLA/5P3Xz/6YbR+d3tJWxCrgv/pQ4lLEkvDAw5wRHxGIwDph+w6LFMPM FrK1AEYKF0Ctww+8NssZEQWKjqKZbtR/x6n3SV2/CLl1+WB4jI75DQMpIafdz3PkAwLJ nRrjqDBBfoJpFIUEVAqoShcMSn1OpFNIJcxjUmbkFqmncIAvaoGsEZGMtN3vehmGwfPg PYOg==
Just for info.
There's a bug in the xar_from_base64 function of the b64.c file of the
xar project (which is used in pkgutil and probably in
PackageKit.framework).
The output of the function can be incorrect because the output array
of unsigned chars is is not set to 0.
This is the bug:
output = malloc(3 * (inputLength / 4 + 1));
So in case output is allocated to some location that was previously
used, the contents of output will not be a bunch of zeroes (so no
terminating NULL char after the last decoded character). And anyway,
it should not be assumed to be a bunch of zeroes.
It just happens that having a distribution package (.pkg) containing a
Package name with some accented characters (such as é) will trigger
the bug every single time when using pkgutil --expand or xar -tc
This problem can be reproduced on Mac OS X 10.10.5 and 10.11.6 with
the Apple built binaries and it can be reproduced using the latest xar
source code available on opensource.apple.com (xar-400). And based on
what I see in xar-28, the problem is apparently there since Mac OS X
10.5.0.
Problem# 37427477
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (Darwin-dev(a)lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap…
This email sent to site_archiver(a)lists.apple.com