feat(cli): add development code signing #16845
Conversation
wschurman
force-pushed
the
@wschurman/expo-cli-multipart
branch
from
4861bf2
to
801051e
Compare
wschurman
force-pushed
the
@wschurman/expo-cli-codesigning
branch
from
17c5f47
to
5ded4d7
Compare
wschurman
force-pushed
the
@wschurman/expo-cli-codesigning
branch
from
5ded4d7
to
f6e65a7
Compare
expo-bot
added
bot: passed checks
There was a problem hiding this comment.
There are two functions: createCachedFetch and wrapFetchWithOffline you may want to look at. I don't think they quite meet the needs here since createCachedFetch doesn't expire content (I think).
It is also worth looking at the cacache library that is already used by createCachedFetch. It's npm's caching implementation and guards against corruption. This is maybe preferable compared to using "fs" directly.
packages/@expo/cli/src/start/server/middleware/ExpoGoManifestHandlerMiddleware.ts
Outdated
Show resolved
Hide resolved
...ages/@expo/cli/src/start/server/middleware/__tests__/ExpoGoManifestHandlerMiddleware-test.ts
Outdated
Show resolved
Hide resolved
...ages/@expo/cli/src/start/server/middleware/__tests__/ExpoGoManifestHandlerMiddleware-test.ts
Outdated
Show resolved
Hide resolved
| @@ -77,6 +78,7 @@ export const expoStart: Command = async (argv) => { | |||
|
|
|||
| --dev-client Experimental: Starts the bundler for use with the expo-development-client | |||
| --force-manifest-type <manifest-type> Override auto detection of manifest type | |||
| --private-key-path <path> Path to private key for code signing. Default: "private-key.pem" in the same directory as the certificate specified by the expo-updates configuration in app.json. | |||
There was a problem hiding this comment.
The start command does a lot of stuff, maybe signing-key would be a more useful name? This would be akin to serve CLI which uses --ssl-key.
| --private-key-path <path> Path to private key for code signing. Default: "private-key.pem" in the same directory as the certificate specified by the expo-updates configuration in app.json. | |
| --signing-key <path> Path to private key for code signing. Default: "private-key.pem" in the same directory as the certificate specified by the expo-updates configuration in app.json. |
There was a problem hiding this comment.
eas-cli uses --private-key-path so I'm tempted to keep it for consistency. That being said I don't feel too strongly about naming so I'm happy to change this if you think the name is clearer and the benefit outweighs the cost of inconsistency (I guess we could rename the eas-cli one as well though.
There was a problem hiding this comment.
I do like the consistency aspect so I'm not in love with changing the arg.
I just checked the help of eas update and noticed a bit of a naming inconsistency there as well which leads me to think it doesn't matter much (dir, path)
--input-dir=<value>
--private-key-path=<value>
Personally I like the shorter argument names because I'm lazy.
wschurman
force-pushed
the
@wschurman/expo-cli-codesigning
branch
from
3bebe72
to
a570071
Compare
Why
This adds development code signing which will supersede legacy code signing. For now clients will continue to support and request both, but after a while we'll stop requesting the old style and then a while after that we'll stop supporting legacy code signing on this dev server.
The rough strategy for this is outlined in expo/code-signing-certificates#1.
Support for development certificates was added to the server in https://github.com/expo/universe/pull/9232 and https://github.com/expo/universe/pull/9349.
Support for chains (required for this feature) was added to the client in #16375 and #16634.
Depends on #16804.
Closes ENG-4480.
How
Inline docblocks and comments are probably the best way to describe the how, but the general approach is:
keyid=expo-rootorkeyid=<user keyid>, we handle each one separately.Test Plan
Run new and existing tests.
Manual tests:
curl --request GET \ --url 'http://192.168.0.113:19000/?platform=ios' \ --header 'accept: multipart/mixed' \ --header 'expo-expect-signature: sig, keyid="expo-root", alg="rsa-v1_5-sha256"'nexpo start --force-manifest-type=expo-updates