Repository navigation
Conversation
- Added support for RDP authentication levels and CredSSP usage in connection settings. - Updated Makefile to include new build flags for GUI applications. - Improved the user interface for adding and editing connections, including new fields for authentication level and CredSSP. - Enhanced the launcher to handle new RDP settings and bypass local addresses for gateways. - Updated 1Password integration to check for CLI availability more effectively. - Added new RDP files with updated settings for testing. - Created new screenshots and recordings for documentation purposes.
feat: Gateway support and visual enhancements
…lags to disable debug symbols
…dows taskbar icon enhancements
…nd resource management
… for better resource management
…ed logic to check window title for authentication completion and cleanup of credentials and rdp files
- Connections can redirect local drives into the RDP session via the new RDPRedirectDrives field: all drives, dynamic-only, local disks only (excluding network drives, resolved via GetDriveTypeW), or a specific comma-separated drive letter list. Exposed in the Add/Edit Connection dialogs and written to the .rdp file's drivestoredirect setting. - Fix a startup crash where the git-status-check code (1.3.0) called Fyne widget/dialog methods from a background goroutine without fyne.Do, which newer Fyne versions treat as a fatal thread-safety violation. - Backfill the missing 1.3.0 CHANGELOG entry and document 1.4.0. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- New internal/update package: checks the GitHub releases list (not
/releases/latest, since every release here is a prerelease and that
endpoint always 404s), downloads the platform-matching archive,
replaces the running executable, and relaunches it.
- Windows: rename the running exe aside to <exe>.old (renaming a
running exe is allowed, overwriting it isn't), move the new one
into place, clean up the leftover on next startup.
- Linux/macOS: replace the executable's directory entry directly,
safe since the running process keeps its already-open handle.
- GUI: silent check ~5s after startup (only surfaces a dialog when an
update is found), plus a manual "Check for Updates..." Help menu
item. Confirm dialog shows release notes before downloading.
- Embed the running version into the binary via -X main.version=...,
wired through Makefile, build-gui.ps1, and the release workflow.
About dialog now shows the real version instead of a hardcoded "v1.0".
- Unit tests for version comparison and asset-name resolution; the
full check/download/extract/relaunch flow was verified manually
end-to-end against the real v1.4.0 release.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Release workflow generates a SHA256SUMS file (sha256sum over every platform archive) and publishes it as a release asset. - internal/update fetches SHA256SUMS for the target release and verifies the downloaded archive's hash before extracting/installing it. Fails closed: missing SHA256SUMS asset, missing entry, or a mismatch all abort the update with no changes made. - Self-updating bypasses the Mark-of-the-Web/SmartScreen check a manually downloaded-and-extracted exe gets, so this restores an integrity check in its place. - Unit tests for the checksum-listing parser and the fail-closed path. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…lease - prerelease was hardcoded to true for every release the workflow created, with nothing ever able to graduate it to a real release. Now determined by tag: a plain tag (v1.6.1) publishes stable; a tag with a semver pre-release identifier (v2.0.0-alpha, -beta, -rc1) publishes as a pre-release. - internal/update.CheckLatest now skips prerelease entries (in addition to drafts) when picking "latest", so a future alpha/beta tag won't get auto-offered to everyone on the stable channel. - Releases 1.0.0-1.6.0 stay marked pre-release on GitHub itself (cosmetic/historical only) since editing already-published releases is out of scope here; self-update just treats this release as the first stable one to offer going forward. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… job Windows Defender's real-time scanning of every object file written during compilation is the standard explanation for CGO builds being disproportionately slower on GitHub Actions Windows runners than on Linux/macOS for equivalent code. Confirmed here: in the v1.6.0 run, the Windows "Build" step alone took 401s vs. 151s on Linux and 38s on macOS for the exact same sources. Also explicitly enables actions/setup-go's cache (module + build cache), matching the documented default rather than leaving it implicit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"go install ...@latest" re-resolves and recompiles go-winres from source on every Windows job (~40s wasted, confirmed via timing data), even though the tool itself never changes. Pin the version and cache the compiled binary so only the first run after a version bump pays that cost. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause of the slow Windows builds found via direct measurement: GitHub Actions caches are only restorable from the same ref or the default branch, and releases are triggered by pushing a brand-new tag every time — a ref with no prior build, hence no cache to restore. Confirmed by re-running the workflow twice on main via workflow_dispatch: the Windows build (by far the slowest, since it compiles Fyne's CGO/OpenGL bindings) took 378-401s cold, then only 35s once main's cache was warm — an 11x difference, with zero toolchain changes. This was never a compiler/download problem; it was that main's cache never existed to begin with, because nothing had ever built there. Building on every push to main keeps it warm, so the next tagged release should inherit it instead of starting cold. The create-release job's `if: startsWith(github.ref, 'refs/tags/v')` guard is unchanged, so this doesn't publish a release on every commit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ning actions/cache@v4 was pinned to a version that still declares "using: node20" in its action.yml, which GitHub now runs on Node 24 anyway with a deprecation warning. Bumped to v6.1.0 (node24), and brought the other pinned actions along to their latest patch/minor release while checking for it: actions/checkout v6.0.2 -> v7.0.1, actions/setup-go v6.4.0 -> v7.0.0, softprops/action-gh-release v3.0.0 -> v3.0.2. actions/upload-artifact and actions/download-artifact were already on their latest release. No breaking changes noted in any of these releases' changelogs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
… URL The rdp://user@domain@host URL is not a valid URI for Windows App or Microsoft Remote Desktop, which rejected it with "The URL is not valid. Notify your network administrator." Open the same .rdp file used on Windows with the default .rdp handler instead, so port, domain, gateway and drive redirection settings carry over too. The file is removed after 60 seconds or on app exit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Windows App and Microsoft Remote Desktop on macOS ignore passwords in .rdp files, so the 1Password-resolved password never reached the client. Copy it to the clipboard (via stdin, marked Concealed/Transient so clipboard managers skip it, with a pbcopy fallback) before opening the .rdp file, tell the user in the status bar to paste it, and clear it after 45 seconds or on app exit, unless the clipboard changed meanwhile. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The macos-14 image was retired on 2026-11-02, failing the job with "The configuration 'macos-14-arm64-us-default' is not supported". Also set MACOSX_DEPLOYMENT_TARGET=12.0 so the cgo code isn't built for the runner's own macOS version, keeping the binary runnable on older Macs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Windows App can't take the 1Password password, so prefer FreeRDP's SDL client when it is installed (PATH, then Homebrew/MacPorts directories) and pass all arguments, passwords included, via /args-from:stdin so they don't show up in ps. Connection settings (gateway, certificate level, NLA, drives, resolution, colour depth) are mapped to FreeRDP options. Smartcard gateways and machines without sdl-freerdp keep using Windows App with the clipboard hand-off; MREMOTEGO_MAC_RDP_CLIENT forces either client. Untested on a Mac so far: docs/MACOS_FREERDP_TESTING.md lists what to check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A colleague confirmed sdl-freerdp works on a Mac, so the checklist is no longer needed. README, QUICKSTART, PASSWORD-MANAGEMENT and CLAUDE.md now describe which RDP client each platform uses and how credentials reach it; the CHANGELOG gains entries for 1.7.1-1.7.3 and the FreeRDP feature. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The previous commit only removed the test checklist; the README, QUICKSTART, PASSWORD-MANAGEMENT, CLAUDE.md and CHANGELOG updates it describes were left unstaged and are added here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.