Syncthing broken by go-1.15 + quic

Development
1

Hi,

Due to this Syncthing is currently broken with go-1.5 edit: go-1.15.

I was wondering if there are any workarounds? Can quic support be disabled, for example?

Thanks!

2

I think @calmh has a branch, but I donā€™t think we have any way of disabling it. Probably deleting the quic files from the repo after checkout is the best bet.

I know there were some other issues with our certificates too in 1.15

3

I see.

Iā€™m in the unfortunate position where go was updated in OpenBSD and syncthing and go-ipfs were broken (at runtime). Users are complaining and I donā€™t have any kind of workaround to offer them :\

It sounds like we have to wait for quic to address thisā€¦

1 Like
4

I donā€™t get it. Go 1.5 is super old, Go 1.15 isnā€™t released yet. If you mean the Go 1.15 release candidate for some reason you can build the main branch of Syncthing using the noquic tag. But we really recommend a release version of Go. (And of Syncthing.)

6

So as of right now Go 1.15 is released, yet the above still holds. Iā€™ll want to make builds using both 1.14 and 1.15 for a long while so letā€™s see how the quic situation evolvesā€¦

7

From the discussion in the linked issue and earlier ones I get the impression that the mind-set of quic-devs towards (backwards-) compatibility in go versions and their own versions is that they donā€™t care much, except for what go-ipfs and eventually another consumer needs at that exact point in time. Which is a pity, because other than that it looks like an extremely well done and cared-for project. What irks me the most is not that they do not take action themselves, but the lack of reaction to the offer by a consumer to provide patches/PRs. I hope this particular issue will resolve itself until next week, now that 1.15 is outā€¦

8

I think we should pile on the bitching to apply pressure. Syncthing is big enough in terms of user count for them to have to care. Probably bigger than ipfs.

On the other hand, I thought we had other issues with 1.15, hence I wasnā€™t as concerned about quic compatability.

9

Oops. Yes thatā€™s meant to read 1.15.

10

There were some host check issues, but Jakob already took care of that. I am not aware of anything else.

11

I donā€™t think going full entitled asshole is the way to go, we have enough of those on the receiving side. That said I do think a package should support more than a single Go revision and it would have been nice to see them say ā€œPR welcomeā€, as noted by the issue creatorā€¦ A full set of build tags seems like the cost of doing business when youā€™re doing low level magic.

1 Like
12

Hi all,

Looks like quic are about to merge a PR to fix the go-1.15 issues. They then plan to roll a release:

13

Weā€™ve merged the fix and Iā€™m pushing a 1.9.0-rc.3 that 1) includes the fix and 2) is built with Go 1.15. Letā€™s see how that goes.

14

Great!

Iā€™ve just tried building the 1.9.0-rc.3 tag and got the same error:

panic: qtls.ConnectionState doesn't match

goroutine 1 [running]:
github.com/marten-seemann/qtls-go1-15.init.0()
        github.com/marten-seemann/qtls-go1-15@v0.1.0/unsafe.go:11 +0x245

Thatā€™s using go1.15beta1. Iā€™m a little behind, but should have worked, right?

15

Itā€™s working on the build servers, so thereā€™s no general problem. First thing Iā€™d eliminate is using the actual 1.15 release.

16

Probably no. Those TLS hacks are very sensitive indeed to the actual, specific version. :man_shrugging:

17

I can confirm that it works with the go 1.15 release on OpenBSD.

Iā€™ve sent a diff to update our package to 1.9.0rc4 to get us syncing again!

All tests passing!

Thanks everyone :slight_smile: