7b1b77e50d
Bumps [github.com/quic-go/quic-go](https://github.com/quic-go/quic-go) from 0.42.0 to 0.43.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/quic-go/quic-go/releases">github.com/quic-go/quic-go's releases</a>.</em></p> <blockquote> <h2>v0.43.0</h2> <h2><em>quic-go.net</em>: Launching a new Documentation Site</h2> <p>With this release, we're launching a new documentation site for the quic-go projects (quic-go itself, HTTP/3, webtransport-go, and soon, masque-go): <a href="https://quic-go.net">quic-go.net</a>.</p> <p>The documentation site aims to explain QUIC concepts and how they are made accessible using quic-go's API. This site replaces the wiki, and the ever-growing README files.</p> <p>A lot of work has gone into the documentation already, but we're by no means done yet. The entire source is public in <a href="https://github.com/quic-go/docs/">https://github.com/quic-go/docs/</a>, and we're happy about community contributions.</p> <h2>HTTP Datagrams (RFC 9297)</h2> <p>This release adds support for HTTP Datagrams (<a href="https://datatracker.ietf.org/doc/html/rfc9297">RFC 9297</a>), both on the client and on the server side (<a href="https://redirect.github.com/quic-go/quic-go/issues/4452">#4452</a>). HTTP Datagrams are used in WebTransport in CONNECT-UDP (<a href="https://datatracker.ietf.org/doc/html/rfc9298">RFC 9298</a>), among others.</p> <p>The new API for HTTP Datagrams is described on the new documentation page: <a href="https://quic-go.net/docs/http3/datagrams/">HTTP Datagrams</a>. The integration of HTTP Datagram support necessitated a comprehensive refactor of the HTTP/3 package, resulting in several breaking API changes listed below.</p> <h2>Breaking Changes</h2> <ul> <li>quicvarint: functions now return an <code>int</code> instead the internal <code>protocol.ByteCount</code> (<a href="https://redirect.github.com/quic-go/quic-go/issues/4365">#4365</a>)</li> <li>http3: <code>Server.SetQuicHeaders</code> was renamed to <code>SetQUICHeaders</code> (<a href="https://redirect.github.com/quic-go/quic-go/issues/4377">#4377</a>)</li> <li>http3: <code>Server.QuicConfig</code> was renamed to <code>QUICConfig</code> (<a href="https://redirect.github.com/quic-go/quic-go/issues/4384">#4384</a>)</li> <li>http3: <code>RoundTripper.QuicConfig</code> was renamed to <code>QUICConfig</code> (<a href="https://redirect.github.com/quic-go/quic-go/issues/4385">#4385</a>)</li> <li>http3: <code>RoundTripOpt.CheckSettings</code> was removed (<a href="https://redirect.github.com/quic-go/quic-go/issues/4416">#4416</a>). Use the new<code>SingleDestinationRoundTripper</code> API instead.</li> <li>http3: the <code>HTTPStreamer</code> interface is now implemented by the <code>http.ResponseWriter</code> (and not the <code>http.Request.Body</code>) (<a href="https://redirect.github.com/quic-go/quic-go/issues/4469">#4469</a>)</li> <li>include the maximum payload size in the <code>DatagramTooLargeError</code> (<a href="https://redirect.github.com/quic-go/quic-go/issues/4470">#4470</a>)</li> </ul> <h2>Other Notable Changes</h2> <ul> <li>GSO and ECN is disabled on kernel versions older than 5 (<a href="https://redirect.github.com/quic-go/quic-go/issues/4456">#4456</a>)</li> <li>http3: logging can be controlled using an <code>slog.Logger</code> (<a href="https://redirect.github.com/quic-go/quic-go/issues/4449">#4449</a>)</li> <li>http3: HEAD requests can now be sent in 0-RTT (<a href="https://redirect.github.com/quic-go/quic-go/issues/4378">#4378</a>)</li> <li>http3: duplicate QPACK encoder and decoder streams are not rejected as required by the RFC (<a href="https://redirect.github.com/quic-go/quic-go/issues/4388">#4388</a>)</li> <li>http3: Extended CONNECT are blocked until the server's SETTINGS are received, as required by the RFC (<a href="https://redirect.github.com/quic-go/quic-go/issues/4450">#4450</a>)</li> <li>http3: HTTP/3 client connections aren't removed if <code>RoundTrip</code> errors due to a cancelled context (<a href="https://redirect.github.com/quic-go/quic-go/issues/4448">#4448</a>). Thanks to <a href="https://github.com/GeorgeMac"><code>@GeorgeMac</code></a>!</li> <li>http3: sniff Content-Type when flushing the ResponseWriter (<a href="https://redirect.github.com/quic-go/quic-go/issues/4412">#4412</a>). Thanks to <a href="https://github.com/WeidiDeng"><code>@WeidiDeng</code></a>!</li> <li>The <code>Context</code> exposed on the <code>quic.Stream</code> is now derived from the connection's context (<a href="https://redirect.github.com/quic-go/quic-go/issues/4414">#4414</a>)</li> <li>The UDP send and receive buffer size was increased to 7 MiB (<a href="https://redirect.github.com/quic-go/quic-go/issues/4455">#4455</a>). Thanks to <a href="https://github.com/bt90"><code>@bt90</code></a>!</li> </ul> <h2>Clarifications on the QUIC Stream State Machine</h2> <h3>Calling CancelWrite after Close</h3> <p>After a long and fruitful discussion (<a href="https://redirect.github.com/quic-go/quic-go/issues/4404">#4404</a>), we decided to clarify that calling <code>CancelWrite</code> after <code>Close</code> on a <code>SendStream</code> (or a bidirectional stream) should cause a state transition from the "Data Sent" to the "Reset Sent" state, as described in <a href="https://datatracker.ietf.org/doc/html/rfc9000#section-3.1">section 3.1 of RFC 9000</a>. This matches the current behavior of quic-go, however, it didn't match the API documentation (fixed in <a href="https://redirect.github.com/quic-go/quic-go/issues/4419">#4419</a>).</p> <p>This means that stream data will not be delivered reliably if <code>CancelWrite</code> is called, and that this applies even if <code>Close</code> was called before.</p> <h3>Garbage Collection of Streams</h3> <p>This release also changes the way streams are garbage-collected (and the peer is granted additional limit to open a new stream), once they're not needed anymore, in a subtle way:</p> <ul> <li>for the send direction of streams: <a href="https://redirect.github.com/quic-go/quic-go/issues/4445">#4445</a></li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
---|---|---|
.github | ||
assets | ||
cmd | ||
etc | ||
gui | ||
lib | ||
man | ||
meta | ||
next-gen-gui | ||
proto | ||
script | ||
test | ||
.codecov.yml | ||
.deepsource.toml | ||
.gitattributes | ||
.gitignore | ||
.golangci.yml | ||
.yamlfmt | ||
AUTHORS | ||
build.go | ||
build.ps1 | ||
build.sh | ||
CONDUCT.md | ||
CONTRIBUTING.md | ||
Dockerfile | ||
Dockerfile.builder | ||
Dockerfile.stcrashreceiver | ||
Dockerfile.stdiscosrv | ||
Dockerfile.strelaypoolsrv | ||
Dockerfile.strelaysrv | ||
Dockerfile.stupgrades | ||
Dockerfile.ursrv | ||
go.mod | ||
go.sum | ||
GOALS.md | ||
LICENSE | ||
README-Docker.md | ||
README.md | ||
tools.go |
Goals
Syncthing is a continuous file synchronization program. It synchronizes files between two or more computers. We strive to fulfill the goals below. The goals are listed in order of importance, the most important ones first. This is the summary version of the goal list - for more commentary, see the full Goals document.
Syncthing should be:
-
Safe From Data Loss
Protecting the user's data is paramount. We take every reasonable precaution to avoid corrupting the user's files.
-
Secure Against Attackers
Again, protecting the user's data is paramount. Regardless of our other goals, we must never allow the user's data to be susceptible to eavesdropping or modification by unauthorized parties.
-
Easy to Use
Syncthing should be approachable, understandable, and inclusive.
-
Automatic
User interaction should be required only when absolutely necessary.
-
Universally Available
Syncthing should run on every common computer. We are mindful that the latest technology is not always available to every individual.
-
For Individuals
Syncthing is primarily about empowering the individual user with safe, secure, and easy to use file synchronization.
-
Everything Else
There are many things we care about that don't make it on to the list. It is fine to optimize for these values, as long as they are not in conflict with the stated goals above.
Getting Started
Take a look at the getting started guide.
There are a few examples for keeping Syncthing running in the background on your system in the etc directory. There are also several GUI implementations for Windows, Mac, and Linux.
Docker
To run Syncthing in Docker, see the Docker README.
Getting in Touch
The first and best point of contact is the Forum. If you've found something that is clearly a bug, feel free to report it in the GitHub issue tracker.
If you believe that you’ve found a Syncthing-related security vulnerability, please report it by emailing security@syncthing.net. Do not report it in the Forum or issue tracker.
Building
Building Syncthing from source is easy. After extracting the source bundle from
a release or checking out git, you just need to run go run build.go
and the
binaries are created in ./bin
. There's a guide with more details on the
build process.
Signed Releases
As of v0.10.15 and onwards, release binaries are GPG signed with the key D26E6ED000654A3E, available from https://syncthing.net/security/ and most key servers.
There is also a built-in automatic upgrade mechanism (disabled in some distribution channels) which uses a compiled in ECDSA signature. macOS binaries are also properly code signed.
Documentation
Please see the Syncthing documentation site [source].
All code is licensed under the MPLv2 License.