This might not work, but I can't test it locally (who actually has
ppc64le and s390x hardware, anyway?)
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
- Added support for using libsodium for encryption rather than OpenSSL
- Removed AES-GCM tests with keys shorter than 256; libsodium only supports 256
- Added a build with libsodium to the CI matrix
Signed-off-by: Andrew Simpson <andy@aiusepsi.co.uk>
steven@ edited and rebased:
- integrated with new USE_CRYPTO/USE_CRYPTO25519 options in CMake/meson
- separated using libsodium for ed25519/curve25519 and AES/SHA256.
- ensured libsodium simple crypto tests run on all builders instead of
a single isolated builder.
- prevented building with -DUSE_CRYPTO=libsodium for non-x86 hardware,
as libsodium's AES implementation depends on AES-NI. it is still
possible to configure with -DUSE_CRYPTO25519=libsodium on arbitrary
hardware targets.
Fixes#88.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
- We no longer return true when paring the string "invalid". Yes, technically
we *parsed* successfully. However, most callers would not consider parsing
the invalid identity a success for their puspose, they assume that if true
is returned, we have a real identity of some kind. (But perhaps one that is
the "unknown" kind.) This was true of all existing call sites. So this
was basicaly a bug trap and/or security issue. If a new caller wants to
handle the string "invalid", they can do it themselves.
- Assume that the relay is running the latest protocol, so treat an unknown
prefix as failure / invalid. Do not try to continue. This doesn't impact
this opensource code, since the relay is not currently open source.
It's amazing the bugs that can be found once code actually gets executed.
This used to work. It broke when I changed the prefix text and forgot to
update the hardcoded literals. [Insert comment here about the evils of
using hadrcoded literals. Yes yes.]
They cause compile errors on s390x for example, because the
__storewordbytereverse and friends don't exist there. But since we
aren't using any of these it's pointless.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
And possibly others -- we just want to ensure that the semicolon after
DebuggerBreak() doesn't seem superfluous to the compiler. Ugh.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
- Abstracted difference between ByteSize() and ByteSizeLong() to use only
the non-deprecated version where available.
- Remove check which disables C++ static_assert() on macOS; pretty sure
it is supported in Apple Clang these days
Signed-off-by: Andrew Simpson <andy@aiusepsi.co.uk>
Windows isn't case-sensitive but Linux is, and the MinGW distributions
use a lower-case filename.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Most of the important stuff is in files that are not part of the opensource
distribution, unfortunately. There were some bugs where the destructor was
declared public in a derived class, which made it possible to use operator
delete directly.
Also fixed some comments.
Remove() takes a key to lookup and remove. Since we already have the
index when removing entries from the map of sockets and poll groups,
RemoveAt() is the appropriate function.
This is used to poll many connections in a single function call. Previously,
this was only possible if all of the connections were those accepted on the
same listen socket. (ReceiveMessagesOnListenSocket). But this left out at
least two important use cases with known users:
- If you create more than one listen socket (because there is more way to
contact your service, e.g. once for P2P and another for direct IP, and
another for relayed connections), then you could not poll all of the
connections efficiently.
- In P2P use cases, we may initiate many connections to peers, and we want
to poll all of them at once.
This change is relevant to: Issue #49, Issue #50, and issue #52. (But I don't
this it really "fixes" any of them.)
This is to try to limit what is exposed in a naive generic interface to allow
users to adjust config values, in a way that doesn't allow the user to break
the security in a trivial way.
After reviewing all existing use cases, I realized that all of them were
tolerant of being woken up earlier instead of late, and that all of the
complexity I was doing with tracking earliest and latest allowed wake up
times was not really getting anything. Furthermore, the way the code was
written, forcing everybody to accept a 1ms late slack had the effect of
almost *always* waking up 1ms late, even if we could have woken up at the
right time.
So now each thinker just has a target wake up time, and we will not call
them before that, but we will call them as soon as possible after that.
I suspect that I could make this a lot better by using waitable timers
on Windows and the timerfd functions on linux. I'd need a solution for
other POSIX systems, though.
This was a problem for manual polling mode.
Also for "normal" mode, where there is a service thread, increase the timeout.
We should never depend on this timeout to avoid any bad performance or solve
race conditions. We should explicitly wake up the trhead when needed. So if
we have a bug, we want it to stall for a long time, and cause people to ask
questions and investigate.