Run clang-format over the Mosh source tree. This is a large change and
has been factored into its own commit for auditability. Reproduce it
with
find . -name \*.cc -or -name \*.h | while read f; do clang-format -i --style=file $f; done
Create .clang-format to describe the current C++ style used in Mosh.
Mark one carefully-formatted array with `// clang-format off`. Also turn
off clang-format in src/crypto/ocb_internal.cc, since it was imported
almost wholesale from another project and is written in a style
different from the rest of Mosh.
Previously, mosh used extensive -I flags and all of the mosh-local
makes it really hard to tell what the proper dependency graph is, so
instead remove the -I arguments in favvor of $(top_srcdir) and qualify
the paths wherever they are used.
Protobuf versions since 3.6.0 have long had a C++11 dependency; even
more recent versions have picked up an Abseil dependency bumping that
to C++14. Since it is now 2023, defaulting to C++17 is reasonable, so
remove the conditional C++ standards version check that mosh
previously had and replace it with an unconditional C++17 check.
This means that all future commits can use C++17 features. According
to https://en.cppreference.com/w/cpp/compiler_support/17 this means
that minimum effective compiler versions for mosh become:
gcc 7 (May 2017)
clang 5 (September 2017)
This, in turn, implies that future versions of mosh will no longer be
available for RHEL/CentOS 7 (June 2014).
Closes: #1267
Per release-team’s recent request that maintainers support the nocheck
profile <E1oit90-0073rh-LX@respighi.debian.org>, annotate build
dependencies that are test-only with <!nocheck>.
tmux 3.3a has a behavior change, since reverted, that is incompatible
with this test. Unfortunately, tmux 3.3a has already made it into some
distributions, so the test has to be disabled when tmux 3.3a is encountered.
This helps to avoid problems when the 1.4.0 release is made and
distributions with version sort order think the rc sorts after
the non-suffixed version
`git fetch --tags --unshallow`, run as part of the CI for `git
describe` to do the right thing, ran into the error:
```
! [rejected] mosh-1.4.0-rc0 -> mosh-1.4.0-rc0 (would clobber existing tag)
```
This is because mosh uses annotated tags, whereas the initial fetch
command run by actions/checkout@v2 ends up creating an *unannotated*
tag of the same name.
This means that any time the release CI runs, it would fail.
The resolution is straightforward: --force so that the line becomes
```
t [tag update] mosh-1.4.0-rc0 -> mosh-1.4.0-rc0
```
and the annotation is brought in.
The previous CI attemtped to use Homebrew for builds, but
unfortunately Homebrew has dropped support for universal packages aka
multiarch (fat) binaries. This means that in order to build an arm64 +
x86_64 package, macports has to be used instead of homebrew.
Unlike Homebrew, MacPorts is not installed by default on the GitHub
Actions runners, so we need to install it ourselves. This means
managing our own instance of the cache, which itself produces
challenges as the `gtar` binary run by the action doesn't have enough
permissions to restore the MacPorts checkout. So we have to shim gtar
with a sudo wrapper.
With this commit, we produce a Mosh package that works on macOS 11.0
and newer, on both arm64 and x86_64 architectures. The protobuf
library is statically linked, but all other libraries are provided by
the system.
This change ports the Travis CI release workflow for macOS to Github
Actions. Note that while this is functionally identical to the
previous Travis CI flow, no work has been done to update the macOS
build scripts to build for arm64.
This Github Actions workflow uses a Linux-based running to create the
release tarball for mosh. This is necessary since mosh does not check
in the autoconf/automake generated files, so the default release
action source download is missing files that are needed for
distributions that use the upstream-provided ./configure script.
Previously, ocb_internal.cc supported different key sizes, by way of
the deprecated aes_* function family. However, in practice, mosh
always uses AES-128. In Nettle, the explicit key-size APIs are not
deprecated, so switch to AES-128 directly.
Fixes: 1202
Explicitly define the primitive AES API used by the internal OCB
implementation, and move it into its own namespace (ocb_aes). This will
ease future implementation changes.
Also make some style fixes to affected lines: Replace C-style casts
with C++-style casts, add some missing spaces in argument lists, and
remove some `inline` that the compiler will ignore.
Bug: https://github.com/mobile-shell/mosh/issues/1174
bacc024083 inadvertently stopped
propagating `pkg-config --libs` output into the link line. This didn’t
affect OpenSSL (since configure.ac puts -lcrypto there manually) or
Apple Common Crypto (since it’s not a separate dylib), but it broke
Nettle builds. Fix Nettle builds by ensuring that `pkg-config --libs`
output actually makes it to the linker.
After further discussion, the Mosh maintainers have decided to stick
with the internal OCB implementation for this release. Restore support
for using OpenSSL’s AES but internal OCB. To make this commit easy to
audit, restore the code exactly, including calls to AES functions that
are deprecated in OpenSSL 3; a future commit will update ocb_internal.cc
to use EVP instead of directly calling the AES primitives.
In anticipation of future changes, preserve support for OpenSSL’s
AES-OCB, but don’t compile it in. Add
--with-crypto-library=openssl-with-openssl-ocb and
--with-crypto-library=openssl-with-internal-ocb options to configure so
that developers can easily test Mosh using OpenSSL’s AES-OCB. These
options are intended only for testing, are undocumented, and are not
subject to any API stability guarantees.
Rework configure to look for all possible cryptography libraries first
and then dispatch on --with-crypto-library as appropriate.
Benjamin Barenblat