For RHEL we want apps to use FIPS-certified crypto libraries,
and HMAC apparently counts as "keyed" and hence needs to
be validated.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1630260
Replaces: https://gitlab.gnome.org/GNOME/glib/merge_requests/897
This is a build-time option that backs the GHmac API with GnuTLS.
Most distributors ship glib-networking built with GnuTLS, and
most apps use glib-networking, so this isn't a net-new library
in most cases.
=======================================================================
mcatanzaro note:
I've updated Colin's original patch with several enhancements:
Implement g_hmac_copy() using gnutls_hmac_copy(), which didn't exist
when Colin developed this patch.
Removed use of GSlice
Better error checking in g_hmac_new(). It is possible for
gnutls_hmac_init() to fail if running in FIPS mode and an MD5 digest is
requested. In this case, we should return NULL rather than returning a
broken GHmac with a NULL gnutls_hmac_hd_t. This was leading to a later
null pointer dereference inside gnutls_hmac_update(). Applications are
responsible for checking to ensure the return value of g_hmac_new() is
not NULL since it is annotated as nullable. Added documentation to
indicate this possibility.
Properly handle length -1 in g_hmac_update(). This means we've been
given a NUL-terminated string and should use strlen(). GnuTLS doesn't
accept -1, so let's call strlen() ourselves.
Crash the application with g_error() if gnutls_hmac() fails for any
reason. This is necessary because g_hmac_update() is not fallible, so we
have no way to indicate error. Crashing seems better than returning the
wrong result later when g_hmac_get_string() or g_hmac_get_digest() is
later called. (Those functions are also not fallible.) Fortunately, I
don't think this error should actually be hit in practice.
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/903
Add a test for monitoring an existing local file, with the
WATCH_HARD_LINKS flag specified. This would previously cause a crash;
now it doesn’t.
This test contains a FIXME where I suspect we should be getting some
additional file change notifications from changes made through the hard
link; this requires further follow up and probably further fixes to our
inotify backend.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755721
Supports %OB (alternative, standalone, nominative) month name along
with the old %B (primary, in a complete date format context, genitive)
month name. Similarly %Ob and %Oh for abbreviated month names.
Depending on the underlying operating system uses nl_langinfo()
or provides our custom implementation.
(Tweaked by Philip Withnall <withnall@endlessm.com> to add test case
comment and bug reference.)
https://bugzilla.gnome.org/show_bug.cgi?id=749206
Since commit 96ebcee8c4, we don’t actually need libmount 2.28. Lower our
dependency to 2.23 so that we can continue to build against CentOS 7.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=793288
Building against libmount installed into a non-default prefix wasn’t
working, as we were using #include <libmount/libmount.h> rather than
the correct #include <libmount.h> — all the mount.pc pkg-config files
set `Cflags: -I${includedir}/libmount`.
Fixing this while retaining the fallback support for versions of
libmount without a pkg-config file would have been tricky (we would need
to work out a suitable -I flag to set in LIBMOUNT_CFLAGS) to still be
able to use the correct #include path). Thankfully, libmount gained
pkg-config support a long time ago, so I think we can safely drop the
fallback code. In particular, Debian Jessie, Ubuntu Trusty, and CentOS 5
all ship a mount.pc file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793288
GLib makes various assumptions about aliasing throughout its codebase,
and compiling with -fstrict-aliasing has been demonstrated to cause
problems (for example, bug #791622). Explicitly disable strict aliasing
as a result.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
As 'auto' dependency checking has been declared undesirable,
skip checking of optional dependencies where the option
defaults to true, but where the option doesn't make sense for
the operating system we're building for. Example: selinux only
makes sense on Linux, people compiling on Windows or macOS
shouldn't have to specify -Dselinux=false to get glib to build.
https://bugzilla.gnome.org/show_bug.cgi?id=792129
Properly define GLIB/GOBJECT_STATIC_COMPILATION when static build is enabled.
Use library() instead of shared_library() to allow selecting static builds.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
This is a corresponding change to meson.build to match commit
030efac0777cdc3330d3afa12dafa95f6449e14b
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=662802
The m4 and bash completion items are usable and relevant
depending on the host system's configuration. So, we check for the
presence of the programs that these items depend on, and only install
them when those programs are found.
For the Valgrind suppression files, we don't install them on Windows as
Valgrind is currently not supported on Windows.
Als fix the path where the GDB helpers are installed, as the path is
incorrectly constructed.
This will fix the "install" stage when building on Visual Studio at
least as there are some post-install steps that are related to them,
which will make use of these programs.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
We want to set _WIN32_WINNT so that functions will be properly found in
the headers, to target the NT6.1+ (Windows 7+) APIs.
Also improve the checks for if_nametoindex() and if_indextoname() on
Windows as they are supported in Windows Vista+, but they have
to be checked by linking against iphlpapi.lib (or -liphlpapi). On other
platforms, they are still checked as they were before.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Instead of hardcoding -DPCRE_STATIC into the CFLAGS of GLib, do the
following on Windows only (since PCRE_STATIC only matters on Windows):
-If there is no installed PCRE, use the included PCRE copy and
enable -DPCRE_STATIC, as we did before.
-If there is a installed PCRE, check whether the PCRE build is a static
or DLL build by checking the linkage against pcre_free() with
PCRE_STATIC defined works. If it does, enable -DPCRE_STATIC.
-On non-Windows builds, do not enable -DPCRE_STATIC
https://bugzilla.gnome.org/show_bug.cgi?id=783270
The HAVE_GOOD_PRINTF config variable determines whether we are able to
use the CRT-supplied *printf() functions directly, by determining whether
the CRT-supplied vsnprintf() and snprintf() functions support C99 well
enough.
This means, we need to build the gnulib subdir as a static lib in GLib, and use
the gnulib *printf() functions when:
-We are on Windows
-The CRT's vsnprintf() and snprintf() is not sufficiently C99-compliant.
This will fix the problem when the *printf() functions cause a CRT
abort() call on pre-2015 Visual Studio builds at least, and ensures that
the Visual Studio 2015+ builds will pass the printf tests in GLib, since
the *printf() in Visual Studio 2015/2017's CRT does not support the %n
format specifier, nor the positional parameters (which requires
different _*printf_p*() functions), as indicated by
glib/tests/test-printf.c.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Copy the msvc_recommended_pragmas.h helper header when we build for
Windows, so that people developing/using GLib on Windows can make use
of them in Visual Studio, so that unwanted compiler noise can be
filtered out and code with potentially-problematic warnings can be
attended to.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Some of the dependencies' build systems for Visual Studio do not provide a
pkg-config file upon build, so we use find_library() for them when the
corresponding pkg-config files are not found during Visual Studio builds,
so that one will not need to make up pkg-config files for them, which
could be error-prone. These .lib names match the names that are built
with the officially supported build system that is used by their
respective Visual Studio support.
For ZLib, this will make gio-2.0.pc reflect on the zlib .lib based on
what is found, or whether we use the fallback/bundled ZLib, when we
don't have a pkg-config file for ZLib on MSVC. We still need to depend
on Meson to be updated to put the correct link argument for linking ZLib
in the pkg-config case.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Without this, GNU-specific symbols won't be defined and the compiler
check will pass because GCC will assume that you know what you're
doing since it doesn't know what the symbol prototype is and compiler
checks aren't built with -Wall -Werror.
This will then cause a build failure because the wrong prototype will
be used.
We use it pretty much everywhere in order to get feature detection, and
that's also what the AC_USE_SYSTEM_EXTENSIONS m4 macro defines in the
Autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=785955
