tanzislam / cryptopals Goto Github PK

Google has removed the build scripts for C++Builder and Visual Studio. (While the PR accepted after that has reinstated those files, that seems to be an accident. 🙂)

Need to update the Wiki pages with steps for preparing the project files ourselves, or extracting them from the Git history.

The Boost Wiki is now at: https://github.com/boostorg/wiki/wiki. Need to fix any broken links.

• https://github.blog/2022-08-15-the-next-step-for-lgtm-com-github-code-scanning/
• https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#setting-up-code-scanning-manually

The SonarCloud plugin is documented to not work on external pull requests, but it's worse than just that -- the plugin's utility scripts are actually not present during the run, causing a build failure on the pull request. (Example: #17.) Need to revert to a normal build during external pull requests (or perhaps all pull requests, if simpler), until the promised feature of scanning external pull requests appears.

On another note, the github_token property in .travis.yml is now deprecated. It was used for supplying the personal access token of the GitHub account to use for annotating internal pull requests, and can now be specified in

the “Administration > General Settings > Pull Requests” page of your project on SonarCloud

So need to remove that key and its documentation from the .travis.yml file, and the SONAR_GITHUB_TOKEN encrypted environment variable from Travis settings.

Need to use a SSL/TLS library now, like Boost.Asio's SSL support.

OpenSSL used to support C++Builder long ago before modernizing their build system, but reverting that logic no longer works. Also unclear whether/how OpenSSL supports building with Oracle Developer Studio.

boostorg/endian@59097ad started causing a compilation error in aes_ctr.cpp. Need to cast back to char* or void*.

Example: https://travis-ci.org/github/tanzislam/cryptopals/jobs/679871545

[ FAILED ] 1 test, listed below:
[ FAILED ] ForgeAdminProfileCbc.CreatesForgedAdminProfile

1 FAILED TEST
The command "$shell ./test --gtest_color=yes" exited with 1.

The std::istrstream and std::ostrstream classes are long-deprecated and will be removed in C++17. They have been used as an efficient mechanism to read/write a user-provided character array as a stream, without ownership semantics (i.e. don't assume a particular allocation method and leave deallocation to the user).

The recommended replacements for this use case are boost::iostreams::array_source and boost::iostreams::array_sink.

This online analyzer used to be controlled by a checked-in config file (containing detailed build steps) or compile_commands.json file, which I had requested a programmatic-generation option for. The current documentation shows that request to have been implemented around end-of-August.

• https://github.blog/2022-08-15-the-next-step-for-lgtm-com-github-code-scanning/
• https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/setting-up-code-scanning-for-a-repository#setting-up-code-scanning-manually

weidai11/cryptopp@04dee2a467 added a dependency on:

• FileStore::MaxRetrievable()
  • std::istream::seekg(0, std::ios::end)
    • std::streambuf::pubseekoff(0, std::ios::end, std::ios_base::in)

and this seek-to-end behavior is unimplemented in our streambuf implementations. This started assertion failures in our CI.

I'm classing this as a Dependency Breakage rather than a Bug, because Crypto++ is expecting all input streams to implement seek-to-end behavior, which isn't mandated in the C++ standard.

Google Test emits test execution reports in the JUnit XML format. SonarCloud (i.e. SonarCFamily not sonar-cxx), however, expects test execution reports in CppUnit's XML format which can be gleaned from the implementation. Need to convert somehow (perhaps XSLT) before calling sonar-scanner.

SonarCloud also supports importing coverage reports from gcov or llvm-cov. We'll need to use the latter if we use the macOS-specific workflow in our .travis.yml.

CodeClimate also supports importing coverage reports generated with gcov, but not llvm-cov.

Codacy also supports importing coverage reports from lcov, and this blog explains how to upload coverage data for unsupported languages like C++.

Same as VS2015, except that when building the Boost libraries the toolset needs to be specified with the version, i.e. toolset=msvc-14.1.

The Wiki page also needs fine-tuning on the indentation of the bullet points.

Integrate with lgtm.com / Semmle QL static analysis.

Build #572.2 started to time out on macOS. Some main time contributors compared to the prior successful job (that finished in 39 min 36 seconds):

• brew update took 413.05 seconds compared to the prior 340.64 seconds -- increase of 1 min 12.41 seconds.
• Installing Homebrew packages took 878.36 seconds compared to the prior 59.70 seconds -- an increase of 13 min 38.66 seconds.
• The $shell ./prepare_deps step took 1282.83 seconds compared to the prior 1005.73 seconds -- an increase of over 4.5 minutes.
• SonarCFamily plugin has updated to v6.18.0.29274 (which ran until the 50-minute job timeout) compared to the prior v6.17.0.27551 (which finished in 731.89 seconds including the compilation, or 9 min 45.143 seconds for just the analysis).

Other time contributors from the later stages of the prior successful job were:

• Running the tests: 16.56 seconds
• brew cleanup: 16.22 seconds
• Store build cache: 167.16 seconds

So the new compile+analysis phase managed to run for:

50 min - (413.05 + 878.36 + 1282.83) seconds = 425.76 seconds ≈ 7 min 5.76 seconds

with the updated SonarCFamily plugin before timing out. Therefore the Homebrew package-installation needs to be looked at in more detail.

• Fetch only necessary Boost submodules.
• Use yaSSL instead of OpenSSL, in order to reuse Crypto++.
• Use curl instead of wget. (Much quicker to build in MacPorts.)

Same service, different name.

• https://link.medium.com/V42USdyFElb
• https://doc.code-inspector.com/docs/integration-ci/

using SonarCloud.

The std::basic_streambuf<> class template has a copy constructor as of C++11 that does a shallow-copy of the member pointers, which is completely unsuitable for our "mechanism" use case. Apply boost::noncopyable to mitigate this.