GError codes are only unique per domain, so logging the code without
also indicating the domain is not helpful. And anyway, if the error
messages are not distinctive enough to tell the whole story then we
should fix the error messages.
Based-on-patch-by: Dan Winship <danw@gnome.org>
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
We already have "nm-utils*.h" and "NetworkManagerUtils.h" headers. Rename
"include/nm-utils-internal.h" to "nm-macros-internal.h". I think that
name is better, because this file is header-only, internal, and
repository-wide.
Also, it will never contain non-header-only declarations because
there is no backing object file under "include/".
It will only contain macros and inline functions.
A valid blob cannot start with "file://", otherwise it would
break the implementation of the certificate properties in
NMSetting8021x. Simply reject every blob in nm_setting_802_1x_set_ca_cert()
et al. that is not valid according to get_cert_scheme().
get_cert_scheme() would return PATH scheme for binary data that
later will be rejected by verify_cert(). Even worse, get_cert_scheme()
would not check whether the path is NUL terminated, hence the following
can crash for an invalid connection:
if (nm_setting_802_1x_get_ca_cert_scheme (s_8021x) == NM_SETTING_802_1X_CK_SCHEME_PATH)
g_print ("path: %s", nm_setting_802_1x_get_ca_cert_path (s_8021x))
Combine the two functions so that already get_cert_scheme() does
the same validation as verify_cert().
Also change behavior and be more strict about invalid paths:
- Now, the value is considered a PATH candidate if it starts with "file://",
(sans NUL character).
A change is that before, the "file://" (without NUL) would have
been treated as BLOB, now it is an invalid PATH (UNKNOWN).
- If the binary starts with "file://" it is considered as PATH but it
is only valid, if all the fllowing is true:
(a) the last character must be NUL.
(b) there is no other intermediate NUL character.
Before, an intermediate NUL character would have been accepted
and the remainder would be ignored.
(c) there is at least one non-NUL character after "file://".
(d) the string must be fully valid utf8.
The conditions (b) and (c) are new and some invalid(?) paths
might no longer validate.
Checking (d) moved from verify_cert() to get_cert_scheme().
As set_cert_prop_helper() already called verify_cert(), this
causes no additional change beyond (b).
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _()
will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than
"gettext (string)" (which will use the program's default domain, which
works fine for programs in the NetworkManager tree, but not for
external users). Likewise, we need to call bindtextdomain() so that
gettext can find the translations if the library is installed in a
different prefix from the program using it (and
bind_textdomain_codeset(), so it will know the translations are in
UTF-8 even if the locale isn't).
(The fact that no one noticed this was broken before is because the
libraries didn't really start returning useful translated strings much
until 0.9.10, and none of the out-of-tree clients have been updated to
actually show those strings to users yet.)
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
clang warns:
make[4]: Entering directory `./NetworkManager/libnm-util'
CC nm-setting-8021x.lo
nm-setting-8021x.c:1824:17: error: implicit conversion from enumeration type 'NMCryptoFileFormat' to different enumeration type 'NMSetting8021xCKFormat' [-Werror,-Wenum-conversion]
*out_format = format;
~ ^~~~~~
nm-setting-8021x.c:2135:17: error: implicit conversion from enumeration type 'NMCryptoFileFormat' to different enumeration type 'NMSetting8021xCKFormat' [-Werror,-Wenum-conversion]
*out_format = format;
~ ^~~~~~
Signed-off-by: Thomas Haller <thaller@redhat.com>
- Remove list of authors from files that had them; these serve no
purpose except to quickly get out of date (and were only used in
libnm-util and not libnm-glib anyway).
- Just say "Copyright", not "(C) Copyright" or "Copyright (C)"
- Put copyright statement after the license, not before
- Remove "NetworkManager - Network link manager" from the few files
that contained it, and "libnm_glib -- Access network status &
information from glib applications" from the many files that
contained it.
- Remove vim modeline from nm-device-olpc-mesh.[ch], add emacs modeline
to files that were missing it.
Remove all the GParamSpec docs, since everything now uses the gtk-doc
docs instead, so there's no point in having two copies of each (which
are often out of sync anyway).
Since we're touching so many lines anyway, also fix up the indentation
of the remaining property-installing lines, and add
G_PARAM_STATIC_STRINGS to each paramspec (so the nick strings don't
get strduped). Also, be consistent about starting a new line between
"g_object_class_install_property" and its opening parenthesis.
Fix up various issues with the docs for the NMSetting properties, and
pull in text from the GParamSpec docs where the GParamSpec docs were
better (or contained information that is necessary in the context of
nm-settings.5).
Also, consistently wrap all of the doc comments to the same width (80
columns).
Fix misused gtk-doc annotations and incorrectly-identified properties.
In particular, the upcoming introspection-based generate-settings-spec
expands macro and enum values, so if you use '%' where you should have
used '#', it will fail to find an expansion, and error out.
We made the UIs consistent last year, but missed the documentation.
Fix the docs to also consistently use "Wi-Fi" rather than "WiFi",
"Wifi", "wifi", or "WiFI"; "Ethernet" rather than "ethernet"; and
"InfiniBand" rather than "Infiniband".
- refactor register_settings to allow lookup by GType and
add the settings name to SettingInfo.
- setting NM_SETTING_NAME is deprecated and should not be set anymore.
Indeed it has always be a bug, to reset the name to a different value.
The only valid place to set the name was in the _init() function of
the derived class itself.
This is now no longer needed/possible. Instead the name get's
detected based on the registered setting types. This makes use of
the registered metadata that is available anyway since every
usable setting has to register itself.
Signed-off-by: Thomas Haller <thaller@redhat.com>
GLib-GObject-WARNING **: g_object_get_property: object class `NMSetting8021x' has no property named `pin'
GLib-GObject-WARNING **: g_object_get_property: object class `NMSetting8021x' has no property named `pin-flags'
If the certificate's format was valid, but we're asked to refer to it by
paths instead of using the raw data, 'data' would be leaked.
==23089== 8,232 (40 direct, 8,192 indirect) bytes in 1 blocks are definitely lost in loss record 5,109 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B9024539: g_array_sized_new (garray.c:195)
==23089== by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089== by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089== by 0x31FC01ED26: nm_setting_802_1x_set_client_cert (nm-setting-8021x.c:819)
==23089== by 0xC6944A4: eap_tls_reader (reader.c:2316)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
==23089== by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089== by 0xC698E3A: connection_from_file (reader.c:4316)
==23089== by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)
==23089==
==23089== 8,352 (160 direct, 8,192 indirect) bytes in 4 blocks are definitely lost in loss record 5,110 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B9024539: g_array_sized_new (garray.c:195)
==23089== by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089== by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089== by 0x31FC01E5E6: nm_setting_802_1x_set_ca_cert (nm-setting-8021x.c:538)
==23089== by 0xC694DD8: eap_peap_reader (reader.c:2358)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
==23089== by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089== by 0xC698E3A: connection_from_file (reader.c:4316)
==23089== by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)
g_malloc(), etc, never return NULL, by API contract. Likewise, by
extension, no other glib function ever returns NULL due to lack of
memory. So remove lots of unnecessary checks (the vast majority of
which would have immediately crashed had they ever run anyway, since
g_set_error(), g_warning(), and nm_log_*() all need to allocate
memory).
https://bugzilla.gnome.org/show_bug.cgi?id=693678
Make setting type registration less icky; instead of having the
connection register all the settings, have the settings themselves
register that information at library load time. Putting this sort
of thing in G_DEFINE_TYPE_WITH_CODE is apparently more standard
than the home-rolled stuff we had before. Also document the
priority stuff so when adding new settings, people know what
priority to use.
(cleanups by jklimes)
The ctype macros (eg, isalnum(), tolower()) are locale-dependent. Use
glib's ASCII-only versions instead.
Also, replace isascii() with g_ascii_isprint(), since isascii()
accepts control characters, which isn't what the code wanted in any of
the places where it was using it.
Rather than generating enum classes by hand (and complaining in each
file that "this should really be standard"), use glib-mkenums.
Unfortunately, we need a very new version of glib-mkenums in order to
deal with NM's naming conventions and to fix a few other bugs, so just
import that into the source tree temporarily.
Also, to simplify the use of glib-mkenums, import Makefile.glib from
https://bugzilla.gnome.org/654395.
To avoid having to run glib-mkenums for every subdirectory of src/,
add a new "generated" directory, and put the generated enums files
there.
Finally, use Makefile.glib for marshallers too, and generate separate
ones for libnm-glib and NetworkManager.
In cases where the actual password is non-ASCII, it may not be
possible to deliver the 802.1x password as a D-Bus string. Instead
provide an alternate field holding the password as a byte array.
In cases where both a password and password-raw are supplied,
password is preferred.
Includes subject_match and phase2_subject_match (string) parameters,
and altsubject_matches and phase2_altsubject_matches (list of string)
parameters.
subject_match is matched against a substring of the subject from the
certificate presented by the remote authentication server. If this
option is unset, no subject verification is performed.
altsubject_matches are each tested against the alternate subject name
(altSubjectName) of the certificate presented by the remote
authentication server. If this option is unset, no verification of the
altSubjectName is performed.
Clarify that these are supposed to be paths in the argument name;
this shouldn't break API as it's just an argument rename. Helps
users figure out what the argument should be without as much trouble
as 'value', which is what it was before.
