Previously, we would clear xtool's temporary directory on startup. This
(practically) meant you couldn't have multiple instances running in
parallel, because the second instance could delete the first instance's
temp resources while the first instance still needed them. Fix this by
having xtool instances declare locks on their temporary directories.
Ref #216: the public API seems to now complain when passing in
`capabilities`, but the field is still required when using the private
API.
Co-authored-by: sfusco <slf@stevenfusco.com>
## Problem
`xtool setup` fails on Linux Mint (and other distros) with:
```
Error: Error Domain=NSCocoaErrorDomain Code=512 "(null)" UserInfo={
NSUserStringVariant=["Copy"],
NSSourceFilePathErrorKey=/tmp/sh.xtool/tmp-DarwinSDKBuild-.../darwin.artifactbundle/...,
NSDestinationFilePath=/home/<user>/.swiftpm/swift-sdks/darwin.artifactbundle/...,
NSUnderlyingError=Error Domain=NSPOSIXErrorDomain Code=22 "Invalid argument"
}
```
## Root Cause
On Linux Mint (and Ubuntu-based distros), `/tmp` is mounted as **tmpfs**
while the home directory is on **ext4**. Foundation's
`FileManager.copyItem` uses `sendfile(2)` internally, which returns
`EINVAL (22)` when copying between different filesystem types.
`TemporaryDirectoryRoot` defaults to
`FileManager.default.temporaryDirectory` → `/tmp` on Linux. When `swift
sdk install` copies the built SDK from `/tmp/sh.xtool/...` to
`~/.swiftpm/swift-sdks/`, it crosses filesystem boundaries and fails.
## Fix
On Linux, default the temp directory root to `$XDG_CACHE_HOME/xtool`
(falling back to `~/.cache/xtool`) instead of `/tmp`. This keeps the
build directory and install destination on the same filesystem, so the
copy always succeeds.
- `$XTL_TMPDIR` and `$TMPDIR` overrides continue to work as before
- macOS behaviour is unchanged
- Follows XDG Base Directory Specification
## Changes
One file, `Sources/XUtils/TemporaryDirectory.swift` — 11 lines added
inside a `#if os(Linux)` block.
Fixes#181
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
- 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.
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.
* getTeamIsFree -> XcodeAuthData.team().isFree
* Only revoke certificates if on a free team
* Update OpenAPI spec, handle AVP
* Fix App ID capabilities on paid accounts
Kabir Oberai
Swapnil Nakate
Antonio Cheong
Erik Bautista Santibanez
Amlal El Mahrouss