Where `folderFilesystems` and `folders` is built, there's a comment
spelling out the purpose: To have the same folder first, as that's the
most likely to get hits. Plus a copy is possibly more efficient than
from another folder, e.g. if that's on a different filesystem. We lost
that behaviour during some unrelated change.
(Also sneaking in a comment fix on yesterdays change.)
This is a draft because I haven't adjusted all the tests yet, I'd like
to get feedback on the change overall first, before spending time on
that.
In my opinion the main win of this change is in it's lower complexity
resp. fewer moving parts. It should also be faster as it only does one
query instead of two, but I have no idea if that's practically
relevant.
This also mirrors the v1 DB, where a block map key had the name
appended. Not that this is an argument for the change, it was mostly
reassuring me that I might not be missing something key here
conceptually (I might still be of course, please tell me :) ).
And the change isn't mainly intrinsically motivated, instead it came
up while fixing a bug in the copier. And the nested nature of that code
makes the fix harder, and "un-nesting" it required me to understand
what's happening. This change fell out of that.
After opening the database, we performed some checks, such as whether
the migration had already been successfully completed. If so, the
function returned immediately, and the database was not closed.
---------
Co-authored-by: Jakob Borg <jakob@kastelo.net>
* main:
fix(strelaysrv): make the session limiter session-dependent (fixes#10072) (#10073)
build: artifact uploads destination OCI
chore(gui, man, authors): update docs, translations, and contributors
chore(gui): use go list --deps for dependency list (#10071)
### Purpose
Fix https://github.com/syncthing/syncthing/issues/9336
The `emitLoginAttempt` function now checks for the presence of an
`X-Forwarded-For` header. The IP from this header is only used if the
connecting host is either on loopback or on the same LAN.
In the case of a host pretending to be a proxy, we'd still have both IPs
in the logs, which should make this much less critical from a security
standpoint.
### Testing
1. directly via localhost
2. via proxy an localhost
#### Logs
```
[3JPXJ] 2025/04/11 15:00:40 INFO: Wrong credentials supplied during API authorization from 127.0.0.1
[3JPXJ] 2025/04/11 15:03:04 INFO: Wrong credentials supplied during API authorization from 192.168.178.5 proxied by 127.0.0.1
```
#### Event API
```
{
"id": 23,
"globalID": 23,
"time": "2025-04-11T15:00:40.578577402+02:00",
"type": "LoginAttempt",
"data": {
"remoteAddress": "127.0.0.1",
"success": false,
"username": "sdfsd"
}
},
{
"id": 24,
"globalID": 24,
"time": "2025-04-11T15:03:04.423403976+02:00",
"type": "LoginAttempt",
"data": {
"proxy": "127.0.0.1",
"remoteAddress": "192.168.178.5",
"success": false,
"username": "sdfsd"
}
}
```
### Documentation
https://github.com/syncthing/docs/pull/907
---------
Co-authored-by: Jakob Borg <jakob@kastelo.net>
This cleans up the option to allow old TLS 1.2 sync connections. The
flag existed for compatibility with old Syncthing versions that don't
support TLS 1.3, which is approximately Syncthing 1.2.2 (September 2019)
and older. ("Approximately" because it depends on the Go version it's
built with and that's when we switched to building with Go 1.13.)
Ref #10062 because it reminded me this exists.
* infrastructure:
feat(stdiscosrv): configurable desired not-found rate
chore(blobs): generalised blob storage
chore(stdiscosrv): path style s3
feat(ursv): add os/arch/distribution metric
chore(strelaypoolsrv): limit number of returned relays
build(infra): run in Docker environment for pushes
chore(stupgrades): expose latest release as a metric
* main:
build: push artifacts to Azure (#10044)
fix(syncthing): use separate lock file instead of locking the certificate (fixes#10053) (#10054)
fix(syncthing): use separate lock file instead of locking the certificate (fixes#10053) (#10054)
* release-1.29.5:
build: push artifacts to Azure (#10044)
fix(syncthing): use separate lock file instead of locking the certificate (fixes#10053) (#10054)
* main:
fix(gui): fix previous commit
fix(gui): mark unseen disconnected devices as inactive (#10048)
fix(strings): differentiate setup(n) and set(v) up (#10024)
chore(fs): changes to allow Filesystem to be implemented externally (#10040)
chore(config): resolve primary STUN servers via SRV record (fixes#10029) (#10031)
build: push artifacts to Azure (#10044)
chore(gui, man, authors): update docs, translations, and contributors
Currently, the "Disconnected (Inactive)" status is only given to devices
that have not been seen for 7 days or longer. However, this is not the
case when adding a new device, or after resetting the database. Those
devices are only marked as "Disconnected", and they will stay like that
even if a long time passes without any connectivity. Moreover, the lack
of an "Inactive" status may confuse the user to believe that their
disconnect is only temporary.
For this reason, always mark devices that have not been seen yet as
"Disconnected (Inactive)".
Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
### Purpose
The `fs.Filesystem` interface contains two parts that cannot be
implemented externally because they are private:
* `filesystemWrapperType`: this PR changes `unwrapFilesystem` to
downcast to a specific concrete type
* `underlying`: this PR simply moves it to an unexported interface
### Testing
Regular tests pass.
Simon FreiandGitHub
Jakob Borg
domainandGitHub
Syncthing Release Automation
Ross Smith IIandGitHub
Marcus B SpencerandGitHub
TheCreeperandGitHub
Sébastien WENSKEandGitHub
Tommy van der VorstandGitHub
tomasz1986andGitHub
Paul DonaldandGitHub