commit 6e99f8b301f0db7c9f74c0f8a37eab53c266f10e
Author: Leon Brocard <acme@astray.com>
Date:   Wed May 6 10:40:34 2026 +0100

    gui: serve static files with gzip/deflate compression
    
    Before this change, the GUI server sent all static files uncompressed,
    meaning the browser had to download the full size of every JS, CSS,
    and HTML asset.
    
    After this change, the GUI server uses chi's Compress middleware at
    level 5, which negotiates gzip or deflate encoding based on the
    client's Accept-Encoding header.
    
    This reduces transfer sizes significantly for the web UI assets, for
    example assets/index-CvfdU_RR.js is 874 KB uncompressed, and
    265 KB compressed.
    
    This is consistent with how rclone serve http, webdav, and restic
    already compress their responses.

commit 9d4c912e0e479dc459464cf3559088bb67385655
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Sat May 2 21:11:50 2026 +0100

    s3: fix STS call per request by caching AssumeRole credentials
    
    The stscreds.AssumeRoleProvider from AWS SDK Go v2 does not cache
    credentials by itself. The SDK only auto-wraps providers with
    aws.CredentialsCache when they are loaded via
    config.LoadDefaultConfig; when assigned directly to
    aws.Config.Credentials it must be wrapped manually, as documented on
    stscreds.NewAssumeRoleProvider.
    
    Without the cache, configurations using role_arn would call AssumeRole
    once per S3 request, flooding STS and CloudTrail.
    
    See: https://forum.rclone.org/t/aws-iam-roles-credentials-arent-cached/53732

commit 0737599cd4b4ecd74b37721a401b0891d04bb6f6
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue Apr 28 10:57:02 2026 +0100

    protondrive: fix segfault when copying files missing revision metadata
    
    When a Proton Drive file has no active revision attributes,
    readMetaDataForLink returns a nil FileSystemAttrs and Object.originalSize
    is left as nil. Object.Open then dereferenced this nil pointer when
    calling fs.FixRangeOption, causing a SIGSEGV during copy.
    
    Use Object.Size() instead, which already implements the correct fallback
    to the link size when originalSize is unavailable.
    
    This updates the github.com/rclone/Proton-API-Bridge package to fix a
    segfault when reading files with no metadata.
    
    Fixes #9377
    Fixes #9117

commit 3b2011c7a09fc32d8a62036891bbd47a36175e4d
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Mon May 4 18:25:56 2026 +0100

    protondrive: route library logging through rclone's logger
    
    Previously all log output produced by Proton-API-Bridge (stdlib log)
    and go-proton-api (logrus + resty's logger) bypassed rclone's
    logging: it ignored -v / -vv levels and didn't reach --log-file.
    
    Add a small adapter implementing the resty.Logger / bridge Logger
    shape that calls fs.Errorf / fs.Logf / fs.Debugf, and pass it via
    the new Config.Logger hook. The bridge in turn forwards the same
    value to go-proton-api's WithLogger option, so HTTP-layer warnings
    and the formerly-hardcoded logrus warnings inside go-proton-api
    also surface through rclone's log levels.

commit ef26e6d26d3b6ccb989fe69e2c78eb8fe707b88d
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Mon May 4 18:19:10 2026 +0100

    protondrive: route HTTP through rclone's transport
    
    The Proton Drive backend constructed the upstream Proton-API-Bridge
    without ever passing rclone's HTTP transport. As a result none of
    rclone's HTTP flags reached Proton: --dump headers, --dump bodies,
    --no-check-certificate, --user-agent, --bind, --ca-cert, --header,
    --tpslimit etc. all silently did nothing for this remote, and HTTP
    traffic was invisible to -vv.
    
    Pass fshttp.NewTransport(ctx) through the new Config.Transport hook on
    the bridge, which forwards it to the updated go-proton-api's
    WithTransport option and so to the underlying resty client.

commit c0a8b2597d6957c4ffe88174fa2038b6a3b82b32
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue May 5 09:43:22 2026 +0100

    Add Copilot to contributors

commit 74d65bf670503d26ca1b2c5fe163859e558d269b
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue May 5 09:43:22 2026 +0100

    Add Sven Rebhan to contributors

commit a4e647664221c84861bdbf66f9f73640efce53f9
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue May 5 09:43:22 2026 +0100

    Add Gustavo V. F. to contributors

commit 6c66b4985dbc4b8eeaa4a239de133897aa56c30a
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue May 5 09:43:22 2026 +0100

    Add 王一赫 to contributors

commit b8b3346499139ead43474530bbac8ab2ef542492
Author: Sven Rebhan <36194019+srebhan@users.noreply.github.com>
Date:   Mon May 4 12:06:30 2026 +0200

    log: fix side effects when importing rclone as a library
    
    Avoid side effects by using own logger instance
    
    - Importing fs/log only sets rclone's private logger via fs.SetLogger,
      so internal rclone logging works from the moment the package is
      imported but the process-wide slog default is left untouched.
    
    - slog.SetDefault and slog.SetLogLoggerLevel move into InitLogging,
      which is called explicitly from the CLI (cmd/cmd.go), the librclone
      wrapper and the integration test framework. So rclone-as-a-program
      keeps capturing log.Print/log.Fatal and slog.Default() output as
      before.
    
    Library consumers that import fs/log without calling InitLogging now
    keep their own slog default and can safely route rclone output back
    into it via log.Handler.SetOutput without recursing.
    
    Fixes #8907
    
    Co-authored-by: Nick Craig-Wood <nick@craig-wood.com>

commit 9f89102a574c841dbb00f2e8acdaa77c1b3b8a60
Author: Gustavo V. F. <31892323+Gustavo-V-F@users.noreply.github.com>
Date:   Sat May 2 12:47:07 2026 -0300

    bisync: fix retryable without --resync error message when --resync has a critical failure

commit 075552367ef240d90aea7f894948ff6485269909
Author: Leon Brocard <acme@astray.com>
Date:   Sat May 2 12:28:30 2026 +0100

    cmd/serve/s3: return object listings in key order
    
    The S3 ListObjects response from `rclone serve s3` was sorting object
    contents by modification time instead of object key. This made the
    listing order incompatible with S3 clients which expect lexicographic
    key ordering.
    
    In particular, `aws s3 sync` assumes both source and destination
    iterators are ordered by key. With the old modtime ordering it could
    misidentify files as missing or outdated and re-download objects that
    were already up to date.
    
    Change the pager to sort returned objects by key and add a regression
    test which uses keys and modtimes arranged so the old behaviour would
    fail.
    
    Fixes #9002

commit ada5559fe115385d28b0db02d85f413ca3c91d51
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Fri May 1 17:15:20 2026 +0100

    Start v1.75.0-DEV development
