A bunch of CMake developers, who apparently did not comprehend the previous
compatibility promise statement, decided to passive-aggressively demand we fix
their non-bug anyway.
Clarify in more detail what level of pkg-config compatibility we provide, and
mention that such passive-aggressive behaviour is considered a CoC violation.
Fixes#228.
Prior to this commit, the code path responsible for prefix redefinition
(motivated by --define-prefix or otherwise) was visited more than
once, specifically since the check ignored pkg->owner->prefix_varname.
The current approach was to parse the .pc and, detect the prefix, throw
everything together and at the end replace all \ with / to not produce invalid
escape sequences.
This has the problem that escaping in .pc files is ignored and no longer
possible. Also in case the prefix path has a space in it the result would be
invalid because of missing escaping.
This changes the following things:
* We no longer normalize values at the end. Instead we assume .pc files use "/"
as a directory separator or "\\", same format as under Unix. "\" alone no
longer works. This shouldn't be a problem since most build tools produce .pc
files with "/" like meson, cmake, autotools.
* When injecting the prefix at runtime we convert the prefix to use "/" and
escape spaces so that in combination with the .pc content the result is a
valid escaped path value again.
This patch has been used in MSYS2 for some months now.
See #212
On Windows, pkgconf redefines the prefix by default.
This gives the user the option to disable this behavior via an environment variable.
The benefit of an environment variable is the user can change this behavior when
using a build system such as cmake or meson, which may not expose this
parameter to the user.
To avoid a crash on some platforms (like Darwin 9) provide a buffer to
realpath(3).
Darwin 9 (last PPC target) documents realpath needs to be given a buffer
to the resolved_path argument large enough to hold PATH_MAX bytes.
With NULL argument it crashes. Solaris makes no mention of
resolved_path to be allowed NULL, yet recent versions accept it and
malloc(3) accordingly.
Because the documentation explicitly mentions PATH_MAX being the limit
to what realpath(3) would write in resolved_path, switching to a static
buffer here doesn't limit resolution compared to dynamically allocating
a buffer by realpath(3).
While this change requires a bit more space on the stack, it avoids a
malloc/free sequence, and allows successful operation on (older)
platforms that lack support for dynamically allocating a return buffer
in realpath(3).
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
when using library() instead of shared_library() the user can decide
to build a shared or static version, or both. The default is still shared
as before.
This mirrors what the autotools based build sysstem can do.
In case the version string has no whitespace then strcspn() returns
strlen() of the input, so whitespace is only found if len != strlen.
This fixes invalid warnings when parsing version fields.
If a file with a matching "uninstalled" name exists but cannot be
parsed, an invalid memory area is accessed.
How to reproduce:
$ touch poc-uninstalled.pc
$ PKG_CONFIG_PATH=. pkgconf poc
This is the same issue which has been fixed in dependency code.
If a line contains a variable which is longer than PKGCONF_ITEM_SIZE,
then the varname buffer overflows.
The code itself still does not check if a closing } exists and
truncates variable names which are too long. Since these would
be functional changes and this commit is about a protection against
undefined behaviour on a language level, these changes are not
included.
Proof of concept:
$ echo "Description: poc" > poc.pc
$ echo "Version: 1" >> poc.pc
$ echo -n 'Name: ${'
$ dd if=/dev/zero bs=1 count=66535 | tr '\0' 'x' >> poc.pc
$ echo >> poc.pc
$ pkgconf poc.pc
On my Linux system, when compiled with gcc, the varname buffer overflows
directly into buf, which means that no crash can be notified.
It's easiest to figure out when adding strlen() and sizeof() output
as debug lines.
fragment_quote adds quotation to fragments if needed. It allocates a
buffer and grows it as needed.
Unfortunately the dst pointer is not updated after a realloc, which
means that dst still points into the old memory area. Further writing
characters into that area leads to out of boundy writes.
Proof of concept:
$ cat > poc.pc << EOF
Name: poc
Description: poc
Version: 1
CFlags: -Ia
CFlags: -I%%%%%%%%%%%%%%%%%%%%b
CFlags: -I%%%%%%%%%%%%%%%%%%%%c
CFlags: -Id
EOF
$ pkgconf --cflags poc.pc
Most reliable attempt is to compile pkgconf with address sanitizer,
but this file should lead to an abort on a glibc system due to modified
chunk pointers (tested with Linux on amd64).
But since this is undefined behaviour, it depends on system details.
Parsing a fragment which consists only of a single dash leads to
an out of boundary read. It duplicates the following entry which
is not expected behaviour if another fragment follows.
Proof of concept:
$ cat > poc.pc << "EOF"
Name: poc
Description: poc
Version: 1
Cflags: - -I/somewhere
EOF
$ PKG_CONFIG_PATH=. pkgconf --cflags poc
-I/somewhere -I/somewhere
If - is the last entry, it leads to an out of boundary read, which is
easy to see if pkgconf is compiled with address sanitizer.
Ariadne Conill
Sandro Mani