IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is probably the last change of such kind. There are many other
instances left, and fixing them all is hopeless. On the other hand,
the way mod 2^32 arithmetic works, although technically not always
well defined, is to our advantage. I suggest that only user-visible
discrepancies further be fixed.
The following comparison to st_size looks particularly bad.
The code turns out to be unused!
lib/signature.c:
> verifySizeSignature(const char * datafile, int_32 size, /*@out@*/ char * result)
> [...]
> if (size != st.st_size) {
> sprintf(result, "Header+Archive size mismatch.\n"
Some of the preceding code is probably undefined or unspecified behavior,
but there's no easy way to fix it other than rewriting, which I'm not
going to do. Surprisingly enough, the code just happens to work, due to
a series of mutual cancellations mod 2^32. As they say in Russian,
the war will write off all. Likewise, mod 2^32 arithmetic can write off
a multitude of sins (James 5:20).
> static inline rpmRC checkSize(FD_t fd, int siglen, int pad, int datalen)
[...]
> int delta;
[...]
> delta = (sizeof(struct rpmlead) + siglen + pad + datalen) - st.st_size;
Here, the expression in parentheses yields a different numeric value
depending on whether datalen is signed or unsigned. However, when delta
is finally truncated to 32 bits, the result turns out to be the same.
> switch (delta) {
> case -32: /* XXX rpm-4.0 packages */
> case 32: /* XXX Legacy headers have a HEADER_IMAGE tag added. */
> case 0:
The diff context is just big enough to see what happens.
RPMTAG_FILESIZES are interpreted as signed integers, and st_size which
has type off_t is also signed. So the 32-bit file size form the header
gets sign-extended, after which the equality to st_size does not hold.
This completes support for building packages with 2G+ files, more or
less (packaging 4G+ files is still a distant goal). I am able to build
a valid package with a 3G sparse file on both i586 and x86-64. On i586,
though, such a package cannot be installed with rpm-4.0:
error: unpacking of archive failed on file /usr/bin/6;5a70a676:
cpio: write failed - File too large
I believe there is no obvious way to identify and mark such packages,
since rpmlib(LargeFiles) dependency is meant only for 4G+ files, which
require 07070X cpio entries.
Therefore, limited support for handling such packages shall be provided
for rpm-4.0 in branch p8 (there are issues other than simply enabling
AC_SYS_LARGEFILE).
This turns out to be a bit easier than I thought yesterday. When mmap
fails in lib/fsm.c, it falls back to file descriptor IO. So by simply
enabling AC_SYS_LARGEFILE, I'm already able to package a 3G file, which
can be written like this:
perl -e 'seek STDOUT,3<<30,0 and print 1 or die' >out
The nearest goal is to be able to package files up to 4G, on both 32-bit
64-bit architectures, provided that cpio payload size also does not
exceed 4G. More specifically, the limit is 2^32-2, while 2^32-1 remains
special (this is not my own invention, I adopt it from rpm.org).
If the limit is exceeded, rpmbuild should fail gracefully instead of
writing malformed packages with truncated integer tags.
(Supporting 4G+ files is a distant goal - neither rpm-4.0 nor apt-rpm
can handle them yet. Besides, it's not clear if producing such big
packages is even a good idea, unless one wishes to package p0rn.)
This is the reason why files >= 2G could not be added to cpio, even on
64-bit architectures. Fwrite was called with a buffer >= 2G, but the
return value was truncated to int (this narrowing conversion is probably
undefined behavior already; what happens next, though, is that after
casting to size_t it assumes a very big numeric value of >= 2^64-2^32).
So rpmbuild was failing with an unrelated errno, "cpio: write failed -
Bad file descriptor".
There are other reasons why this still won't work on 32-bit architectures.
For one, rpmbuild mmaps a file before feeding it to cpio, and 32-bit
architectures have a very limited ability, if any, to mmap 2G+ files.
[4.0.4-alt102]
+ verify-elf: fixed passing of LD_PRELOAD in verify_unresolved.
[4.0.4-alt101]
+ verify-elf: made verify_lfs check shared objects too.
+ Relaxed check for gcc package name in {cpp,pkgconfiglib}.req generators.
[4.0.4-alt100.99]
+ Updated generator of non-LFS functions list.
[4.0.4-alt100.97]
+ fixup-libraries: fixed recognition of PIEs (ldv@).
+ verify-elf: treat PIEs as executables in the check for unresolved symbols (ldv@).
In verify_unresolved(), do not preload requested objects to $elf_ldd
directly because the latter is not an ELF interpreter but a shell
script. Instead, pass the list of objects that have to be preloaded
to $elf_ldd script which in turn assigns it to LD_PRELOAD variable
in the ELF interpreter invocation.
In file included from /usr/include/string.h:648:0,
from ../system.h:76,
from rpmio.c:6:
In function 'strncat',
inlined from 'Fdopen' at rpmio.c:3473:5:
/usr/include/bits/string3.h:158:10: warning: call to __builtin___strncat_chk might overflow destination buffer
return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
Previously, verify_lfs checked if object has valid interpreter, but it
doesn't make sense in case of shared objects. verify_lfs check is valid
for all ELFs linked with libraries supporting both LFS and non-LFS API
(libc.so and libz.so in our case).
Previously (according to the exit statuses):
0. if something strange was found in $rpath, an error was reported;
1. if nothing strange was found, no error was reported;
2. if grep failed, it looked like the previous case and no error was
reported (as if $rpath was valid).
Now, the pipe (and the whole script) would abort on grep's failure.
Now, if something fails, the pipe (and the function, and the whole
script) will fail.
If the exit codes are normal, they are handled according to our logic.
Previously, a failure (which is an exceptional rare case) would lead to:
1. skipping the further exe_stack check and error_strict STACK "$f" 'STACK entry not found'
2. silently skipping the exe_stack check (which was impossible anyway because of the failure)
The pipe (and the function, and the whole script) would fail when the
resulting constructed rpath was empty. But usually at least
$RPM_VERIFY_ELF_LDD_RPATH is not empty, so the bad behavior has not
been observed.
- verify-elf: honor RUNPATH in addition to RPATH, too (like in lib.req).
- (unnoticeable) shell.req: generalize the shebang regexp w.r.t. other
hardcoded locations of /usr/bin/env. (No need to be too strict here:
shebang.req should catch bad locations. It's not our job.)
- %distribution: ALT Linux --> ALT (ALT#32707).
From ld.so's documentation about the search order:
Using the directories specified in the DT_RPATH dynamic section
attribute of the binary if present and DT_RUNPATH attribute does not
exist. Use of DT_RPATH is deprecated.
Reasons:
1. code clarity (and more robust w.r.t. to future changes which might
lead to bugs, as before)
2. to give all the special methods a chance to print something in the
case of an empty list, too (when needed)
Since there appeared a special handling for just some kind of
symlinks, "$tmpdir"/files gave only a part of "$tmpdir"/files+types --
the final list of what to analyze.
- find-requires: treat symlinks leading to some real content all way
through the same package as that content.
- find-{requires,provides}: in case of an error in it, the pipe to it
will be broken (must not change the visible behavior of rpm-build).
