Nickolay Olshevsky

I would not be concerned that much as primary secret key is offline, and in GitHub cellars we store only secret signing subkey, which expires in a year and can...

Here is the possible reason: ```C++ if (bn_num_bytes(*y) < BITS_TO_BYTES(keybits)) { botan_privkey_destroy(key_priv); goto start; } ``` This would re-generate underlying group, spending again more time in the primality test. Also...

Those are already defined, just didn't get reflection in development docs: ``` set(CMAKE_C_STANDARD 99) set(CMAKE_CXX_STANDARD 11) ```

...however latest GTest `main` commit seems to require C++14: `The 1.12.x branch will be the last to support C++11. Future releases will require at least C++14.`. Could we use C++14...

Yeah, it ships 4.8, which: `GCC provides experimental support for the 2011 ISO C++ standard.`

...as a solution we may use some CMake stuff to detect whether compiler supports C++14 (via compiler version check or via approaches like here: https://stackoverflow.com/questions/10984442/how-to-detect-c11-support-of-a-compiler-with-cmake )

> Strange, Fedora 36 has GCC 12.1.1 but compiled GTest fine before... Could it be that Fedora 36 runners used pre-built GTest from the Fedora packages?

@antonsviridenko Do you need some help with this? It appears to be showstopper for the Fedora 36 support, and should be included into the v0.16.1 release.

@antonsviridenko Yeah, it seems so. Anyway, we'll need to workaround it. I'd suggest following solution: - use latest release of GTest for most solutions. - except old GCC (pre-C++14), use...

@antonsviridenko Don't you mind me pushing fixes to this branch?