Disclaimer: I have no idea what I'm looking at.
Some tests fail, but I believe they have nothing to do with my changes
(fingers crossed). `make certs` doesn't work, I don't have `minica`
installed and don't want to litter my system with even more stuff. It's
bad enough that I got a shitload of Go dependencies downloaded when
running `make test`.
Co-authored-by: Lysander Trischler <twtxt@lyse.isobeef.org>
Reviewed-on: https://git.mills.io/saltyim/saltyim/pulls/186
Reviewed-by: James Mills <james@mills.io>
Co-authored-by: lyse <lyse@noreply@mills.io>
Co-committed-by: lyse <lyse@noreply@mills.io>
Alternative to #177
The way this works is:
Client:
- Client creates a normal `net/http.Request{}` object using the `Request()` function in `utils.go`. The `http.Request{}` object is then signed using the Client's Ed25519 private key.
- The HTTP Method and Path (_note this is important_) are hashed, as well as the request body (if any) using the FNV128a hashing algorithm.
- This hash is then signed by the Client's's Ed25519 private key.
- The resulting signature is then encoded to Base64 (_standard encoding_) and added to the HTTP headers as a `Signature:` header.
- In addition the Client's Ed25519 public key is added to the HTTP headers as `Signer:`
Server:
- The server calculates the same FNV128a hash of the HTTP Request Method and Path and the body (if any)
- The server decodes the HTTP header `Signature:`
- The server then uses the Client's Ed25519 public key in the HTTP header `Signer:` to verify the signature of the `Signature:` HTTP header which gives us back the original FNV128a hash the Client calculated for the request.
- The server then compares the Client's hash with the expected hash to see if they compare equally.
Co-authored-by: James Mills <1290234+prologic@users.noreply.github.com>
Co-authored-by: Jon Lundy <jon@xuu.cc>
Reviewed-on: https://git.mills.io/saltyim/saltyim/pulls/178
Reviewed-by: xuu <xuu@noreply@mills.io>
Fixes#169
This now behaves like this:
```
/Users/prologic/Projects/saltyim/saltyim # ./salty-chat write prologic@mills.io test
WARN[0000] error looking up user endpoint error="error looking up user testing123@shortcircuit.net.au: non-2xx response received: 404 Not Found"
error initializing client: unable to find your endpoint for testing123@shortcircuit.net.au
/Users/prologic/Projects/saltyim/saltyim #
```
Co-authored-by: James Mills <prologic@shortcircuit.net.au>
Reviewed-on: https://git.mills.io/saltyim/saltyim/pulls/171
Reviewed-by: m u t e f a l l <mutefall@noreply@mills.io>
See #169 which this patch partially fixes one issue found but not the most critical one (hence this PR does not close the issue)
Co-authored-by: James Mills <prologic@shortcircuit.net.au>
Reviewed-on: https://git.mills.io/saltyim/saltyim/pulls/170
Reviewed-by: m u t e f a l l <mutefall@noreply@mills.io>
After testing quite a bit on the saltyim/app client, I tracked down why all outbox messages were being pulled every time a new client starts up.
I believe the outbox client state should be shared with the parent client to allow the last message retrieved from the oubox to be persisted.
Co-authored-by: mlctrez <mlctrez@gmail.com>
Reviewed-on: https://git.mills.io/saltyim/saltyim/pulls/168
Reviewed-by: James Mills <james@mills.io>
Co-authored-by: mlctrez <mlctrez@noreply@mills.io>
Co-committed-by: mlctrez <mlctrez@noreply@mills.io>
this changeset addresses the need for a simple docker swarm deployment and setup of dns records on cloudflare.
Co-authored-by: m u t e f a l l <mutefall@noreply.mills.io>
Reviewed-on: https://git.mills.io/saltyim/saltyim/pulls/167
Reviewed-by: James Mills <james@mills.io>
Co-authored-by: m u t e f a l l <mutefall@noreply@mills.io>
Co-committed-by: m u t e f a l l <mutefall@noreply@mills.io>
xuu