This adds pre-validation directly at the unmarshal step, of annotations
added to the protobuf definitions. This seeks to weed out unreasonable
situations early, by ensuring offsets are positive, string lengths are
limited, etc. Some of the limits are a bit subjective, but I think I've
put them above what is expected and reasonable...
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
A couple of "panic: bug: foo" type things, where the bug could be
controlled by the supposedly untrusted side.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
We might send unnecessary updates because something changed by the
actual announcement remains identical; skip those.
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
The API can use arbitrary paging parameters, causing arbitrary numbers
of prepared statements, which becomes a memory leak.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
This could happen when a folder has deleted files as the latest entries,
and nothing else happened for 180 days (the default tombstone cleanup
time).
Signed-off-by: Jakob Borg <jakob@kastelo.net>
Prior to refactoring, this delay kicked in once all batches were sent.
Now, it came between each batch. Fix that.
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
In e7b8efb41 I disabled keepalives in several HTTP clients, which
inadvertently also disabled HTTP/2. However, the TLS setup announced h2
as a supported protocol, which caused confusion. This fixes that, and
makes sure to use the same client in all relevant places.
The old option to do usage reporting posts with InsecureSkipVerify goes
away -- nobody should have ever used it.
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
### Purpose
Improve the contrast of semantic request-dialog headers and buttons in
the light, dark, and black GUI themes.
The light theme keeps its bright semantic colors and uses black text for
success, warning, and danger alerts plus success/warning buttons. Danger
buttons use the existing darker red with white text. The dark themes use
darker success, warning, and danger backgrounds with white text.
The lowest enabled-state contrast ratio is 4.509:1, meeting WCAG AA for
normal text.
### Testing
- `go run build.go assets`
- `go run build.go build syncthing`
- `git diff --check`
- Checked the base and interactive semantic color pairs with a WCAG
contrast calculation; all enabled states are at least 4.5:1.
- Loaded the generated GUI assets in Chromium and verified the computed
foreground/background colors for success, warning, and danger alerts and
buttons in both light and dark themes.
### Screenshots
Rendered light and dark fixtures locally to verify the complete alert
and button combinations. The computed colors matched the intended theme
rules and no clipping or layout changes were introduced.
### Documentation
No documentation changes are required; this only corrects existing theme
colors.
Signed-off-by: Giridhar <giridharpavan593@gmail.com>
Co-authored-by: Giridhar <giridharpavan593@gmail.com>
### Purpose
#10726 introduces a problematic side effect which only surfaced recently
in #10882:
On Windows 24H2 stdout will be invalid when Syncthing is started
detached from a console. This caused the monitors logwriter to fail
silently before it writes it a log file.
This PR fixes this by letting the multiwriter continue even after
failing on stdout.
### Testing
#10882 can be reproduced without this PRs commit. With this PR logging
does work again.
Following scenarios are tested in which the logfile will be written
again
-console: syncthing.exe
-console: start "" syncthing.exe
-console: start "" syncthing.exe serve --log-file=path
-explorer: double click
`go test ./lib/osutil ` checks if the introduced tolerantMultiWriter
writes to all targets even on errors.
---------
Signed-off-by: Elias <1elias.bauer@gmail.com>
Co-authored-by: Elias <1elias.bauer@gmail.com>
Where we don't expect connection reuse for further requests this reduces
the number of open connection server-side.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
fix(gui): add accessible labels to buttons in Edit Device modal (fixes
#10873)
Currently, the buttons show text on mouse hover or keyboard focus, but
they are inaccessible to screen readers due to a lack of any readable
labels.
However, there is not enough space to add full-length textual labels
that would be visible to everyone. Therefore, add only aria labels for
screen readers, while keyboard and mouse users can still learn their
function via the tooltips.
Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
As documented and intended, introducers should be able to vouch for
folders shared with them, but not other folders.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
It's only polite, and it enables better troubleshooting in situations
like weird-ass requests to the upgrades download service.
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
* infrastructure:
fix(stdiscosrv): slightly increase reannounce times and smoothing
fix(stdiscosrv): 500 errors should be accompanied by log entry
fix(ursrv): data problems are the clients fault
build: sign docker images
This is primarily to improve the experience in environments that start
Syncthing from a graphical environment, e.g., Windows.
When already running, instead of printing an error we open the GUI. If
the GUI is not available (but the lockfile indicates we are running),
print an error and exit.
If --no-browser is given or STNOBROWSER is set, act like before.
Closes#10736. Marking as `fix` because this does not deserve to trigger
a minor release on its own.
---------
Signed-off-by: Jakob Borg <jakob@kastelo.net>
When adding a folder in receive-only mode where the contents were
already identical to a remote device, directories would remain as
locally changed when everything else had consolidated. The reason this
happened is that we only did the matching between locally changed files
and their global equivalent for changed items, but directories are
typically not "changed" much as we don't track their mtime, so they
wouldn't pass through this stage when scanning.
Now, instead, do the check when we're anyway walking all the files in
phase two of scanning. This catches all cases of identical items, files
or directories, regardless of how they came to be in the index.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
There is a danger of deadlock wherever we have database operations
inside a database iterator. The iterator itself pins a connection, so
the nested operations need another connection; if we've reached
maxOpenConns then it blocks until a connection is released. If all
connections are consumed by such iterators then none can make progress.
Luckily, we have limited concurrency for most such iterator loops. They
are part of scanning, pulling, reverting, etc where there is only ever
one such routine per folder. The exception is block reuse in the copier
routine, which is limited by the `Copiers` setting per folder. This
could in practice deadlock since you could set copiers to eight and end
up with six `AllLocalBlocksWithHash` iterators when `maxDBConns=6`, all
of which need to make additional database calls inside the loop.
This PR fixes the problem twice;
- The problematic loop does not need to be reentrant. The set of blocks
that may be returned by the iterator is finite so we can easily just
collect them to a slice before we start processing them. This avoids the
problem entirely.
- We do not need to limit database connections as strictly as we
currently do. Increase the maximum allowed, while reducing the number of
held-open idle connections slightly. This is not an exact science, but
ideally we want "most" operations to be able to use the pinned
connections to avoid cache churn. Most operations are short lived
queries, or single-goroutine iterators with short lived queries inside,
so four connections seems like it should usually be enough. 🤷
- Additionally, set a cap on Copiers. Currently you could set it to an
arbitrarily large number, which is not advantageous. Limit it to
2*NumCPU which scales somewhat with system performance.
Signed-off-by: Jakob Borg <jakob@kastelo.net>
Jakob Borg