| commit | 1106333af4a5b566d8b3686b3438ddebc75b1b5d | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Fri Sep 24 11:55:44 2021 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Thu Sep 30 16:31:15 2021 +0000 |
| tree | 31fd42b3019e5a155717ed3921933e893c756ee4 | |
| parent | 567e3ab77c0770da7def4352808e2744aa13369e [diff] |
Fix use after move in account service
A clang analyzer was able to find this issue.
dbus::utility::checkDbusPathExists(
dbusObjectPath,
[dbusObjectPath(std::move(dbusObjectPath)), username,
password(std::move(password)), roleId(std::move(roleId)), enabled,
locked, asyncResp{std::move(asyncResp)}](int rc) {
"Object 'dbusObjectPath' of type 'std::basic_string' is left in a valid
but unspecified state after move"
This is obviously a mistake, but apparently the undefined behavior works
for us. This commit makes it so we no longer rely on UB.
Tested: Trivial change, code compiles.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I1b82778cb74f4e5abc53edec35a6d276161de1af
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D flags that correspond to options in bmcweb/meson_options.txt and then compiling. For example, meson <builddir> -Dkvm=disabled ... followed by ninja in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja coverage -C builddir test
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1 algorithm. The certificate
C=US, O=OpenBMC, CN=testhost,SHA-256 algorithm.