Revert "Make `Dictionary::Remove(Iterator)` return the next iterator" and
change the one location that now made use of that return value to increment the
iterator itself beforehand. I don't see anything that would be wrong with the
previous code and I'm pretty certain this is a compiler bug. While at it, I've
also removed a stray semicolon and changed the increment in the other branch to
the prefix operator as the value is discarded.
[35/151] Building CXX object lib/base/CMakeFiles/base.dir/base_unity.cpp.o
FAILED: lib/base/CMakeFiles/base.dir/base_unity.cpp.o
/usr/bin/c++ -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DBOOST_COROUTINES_NO_DEPRECATION_WARNING -DBOOST_FILESYSTEM_NO_DEPRECATED -DOPENSSL_SUPPRESS_DEPRECATED -D_GNU_SOURCE -I/builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f -I/builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib -isystem /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/third-party/nlohmann_json -isystem /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/third-party/utf8cpp/source -isystem /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/third-party/mmatch -isystem /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/third-party/socketpair -O2 -g -Wsuggest-override -g -pthread -Winvalid-pch -O2 -g -DNDEBUG -std=c++1z -MD -MT lib/base/CMakeFiles/base.dir/base_unity.cpp.o -MF lib/base/CMakeFiles/base.dir/base_unity.cpp.o.d -o lib/base/CMakeFiles/base.dir/base_unity.cpp.o -c /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/base_unity.cpp
In file included from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/configobject.cpp:8:0,
from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/base_unity.cpp:9:
/builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/serializer.hpp:20:14: warning: 'virtual const char* icinga::CircularReferenceError::what() const' can be marked override [-Wsuggest-override]
const char *what(void) const throw() final;
^~~~
In file included from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/filelogger-ti.hpp:12:0,
from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/filelogger.hpp:8,
from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/filelogger.cpp:4,
from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/base_unity.cpp:25:
/builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/streamlogger.hpp:33:7: warning: 'virtual void icinga::StreamLogger::ProcessLogEntry(const icinga::LogEntry&)' can be marked override [-Wsuggest-override]
void ProcessLogEntry(const LogEntry& entry) final;
^~~~~~~~~~~~~~~
/builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/streamlogger.hpp:34:7: warning: 'virtual void icinga::StreamLogger::Flush()' can be marked override [-Wsuggest-override]
void Flush() final;
^~~~~
In file included from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/config/configitem.hpp:8:0,
from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/scriptutils.cpp:17,
from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/base_unity.cpp:56:
/builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/config/expression.hpp:264:19: warning: 'virtual const icinga::DebugInfo& icinga::DebuggableExpression::GetDebugInfo() const' can be marked override [-Wsuggest-override]
const DebugInfo& GetDebugInfo() const final;
^~~~~~~~~~~~
In file included from /builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/base_unity.cpp:78:0:
/builds/packages/icinga2/packaging/sles/15.7/BUILD/icinga2-2.16.3+111.g8ff3d586f/lib/base/workqueue.cpp:80:1: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.opensuse.org/> for instructions.
This reverts commit 3cb6e5a152.
to fix a build error against OpenSSL 4.0.
OpenSSL 4.0 made `X509_NAME*` pointers returned by `X509_get_subject_name()`,
`X509_REQ_get_subject_name()` and related getters const.
In contrast, under OpenSSL 1.x, setters expect non-const pointers,
hence our new typedef `X509NameConstPtr`.
- Use `X509NameConstPtr` parameters in `GetX509NameCN()`, `CreateCert()` and,
`CreateCertIcingaCA()` to match the const expectations per OpenSSL version
- Replace `X509_REQ_get_subject_name()` with `X509_NAME_new()` +
`X509_REQ_set_subject_name()` for CSR subject modification,
since the returned data can't be directly modified now
`DiagnosticInformation()` wasn't able to take a `std::exception_ptr` due
to the missing conversion on older boost versions, so now everything uses
the std::exception_ptr instead. There are still a few reasons to use
`boost::exception` in some places, but for exception pointers, the standard
one should be better in most cases and almost never requires to include an
extra header.
This was likely meant as a fallback for non-`std::exception`
exception pointers, but it would never have been reached, because
`(std|boost)::rethrow_exception()` would have thrown those out of
the function scope.
This fixes the fallback by making it a catch handler and also using
the more direct way of getting this fallback diagnostic info inside
a catch handler.
The recursion depth limit added to JsonDecode() in 2.16.2 gave the C++
function a second parameter with a default value. Function pointers do not
carry default arguments, so the DSL function binding deduced an arity of 2
via boost::function_types::function_arity and required two arguments. As a
result `Json.decode("...")` failed with "Too few arguments for function",
an undocumented breaking change in a patch release.
Wrap JsonDecode() in a single-argument shim (mirroring the existing
JsonEncodeShim) so the registered function keeps its one-parameter contract
while still applying the default depth limit internally.
refs #10913
More relaxed memory_order = less safety guarantees = faster execution.
This is safe because std::shared_ptr does the same. See also:
https://en.cppreference.com/w/cpp/atomic/memory_order
"Typical use for relaxed memory ordering is incrementing counters, such as the reference counters of std::shared_ptr, since this only requires atomicity, but not ordering or synchronization (note that decrementing the std::shared_ptr counters requires acquire-release synchronization with the destructor)."
This is currently a false positive on the debian:11 target and my
assumption is that the older GCC can't prove that when `ProcessWaitPID()`
returns early, `WIFSIGNALED(status)` is never used.
However leaving the variables uninitialized like that is bad anyway, since
this might easily be missed when slightly refactoring the function or
if/else blocks and then lead to undefined behavior. So now they just get
initialized to zero.
In the `boost::asio::spawn()` call for newer Boost versions with
`std::allocator_arg`, switch from `fixedsize_stack` to
`protected_fixedsize_stack` in order to allocate the stacks with guard pages.
This is done as an additional safeguard in case there was still some way to
overflow, this at least reliably crashes the process instead of going into
undefined behavior, which could even result in code execution.
Unfortunately, the old-style `spawn()` function with
`boost::coroutines::attributes` does not - at least to my knowledge - provide a
way to request a stack allocated with guard pages, hence this is only enabled
for Boost 1.87 and later with this commit.
Add validation checks to code paths reachable from the HTTP API (except full
config file deployments via /v1/config) that prevent creating deeply nested
data structures that could later cause a stack overflow.
If parsing JSON is rejected due to the depth limit introduced in the last
commit, also include the path (like root["object"]["children"]...) that exceeds
the allowed nesting depth.
Data structures parsed from JSON may be accessed recursively, so deeply nested
structures may wreak havoc by overflowing the stack. Thus, enforce a general
nesting depth limit of 24 by default (which should be more than enough for
reasonable use), with the ability to pass a different limit to JsonDecode() if
needed.
int is just not the right type to use for an index variable, so change it to
size_t, even if it's unlikely to be called on sufficently large inputs that it
would actually make a difference.
Forgot to replace one of the two uses of SHA_DIGEST_LENGTH with length in
6cd3a483a0. All users use it for SHA1 so far, so
there was no wrong usage yet.
`strand.running_in_this_thread()` relies on thread-local storage
internally, and may return false positives if the coroutine is resumed
in a different thread than it was suspended in. In debug builds, this is
not problem, since there's no TLS optimization done by the compiler, but
in release builds, the compiler might cache the address of the
thread-local variable read before the coroutine suspension, and thus
potentially reuse the same address in a different thread after
resumption, which would cause `running_in_this_thread()` to return false
or even crash (but we didn't see any crashes related to this). So,
perform the assertion only in debug builds to prevent potential wrong
usages of the `Timeout` class. For more details, see [^1][^2][^3].
[^1]: https://github.com/chriskohlhoff/asio/issues/1366
[^2]: https://bugs.llvm.org/show_bug.cgi?id=19177
[^3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
Escape all user-supplied template imports when creating an Icinga 2 DSL
configuration object. Without the escape, a `"` within the template name
would allow escaping the created object and create other Icinga 2 DSL
objects, exceeding potential user privileges.
The same bug was present in ConfigWriter::EmitComment, but as this
method is dead code, it could just be removed.
This is inefficient and involves possible bad surprises regarding
waiting durations on busy nodes. Instead, use `AsioConditionVariable#Wait()`
if there are no free slots. It's notified by others'
`CpuBoundWork#~CpuBoundWork()` once finished.
Without this change, it is easy to pass a temporary, for example a vector
returned by a function to ParallelFor(). With this commit a type-constraint
is added to disable the use of this function for rvalue sequences.
An alternative would have been to capture rvalue-references in the function,
but that would have made the function unnecessarily complex, involving tuple-capture
and `shared_ptr`s, while it is usually easy to control lifetime at the call-site.
This also enables the use of the function with "containers" that
don't have a size function but implement an overload for `std::size()`,
like c-arrays with fixed sizes.
This commit refactors the ValueGenerator class to be a template that can
work with any container type. Previously, one has to manually take care
of the used container by lazily iterating over it within a lambda. Now,
the `ValueGenerator` class itself takes care of all the iteration,
making it easier to use and less error-prone. The new base `Generator`
class is required to allow the `JsonEncoder` to handle generators in a
type-erased manner.
