Page MenuHomePhabricator
Differential D4659

[Nix] Fix source usage of source-nvm.sh
ClosedPublic
Actions

Authored by • jon on Jul 27 2022, 4:58 PM.
Tags
None
Referenced Files
F6140196: D4659.id15074.diff
Tue, Apr 22, 7:02 AM
F6134906: D4659.id.diff
Tue, Apr 22, 5:06 AM
Unknown Object (File)
Tue, Apr 22, 12:19 AM
Unknown Object (File)
Mon, Apr 21, 6:38 AM
Unknown Object (File)
Tue, Apr 8, 8:47 PM
Unknown Object (File)
Tue, Apr 8, 8:47 PM
Unknown Object (File)
Tue, Apr 8, 8:47 PM
Unknown Object (File)
Tue, Apr 8, 8:47 PM
View All Files
Subscribers
• adrian
tomek

Details

Reviewers
ashoat
atul
varun
• abosh
Commits
rCOMM56a05cf0c33d: [Nix] Fix source usage of source-nvm.sh
Summary

exit 0 will cause the current current process to end.
Normally this is okay when executing a script (e.g. ./source-nvm.sh),
but when sourcing it (e.g. . source-nvm.sh) will cause the current
shell/process to end.

Use of return 0 will cause the shell "function" (in this case the sourced
script) to return with the status 0 to the calling scope (e.g. yarn dev)

Full disclosure: I only partially tested this. I Don't have a database
configured, and setting up the database instances through nix is future work.
I was able to assert that running running (cd keyserver && yarn dev &) now
correctly waits for changes in keyserver/dist/

Test Plan

Then run:

nix develop
yarn cleaninstall

# start web or landing dev
(cd web && yarn dev &)

# start keyserver
cd keyserver
yarn dev

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Revision Contents
Changeset List

PathSize
keyserver/
bash/
2 lines

Diff 15074

View Options

keyserver/bash/source-nvm.sh

import ExpoModulesCore import ExpoModulesCore
import CryptoKit
public class AESCryptoModule: Module { public class AESCryptoModule: Module {
public func definition() -> ModuleDefinition { public func definition() -> ModuleDefinition {
Name("AESCrypto") Name("AESCrypto")
Function("hello") { () -> String in Function("generateKey", generateKey)
return "Hello world! 👋"
} }
} }
// MARK: - Function implementations
private func generateKey(destination: Uint8Array) throws {
let key = SymmetricKey(size: .bits256)
guard destination.byteLength * 8 == key.bitCount else {
throw InvalidKeyLengthException()
}
atulUnsubmitted
Not Done
Inline Actions

Before we even generate key via SymmetricKey, should we check that destination.byteLength is 32 and throw InvalidDestinationSizeException() if not?

It seems like destination is the input that we want to validate, so we should just do that directly? It's not really so much that SymmetricKey is giving us incorrect size key since it's (I'm assuming) always going to give us exactly the size we're asking for?

Feel free to re-request review if there's something I'm missing here.

atul: Before we even generate `key` via `SymmetricKey`, should we check that `destination.byteLength`…
bartekAuthorUnsubmitted
Done
Inline Actions

The only reason the guard is below SymmetricKey is that I wanted to use its bitCount property to get the desired destination length, but you're right that it can be done this way:

guard destination.byteLength == KEY_SIZE else {
  throw InvalidKeyLengthException()
}
let key = SymmetricKey(size: .bits256)

I'll refactor this as it is more clear solution

bartek: The only reason the guard is below `SymmetricKey` is that I wanted to use its `bitCount`…
key.withUnsafeBytes { bytes in
let _ = bytes.copyBytes(to: destination.rawBufferPtr())
}
}
// MARK: - Utilities
extension TypedArray {
func rawBufferPtr() -> UnsafeMutableRawBufferPointer {
UnsafeMutableRawBufferPointer(start: self.rawPointer,
count: self.byteLength)
}
}
// MARK: - Exception definitions
private class InvalidKeyLengthException: Exception {
override var reason: String {
"The AES key has invalid length"
}
} }