You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#28 tracks the issue where some native node_modules are not detected as files that should be signed, so the workaround is:
Sign bundle: sign Foo.app, then notary-submit
For every file in the error, sign Foo.app/path/to/that/file
Sign the whole bundle again: sign Foo.app
And this works. But when using remote-sign, instead of forming 1 session, there are N+2 times that the session joining string needs to copied. If there are 10 files missed, then that means copying strings 12 times from CI to local.
If multiple inputs are accepted, then I think a single shared connection can be used to sign all of them together?
Of course it's better to improve the detection so a single bundle sign doesn't miss files, but read somewhere that there are a lot of variety and is hard to make sure all are covered.
Multiple inputs can help not just here, but also when there are many apps to sign.
The text was updated successfully, but these errors were encountered:
The lack of multiple signing (especially in the context of remote signing) has frustrated me as well! During release processes for my projects, I often have to initiate multiple remote signing sessions. This is laborious and does not spark joy.
I'd love to support multiple signing via a single CLI command.
The biggest open issue in my mind is what the CLI interface looks like. We currently use positional arguments for the input and output paths. Using positional arguments with no other flags to indicate multiple inputs mode leads to ambiguous argument parsing. So we have to invent a new CLI argument mechanism to specify multiple inputs - and maybe multiple outputs.
Once we figure out what that UI looks like, I think this should be relatively straightforward to implement.
// paths = list of file paths (positional arguments) after OPTIONSif(paths.length===2){input=[paths[0]];output=paths[1]||options.out;}elseif(paths.length>2){input=paths;output=options.out;}
Another factor here is how scoped setting should behave in the face of multiple inputs, as each scope's path could match multiple inputs.
That consideration biases me towards use of -- as a delimiter between distinct sets of signing components.
Or, we could just say the problem space is too complex and close this issue as won't fix. The main thing that gives me pause is I'd really like to support multi-signing for remote signing so you only have to establish 1 signing session on the remote.
#28 tracks the issue where some native node_modules are not detected as files that should be signed, so the workaround is:
sign Foo.app
, thennotary-submit
sign Foo.app/path/to/that/file
sign Foo.app
And this works. But when using remote-sign, instead of forming 1 session, there are N+2 times that the session joining string needs to copied. If there are 10 files missed, then that means copying strings 12 times from CI to local.
If multiple inputs are accepted, then I think a single shared connection can be used to sign all of them together?
Of course it's better to improve the detection so a single bundle sign doesn't miss files, but read somewhere that there are a lot of variety and is hard to make sure all are covered.
Multiple inputs can help not just here, but also when there are many apps to sign.
The text was updated successfully, but these errors were encountered: