* exwm-manage.el (exwm-manage--on-MapNotify, exwm-manage--init):
Restack X windows after being mapped in order to ensure they receive
an EnterNotify event (does not happen under XQuartz).
Implements initial validations of token claims. The included
validations are:
* validation of token issuer
* validation of token audience
* validation that a subject is set
* validation that a token is not expired
These fields are only used to constrain deserialisation to the
supported values, but have no further effect.
`rustc` throws warnings about them not being used, which this commit
disables.
Implements the logic for validating a token signature and returning
its decoded headers and claims.
This does not yet apply claim validations, as those have not been
specified yet.
Introduces a new struct type which contains the token's headers and
claims as JSON values. This is constructed by validating a token and
allows library users to deal with the deserialised values as they
please.
There are multiple points in the code where a token part needs to be
deserialised (i.e. first base64-decoded, then JSON-deserialised). This
is extracted to a helper function in this commit.
Introduces the internal function for validating JWT signatures. The
process is relatively straightforward:
1. Create an OpenSSL signature verifier using the public key from the
JWK.
2. Split the JWT into the data (header + claims) and signature parts.
3. Validate the data against the signature using the verifier from (1)
OpenSSL "cleanly" returns a boolean in case of an invalid signature,
but an otherwise successful operation.
This is represented differently in the returned error variant, with an
invalid signature being represented as `InvalidSignature`, and other
errors as the `OpenSSL` error variant which wraps the underlying
OpenSSL issue.
Successful validation returns an empty `Ok` result.
This makes the library slightly more "rusty". Instead of returning a
validation result which also represents potential success, use an enum
representing the error variants and the standard library's
`Result`-type to represent success/failure.
It's pretty easy to unintentionally install a second version of nix
into the user profile when using a daemon install. In this case it
looks like nix was upgraded while the nix-daemon is probably still
unning an older version.
A protocol mismatch can sometimes cause problems when using specific
features with an older daemon. For example:
Nix 2.0 changed the way files are compied to the store. The daemon is
backwards compatible and can still handle older clients, however a 1.11
nix-daemon isn't forwards compatible.
