We had a few places where we had perhaps too much of an opinion on the
permissions on created files and directories, sometimes fuled by a
misconception about how permissions work in both Unix and Windows. Recap
on the ground rules:
- On all unixes, all file & directory creation (`Mkdir`, `MkdirAll`,
`Create`, `WriteFile`, `Open`) has the given permission bits filtered
via the user's umask. The proper permissions for us to use are in almost
all cases 0o666 for files and 0o777 for directories, strange as that may
look at the call site.
- On Windows, there is no umask but in turn all of the permission bits
except the user write bit are ignored. The absence of user write bit is
converted into the read only attribute. This means that what is proper
for Unix above is also proper for Windows.
- We make an exception when creating files for certificate keys and the
config / database directories, as those contain secrets we think should remain closed
even if the user generally collaborates with other users on the system.
(Also removal of a bugfixed copy of MkdirAll for Windows that hasn't
been necessary for a few years.)
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
This change allows Syncthing to be launched from Explorer without
showing a console window, while preserving the existing command-line
behavior.
Previously, launching syncthing.exe from Explorer would always allocate
a console window, which could only be hidden later by using
`--no-console`. It was not possible to avoid console allocation entirely
without introducing other issues.
On Windows 24H2 and later a new application manifest allows us to
achieve it. See [console allocation
policy](https://learn.microsoft.com/en-us/windows/console/console-allocation-policy)
This manifest is built into a syso-file by `goversioninfo`, which is
already used to generate Windows resource files consumed by the Go
compiler.
**Note1:** On Windows 24H2 and later, no console is allocated when
Syncthing is launched from Explorer, even if `--no-console` is set to
`False`. It can still be used as a CLI tool as usual if you call it from
console.
**Note2:** The content of the manifest file may not be formatted. Even a
`newline` would break it.
### Testing
Tested on Windows 11 25H2: No console visible from explorer. CLI works
as usual.
Ref #8046, ref #10633, ref #10481, ref #10600
Signed-off-by: Elias <1elias.bauer@gmail.com>
Co-authored-by: Elias <1elias.bauer@gmail.com>
### Purpose
On Windows replace `cmd.exe /C start` with direct `ShellExecute` API for
opening the webpage.
The previous implementation used `exec.Command("cmd.exe", "/C", "start
"+url)` which spawns two extra processes (cmd.exe → start). Launching
cmd.exe resulted in a shortly visible terminal.
Both
-`start`
-and another alternative `exec.Command("rundll32",
"url.dll,FileProtocolHandler", url).Start()`
are just wrappers for `ShellExecute`. So this implementation is even
more direct
### Testing
I executed the compiled syncthing.exe on Windows 11, both from explorer
and console. The webpage opened as expected.
### Screenshots
N/A.
### Documentation
N/A
## Authorship
Name: Elias @Shablone
Email: [1elias.bauer@gmail.com](mailto:1elias.bauer@gmail.com)
Signed-off-by: Elias <1elias.bauer@gmail.com>
Co-authored-by: Elias <1elias.bauer@gmail.com>
### Purpose
`path` is for slash-separated paths (URLs, BEP protocol); local file
system paths should use `path/filepath`. Fixed in
`cmd/stdiscosrv/database.go` (3 sites) and
`internal/db/sqlite/db_test.go` (1 site).
### Testing
`go build ./cmd/stdiscosrv/...` and `go vet` pass.
Signed-off-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
Fix a response body leak in `githubSourceCodeLoader.Load` where the body
was not closed when the HTTP status was non-200.
Signed-off-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
lib/ur brings in a lot of dependencies we don't need in e.g.
stcrashreceiver, who only needs the small failure reporting structs.
Make those part of the lean `contract` package instead.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
The runtime prints a lot of context for crashes due to bad pointers etc,
which is required to understand the crash, but this context comes before
the `fatal error: ...` line. Currently those lines get filtered out and
not included in the crash report. This change modifies the criteria so
that we start collecting crash data also at a line that begins with
`runtime:`, and tweaks the parsing later to look for the specific
`panic:` or `fatal error:` which may come later as the subject.
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
The locking logic for upgrades got inverted in the lockfile changes. If
we got the lock it means Syncthing wasn't already running, so we can do
a direct upgrade. If we failed to get the lock it means Syncthing was
running and we should tell the REST interface to do the upgrade.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
## Summary
- Replace vendored `jquery-2.2.2.js` with `jquery-3.7.1.js` in
`gui/default/vendor/jquery/`
- Update script reference in `gui/default/index.html` to point to the
new file
- Update CDN reference in `cmd/infra/strelaypoolsrv/gui/index.html` from
`jquery-2.1.4.min.js` to `jquery-3.7.1.min.js`
## Why
The previously used jQuery versions (2.2.2 and 2.1.4) are vulnerable to
three known CVEs:
| CVE | Description | Fixed in |
|-----|-------------|----------|
| CVE-2015-9251 | XSS via cross-domain Ajax requests with non-text
content types | jQuery 3.0.0 |
| CVE-2020-11022 | XSS when passing HTML containing `<option>` elements
to manipulation methods | jQuery 3.5.0 |
| CVE-2020-11023 | XSS via passing HTML from untrusted sources to
manipulation methods | jQuery 3.5.0 |
jQuery 3.7.1 is the latest stable release and resolves all three.
## Compatibility notes
The GUI code was audited for jQuery 2→3 breaking changes. No removed
APIs are used:
- `.success()` / `.error()` calls throughout the codebase are
**AngularJS `$http`** promise methods, not jQuery — unaffected
- `.bind('beforeunload', ...)` is deprecated in jQuery 3 but not removed
— still works
- No usage of `.size()`, `.load()` event shorthand, `jQuery.isFunction`,
or `$.type()`
---------
Signed-off-by: Umer Azaz <umer_azaz@yahoo.com>
Co-authored-by: Jakob Borg <jakob@kastelo.net>
These headers should not be inspected when running with a TLS listener.
Additionally, we should really enable them individually instead of
trusting the proxy to filter out the unused variants, but baby steps.
Reported by multiple AI vuln scanners.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
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>
This change allows the periodic database maintenance to be disabled, while providing a way to programmatically start maintenance at a convenient moment.
Signed-off-by: Tommy van der Vorst <tommy@pixelspark.nl>
* Show proper subcommand prefix in generated config CLI.
* Remove useless author info and copy command group description.
* Really accept (implicit) -h and --help flags.
These were disabled by HideHelp, leading to an error message in every
usage output. This way, the flags get documented as well.
* Override AppHelpTemplate to better match Kong's style.
* Override (Sub)commandHelpTemplate to better match Kong's style.
* Use <command> and [flags] like Kong.
Signed-off-by: André Colomb <src@andre.colomb.de>
This changes the files table to use normalisation for the names and
versions. The idea is that these are often common between all remote
devices, and repeating an integer is more efficient than repeating a
long string. A new benchmark bears this out; for a database with 100k
files shared between 31 devices, with some worst case assumption on
version vector size, the database is reduced in size by 50% and the test
finishes quicker:
Current:
db_bench_test.go:322: Total size: 6263.70 MiB
--- PASS: TestBenchmarkSizeManyFilesRemotes (1084.89s)
New:
db_bench_test.go:326: Total size: 3049.95 MiB
--- PASS: TestBenchmarkSizeManyFilesRemotes (776.97s)
The other benchmarks end up about the same within the margin of
variability, with one possible exception being that RemoteNeed seems to
be a little slower on average:
old files/s new files/s
Update/n=RemoteNeed/size=1000-8 5.051k 4.654k
Update/n=RemoteNeed/size=2000-8 5.201k 4.384k
Update/n=RemoteNeed/size=4000-8 4.943k 4.242k
Update/n=RemoteNeed/size=8000-8 5.099k 3.527k
Update/n=RemoteNeed/size=16000-8 3.686k 3.847k
Update/n=RemoteNeed/size=30000-8 4.456k 3.482k
I'm not sure why, possibly that query can be optimised anyhow.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
Remove the migrated v0.14.0 database format after two weeks. Remove a
few old patterns that are no longer relevant. Ensure the cleanup runs in
both the config and database directories.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
This adds several options for configuring the log format of timestamps
and severity levels, making it more suitable for integration with log
systems like systemd.
--log-format-timestamp="2006-01-02 15:04:05"
Format for timestamp, set to empty to disable timestamps ($STLOGFORMATTIMESTAMP)
--[no-]log-format-level-string
Whether to include level string in log line ($STLOGFORMATLEVELSTRING)
--[no-]log-format-level-syslog
Whether to include level as syslog prefix in log line ($STLOGFORMATLEVELSYSLOG)
So, to get a timestamp suitable for systemd (syslog prefix, no level
string, no timestamp) we can pass `--log-format-timestamp=""
--no-log-format-level-string --log-format-level-syslog` or,
equivalently, set `STLOGFORMATTIMESTAMP="" STLOGFORMATLEVELSTRING=false
STLOGFORMATLEVELSYSLOG=true`.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
