This adds a new folder-level configuration `FullBlockIndex`. It controls
whether we maintain the block index for a given folder -- currently
that's always true, now it becomes possible to turn off. The block index
is used for lookup of blocks across files and folders. Effectively, when
syncing a change, for each block, we check:
1. Is the block already present in the old version of the file? If so,
we can reuse (copy) it without network transfer. **This check is always
possible.**
2. Is the block already present in any other file in this folder or
other folders? If so we can copy it. **This check is only possible with
the full block index.**
3. We must transfer the block over the network.
Maintaining the full block index is costly in time, I/O and database
size. With this PR, maintaining the full block index becomes the default
for send-receive and receive-only folders only, with it disabled for
send-only and receive-encrypted folders. The block index is never useful
for encrypted folders, as blocks are encrypted separate for each file.
It is also not useful for send-only folders by themselves, though the
data in the send-only folder could be reused by other receive-type
folders if it were enabled.
For very large folders it may make sense to disable the full block index
regardless of folder type and just accept the resulting decrease in data
reuse.
Disabling or enabling the option in the GUI causes the index to be
destroyed or rebuilt accordingly.
https://github.com/syncthing/docs/pull/1005
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
Register HTTP and HTTPS proxy dialers and implement CONNECT-based
tunneling for HTTP proxies.
The new dialer supports:
- Plain HTTP proxies using CONNECT
- HTTPS proxies by performing a TLS handshake before CONNECT
- Optional basic authentication via Proxy-Authorization (with a warning
when creds are used over cleartext HTTP)
This allows all_proxy to be set to http:// or https:// URLs, enabling
data transfer through HTTP(S) proxies.
### Purpose
Allow peers to connect using HTTP Proxies (CONNECT)
### Testing
Tested with both HTTP and HTTPS proxy connection, using both no auth and
plain authentication.
### Screenshots
No visual change
### Documentation
https://github.com/syncthing/docs/pull/987
## Authorship
Your name and email will be added automatically to the AUTHORS file
based on the commit metadata.
---------
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Jakob Borg <jakob@kastelo.net>
Co-authored-by: Jakob Borg <jakob@kastelo.net>
Hopefully deflakes TestHTTPLogin on Windows, where it currently often
times out, presumably in the config saving stage after already having
started a shutdown of the API and being CPU constrained due to password
hashing.
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
### Purpose
Fixes issue #10634.
### Testing
Manually tested by reproducing the issue:
- Created a new folder with "Add ignore patterns" enabled
- Verified that after saving, only the "Ignore Patterns" tab remains
accessible
- Confirmed that other tabs are visually disabled and no longer
clickable
### Screenshots
No visible UI changes.
### Explanation of the Fix
**Cause**
The issue was caused by only visually disabling tabs in the UI by
setting
their `href` attribute to an empty string (`href=""`). This made the
tabs
appear disabled, but they were still clickable, leading to confusing
behavior
where users could interact with the tabs without any actual navigation.
**Fix**
- Introduced `isFolderTabDisabled` to centralize the logic for
determining
whether a tab should be disabled
- Added `onFolderTabClick` to prevent interaction with disabled tabs
- Updated the HTML to remove tab behavior (such as `data-toggle="tab"`
and
`href`) when a tab is disabled
### Documentation
No documentation changes required.
Signed-off-by: JRNitre <nichinichisou67@outlook.com>
Co-authored-by: Jakob Borg <jakob@kastelo.net>
The test expected the stopped scanner to produce at most numHashers
additional results, but there's also the case where a directory is
encountered (which doesn't require hashing) and sent directly.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
There was a race condition where using IndexUpdate would trigger a pull,
which would sync the delete we are looking for, making the completion
100%. By doing the insert directly into the database we are not
triggering these things and get the expected completion percentage
always.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
These have been flaky for a long time, seemingly because the multiple
connection code slightly changed the timing of cluster config sending by
moving them to the connection promotion loop. This adds some resiliency
to that, instead of assuming that the CC:s will be immediately available
after adding the connection.
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
## Summary
Fixes issue #10458: When removing a folder without a Folder Label, the
confirmation dialog now shows the folder ID instead of an empty string.
### Before
> Are you sure you want to remove folder **?**
### After
> Are you sure you want to remove folder **dnjdr-hssze**?
### Changes
Modified `gui/default/syncthing/folder/removeFolderDialogView.html`:
```html
<!-- Before -->
<p translate translate-value-label="{{currentFolder.label}}">
<!-- After -->
<p translate translate-value-label="{{currentFolder.label || currentFolder.id}}">
```
### Testing
1. Create a folder without a label
2. Open the folder edit dialog
3. Click remove
4. Verify the confirmation dialog shows the folder ID instead of blank
Fixes#10458
Signed-off-by: RealCharlesChia <161665317+RealCharlesChia@users.noreply.github.com>
### Purpose
There were some additional regression created during #10563 and #10631 which are:
* Folders were not being ordered by their label within their group
* Local device could still show up randomly with the list of remote devices
The respective fixes in this PR does the following:
* Ensure sorting of the grouped folders (and devices) are done by group name (the top level map key) and then by the specified nested object property or a fallback property if specified property value is empty. So in the case of the folders it's `label` and device is `name`.
* When populating the `devicesGrouped` using `$scope.otherDevices`, do this within a watcher on `$scope.myID` as this is what `$scope.otherDevices` relies on to determine what is a remote device. This is required because `$scope.myID` might not be populated yet given the indeterministic call order being made to `refreshSystem` and `refreshConfig`.
### Testing
Populate folders and devices into different groups, and ensure the ordering is correct and the local device is not showing in remote devices even after many, many refreshes on the UI or restarts of syncthing entirely.
### Screenshots
Before the fix
<img width="1108" height="951" alt="Screenshot_20260409_083910" src="https://github.com/user-attachments/assets/6eb8cacc-5924-4612-aa70-29ed4f691233" />
After the fix
<img width="1090" height="934" alt="Screenshot_20260409_084553" src="https://github.com/user-attachments/assets/f5b74391-228a-43d3-b5ee-433958236d84" />
### Documentation
N/A
## Authorship
Ben Norcombe [bennorcombe@pm.me](mailto:bennorcombe@pm.me)
* infrastructure:
chore(stdiscosrv): smooth retry-after delays over a slightly larger normal distribution
chore(stdiscosrv): optionally delay shutdown
chore(stdiscosrv): adjust desired seen and unseen rate separately
The error path after bw.Flush() failed referenced fd.Close without calling it, so the descriptor was not closed when flush failed.
Signed-off-by: Weixie Cui <cuiweixie@gmail.com>
chore(sqlite): reduce max open connections, keep them open permanently (fixes#10592)
Reduces connection churn, possibly tickling concurrency bug on Windows.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
fix(systemd): Add back chown allowed syscalls
IFF the user enables the `syncOwnership` feature AND sets
`AmbientCapabilities=CAP_CHOWN CAP_FOWNER` as the docs in
https://docs.syncthing.net/users/autostart.html#permissions state,
THEN syncthing needs to use the `chown` syscall.
PR #10421 added a comprehensive sandbox that breaks `syncOwnership`.
In PR #10602 we fixed one part, which is expanding the default
`CapabilityBoundingSet` (see the PR for details).
But there's a very subtle bug that this PR fixes. PR #10421 sets the
following properties:
SystemCallFilter=@system-service
SystemCallFilter=~@privileged io_uring_enter io_uring_register io_uring_setup
(Systemd merges `SystemCallFilter` values; we had to set the property
twice because to negate syscalls, the whole list has to start with `~`.)
The goal was to allow all syscalls in the `@system-service` set, BUT
disallow any `@privileged` syscalls and the `io_uring*` syscalls.
But the sets are not disjoint; `chown` is in both `@system-service` and
in `@privileged`, so it is removed from the allow list by the second
property value.
This property is also parsed in a very peculiar way. From systemd docs:
> If you specify both types of this option (i.e. allow-listing and
> deny-listing), the first encountered will take precedence and will
> dictate the default action (termination or approval of a system call).
> Then the next occurrences of this option will add or delete the listed
> system calls from the set of the filtered system calls, depending of its
> type and the default action. (For example, if you have started with an
> allow list rule for read() and write(), and right after it add a deny
> list rule for write(), then write() will be removed from the set.)
Not only does the order of `SystemCallFilter` properties matter (later
ones can undo effects of prior ones), but the _type_ of the _first_
property sets the overall behavior of the syscall filter: if the first
`SystemCallFilter` value is an allow list, then all syscalls that are
not specified are disallowed by default (and reverse if the first value
is a deny list).
Of course, this is completely different from how other allow/deny lists
are implemented in systemd; for example, `IPAddress[Allow|Deny]`
properties don't work like this at all. >:(
Since this complexity has bit us once, we're removing the additional
deny list of syscalls and sticking with just
`SystemCallFilter=@system-service`.
This leaves some privileged syscalls in the allow list. Other options
would require entering the "deny list by default" mode and deny lists
are less secure than allow lists in general because they have to be
maintained (the kernel always adds new syscalls). The rest of the
sandbox (capability bounds) should be sufficient.
Fixes#10603
Signed-off-by: Val Markovic <val@markovic.io>
Syncthing docs in https://docs.syncthing.net/users/autostart.html#permissions
tell the user to set `AmbientCapabilities=CAP_CHOWN CAP_FOWNER` if the
user wishes to use the `syncOwnership` option.
https://github.com/syncthing/syncthing/pull/10421 broke `syncOwnership`
for users that followed that advice because the PR introduced
`CapabilityBoundingSet=` which cancels out any additional capabilities
granted with `AmbientCapabilities`.
(`AmbientCapabilities` _adds_ capabilities; `CapabilityBoundingSet`
_limits_ maximum capabilities to the specified set. Setting
`CapabilityBoundingSet` to an empty list prevents any capabilities from
being acquired in any way.)
This PR fixes the breakage by explicitly setting
CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER
This does _not_ grant any additional access rights to syncthing if the
user is not explicitly setting `AmbientCapabilities` as well, but it
does loosen the sandbox _a bit_. An attacker compromising the syncthing
process could now more easily expand their access to include
CAP_CHOWN/CAP_FOWNER even if the user is not setting
`AmbientCapabilities`.
Signed-off-by: Val Markovic <val@markovic.io>
Jakob Borg
RealCharlesChiaandGitHub
Syncthing Release Automation
Ben NorcombeandGitHub
dageckoandGitHub
bt90andGitHub
cuiandGitHub
Val MarkovicandGitHub