Repository navigation
Replies: 80 comments
|
Post-v4.1.6 cleanup: winget unblocked, release assets made immutable, and the rsync parity story told honestlyPost-4.1.6 follow-up, done on Four things landed today, all of them consequences of the v4.1.6 release audit rather than new work. The winget 4.1.6 submission was blocked; fixing it properly surfaced a second, older defect in the same area that had been quietly breaking an old published version since April.
An audit ran alongside the 3.3.5 fix, to establish whether the asset drift was isolated or a pattern. Every published winget version was checked against the Sigstore bundle shipped next to each asset in the same GitHub release:
Two independent methods agree on the same single answer: Microsoft's own hash detector flags 3.3.5 and nothing else, and the Sigstore sweep flags 3.3.5 and nothing else. The drift is a one-off, and the immutability fix above closes the mechanism that caused it. On the parity split, the substance rather than the wording: Verified green: |
|
The Nextcloud trash was unreachable from the CLI, and the reason was one string comparisonPost-4.1.6 follow-up, done on This batch started as a disk-space cleanup on the lab server and turned into three product defects, one of them user-facing on every Nextcloud-class profile. Reporting it in the order it was found, because the order is the point: each finding was only visible because the previous one had been fixed.
Live result of the trash work, on real servers:
On the benchmark, the finding worth remembering: the suite was not idempotent, so from the second execution onward the cold-upload scenario found its target already on the remote and measured a no-op, while keeping the label One correction to an earlier report in this tracker: Verified green: |
|
AeroRsync learns the xattr block, without changing a single transferPost-4.1.6 groundwork, done on rsync appends an extended-attribute block to every file-list entry once The wire shape is pinned against bytes measured on rsync 3.2.7 with
Two defects were found and fixed during the work rather than left for the next session:
Verified green: On CI: Checks, Aerorsync Protocol (strict clippy with the feature, mock suite, and the Docker lane 3 against a real rsync 3.2.7) and Delta Sync Integration all green on Three things this step deliberately did not do, recorded so they are not lost: the sender still reads no attribute from the local file, the negotiation flag is hard-wired off in two places that must be flipped together, and the symlink case is handled from a reading of rsync's own call order rather than from captured bytes, so it needs covering in the live acceptance lane. |
The update toast shows the 100% frame, and the badge says what Sigstore actually provedPost-4.1.6 follow-up, fixed on Three defects in the same surface. One is visible, the other two are about the app describing its own verification in terms that did not match what it had checked. The Rust verification path itself is unchanged: what changes is that the evidence it already produces now reaches the user, and that the states where there is no evidence stop borrowing the language of the states where there is.
The verifier version shown in the panel comes from Two things the review pass is worth recording for:
Verified green: Not yet done, and it cannot be: the live test. The verified path is only observable across a signed release pair, so it has to ship first and then be exercised by updating from v4.1.6. One data point for known issue #3 while it was open in front of me: the rsync preamble desync recurred a third time on 2026-07-25, on this PR at |
|
The rsync extended-attribute wire is finished, and none of it changes a transfer yetPost-4.1.6 groundwork, done on The file-list entry can only carry an attribute value up to 32 bytes. Above rsync's Everything below was measured against rsync 3.2.7 with
On modelling: an attribute's value is now either inline bytes or a deferred length plus digest, rather than a byte vector that would have had to lie about the deferred case by being empty. After decoding an entry, a large attribute's bytes are genuinely not known yet, and the type says so. The sender gate also became rsync's own, Verified green: Still deliberately not done, so it is on the record rather than implied: the sender does not yet read attributes off the local file, nothing applies them on the receiving side, and the symlink case is handled from a reading of rsync's own call order rather than from captured bytes, so it wants covering in the live acceptance lane. |
The snap GUI paints again, and CI has the frame to prove itPost-4.1.6 follow-up, fixed on The snap fixed in #460 started, ran its CLI, and opened a white window. Two separate defects were behind it, and neither was congenital: they were introduced by a packaging change in December.
What the gate measured on run 30239820626, the first machine-checked evidence that this window draws anything:
One deliberate trade is still open. Note for the release: Verified green: Build AeroFTP run 30239820626, all four platform legs plus |
|
Lane 3 survives Docker Hub, the preamble desync is gone, and local xattrs can opt inPost-4.1.6 follow-up, fixed on Three aerorsync-only landings, isolated from the snap packaging work. None of them changes a default transfer path unless a caller opts into
What was ruled out before the root cause for known issue #3 (kept for the file): the bad version was byte-identical every time, not the LCG test payload, not the per-session rsync seed, and not caused by pure Verified green (local, with the aerorsync feature the pre-push gate does not enable): On CI for #467 at Still open on purpose: B4 live Docker acceptance for xattrs is not in this PR, and |
Windows: the vault files stopped being deletable by the user who owns themPost-4.1.6 follow-up, fixed on A user installed the portable build to try it, then could not delete the folder. Everything went except The hardening in
What replaced it: the DACL is built from the process token's user SID ( Two traps closed on the way:
Verified green: One honest caveat: the five new |
The GPU comes back for the machines whose driver worksPost-4.1.6 follow-up, fixed on Queued #14 made the snap GUI paint again, and one of the steps it took was pinning So the question is now asked instead of assumed, at startup, before GTK or WebKit initialize anything, since WebKit reads the variable on its way up.
What the snap gate measured on run 30247614244:
Worth recording, because it inverts the assumption the pinned variable was based on: Verified green: Build AeroFTP run 30247614244, all four platform legs plus |
|
Community triage pass: ten fixes across Discover, My Servers, Zoho WorkDrive, Jottacloud, MEGAcmd, profile export and the docsPost-4.1.6 follow-up, fixed on One pass over the open feedback. Three of the reports turned out to be something other than what the symptom suggested: the profile drop was landing correctly and the indicator was wrong, the Zoho failure was the API gateway rejecting a URL rather than WorkDrive rejecting a move, and the TAB.DIGITAL placeholder was not a TAB.DIGITAL miss but a catalogue-wide one. Two more defects were found while answering questions rather than reported at all, and one more while verifying the Zoho fix end to end on a live account, which is the export defect at the bottom of the table and the one with the widest blast radius of the batch.
Both provider chains are confirmed against live accounts, not just against the documented shapes. Jottacloud: a folder listing of 13 entries, two files moved to the bin, the listing down to 11, and both files present in the recycle bin with Still open from the same batch, reported after these landed: in table view a profile row will not lift at all while a sidebar protocol chip is active (it does on All, and the card view is unaffected). Under investigation, tracked on #453. Verified green: |
Every secret a connect path reads is now a secret the export carriesPost-4.1.6 follow-up, fixed on Queued #27 fixed one exported profile that could not refresh, and it was found the way such things usually are: by exporting a Zoho WorkDrive profile into another vault and watching it fail. This is the systematic version of that question, asked for every provider. The method was to enumerate the vault keys each connect path reads, then diff them against
Providers checked and found clean: Jottacloud, Yandex Disk, Google Drive, Google Photos, Dropbox, OneDrive, Box, pCloud (its region was covered by Not live-verified: there is no 4shared account on this machine, so the work is verified against the vault layout, the connect paths it mirrors and the new map test, not against a real 4shared export and import. Verified green: |
A flaky guard is a guard you cannot readPost-4.1.6 follow-up, fixed on
On the evidence, plainly: an earlier version of this description said the failure had not been reproduced. That was true when written and stopped being true. What did not reproduce it: 5 isolated runs on the branch it appeared on, 5 on So the reproducer is concurrency, not CPU load. What stretches is the scheduling of the poller task between observing Verified green: |
|
AeroRsync preserves
|
| Area | Description | Status | Ref |
|---|---|---|---|
| Live X.6 (lane 3) | 5 acceptance tests with .with_xattrs(true) vs stock rsync 3.2.7 on :2224 |
🟢 live | f6f91f930 |
| Generator drain | Drain peer send_xattr_request (skip varints + 0 terminator) before sum_head when ITEM_REPORT_XATTR is set; without it OOB desynced sum_head |
🟢 fix | f6f91f930 |
| CI registration | lane3 filters for all 5 xattr tests in aerorsync-protocol.yml |
🟢 | f6f91f930 |
| Unix production | SftpProvider::delta_transport #[cfg(unix)] transport.with_xattrs(true); fail_on_metadata_loss stays soft (X.5) |
🟢 | 77e38681a |
| Windows | Default off (no direct user.* analogue) |
🟢 intentional | - |
| Public docs (X.7) | PROTOCOL-RSYNC-COMPARE.md + aerorsync README: xattr removed from "not yet implemented"; ACL #1 |
🟢 docs | a39e7d6f7 |
| Residuals R1-R5 | Docker Hub gate, symlink attribute reads, batch flag drop, apply-before-rename unit pin, probe side effect. Out of scope for this wave, but see the note below: R2 stops being latent with this merge | 🟡 open | residual audit of #467 |
Live X.6 tests (names)
Prior lane3 (content/symlink), still green:
driver_upload_live_lane_3_real_rsync_byte_identicaldriver_upload_streaming_live_lane_3_real_rsync_byte_identicaldelta_upload_symlink_live_lane_3_readlink_identicaldelta_download_symlink_live_lane_3_readlink_identical
New xattr acceptance:
delta_upload_xattr_inline_live_lane_3(value <= 32 B inline blob)delta_upload_xattr_oob_live_lane_3(value > 32 B digest + OOB section)delta_upload_xattr_binary_nul_live_lane_3(interior NUL / binary)delta_upload_xattr_none_with_x_flag_live_lane_3(-Xnegotiated, empty attrs, no desync)delta_download_xattr_live_lane_3(remote seed -> local apply before rename)
CLI smoke (Unix production path)
Threshold: CLI uses AeroRsync only for files >= 1 MiB.
1 MiB payload, user.aeroftp.test=cli-smoke-b4, put --delta to stock rsync on :2224: remote sha256 MATCH, remote xattr matched, log transport=aerorsync-proto-31.
Local gates (feature branch, pre-merge)
cargo fmt --all -- --check
cargo clippy --lib --features aerorsync --all-targets -- -D warnings
cargo test --release --features aerorsync --lib aerorsync # 593 passed
RUSTFLAGS='--cfg ci_lane3' cargo test --release --features aerorsync --lib live_lane_3 -- --test-threads=1
# 9/9 (4 prior + 5 xattr)
Verified green on the feature branch with the gates above, and green on the full CI of the merged PR, including the Docker lane 3 (real rsync 3.2.7) job at 11m46s and build-and-release (ubuntu-22.04, linux). Merged as a merge commit (f1c53f833), so the three SHAs above resolve unchanged.
One consequence of turning -X on, stated up front
The residual audit of #467 flagged that reading attributes follows symlinks, and it was latent only because the flag was off in production. It is not latent any more, and it was confirmed against the merged code rather than taken from the audit: xattr_fs.rs documents "we always follow symlinks (options/flags = 0)", and do_upload_symlink passes the link path to build_source_entry, which reads user.* from it whenever preserve_xattrs is set. So a symlink uploaded with -X carries the target's attributes labelled as the link's, and a stock rsync receiver answers EPERM, because Linux forbids user.* on a symlink at all. Correct behaviour, the one stock rsync has, is to send nothing. The fix is llistxattr/lgetxattr on Linux and XATTR_NOFOLLOW on macOS, or simply skipping the read when the path is a symlink.
The four residuals of the #467 audit, closedPost-4.1.6 follow-up, fixed on An independent verification of #467 was done before that PR merged, and #467 merged without the defects it found being corrected, so they went to
On R5, and why it is still openThe probe writes a throwaway The obvious remedy, a probe that does not write, weakens what the probe answers: Method note, since it is the part worth reusingEvery pin here was run against the broken code, not merely observed to pass:
Verified green: |
|
Six reports from Ehud, closed in one pass: Felicloud's flag, middle-click tab close, Security Tools, the benchmark identity columns, copying a link before you open it, and what the default salt actually isPost-4.1.6 follow-up, fixed on Six separate comments landed over a week. They are unrelated to each other but each is small and each is a real defect, so they ship as one branch rather than six. Two of them are cases where a previous fix was correct and incomplete: the TAB.DIGITAL flag correction did not sweep the rest of the catalog for the same error, and middle-click gained "open in background" without gaining its counterpart.
One thing found while checking the picker and worth stating plainly, because it is wider than the column rename: the picker's identity helper read Verified green: |
|
Six destructive actions were asking a question that never reached the userPost-4.1.6 follow-up, fixed on The report was "Manage Users deletes without asking, for consistency's sake please add a popup". There was a confirmation on that path. WebKitGTK does not implement the JavaScript script dialogs, so This class was closed once already. The v2.6.4 audit filed it as H18, converted six components, and recorded the verification in
No new i18n keys: all five messages and both button labels already existed in the 47 locales.
An audit sentence cannot hold an invariant. A test can, which is why the invariant is stated as one now. Verified green: |
|
Main CI is green again:
|
| Area | Description | Status | Ref |
|---|---|---|---|
| Dependencies | event-listener 5.4.1 -> 5.4.2 (patched range >=5.4.2), lockfile-only change, one lock entry, no other packages touched |
🟢 fixed | 2554635c0 |
Verified green: Format, audit & unit tests (the workflow leg that runs cargo audit) passes on the PR, full CI matrix green on 6b442911c.
|
The guard against destroying a user file was itself fail-openPost-4.1.6 follow-up, fixed on The audit fix added an overwrite guard to
Three new tests, each verified failing against the previous guard and passing against this one: an unverifiable caller-named path is refused, the scratch path still runs, and the CLI helper is exercised across NotFound, ServerError, AuthenticationFailed, PermissionDenied and NotConnected. On the atomic no-clobber alternative raised in review: adding an exclusive-create primitive to Verified green: |
The weekly Snap refresh was red for a state that is not a defectPost-4.1.6 follow-up, fixed on The scheduled
Verified against the real tags: Worth stating plainly, because it is the actual remedy: this is a false-red fix, not a fix for #465. The migration is already on |
The remaining sync commands leave the main threadPost-4.1.6 follow-up, fixed on Continuation of the off-main-thread command work whose first batch already shipped. This drains the rest of the sync commands out of
Process note worth recording: these four commits existed only in a local worktree, never pushed and with no PR. They were found by auditing every branch under Verified green: full CI matrix on the PR, all lanes. |
Provider logos as user avatars: two different causes, one featurePost-4.1.6 follow-up, fixed on The report separated two symptoms, and that separation is what made the cause findable: some provider icons did not render at all, and some of the ones that did were zoomed in with their edges cut off. They are unrelated defects that happen to live in the same feature.
Six new tests in Verified green: |
Add Service kept two of everythingPost-4.1.6 follow-up, fixed on Switching between Grid view and Table view changed more than the layout: a typed search term was lost, the search box moved position, the chosen pricing filter was dropped, and whole sections appeared and disappeared. The request was that the two views keep everything the same except the grid or table itself.
Six new tests in Trap worth recording for whoever edits them: one assertion is anchored on the JSX branch specifically, because Verified green: |
One order and one name per connection methodPost-4.1.6 follow-up, fixed on FileLu read
The sequence is the one the reporter proposed, roughly most to least chatty by round trips. Stated explicitly because it matters: this is a presentation order, not a recommendation. Which method is fastest depends on the shape of the transfer, many small files versus few large ones, so the recommended/fastest marker stays deferred on #368 until the benchmark harness produces real per-protocol numbers, rather than being guessed at here. Five new tests in Verified green: |
Sync commands off the main thread: closing the accountingPost-4.1.6 follow-up, fixed on The two earlier comments left the bookkeeping open ("8 moved now, 59 in a follow-up, 23 once it lands", and a drain comment citing one SHA for four commits). End state on
Two corrections to the earlier narrative. The pre-work count was 112, not 82: the 82 figure is what #524 froze after already moving 30, so "8 moved immediately" was really 8 allow-listed alongside those 30. And the residual set is not "15 that must stay synchronous": it is 23 justified entries, of which only 4 claim a hard main-thread requirement. #563's four branch commits were Verified green: the scan re-run on |
|
Main CI is green again:
|
| Area | Description | Status | Ref |
|---|---|---|---|
src-tauri/Cargo.lock |
tauri-plugin-log 2.9.0 no longer pulls byte-unit, so rkyv, rust_decimal, byte-unit, seahash, tap, utf8-width, wyz and value-bag all leave the graph. The manifest already said tauri-plugin-log = "2", so no manifest edit was needed for the Rust side |
🟢 fixed | 3f2e1dcb0 |
package.json, package-lock.json |
@tauri-apps/plugin-log to the matching 2.9.0. Tauri refuses to build when the NPM package and the Rust crate differ on major/minor, so the two halves are not separable; the first attempt moved only the crate and failed the Windows build with "Found version mismatched Tauri packages" |
🟢 fixed | 7c6443aff |
Two things worth recording rather than leaving implied.
cargo tree shows rkyv was never actually compiled into the binary: it sat in Cargo.lock as an optional dependency no enabled feature reached, so real exposure was nil. That is why the fix is low risk, and deliberately not a reason to have silenced the advisory with an ignore entry. cargo audit reads Cargo.lock by design, an entry unreachable today becomes reachable after any upstream feature change, and an ignore would have quietly covered the next real advisory in the same crate.
The npm lockfile was regenerated with npm 10.8.2, the version CI runs under node 20, not the local npm 11. The two resolve differently and a lock written by the newer one has drifted from what npm ci accepts before now. Verified with npx npm@10.8.2 ci --dry-run.
Verified green: cargo audit clean (1186 crates scanned, down from 1205), cargo check --all-targets, and the full PR matrix (15 checks pass, 2 skipped).
One glyph per connection method, shared by both surfacesFixed on Three icon inconsistencies were reported. They are one defect: the glyphs were picked by hand at each site, so they disagreed across surfaces and collided inside a single one.
Worse than the cross-surface mismatch, and not in the original report: inside the My Servers table itself, API and S3 both drew FTPS deliberately shares FTP's glyph and Crypt shares E2E's. The test asserts those two aliases explicitly, so they read as intent rather than as leftover collisions. Four tests were added, and being precise about what they prove: one was verified failing against the pre-fix tree, the one that pins the reported defect (no surface may hand-pick a lucide element for a method). The other three pin invariants of the shared map, which did not exist before this commit and therefore cannot fail against it. They earn their place going forward, not as evidence about the past. Verified green: |
The manual denied an rclone export that ships, and ECC was ambiguousFixed on Two documentation defects, one of which was denying a capability the code has.
That is the worse direction for a document to be wrong in: a user reads "cannot" and never tries. The paragraph now names the providers that do export, states the condition (all three credentials in the vault, which is the case for a profile authorised with your own OAuth app), and describes the fallback. The reporter's practical note is in there too, because it is the part that makes it work rather than merely be possible: AeroFTP and rclone use different redirect URIs, so both have to be registered under the same app for one credential pair to serve both tools. The genuinely unsupported ones are Zoho WorkDrive, 4shared, Internxt and kDrive. Zoho is flagged as a gap rather than a limitation, since rclone has had a Deliberately not done: a blanket rename of every bare "Yandex" to "Yandex Disk". The remaining occurrences refer to the company or sit in broad provider lists, where the short form is correct. One follow up, recorded rather than left implied: this changes the copies in this repository. If Verified green: the full PR matrix (9 checks pass, 2 skipped). |
|
Pre-tag adversarial audit for v4.1.7: PASS, with every release-blocking finding closedFixed on An adversarial review of every commit since v4.1.6, 333 code candidates (236 non-merge) over 342 changed files, across AeroRsync, provider and crypt boundaries, sync and CLI behaviour, frontend regressions, i18n, CI, release workflows and dependencies. The verdict is PASS, and this PR is what makes it one: it carries the fixes for the confirmed release-blocking findings, with regression coverage, plus the security evidence document.
The withheld 30 July audit is formally reconciled in the same pass: MCP-1 and MCP-2 are closed by #549, SEC-K1 by #548, I18N-K1 and the referenced-key gap by #541, PR-2 by #563, and the three quota-limited lanes were completed here. Two previously accepted items stay explicit rather than being quietly folded into the PASS: SEC-2 (Sigstore hard-gate and published-digest product flow) and PROV-4 (Swift recursive-delete pagination beyond 10,000 objects). Verified green: Three release gates remain open and are deliberately not done here: the v4.1.7 manifest and release-note version bump ( |
|
The release pass itself found three things, fixed in the release commitFixed on The v4.1.7 release commit is not only the version bump. Three defects surfaced while preparing it, and none of them would have been caught by anything else in the pipeline.
One process gap is worth recording rather than leaving as luck: no CI workflow runs Verified green: the mandatory local gate on the exact release tree ( |
v4.1.7 is released, closing this trackerv4.1.7 shipped on 2026-08-08 with all 108 queued items, over 237 non-merge commits since v4.1.6. Every platform artifact is published with its Sigstore bundle, and the Snap Store is on revision 218 (
Two items stay explicitly accepted rather than folded into that pass: SEC-2 (Sigstore hard-gate and published-digest product flow) and PROV-4 (Swift recursive-delete pagination beyond 10,000 objects). Three things this release cycle taught us, recorded so the next one does not pay for them again:
Still open and carried forward: the pCloud trash re-auth condition, which code review says is a stale-token state rather than a defect. Everything continues in the v4.1.8 tracker (#575), which carries over the 13 requested items and that one open issue. Thanks to @EhudKirsh, whose reports shaped a large part of this release. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
AeroFTP 4.1.7, Rolling Tracker
Umbrella issue for the next AeroFTP point release (v4.1.7): known issues reported against v4.1.6 and the patches/updates landing on
mainafter the v4.1.6 tag.Before opening a new issue, please check the lists below. If your problem is already tracked here, just add a thumbs-up reaction or a comment with your environment (OS, version, provider) instead of filing a duplicate. We update this issue as bugs are found and fixed.
Found something that is not listed? Open a new issue and we will link it here.
What shipped in 4.1.6
See the v4.1.6 tracker (#422) and the release notes for the full 4.1.6 change set: the AeroRsync Y-RSC wave closing the distance to stock rsync (md4 and sha1 as first-class negotiated checksums in both roles with the whole-file reconstruction genuinely verified, symlinks end-to-end on unix, streaming download signatures, and retirement of the legacy RSNP server stack so production has one path against stock
rsync --server), a stabilised DAG transfer engine (process-global hierarchical governor, durable multipart checkpoints, journal-aware verify and commit, a streaming work frontier bounded over ten million items, endpoint-aware adaptive AIMD, SizeFair scheduling, and five more providers on native multipart workers), MTP and WPD portable devices as a new protocol with its own fingerprint-keyed profile type, AeroCrypt v4 keyslots so a vault unlocks from more than one credential without re-encrypting, measured performance work (multi-file FTPS from 8-18% behind rclone to parity, the FTPS single-stream default 41% ahead, an opt-in SFTP read-ahead about 58% ahead at 12 connections), and the AUDIT-03 sync stack audit closing a remote command execution through a crafted remote filename in rsync-over-SSH plus a class of scan-completeness holes that could drive mass deletion off a truncated listing. 47 languages translated.Patches & updates queued for 4.1.7
Landed on
mainafter the v4.1.6 tag; shipping in v4.1.7.7bd78ccf5d3a03d13523b39ee32382c638c863636e86763636e867sizenames the real reason a figure is a lower bound. Details.63636e8672f0a1087c683d669dfab806712660e09505bbdee1d737b926656e704e477318,d688efadc,d3c5f71d892202590ainvalid rsync protocol version: 2015297409failure is fixed: the write path was discarding the server preamble. Details.cbc6701d8user.*extended attributes when a session opts into-X(B3), without changing any default transfer. Details.4235b8664,5dcc3a9041c455ff4da740a3291,d000d41b97dcc3ce59512b18a6fec98998915bf8f57ee,b721d66ddc27d64b162f26f4ac102f80507e, docs12424a2f16b8934dcf36833f5de5b9f6ab2671a9f47user.*extended attributes end to end against stock rsync, and turns-Xon in production on Unix. Details.f6f91f930,77e38681a,a39e7d6f743c3c1b7f-Xis live. Details.964e44734fe9e8db1e5acfd3bbe028ef4d0197c8bab9e1a5f479734c810ee76,b02b98e4d,7ef33a44f,97a17ea23b6de141cb,9660e3847,a2afd6b86,bfa3c8048,d6d4f2aae,0c084c2ba4b68a188c170967239e9fdc8beca205ba2c25a7efeecbd6951d72f,11c1777f2russhadvisories are closed in the tree, andcargo auditwas never going to say so. Details.61614031719519567d,fb44b9a91,d94cee4cb,edfe61f0f2b07ce5d594c5d33d2n0-mainlinefork is watched now, and the check that was supposed to watch it had quietly become a liar. Details.95026768741754e855be9537c17,87f0114619ea9bc95b82d0f1ebcb9ea098f7186ddf5ee,91f7bed0fcdf7069d85d9b47f9c6d497ba21,644e27791aeroftp-cli connectreported a plausible port and an empty username instead of the real ones, because it rebuilt them by parsing the humanserver_infotext. Details.687d6d597,bb463d1cbtscsits on the production build chain. Details.64efc8f5656dbd12d8,249adf75server_copy, and the AeroCrypt modal rebuilding the silent salt downgrade. Details.c5369ee22,d75887175app.drime.cloudURL. The catalogue also had it inverted,company: 'Drime Cloud', parentCompany: 'Drime', as though the drive were a product under a parent the way pCloud Drive sits under pCloud. README, docs/PROVIDERS.md and cli_catalog.json are regenerated from the corrected entry. Details.52d907d3c2969103b3.max()of the members' signatures rather than of the hamming distances between them, on the raster and text arms both, so a pair two bits apart could report billions and any sort by similarity was meaningless. Test pins it and fails on the old expression. Details.5c92e91c45c92e91c40fc60cdd2197ba20a5621946b88197ba20a5f3287f23dTab.digitalon the docs site were in the VitePress data and config modules, which the 27 July markdown sweep could never reach: the plan snapshot heading, its source label, the sidebar entry and the meta keywords. Verified on the built artefact, zero mixed-case occurrences across the generated site. Details.3e81e42app_readyenvironmental miss is retried once with a visible log line; if it still fails, the gate emits one primary failure and skips every assertion whose evidence the session could not produce. Details.6b748fe08apt install, cancelling the job with every testskipped. The packages come from the Actions cache now, and the step has its own budget3b6cde409x-amz-security-tokenis not on reqwest's strip list; aerorsync applied the peer's mode with& 0o7777in two sites. Details.f9b77aca85768937e3981e64e63,2fad7a15305d30ec41,182a1e3c9,3c7db9c89e8df66b98259ea754840a5a880b#[tauri::command]runs on the GTK thread, solist_subdirectorieswalking a dead network mount froze the whole window. The scoping count was wrong too: 82 synchronous out of 853, not 38c2f7e489dpublic_htmlsubtrees, and paths that only land in one after./..resolution), while the portal gate stops turning a missing baseline into a chooser-shaped red. Details.af109a0686177b9efa&next to a space was mangled in every listing, so a GET of the displayed name 404'd andsync --deleteoffered to delete the real local file. 17 XML readers now keep entity-adjacent fragments; live round-trip re-proved on mergedmainover MinIO and Nextcloud with zerodelete_local. Details.132b681f7,403d565cc,b792b436daeroftp-cli findreportedstatus: okwith zero matches on a directory full of files whenever--profilewas used. With a profile the positionals shift left, so the pattern arrives inpath: the branch passedpathstraight through, dropping--nameand searching forpath's own default/, which matches no file name. A silent wrong answer, not a visible failure. Details.d7a6cbe184c047995dsync --deleteremove the user's real local files: Azure listed nested folders as empty, every strict S3 endpoint (AWS, B2, R2, Alibaba, Storj, Tencent, Oracle, MEGA) could not create a folder at all (411), FileLu WebDAV files would not download (206 read as an error), and FileLu S3 returned double-encoded names. 36 providers now pass end to end. Details.5e6b1e10e,fd420a784,ed209699a,caa030a64,33959e2f2,64937843f,2bf089e393b99f38fb,50cc6bd46,c81119d6b,b13372f21object-containon all three thumbnail surfaces; avatars and chat chips keepcover, and the rule lives in the components because a?rawimport of a stylesheet comes back empty under Vite and would have been the one part no test could read. Details.a5051d89d8b459d430,cca8cd732isRemote={false}to every thumbnail, so a cloud path was looked up on the local disk; both grids now share one LRU thumbnail cache bounded in bytes and keyed by size and mtime, which changing directory no longer clears. Details.5fedb9d7ad3f3a7c83,7eb364b3cwindow.confirmreturns without drawing and the caller proceeds as if the user agreed: on Linux an account went with nothing asked. H18 of the v2.6.4 audit had regressed; it is a test now. Details.5eeafd99b,53e16ccb2,b09593a7eevent-listenerbumped to 5.4.2 for RUSTSEC-2026-0221 (unsoundStackSlotSend/Sync, advisory issued 2026-07-31; the Checks workflow failed oncargo auditfor every main commit since). Lockfile-only change. Details.6b442911cstat(path).is_ok()read every error as "the path is free", so an expired token or a provider 5xx let the upload-then-delete sequence run on a real user file. Both surfaces now proceed only on an explicit not-found; the UUID scratch path stays exempt. Details.b98a7c613graphics-core22. It rebuilds the newest tag with that tag'ssnapcraft.yamlbut gates it with the tooling onmain, which no pre-migration tag can pass. It now skips with a job summary, andforcecannot override that. Details.38272e5b8origin/main. Details.b7253b798object-covercut the edges off logos, including AeroFTP's own rocket. Details.a7bcb52aedb16734beS5 (S3)andS4 (S3). Details.a5e1d4be0tauri-plugin-logbumped to 2.9.0 for RUSTSEC-2026-0235 (rkyv0.7.46, out-of-bounds reads on archives withRc/Arc), reached four levels down viarust_decimalandbyte-unit. The matching@tauri-apps/plugin-logbump ships with it: Tauri will not build when the two differ. Details.3f2e1dcb0,7c6443affCloudmeant OAuth in one and a native API in the other, while inside the table API and S3 both drewDatabase, separated only by colour. One shared map now decides every shape. Details.9f1d7b1d5export_rclonewrites client id, secret and token for Drive, Dropbox, OneDrive, Box, pCloud, Yandex, Koofr and Jottacloud. ECC is now spelled out as error correction, not elliptic curve. Details.681c244b62f864dfa5npm auditwas no longer zero:nanoid(high) anddompurify(moderate, published 7 August) closed at lockfile level. The store listing had served three 404 screenshots sinceabe3402d0, now five real images. Deprecated<mimetypes>replaced. Details.a20a1bc19Requested / under consideration
Community requests and internal follow-ups being evaluated for this or a later release.
Effort: 🟩 quick win · 🟧 medium · 🟥 large / epic. Ordered by effort (quick wins first).
-iselectors (prioritised by the reporter ahead ofEdit(E)and the 2-letter semantics; exact behaviour to be pinned).jpgto.jxltranscode in AeroFile: JXL re-encodes an existing JPEG losslessly and reversibly (the original JPEG bytes reconstruct exactly), for a real size win with no quality loss. Candidate framing: AeroFile as a GUI for libjxl.icnsmulti-size (the v4.1.0 ones are single-resolution drafts). Needs a Mac to build and live-testparticipants/addcontactUUID format (currently a best-effort workaround), investigate the Filen free-plan 10-note limit ghost-note cleanup, and add a rich text editor for the rich note typemalloc(): unaligned fastbin chunk detectedwhile deserializing a D-Bus message, the classic GLib heap-corruption signature (that worker is the victim tripping over an already-poisoned fastbin, not the corruptor). Two marshalling fixes already shipped and are safe: tray badge (31db84f8b) andapp_ready+ splash-timeout (cae95ee91), present since v4.0.5. But the SIGABRT STILL recurs (v4.0.9 on 2026-06-25, and the v4.1.2-era build on 2026-07-05, identical signature): the marshalling is INCOMPLETE, a still-uncovered off-main-thread GTK path remains. Sync Tauri commands are provably main-thread (safe), so the suspects are the event/plugin callbacks whose thread context is unconfirmed: trayon_menu_event/on_tray_icon_event, the single-instance plugin callback, andon_window_eventCloseRequested. Pre-existing across versions, intermittent, triggered by D-Bus storms on suspend/resume or monitor standby; it can corrupt the whole app until restart. Definitive path (owner-approved): adopt self-hosted crash reporting with native minidumps to capture the real corruptor, plus an ASan/valgrind repro, then finish the marshalling on the remaining callbacksHKCU\Software\AeroFTP\Settingsand re-read byNSIS_HOOK_POSTINSTALLso an in-app update cannot silently restore it (POSTINSTALL runs on every install, and an update is an install), plus a/NOASSOCsetup switch. A visible components-page checkbox is out of reach without forking the Tauri NSIS template, which is why it is parked rather than half built. Raised in #454; deferred because AeroFTP never claims the default handler for the general formats, it only adds itself to "Open with" plus its own context-menu entries, so with the uninstall residue fixed (queued #59) what remains is menu visibilityssh_exec.rs/ssh_shell.rsexist andssh_shell_*are registered Tauri commands (lib.rs:19360), but none of the 92 CLI subcommands and no MCP tool expose them, and MCP'sserver_execis file-ops only (ls/cat/stat/find/df) despite the name. (b)nextcloud_empty_trash()(webdav.rs) was reachable only fromNextcloudTrashManager.tsx; same for the Koofr, pCloud, Yandex and Dropbox trash managers. Cost already paid: 30 GB of Nextcloud trash on the lab server that no command-line tool could reclaim, diagnosed over SSH withoccinstead of one click. Partially closed: the trash surface now exists on the CLI (aeroftp-cli trash list/empty/restore/delete), SSH exec/shell does not. The repo already has the instrument to close the class rather than the instances: diffingaeroftp-cli inventoryagainst the#[tauri::command]set registered inlib.rsyields the full gap list in one passstale_nonterminal()only surfaces records past the 7-day TTL, and the scavenger then aborts only those whose provider, protocol, host and account match the endpoint you are currently connecting to. So the condition for cleaning a record is going back to the very server that produced it: stop using a server and its records are not old, they are immortal. Nothing else prunes them, and there is no cap on the directory. The machine where this was found held 325 records accumulated since 21 July, all from mock endpoints that by construction nobody will ever connect to again, which is the pathological case of the same rule a real user hits with a decommissioned server. Wants a decision rather than a patch, since each option has a different failure mode: a hard cap loses the oldest resumable transfer, a global age sweep abandons a session the user might still want, and an explicit "forget this endpoint" is honest but manual. Worth deciding before the store grows on a user's machine rather than a developer's20260728T074500Z-E4-flaky-multipart-cancel-ROOTCAUSE.mdresolve_compare_overlay_keysconsults this connection's cached overlay whenever thekindmatches, without checking thatvault_idhas theprovider-overlay:<kind>:<owner>sentinel shape. Today no caller can reach it: the command is called only by the GUI, and every non-null write ofrcloneCryptVaultId/aeroCryptVaultIdbuilds a sentinel, so a real standalone vault UUID never arrives, which also makes the documented vault-map fallback dead code for this command. The moment one does arrive (and the CLI / GUI / MCP parity audit on row 9 is exactly the work that would wire it) the cache would silently outrank a vault the user named explicitly, normalize with the wrong key material, drop every row and read as "no differences": the very symptom #497 closed. Gating the cache branch on the sentinel shape restores the rule that an explicitly named vault wins, and leaves the error surface unchanged (a sentinel with a mismatched kind still falls through to "Crypt vault is not unlocked"). To be taken with a test that passes a real UUID while the cache is armed on the same kind, otherwise the guard is removable as redundant later, which is the same trap already closed for the normalization guard. (b) The Filen multipart mtime capture fails silently.begin_multipart_uploadreads the source mtime throughtokio::fs::metadata(p).await.ok(), so an I/O error is swallowed and the commit stamps its own time, indistinguishable from the regression #497 just fixed, with no log line to separate the two.filen_logalready exists, so it is amatchin place of.ok()with the fallback unchanged4800472122)en.jsonand all 47 locales (the code treats any exact 32-hex ETag as MD5-shaped, including SSE-KMS/SSE-C; current text implies those are excluded). (b) fr: upload keys using "Télécharger" (download verb) for upload actions, "Transfer Queue"/"staged" mixed labels, advertised AI tool count vs actualai.toolLabelsentries. (c) fi: drag-and-drop wording ("vetää ja pudota" class) and an incompleteplacementBothDescsentence. (d) nl: same ETag wording Major. Small per-locale translator batch, same GLM method as #512REVIEW-NOTES-PR538.mdrclone.conf. Neither direction ships today and the Zoho half is gated by a wrong premise:rclone_oauth_client_cred_keyinbridge_commands.rsreturnsNoneforzohoworkdrivewith a test pinning the comment "there is no Zoho backend in rclone", when rclone has had azohobackend for Zoho WorkDrive for years (region,token,root_folder_id). The three fields it needs are all held already: the OAuth blob, whichaeroftp_token_to_rcloneconverts to rclone's token shape for every other backend; the region, from the provider'sapi_base(); and the workspace or team folder id, fromteam_idand the team-folder discovery inzoho_workdrive.rs. Rclone Crypt is half done in the opposite direction:rclone_import.rsalready parsestype = cryptand bothreveal_obscuredandobscure_passwordexist, so what is missing is the export arm emitting the second section, withremote = <base>:<path>derivable rather than guessed because an overlay path is always at or below the remote path of the server it wrapsKnown issues found after release
Reported against v4.1.6. Carried over from the #1414 tracker where still open.
access_tokenquery param (pCloud rejects the Bearer header on trash) and refreshes viaget_valid_token(both since v3.1.4), with the crypt fix ind1e0bef90, so no code defect remains. The residual is a stale-token / re-auth condition, pending a live re-auth re-test. Carried over from #1414 known issue #4mainby queued #47. Three moderaterusshDependabot advisories (GHSA-g9hv-x236-4qp3, GHSA-5xvq-cp9x-6p6r reachable client-side; GHSA-cqjc-rmpq-xprq server-side only, not reachable), all availability-only panics, all predating v4.1.6 and disclosed in the v4.1.6 release notes. The fix isrussh0.62.4, which was previously unreachable because it requiresed25519-dalek ^3against the=3.0.0-rc.0exact pin held byn0-mainlinein the iroh P2P graph, with both upstreams already at their newest release so no local version selection resolved it. It is resolved now by a[patch.crates-io]onaxpdev-lab/n0-mainlinepinned byrev, which is the v0.5.0 release commit plus the single line that relaxes that requirement, and3.0.0-rc.0is gone from the lockfile. Two things stay true and should not be read as closed by the green:cargo auditstill reports clean because none of the three has a RustSec counterpart, so only the Dependabot graph surfaces them and its silence certifies nothing; and the patch section carries an exit condition that nobody is watching automatically, namely delete it as soon as n0-mainline publishes a release admitting3.0.0final, still not the case upstream on 2026-07-28. Analysis indocs/security-evidence/RUSSH-DEPENDABOT-ADVISORIES-2026-07.md; re-check with.github/scripts/check-russh-unblock.sh(queued #3)native_rsync_upload_against_stock_rsync_preserves_bytesintermittently failed with a preamble desync; root cause found and fixed onmain(queued #16). The upload leg of the stock-rsync integration lane failed withHardRejection(InvalidFrame): server preamble: invalid rsync protocol version: 2015297409(bytes81 ff 1e 78), then passed on rerun with no code change, twice on 2026-07-25 (3deea6f3fand63636e867) and again later. The value was identical every time: LE81 ff 1e 78is the server preamble starting at offset +4 after a discarded 4-byte protocol version. Root cause:ssh2::Channel::flush→libssh2_channel_flush_exempties the read buffer, so a flush after writing the client preamble could drop the already-arrived server reply under CI contention (upload more often than download). Fix incbc6701d8removes that flush from the raw write path and frame writes, with a unit pin for the misaligned value. Delta Sync Integration and Aerorsync Protocol (including Docker lane 3) green on the merge of #467Status legend: 🔴 confirmed · 🟡 investigating · 🔵 planned / idea · 🟢 done / fixed (pending release) · ✅ released
Affected platforms
Maintained by the AeroFTP team. Current release v4.1.6 (#422), next v4.1.7. Patches accumulated here; each release line still gets its own tracker.
All reactions