Skip to content

Conversation

@precla
Copy link
Collaborator

@precla precla commented Sep 5, 2024

for reasons to me yet unknown: it builds fine if the file zconf.h is deleted. Fails with a lot of errors if the file exists

log:

$ zig build
install
└─ install zlib
   └─ zig build-lib zlib Debug native 10 errors
zlib/gzlib.c:242:9: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations
        LSEEK(state->fd, 0, SEEK_END);  /* so gzoffset() is correct */
        ^
zlib/gzlib.c:14:17: note: expanded from macro 'LSEEK'
#  define LSEEK lseek
                ^
zlib/gzlib.c:248:24: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations
        state->start = LSEEK(state->fd, 0, SEEK_CUR);
                       ^
zlib/gzlib.c:14:17: note: expanded from macro 'LSEEK'
#  define LSEEK lseek
                ^
zlib/gzlib.c:332:9: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations
    if (LSEEK(state->fd, state->start, SEEK_SET) == -1)
        ^
zlib/gzlib.c:14:17: note: expanded from macro 'LSEEK'
#  define LSEEK lseek
                ^
zlib/gzlib.c:369:15: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations
        ret = LSEEK(state->fd, offset - (z_off64_t)state->x.have, SEEK_CUR);
              ^
zlib/gzlib.c:14:17: note: expanded from macro 'LSEEK'
#  define LSEEK lseek
                ^
zlib/gzlib.c:455:14: error: call to undeclared function 'lseek'; ISO C99 and later do not support implicit function declarations
    offset = LSEEK(state->fd, 0, SEEK_CUR);
             ^
zlib/gzlib.c:14:17: note: expanded from macro 'LSEEK'
#  define LSEEK lseek
                ^
zlib/gzwrite.c:78:20: error: call to undeclared function 'write'; ISO C99 and later do not support implicit function declarations
            writ = write(state->fd, strm->next_in, put);
                   ^
zlib/gzwrite.c:108:24: error: call to undeclared function 'write'; ISO C99 and later do not support implicit function declarations
                writ = write(state->fd, state->x.next, put);
                       ^
zlib/gzwrite.c:627:9: error: call to undeclared function 'close'; ISO C99 and later do not support implicit function declarations
    if (close(state->fd) == -1)
        ^
zlib/gzread.c:22:15: error: call to undeclared function 'read'; ISO C99 and later do not support implicit function declarations
        ret = read(state->fd, buf + *have, get);
              ^
zlib/gzread.c:599:11: error: call to undeclared function 'close'; ISO C99 and later do not support implicit function declarations
    ret = close(state->fd);
          ^
error: the following command failed with 10 compilation errors:
/usr/bin/zig build-lib -cflags -Wall -Wextra -Wpedantic -- zlib/adler32.c zlib/compress.c zlib/crc32.c zlib/deflate.c zlib/gzclose.c zlib/gzlib.c zlib/gzread.c zlib/gzwrite.c zlib/infback.c zlib/inffast.c zlib/inflate.c zlib/inftrees.c zlib/trees.c zlib/uncompr.c zlib/zutil.c -ODebug -Mroot -lc --cache-dir zlib/.zig-cache --global-cache-dir /home/user/.cache/zig --name zlib -static --listen=- 
Build Summary: 0/3 steps succeeded; 1 failed (disable with --summary none)
install transitive failure
└─ install zlib transitive failure
   └─ zig build-lib zlib Debug native 10 errors
error: the following build command failed with exit code 1:
zlib/.zig-cache/o/cfe7f527f4c329cbb0f1ed2a38d6cd0f/build /usr/bin/zig zlib zlib/.zig-cache /home/user/.cache/zig --seed 0xf5590a51 -Z8b27aa865680b995

tbeu and others added 30 commits August 20, 2023 11:38
To avoid warnings when building with -Wmissing-prototypes.
A bug fix in zlib 1.2.12 resulted in a slight slowdown (1-2%) of
deflate. This commit provides the option to #define LIT_MEM, which
uses more memory to reverse most of that slowdown. The memory for
the pending buffer and symbol buffers is increased by 25%, which
increases the total memory usage with the default parameters by
about 6%.
The appnote says that if the number of entries in the end record
is 0xffff, then the actual number of entries will be found in the
Zip64 end record. Therefore if the number of entries is equal to
0xffff, it can't be in the end record by itself, since that is an
instruction to get the number from the Zip64 end record. This code
would just store 0xffff in the end record in that case, not making
a Zip64 end record. This commit fixes that.
fdopen() is not used by zlib anymore. The #defines are vestigial.
Since each element in s->d_buf is 2 bytes, the sx index should be
multiplied by 2 in the assert.

Fixes madler#897
If it is negative, then the code will enter an infinite loop.
Archive formats such as .zip files are generally susceptible to
so-called "traversal attacks". This allows an attacker to craft
an archive that writes to unexpected locations of the file system
(e.g., /etc/shadow) if an unspecting root user were to unpack a
malicious archive.

This patch neutralizes absolute paths such as /tmp/moo and deeply
relative paths such as dummy/../../../../../../../../../../tmp/moo

The Debian project requested CVE-2014-9485 be allocated for the
first identified weakness. The fix was incomplete, resulting in a
revised patch applied here. Since there wasn't an updated version
released by Debian with the incomplete fix, I suggest we use this
CVE to identify both issues.

Link: https://security.snyk.io/research/zip-slip-vulnerability
Link: https://bugs.debian.org/774321
Link: https://bugs.debian.org/776831
Link: https://nvd.nist.gov/vuln/detail/CVE-2014-9485
Reported-by: Jakub Wilk <jwilk@debian.org>
Fixed-by: Michael Gilbert <mgilbert@debian.org>
gz_intmax() is noted in zlib.map. This assures it's always there.
There used to be one, but no more. It is up to the user or vendor
to compile zlib.
The --version-script linker option is not supported by the linker on AIX systems
This avoids trying to compare a match starting one byte before the
current window. Thanks to @zmodem (Hans) for discovering this.
Not all C compilers have a -w option.
This enables the addition of zlib to other projects.
@precla
Copy link
Collaborator Author

precla commented Sep 5, 2024

@plajjan can you update your develop branch, then git checkout v1.3.1 and push that as a branch? i'd like to target v1.3.1 to avoid having zlib commits

@plajjan
Copy link

plajjan commented Sep 5, 2024

Right, so that zlib ships a zconf.h seems like a problem. In the CMakeLists.txt the zconf.h is moved out of the way in order to make room for the one that CMake generates from zconf.h.cmakein.

if(NOT CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR)
    # If we're doing an out of source build and the user has a zconf.h
    # in their source tree...
    if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h)
        message(STATUS "Renaming")
        message(STATUS "    ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h")
        message(STATUS "to 'zconf.h.included' because this file is included with zlib")
        message(STATUS "but CMake generates it automatically in the build directory.")
        file(RENAME ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h.included)
  endif()
endif()

I tried adding some code to build a config header from zconf.h.cmakein but it is basically moot because it becomes available by zconf.h but it is shadowed by the already existing zconf.h. The CMake config above moves the zconf.h but I don't think that's possible with build.zig because it's truly a out-of-tree build, so we can't really touch the source directory I think. I mean, build.zig is a normal zig program, so we can of course do anything we want, but it's not what is supposed to happen.

I am ready to consider the upstream zlib basically broken. It seems wrong to ship a zconf.h like this. I presume it is done to enable some very basic building without cmake or similar, still though, seems bad.

Our goal is to have a working build.zig. It's just a branch off of the v1.3.1 (and in the future some other version tag). It's ok if we break some other build toolchain I think, so let's just remove the zconf.h file, right?

@plajjan
Copy link

plajjan commented Sep 5, 2024

@precla I have pulled in the changes to develop branch from upstream so I guess you can rebase!?

@precla
Copy link
Collaborator Author

precla commented Sep 6, 2024

@precla I have pulled in the changes to develop branch from upstream so I guess you can rebase!?

i'd rather close it now that we have the zig-kll branch

It's ok if we break some other build toolchain I think, so let's just remove the zconf.h file, right?

yup, we don't really need to care about some other toolchain if it builds fine with zig

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.