Files in 1.2.0 tarball are not world readable, leading to installing headers that are not world readable

[GoogleCodeExporter]

The 1.2.0 distfile has been prepared incorrectly: all the files are missing 
permissions for "everyone". The 1.1.0 distfile did not have this problem.

And because the install script doesn't use a program like "install" that sets 
permissions to what they should be, but instead uses "cp -a" which preserves 
files' existing (incorrect) permissions, when libvpx is installed, the header 
files end up installed without read permission for "everyone". This leads to 
programs that want to use libvpx (such as ffmpeg) failing to be able to use it. 
A simple test.c containing "#include <vpx/vpx_decoder.h>" fails with the 
nonintuitive error message "test.c:1:10: fatal error: 'vpx/vpx_decoder.h' file 
not found"; in fact, the file exists, but is unreadable.

Another reason you should not use "cp -a" is because it is not supported on Mac 
OS X 10.4 Tiger.

So the fix is twofold: use "install" instead of "cp -a"; and when you release a 
new version, ensure the permissions of the files are correct.

Original issue reported on code.google.com by ryandesi...@gmail.com on 12 Oct 2013 at 4:49

[GoogleCodeExporter]

File permissions fixed (-R o+r). TODO: install vs. cp

Original comment by louquil...@google.com on 12 Oct 2013 at 5:34

• Changed state: Started

[GoogleCodeExporter]

Thank you for working on this, but the new 1.2.0 file's permissions still don't 
seem to be right. For example, the enclosing directory has read permission for 
everyone now, but still not execute permission, which is necessary to be able 
to enter a directory. Most of the other directories in the tarball have this 
problem too. The configure script also has read permission but not execute 
permission for everyone, so it can't be executed. Normally, files that don't 
need to be executed should have 644 permission, and directories and files that 
do need to be executed should have 755 permissions.

Also, I see you replaced the existing 1.2.0 tarball. This is a problem for 
package managers like MacPorts which keep checksums for downloaded files, to 
ensure they're identical to the ones that were tested: 
https://trac.macports.org/ticket/40755 After you publish a file for users to 
download, you should never change it. If you need to publish a new file, use a 
new filename, for example with a new version number.

Oddly the new file is 2060272 bytes which is 20% larger than the old file which 
was 1715462 bytes but the tarballs inside are nearly the same size and their 
contents (aside from permissions) are identical. Perhaps different compression 
settings were used to create the two bz2 files.

Original comment by ryandesi...@gmail.com on 12 Oct 2013 at 4:03

[GoogleCodeExporter]

Unfortunately, the tarballs were made quickly with git and not examined with 
the needs of downstream packagers in mind. Hereafter they will be. I've posted 
new files that should meet requirements (though checksums have changed once 
again).

For my own reference, and relying to some degree on generally correct 
permissions in the repo, it's an operation like this:

git clone http://git.chromium.org/webm/libvpx.git
cd libvpx
git checkout v1.2.0
rm -rf .git*
find . -type f -exec chmod a+r {} +
find . -type d -exec chmod a+x {} +
cd ..
tar -jcvfp libvpx-v1.2.0.tar.bz2 libvpx
zip -r libvpx-v1.2.0.zip libvpx

Sorry for the inconvenience.

Original comment by louquil...@google.com on 14 Oct 2013 at 11:39

[GoogleCodeExporter]

Issue 646 has been merged into this issue.

Original comment by louquil...@google.com on 16 Oct 2013 at 12:26

[GoogleCodeExporter]

Original comment by johannko...@google.com on 6 Nov 2014 at 1:26

• Changed state: Done