| Fix Bug #3816: Fix OAuth token exposure in --debug-https logging (#3838) Prevent `--debug-https` from exposing OAuth access and refresh tokens in diagnostic output. The existing HTTPS debug path filtered the `Authorization` header from the application's request-header dump, but OAuth credentials could still be exposed through several other paths: * libcurl verbose output could print the `Authorization` header directly * OAuth token request bodies could expose `refresh_token` * OAuth token endpoint responses could expose both `access_token` and `refresh_token` * exception and response diagnostics could stringify these values unchanged Add a central sanitisation layer in `curlEngine.d` that redacts OAuth credentials only when producing diagnostic output. The sanitiser covers: * `Authorization` and `Proxy-Authorization` headers * HTTP/2-style libcurl `[authorization: ...]` trace output * form-encoded `access_token` and `refresh_token` values * JSON `access_token` and `refresh_token` fields Replace the default libcurl verbose handler with a sanitised debug callback so useful HTTPS connection, TLS, protocol and header diagnostics remain available without exposing credentials. Raw HTTP/TLS payload callbacks are not emitted by the libcurl debug callback. Application-level request and response diagnostics remain available through `CurlResponse`, with OAuth secrets redacted before logging. Add regression tests covering HTTP/1.1 headers, HTTP/2 diagnostic formatting, form-encoded refresh tokens and OAuth JSON responses. This change does not alter OAuth authentication, token renewal, token storage, Graph API behaviour or the explicit `--print-access-token` functionality. | 13 天前 |
| Fix Bug #3850: 'skip_dir' full path rule (leading '/') also excludes same-named directories at any depth (#3851) ## Summary Fixes #3850, where a `skip_dir` full-path rule using a leading `/` could incorrectly exclude same-named directories at deeper levels. For example: ```text skip_dir = "/bin" ``` is intended to exclude only: ```text [sync_dir]/bin ``` but could also exclude: ```text [sync_dir]/some/deeper/path/bin ``` when processing remote `/delta` data. ## Root Cause When processing a remote directory, the client can calculate two paths for `skip_dir` evaluation: * a simplified path, which may degrade to only the directory name when `parentReference.name` is not supplied by the Microsoft OneDrive API * a complete sync-root-relative path derived from database state or `parentReference.path` The existing logic evaluated the simplified path first and only evaluated the complete path when the simplified path did not match. For a rule such as: ```text skip_dir = "/bin" ``` a remotely discovered nested directory could therefore be reduced to: ```text bin ``` before matching. The existing path normalisation performed by `isDirNameExcluded()` then generates both relative and rooted matching candidates, allowing the degraded `bin` value to match `/bin` before the actual full path was considered. This also meant that `skip_dir_strict_match = "true"` could not prevent the incorrect exclusion. ## Resolution Where a complete sync-root-relative path is available, the client now treats that path as authoritative for `skip_dir` evaluation. The simplified path is used only when a complete path genuinely cannot be constructed. This change has been applied to both affected remote directory filtering paths in `src/sync.d`. The existing `skip_dir` matching implementation itself is unchanged. This preserves existing behaviour for: * non-strict directory-name matching * strict full-path matching * leading `/` sync-root anchoring * wildcard matching * case-insensitive matching * multiple configured `skip_dir` rules In particular, case-insensitive matching remains intentional and unchanged. ## E2E Test Coverage TC0012 has been significantly expanded to validate `skip_dir` semantics in both upload and download directions. Coverage now includes: * unanchored non-strict directory-name matching * strict explicit multi-segment path matching * leading `/` single-segment sync-root anchoring with strict matching disabled * leading `/` single-segment sync-root anchoring with strict matching enabled * rooted multi-segment paths containing spaces and trailing `/` * `*` and `?` wildcard matching * case-insensitive matching * multiple and pipe-separated `skip_dir` rules * rooted wildcard rules * local-to-remote and remote-to-local filtering behaviour The regression scenarios specifically confirm that a root-anchored directory is excluded while the same directory name at a deeper path remains synchronised. ### TC0061 adjustment The full E2E run also exposed that TC0061 had historically depended on the same simplified-path behaviour corrected by this PR. TC0061 configured: ```text skip_dir = "Pictures/Archive" skip_dir_strict_match = "true" ``` while the actual test path was: ```text [sync_dir]/ZZ_E2E_TC0061_<run>/Pictures/Archive ``` The previous simplified-path-first behaviour caused this testcase to pass because the complete sync-root-relative path was never evaluated. TC0061 has therefore been corrected so its strict `skip_dir` rule describes the actual full path relative to `sync_dir`. No production behaviour was relaxed to accommodate this testcase. ## Validation Validation completed successfully: * Original Issue #3850 behaviour reproduced before the fix * Expanded TC0012 regression coverage passes all scenarios * Corrected TC0061 passes using the complete strict path * Full 79-case E2E suite passes * Original issue reporter has independently validated the fix against the environment that reproduced the defect This preserves the documented distinction between directory-name matching and explicit full-path matching while ensuring remote directory filtering uses the most authoritative path information available. | 4 天前 |
| Fix Bug #3782: Change mandatory resync exit status from 126 to 78 (#3799) The client currently exits with status `126` when it detects a condition that requires the user to perform a `--resync`. Exit status `126` is conventionally used by shells to indicate that a command was found but could not be executed. This does not accurately represent the OneDrive client's behaviour: the application has executed successfully, but has detected a persistent configuration or state condition that requires user intervention before normal synchronisation can continue. Change the mandatory resync exit status from `126` to `78`. Exit status `78` corresponds to the traditional `EX_CONFIG` value and more accurately represents the condition being reported. It also avoids using the shell-reserved `126` exit status. This change: * changes `EXIT_RESYNC_REQUIRED` from `126` to `78`; * updates both supplied systemd service templates to use `RestartPreventExitStatus=78`; * preserves the existing systemd behaviour where a mandatory resync prevents automatic service restart while leaving the service in a failed state requiring operator action; * improves the resync-required error message to make it clear that `--resync` must be appended to the normal invocation, for example: * `onedrive --sync --resync` * `onedrive --monitor --resync` * documents the new exit status and the compatibility impact for scripts, monitoring systems and custom service definitions that currently test for exit status `126`. No synchronisation or resync processing behaviour is otherwise changed. Existing automation that explicitly checks for exit status `126` will need to be updated to check for exit status `78` instead. | 1 个月前 |
| Add notify_monitor_start option to silence monitor-start notification (#3779) Addresses discussion #3109 Running in `--monitor` mode sends a GUI notification on every startup confirming that filesystem monitoring has begun. There was previously no way to silence just this notification short of disabling all notifications via `disable_notifications`. * Add `notify_monitor_start` config option (default `true`, preserving existing behaviour) that gates only the monitor-start GUI notification * Document the option in `config`, `docs/application-config-options.md` and `docs/usage.md` To disable just this notification, add this to your cofig: ``` notify_monitor_start = "false" ``` Checked to compile with LDC v1.20.1 (Debian) and LDC 1.42.0 (Fedora). | 4 天前 |
| Add notify_monitor_start option to silence monitor-start notification (#3779) Addresses discussion #3109 Running in `--monitor` mode sends a GUI notification on every startup confirming that filesystem monitoring has begun. There was previously no way to silence just this notification short of disabling all notifications via `disable_notifications`. * Add `notify_monitor_start` config option (default `true`, preserving existing behaviour) that gates only the monitor-start GUI notification * Document the option in `config`, `docs/application-config-options.md` and `docs/usage.md` To disable just this notification, add this to your cofig: ``` notify_monitor_start = "false" ``` Checked to compile with LDC v1.20.1 (Debian) and LDC 1.42.0 (Fedora). | 4 天前 |
| Update makefiles.sh * Add `#!/bin/bash` to shell script | 7 年前 |
| Ignoring files created during configure to be consistent with other files generated from .in templates (#3188) * Ignoring files created during configure to be consistent with other files generated from .in templates | 1 年前 |
| OneDrive Client for Linux v2.5.0 (#2805) OneDrive Client for Linux v2.5.0 --------- Signed-off-by: Thomas Staudinger <Staudi.Kaos@gmail.com> Co-authored-by: JC-comp <147694781+JC-comp@users.noreply.github.com> Co-authored-by: Dimitri Papadopoulos Orfanos <3234522+DimitriPapadopoulos@users.noreply.github.com> Co-authored-by: Pierrick Caillon <megamisan@users.noreply.github.com> Co-authored-by: Pierrick Caillon <pierrick.caillon@megami.fr> Co-authored-by: Thomas Staudinger <Staudi.Kaos@gmail.com> Co-authored-by: Yuan Liu <Lyncredible@users.noreply.github.com> | 1 年前 |
| Fix Bug #3834: Validate timestamp authority and detect time differences between host platform and Microsoft OneDrive (#3836) ## Summary This PR implements the first stage of #3834 by introducing a system-time authority and safety gate before timestamp-sensitive OneDrive synchronisation is allowed to proceed. The client now validates the host system clock against time returned by the Microsoft service and maintains a process-wide time-authority state that can be used to determine whether synchronisation is safe. This PR intentionally **does not change how file or directory timestamps are applied during synchronisation**. The broader audit and correction of timestamp application logic described in #3834 will be handled in a separate follow-up PR. ## System Time Validation The client uses Microsoft service time as the external reference and accounts for HTTP round-trip time and measurement uncertainty when calculating effective clock skew. The current policy is: * **0–15 seconds:** system time considered acceptable * **>15 seconds to 120 seconds:** warning is generated, synchronisation continues * **>120 seconds:** potentially unsafe; a second independent Microsoft time observation is performed before the condition is treated as blocking A single anomalous observation therefore cannot immediately prevent synchronisation. When significant drift is confirmed, the client enters `TIME_DRIFT_BLOCKING` and timestamp-sensitive synchronisation is not permitted until system time has been corrected and successfully revalidated. System time is periodically revalidated while the application is running, and significant wall-clock discontinuities trigger revalidation of the previously established authority state. ## Behaviour ### `--sync` If unsafe system clock drift is confirmed before synchronisation begins: * synchronisation does not start * the user is advised to correct the local system clock or time synchronisation service * the application exits with failure If system time becomes unsafe during synchronisation, further timestamp-sensitive processing is stopped and the application exits with failure. ### `--monitor` If unsafe clock drift is present when monitor mode starts: * the monitor process remains running * synchronisation and event processing do not begin * system time is periodically revalidated * normal monitor startup automatically continues once system time is corrected If system time becomes unsafe while monitor mode is already running: * timestamp-sensitive synchronisation is suspended * the monitor process remains running * local filesystem observations may still be retained for later processing * WebSocket/Webhook-triggered reconciliation is prevented while the safety gate is closed * processing automatically resumes once system time has been corrected and revalidated Important blocking and recovery state changes are emitted through normal application logging and notification paths and therefore do not require `--verbose`. ## Configuration A `disable_time_check` configuration option / `--disable-time-check` command-line option is provided for users who explicitly need to bypass system-time validation. ## E2E Coverage A new **TC0077 — Timestamp authority safety gating validation** test case has been added with three scenarios: * **TA-0001:** `--monitor` starts with unsafe clock drift, remains suspended, and automatically starts synchronisation after time is corrected * **TA-0002:** an already-running `--monitor` instance develops unsafe clock drift, suspends synchronisation, retains pending local work, and resumes processing after time recovery * **TA-0003:** `--sync` starts with unsafe clock drift, performs no synchronisation and exits with failure * **TA-0004:** unsafe clock drift with `--disable-time-check` validates that the explicit time-validation override bypasses the clock safety gate, permits normal synchronisation to proceed despite otherwise blocking clock drift, and confirms through independent remote verification that local content is successfully propagated to OneDrive The E2E implementation uses process-local clock manipulation so the GitHub Actions runner, filesystem timestamps and Microsoft-side timestamps are not modified by the test. ## Scope This PR establishes **whether the local system clock can safely participate in timestamp-sensitive synchronisation decisions**. It does **not** yet alter: * remote-to-local timestamp application * local-to-remote timestamp propagation * file or directory timestamp semantics * move/rename timestamp handling * timestamp-only reconciliation * `lastModifiedDateTime` update behaviour * `--local-first` timestamp authority semantics Those areas will be reviewed separately once this timestamp-authority foundation has been merged. | 14 天前 |
| autoconf based build system (#287) * Add autoconf based build system | 7 年前 |
| Release files for 2.5.11 (#3764) * Add the missing `remove_source_folders` entry to `--display-config` output. * Release files for 2.5.11 | 2 个月前 |
| Add notify_monitor_start option to silence monitor-start notification (#3779) Addresses discussion #3109 Running in `--monitor` mode sends a GUI notification on every startup confirming that filesystem monitoring has begun. There was previously no way to silence just this notification short of disabling all notifications via `disable_notifications`. * Add `notify_monitor_start` config option (default `true`, preserving existing behaviour) that gates only the monitor-start GUI notification * Document the option in `config`, `docs/application-config-options.md` and `docs/usage.md` To disable just this notification, add this to your cofig: ``` notify_monitor_start = "false" ``` Checked to compile with LDC v1.20.1 (Debian) and LDC 1.42.0 (Fedora). | 4 天前 |
| Add support for OpenBSD (#3765) Add OpenBSD as a supported platform, including build-system integration, runtime portability fixes, improved crash diagnostics, and long-running monitor-mode validation. Build and platform support: * Detect the `egdc` compiler supplied with OpenBSD 7.9 and handle its GCC-style version output. * Harden compiler-version comparison when version components are absent. * Add the required `libexecinfo` linkage for OpenBSD GDC builds while preserving DMD compatibility. * Document supported OpenBSD releases, required packages, compiler availability, and build instructions. * Document that the OpenBSD 7.8 package repository does not provide a supported D compiler configuration. Runtime and diagnostic improvements: * Add OpenBSD-specific fatal signal handling using `SA_SIGINFO`. * Report the fault address, trap information, interrupted register context, and a native stack trace for segmentation faults. * Re-raise fatal signals after diagnostic output so normal core-dump handling is preserved. * Make database row data independently owned before extracting fields and parse stored timestamps safely before constructing database items. * Add coarse, time-gated garbage collection for long-running monitor processes, running no more than once every 24 hours after sync processing has completed. Microsoft Graph response hardening: * Validate Graph collection responses before accessing or iterating their `value` arrays. * Validate required item, parent-reference, shared-folder, search, upload, directory-creation, and WebSocket subscription fields before accessing them. * Harden path construction and remote item processing against missing or unexpectedly typed JSON properties. * Strengthen shared JSON helper functions to verify object structure and expected value types before accessing strings, integers, objects, or arrays. * Treat incomplete upload responses as failures rather than persisting invalid item data. * Fail safely through the existing skip, retry, return, or failure paths when malformed responses are received. * Correct the generated fake folder response used by test and dry-run processing. Validation completed: * All GitHub Actions E2E account suites passed, including Personal, Business, SharePoint, shared-folder, and 15-character drive-ID testing. * OpenBSD monitor mode completed more than 24 hours of continuous filesystem churn without a crash or processing failure. * The scheduled 24-hour garbage-collection path executed successfully. * Normal WebSocket delta processing, local deletion propagation, remote directory creation, and file uploads continued successfully after the scheduled cleanup. * Resident memory remained stable during the long-running OpenBSD monitor test. | 1 个月前 |
| Add support for OpenBSD (#3765) Add OpenBSD as a supported platform, including build-system integration, runtime portability fixes, improved crash diagnostics, and long-running monitor-mode validation. Build and platform support: * Detect the `egdc` compiler supplied with OpenBSD 7.9 and handle its GCC-style version output. * Harden compiler-version comparison when version components are absent. * Add the required `libexecinfo` linkage for OpenBSD GDC builds while preserving DMD compatibility. * Document supported OpenBSD releases, required packages, compiler availability, and build instructions. * Document that the OpenBSD 7.8 package repository does not provide a supported D compiler configuration. Runtime and diagnostic improvements: * Add OpenBSD-specific fatal signal handling using `SA_SIGINFO`. * Report the fault address, trap information, interrupted register context, and a native stack trace for segmentation faults. * Re-raise fatal signals after diagnostic output so normal core-dump handling is preserved. * Make database row data independently owned before extracting fields and parse stored timestamps safely before constructing database items. * Add coarse, time-gated garbage collection for long-running monitor processes, running no more than once every 24 hours after sync processing has completed. Microsoft Graph response hardening: * Validate Graph collection responses before accessing or iterating their `value` arrays. * Validate required item, parent-reference, shared-folder, search, upload, directory-creation, and WebSocket subscription fields before accessing them. * Harden path construction and remote item processing against missing or unexpectedly typed JSON properties. * Strengthen shared JSON helper functions to verify object structure and expected value types before accessing strings, integers, objects, or arrays. * Treat incomplete upload responses as failures rather than persisting invalid item data. * Fail safely through the existing skip, retry, return, or failure paths when malformed responses are received. * Correct the generated fake folder response used by test and dry-run processing. Validation completed: * All GitHub Actions E2E account suites passed, including Personal, Business, SharePoint, shared-folder, and 15-character drive-ID testing. * OpenBSD monitor mode completed more than 24 hours of continuous filesystem churn without a crash or processing failure. * The scheduled 24-hour garbage-collection path executed successfully. * Normal WebSocket delta processing, local deletion propagation, remote directory creation, and file uploads continued successfully after the scheduled cleanup. * Resident memory remained stable during the long-running OpenBSD monitor test. | 1 个月前 |
| autoconf based build system (#287) * Add autoconf based build system | 7 年前 |
| Fix Bug #3834: Validate timestamp authority and detect time differences between host platform and Microsoft OneDrive (#3836) ## Summary This PR implements the first stage of #3834 by introducing a system-time authority and safety gate before timestamp-sensitive OneDrive synchronisation is allowed to proceed. The client now validates the host system clock against time returned by the Microsoft service and maintains a process-wide time-authority state that can be used to determine whether synchronisation is safe. This PR intentionally **does not change how file or directory timestamps are applied during synchronisation**. The broader audit and correction of timestamp application logic described in #3834 will be handled in a separate follow-up PR. ## System Time Validation The client uses Microsoft service time as the external reference and accounts for HTTP round-trip time and measurement uncertainty when calculating effective clock skew. The current policy is: * **0–15 seconds:** system time considered acceptable * **>15 seconds to 120 seconds:** warning is generated, synchronisation continues * **>120 seconds:** potentially unsafe; a second independent Microsoft time observation is performed before the condition is treated as blocking A single anomalous observation therefore cannot immediately prevent synchronisation. When significant drift is confirmed, the client enters `TIME_DRIFT_BLOCKING` and timestamp-sensitive synchronisation is not permitted until system time has been corrected and successfully revalidated. System time is periodically revalidated while the application is running, and significant wall-clock discontinuities trigger revalidation of the previously established authority state. ## Behaviour ### `--sync` If unsafe system clock drift is confirmed before synchronisation begins: * synchronisation does not start * the user is advised to correct the local system clock or time synchronisation service * the application exits with failure If system time becomes unsafe during synchronisation, further timestamp-sensitive processing is stopped and the application exits with failure. ### `--monitor` If unsafe clock drift is present when monitor mode starts: * the monitor process remains running * synchronisation and event processing do not begin * system time is periodically revalidated * normal monitor startup automatically continues once system time is corrected If system time becomes unsafe while monitor mode is already running: * timestamp-sensitive synchronisation is suspended * the monitor process remains running * local filesystem observations may still be retained for later processing * WebSocket/Webhook-triggered reconciliation is prevented while the safety gate is closed * processing automatically resumes once system time has been corrected and revalidated Important blocking and recovery state changes are emitted through normal application logging and notification paths and therefore do not require `--verbose`. ## Configuration A `disable_time_check` configuration option / `--disable-time-check` command-line option is provided for users who explicitly need to bypass system-time validation. ## E2E Coverage A new **TC0077 — Timestamp authority safety gating validation** test case has been added with three scenarios: * **TA-0001:** `--monitor` starts with unsafe clock drift, remains suspended, and automatically starts synchronisation after time is corrected * **TA-0002:** an already-running `--monitor` instance develops unsafe clock drift, suspends synchronisation, retains pending local work, and resumes processing after time recovery * **TA-0003:** `--sync` starts with unsafe clock drift, performs no synchronisation and exits with failure * **TA-0004:** unsafe clock drift with `--disable-time-check` validates that the explicit time-validation override bypasses the clock safety gate, permits normal synchronisation to proceed despite otherwise blocking clock drift, and confirms through independent remote verification that local content is successfully propagated to OneDrive The E2E implementation uses process-local clock manipulation so the GitHub Actions runner, filesystem timestamps and Microsoft-side timestamps are not modified by the test. ## Scope This PR establishes **whether the local system clock can safely participate in timestamp-sensitive synchronisation decisions**. It does **not** yet alter: * remote-to-local timestamp application * local-to-remote timestamp propagation * file or directory timestamp semantics * move/rename timestamp handling * timestamp-only reconciliation * `lastModifiedDateTime` update behaviour * `--local-first` timestamp authority semantics Those areas will be reviewed separately once this timestamp-authority foundation has been merged. | 14 天前 |
| Add support for OpenBSD (#3765) Add OpenBSD as a supported platform, including build-system integration, runtime portability fixes, improved crash diagnostics, and long-running monitor-mode validation. Build and platform support: * Detect the `egdc` compiler supplied with OpenBSD 7.9 and handle its GCC-style version output. * Harden compiler-version comparison when version components are absent. * Add the required `libexecinfo` linkage for OpenBSD GDC builds while preserving DMD compatibility. * Document supported OpenBSD releases, required packages, compiler availability, and build instructions. * Document that the OpenBSD 7.8 package repository does not provide a supported D compiler configuration. Runtime and diagnostic improvements: * Add OpenBSD-specific fatal signal handling using `SA_SIGINFO`. * Report the fault address, trap information, interrupted register context, and a native stack trace for segmentation faults. * Re-raise fatal signals after diagnostic output so normal core-dump handling is preserved. * Make database row data independently owned before extracting fields and parse stored timestamps safely before constructing database items. * Add coarse, time-gated garbage collection for long-running monitor processes, running no more than once every 24 hours after sync processing has completed. Microsoft Graph response hardening: * Validate Graph collection responses before accessing or iterating their `value` arrays. * Validate required item, parent-reference, shared-folder, search, upload, directory-creation, and WebSocket subscription fields before accessing them. * Harden path construction and remote item processing against missing or unexpectedly typed JSON properties. * Strengthen shared JSON helper functions to verify object structure and expected value types before accessing strings, integers, objects, or arrays. * Treat incomplete upload responses as failures rather than persisting invalid item data. * Fail safely through the existing skip, retry, return, or failure paths when malformed responses are received. * Correct the generated fake folder response used by test and dry-run processing. Validation completed: * All GitHub Actions E2E account suites passed, including Personal, Business, SharePoint, shared-folder, and 15-character drive-ID testing. * OpenBSD monitor mode completed more than 24 hours of continuous filesystem churn without a crash or processing failure. * The scheduled 24-hour garbage-collection path executed successfully. * Normal WebSocket delta processing, local deletion propagation, remote directory creation, and file uploads continued successfully after the scheduled cleanup. * Resident memory remained stable during the long-running OpenBSD monitor test. | 1 个月前 |
