Debug startup:
- some packages were missing explicit use-package calls, which made this
configuration incompatible with fresh computers. After crashing my MBP
and trying to get this working thereafter, I learned.
Support LSP:
- LSP support for Haskell is good; embrace and prefer over Intero
Update KBDs:
- preferences change
- changing to a light theme (for now)
- enable rerere
- prefer less, since bat is my default pager, which doesn't look great
when looking at diffs, patches, etc
- fix broken alias
- support another alias
Adds a package that allows Emacs to searching through a projects
node_modules executables when resolving a binary like eslint, prettier
etc. This was being hacked together before by relying on explicit paths
to executables. This is a more durable solution.
Also includes some packages related to LSP for Javascript, which I
haven't been able to get working yet.
* 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.
