Running an invalid `sdk` subcommand like `xtool sdk list` (there's no
`list` subcommand) is interpreted as "install the sdk at path `./list`".
We previously unconditionally removed the existing SDK during
installation. By switching the order so that we validate the path first,
we avoid performing a potentially destructive action unless we have
clear intent.
See #186.
Before:
```bash
$ xtool sdk list
Removing existing SDK... # destructive!
Error: Could not read file or directory at path 'list'.
```
After:
```bash
$ xtool sdk list
Error: Could not read file or directory at path 'list'.
See 'xtool help sdk' for usage.
```
- We already do the `isFree` declarations in
`DeveloperServiceCapability.swift`. Don't need to duplicate it on the
entitlement types.
- Add support for creating capabilities with raw names
Notably:
- Build xtool with Swift 6.2
- Resolve https://github.com/advisories/GHSA-xvr7-p2c6-j83w. That
advisory shouldn't really affect us since we don't use NIO as a server
but good hygiene anyway.
- We now have a single tmpdir "root" that can be recreated at launch to
clean up old stragglers
- The location of this tmpdir root can be controlled by `XTL_TMPDIR` or
`TMPDIR`. In general the path is `$TMPDIR/sh.xtool`.
With this change it should be possible to `export XTL_TMPDIR=/var/tmp`
if `/tmp` doesn't have enough space, which fixes#23.
No breaking changes afaik
One notable change is the addition of
`components.schemas.PagingInformation.paging.nextCursor` (which is
possibly supposed to be the query parameter portion of `links.next`?
could simplify the pagination code) but this doesn't seem to be returned
by the prod ASC API right now.
Previously this was shadowing the user's cwd path onto the device, e.g.
if you were installing from `/home/foo/bar` it would create
`/home/foo/bar/PublicStaging` on the device. For uniformity with other
tools like `ideviceinstaller`, clean this up and just create
`/PublicStaging`.
# fix: hardening `mobileprovision.c` to avoid future crashes.
## Context:
I found two common weakness inside `Sources/CXKit/mobileprovision.c`,
which seems to be an important layer of `xtool`'s signing logic.
### Common weaknesses found:
- CWE-476
- CWE-119
---------
Co-authored-by: Kabir Oberai <oberai.kabir@gmail.com>
This was vestigial, and besides the fact that we don't actually do any
work in this stage, we also never update the progress here so it gets
stuck at 0%.
- Always try to register the device and just return gracefully if it
fails (prevents races, pagination issues)
- Allow `SigningContext` (and therefore `AutoSigner`) to be created
without a target device: just skip device registration.
We pull the list of App IDs in `upsertApp` to see if we already created
the App ID. This broke when the user had too many App IDs, since DS
returned a paginated response and we only looked at the first page.
We could paginate the whole list (as seen in #89) but that's slow.
Instead, just filter the query to the expected App ID. This is a prefix
search so we might still receive multiple responses, but it's much less
likely that the user has like 10(? I'm not sure what the default/max
pagination limit is) apps registered with the XTL-ABC.com.foo.bar prefix
(they could have PlugIns but usually just a small number of them.)
This is a tentative fix for #87.
- Make some enums non-exhaustive (closes#77)
- Also a tentative fix for #62 and #64
- Improve logging on deserialization failure
We now use raw JS to patch the OpenAPI spec instead of openapi-overlay.
It's a lot more flexible this way.
Allow setting `XTL_DEV_LOG` to a regex (e.g. `export
XTL_DEV_LOG='profiles_.*'`) to log the responses of all matching
operations
Also add `BundleIdPlatform.services` as seen
[here](60bbc198c8/Makefile (L9))
Closes#68
## On any platform
You can now do
```bash
xtool dev build --triple arm64-apple-ios-simulator [--ipa]
```
To build a .app/.ipa that works on the simulator.
## On macOS
You can do
```bash
xtool dev --simulator
```
To one-shot build-and-install on the booted simulator.
