An envelope code that ResponseCode does not know deserializes to Unknown, so
the error a caller sees has lost the number Proton sent. Log path, HTTP status
and the raw code at debug level before mapping it.
A wrong mailbox password surfaced as InvalidOperation("no active user key could
be unlocked"), which a caller could only recognise by its text. It is now
ProtonError::KeysLocked, and AccountClient::unlock() checks a secret with a
single core/v4/users request instead of loading every address.
Derived passphrases, the mailbox password and the cache encryption key were
plain Vec<u8>s, cloned freely and never wiped. They are Zeroizing now, and the
passphrase map is KeyPassphrases: wiped on drop, redacted in Debug, with
derive_secret() for a client that wants a key only an unlocked account can
reproduce. with_key_passphrases takes it.
Breaking: ProtonError gains a variant, key_passphrases() and
with_key_passphrases() change type, and derive_key_passphrase returns
Zeroizing<Vec<u8>>.
Port upstream 0aabea59: report_recently_accessed on ProtonDriveClient and
ProtonPhotosClient, batches of 50. Also read the ThirdParty/Sdk flags from
f257c20e on link and revision DTOs. Pin bumped to df3a717b.
`AccountClient::key_passphrases` is now public, and
`AccountClient::with_key_passphrases` / `ProtonDriveClient::with_key_passphrases`
build a client from the per-key passphrases alone. A client that persists a
session can store those instead of the mailbox password, which on a
single-password account is the login password itself.
`ProtonApiSession::second_factor_methods` exposes the login's 2FA bitmask
(TOTP, FIDO2), so a client without WebAuthn can tell an account that only has
a security key apart from a wrong code.
enumerate_nodes and enumerate_nodes_light cached parent keys per batch by
the link's parent id. Every parentless link in a volume landed on None, so
when several share roots were enumerated together, the first root's share
key was used for the rest and they were dropped with "missing key".
Name a parent key by where it comes from: Parent(folder) for a link with a
parent, Root(link) for a parentless one. The batch cache and the
parent-key single-flight now both use that identity. The single-flight
previously keyed a root and its children on the same link id, although a
root resolves to its share key and its children to its node key, so two
concurrent cold loads could hand one of them the wrong key.
Fixes#2
Every client built by the SDK now shares one builder. It sends TCP
keepalives and HTTP/2 PING frames every 15 seconds, also while the
connection is idle, and drops a connection whose PING goes unanswered for
10 seconds. A connection that a NAT or middlebox silently dropped is then
noticed before a request waits on it for the full request timeout.
Connecting is capped at 15 seconds, or the request timeout if that is
shorter, so an unreachable host fails fast and the retry loop moves on.
Other Proton clients write a `Location` object with `Latitude` and
`Longitude` into a photo's encrypted extended attributes. The decoder
dropped it. It is now decoded and exposed as `PhotoProperties::location`,
a `PhotoLocation` in WGS 84 decimal degrees.
Coordinates that are missing, not finite, or off the globe give no
location rather than a wrong one. The new field defaults on
deserialization, so nodes cached before this change still load.
`PhotoProperties` gains a public field, which breaks code that builds it
with a struct literal.
- read the SHA from the Pinned line (7-40 chars) instead of requiring a
full 40-char SHA the script itself never printed; the old grep died
silently under pipefail
- print the full head SHA to pin
- require the pin to be an ancestor of origin/main, since a rewritten-away
pin still resolves locally until gc
- --diffs now prints patches, not just stats
- --all no longer reports dropped noise
- accept submodule/worktree checkouts where .git is a file
Port AlbumsManager.updateAlbum (name only), deleteAlbum and removePhotos
from the TypeScript SDK: PUT photos/volumes/{vid}/albums/{lid},
DELETE ...?DeleteAlbumPhotos= and POST .../remove-multiple in batches of
ten.
Port 6cbf2f44 (stop retrying permanent API errors on block transfers)
and 20822176 (small file upload interop); 6ce47922 is a no-op here.
- Add ProtonApiError::is_retriable / ProtonError::is_retriable mirroring
C# RetryPolicy.IsRetriable: 4xx is permanent except 404, 408 and 429,
with envelope codes able to override the HTTP status.
- Gate upload_one_block's retry loop on it so a permanent rejection of a
revision fails immediately instead of being replayed three times.
- Extract BlockTargets from RevisionReader so the whole-file download
path, the public link download and the reader all re-mint expired
block URLs through one generation-deduplicated refresh.
- Fall back from the small upload to the block path on AlreadyExists
only; the small upload is not idempotent, so everything else keeps
propagating.
- Bound a server-supplied Retry-After by RetryPolicy::max_retry_after
(default 120 s) so a long rate-limit answer cannot look like a hang.
- Moves go through `move-multiple` in batches of 150, with an optional
target name per node (`move_nodes_streaming` / `NodeMoveItem`), a single
`InvalidRequirements` retry against the server's current name hash, and
passphrase signing for anonymously created nodes. A batch rejected as a
whole keeps its API error code on every node.
- Share memberships carry invite time and inviter email, and the inviter's
`drive.share-member.inviter` signature is verified as non-fatal metadata
(`verify_detached_with_context`).
- `Node` gains `direct_role` and `share_id`.
- Trashed detection reads `TrashTime` as well as the legacy `Trashed`.
Breaking: new public struct fields on `Node` and `ShareMembership`.
Ports upstream C# e0e198e2 (SavePhotosToTimelineAsync, itself the JS
saveToTimeline). Photos already on our photos volume are moved into the
timeline root via PUT photos/volumes/{vid}/links/transfer-multiple,
batched so no request carries more than ten links and a photo is never
split from its related photos; photos on another volume — from an album
shared with us — are copied via POST volumes/{vid}/links/{lid}/copy, one
request each. That closes the cross-volume copy hole (TS copyPhoto).
The re-encryption is what add_photos_to_album already did, so it moves
into a shared photo_target_payload: name re-encrypted to the target key
and signed by the photos membership address, name/content hashes under
the target hash key, node passphrase rewrapped so the original
NodePassphraseSignature survives.
A photo the server reports an incomplete group for is re-queued once
with the related photos it named; only its second answer becomes an
outcome, so outcomes arrive in completion order, not input order.
Also adds ProtonPhotosClient::enumerate_events (c8d03244's only
non-interop hunk) and bumps the upstream pin to c8d03244. Upstream
29e58378 (upload telemetry) and 0537d906 (NodeProvider refactor) are
deliberately not ported — see UPSTREAM_SYNC.md.
Public links (public_link.rs, ported from the TS SDK — the C# SDK has no
equivalent): ProtonDrivePublicLinkClient lets a visitor with no Proton
account open someone else's share link. `info` reads pre-auth metadata,
`open` runs the SRP handshake against drive/urls/{token}/info + /auth and
unlocks the share key (bcrypt SharePasswordSalt -> key password -> the
SKESK'd SharePassphrase -> ShareKey). The read surface then reuses the
ordinary link/children/revision endpoints. Signature verification is
deliberately absent: an anonymous visitor cannot read core/v4/keys/all,
matching the TS SDK. Supporting primitives: http::get_unauthenticated and
crypto::decrypt_armored_with_password.
Revision history: enumerate_revisions / get_revision / restore_revision /
delete_revision, plus open_revision_at / download_revision{,_to} to read a
specific revision. Drafts are filtered on the wire value, since
RevisionState::from_raw maps 0 to Active. Three server behaviors found
live and worked around: ?NoBlockUrls=true still emits Blocks with null
BareURL, so get_revision deserializes into a DTO without that field; the
restore POST needs an empty object body, not null; and restore is async
(HTTP 202, non-1000 envelope) so the new active revision is not live on
return.
Path and hierarchy helpers: get_node_hierarchy, get_node_path,
get_node_by_path, create_folder_path. Names are encrypted and there is no
name-query endpoint, so lookup walks and decrypts one directory level per
segment.
Fix a silent-corruption path in block-size resolution. RevisionReader
accumulates block sizes to derive where each block starts in the
plaintext, so a vector that overstates any block but the last shifts every
block after it and the reader splices at the wrong offsets — full-length
reads of the wrong bytes, no error raised. resolve_block_sizes previously
guessed all-full blocks when both Common.BlockSizes and Common.Size were
unusable. It now errors for multi-block files and only assumes a full
block when there is exactly one (which cannot be misaligned). Regression
test in revision.rs::padded_block_sizes_shift_later_blocks.
Recover from stale upload drafts. An upload interrupted after the draft
node was created but before it was sealed leaves an unsealed draft, and
every later attempt at that name returns 422 AlreadyExists forever. Draft
creation now deletes the conflicting node and retries when the conflict is
an unsealed draft; by default only our own client's, with
upload_file_replacing_draft_from opting into any client's to recover
across a daemon restart (which rotates our client uid). A committed file
of that name is never touched.
Live tests for the public-link round trip, custom-password links, revision
history, and the path helpers.
nvrl