Proposed incompatible update / retirement: syncthing v1.30 -> v2

[Fabio Valentini]

Hi all,

TL;DR: I propose to make a technically "incompatible" update to
syncthing v2 in EPEL 10.3 and 10.2, and to retire the package in EPEL
9 and 8 where it can no longer be updated.

The major version bump signifies a change in the database backend,
from LevelDB to SQLite. The migration is transparently handled on
service startup, just like any other automatic database migration for
schema changes. The syncthing web interface has no user facing changes
in version 2.

The packages in EPEL are currently affected by the following security
issues due to having been built with golang 1.24.4 (or earlier):

- CVE-2025-47906: syncthing: Unexpected paths returned from LookPath in os/exec
- CVE-2025-58189: go crypto/tls ALPN negotiation error contains
attacker controlled information
- CVE-2025-61723: encoding/pem: Quadratic complexity when parsing some
invalid inputs in encoding/pem
- CVE-2025-58185: encoding/asn1: Parsing DER payload can cause memory
exhaustion in encoding/asn1
- CVE-2025-58188: crypto/x509: golang: Panic when validating
certificates with DSA public keys in crypto/x509
- CVE-2025-58183: golang: archive/tar: Unbounded allocation when
parsing GNU sparse map

I cannot rebuild the currently available packages with golang 1.26.3
(which is now available in RHEL 10 and 9) due to compiler changes
breaking the current package's build, but the current Fedora package
rebuilds without problems in RHEL 10 / CentOS Stream 10 buildroots.

On the other hand, the sqlite version in RHEL 9 and the golang
compiler in RHEL 8 are, respectively, too old to build the latest
syncthing.

Fabio

[Carl George]

On Fri, Jun 19, 2026 at 3:03 PM Fabio Valentini  wrote:
> Hi all,
>
> TL;DR: I propose to make a technically "incompatible" update to
> syncthing v2 in EPEL 10.3 and 10.2, and to retire the package in EPEL
> 9 and 8 where it can no longer be updated.
>
> The major version bump signifies a change in the database backend,
> from LevelDB to SQLite. The migration is transparently handled on
> service startup, just like any other automatic database migration for
> schema changes. The syncthing web interface has no user facing changes
> in version 2.
>
> The packages in EPEL are currently affected by the following security
> issues due to having been built with golang 1.24.4 (or earlier):
> CVE-2025-47906: syncthing: Unexpected paths returned from LookPath in os/exec
> CVE-2025-58189: go crypto/tls ALPN negotiation error contains
>
> attacker controlled information
> CVE-2025-61723: encoding/pem: Quadratic complexity when parsing some
>
> invalid inputs in encoding/pem
> CVE-2025-58185: encoding/asn1: Parsing DER payload can cause memory
>
> exhaustion in encoding/asn1
> CVE-2025-58188: crypto/x509: golang: Panic when validating
>
> certificates with DSA public keys in crypto/x509
> CVE-2025-58183: golang: archive/tar: Unbounded allocation when
>
> parsing GNU sparse map
>
> I cannot rebuild the currently available packages with golang 1.26.3
> (which is now available in RHEL 10 and 9) due to compiler changes
> breaking the current package's build, but the current Fedora package
> rebuilds without problems in RHEL 10 / CentOS Stream 10 buildroots.

You have my sympathy, I have the same general problem with caddy.
golang being a rolling appstream makes things... interesting.
> On the other hand, the sqlite version in RHEL 9 and the golang
> compiler in RHEL 8 are, respectively, too old to build the latest
> syncthing.

FYI, it looks like an update to golang 1.26.4 is in the pipeline for RHEL 8.

https://gitlab.com/redhat/centos-stream/rpms/golang/-/merge_requests/174

What is the restriction with sqlite?  libsqlite3 is the same soname
across RHEL 8/9/10 (libsqlite3.so.0 symlinked to libsqlite3.so.0.8.6).
I'm not necessarily saying you shouldn't retire the epel8/epel9
branches, but I am curious what the minimum version is and how it is
enforced if not by soname.
> Fabio
>
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Fabio Valentini]

On Wed, Jul 1, 2026 at 9:43 PM Carl George  wrote:
> FYI, it looks like an update to golang 1.26.4 is in the pipeline for RHEL 8.
>
> https://gitlab.com/redhat/centos-stream/rpms/golang/-/merge_requests/174

Thanks, that's good to know. I was unsure whether that was still
planned with there no longer being new minor releases for RHEL 8.
But given that RHEL 8 ships an *even older* version of sqlite (3.26.0)
than RHEL 9, it won't help.
> What is the restriction with sqlite?  libsqlite3 is the same soname
> across RHEL 8/9/10 (libsqlite3.so.0 symlinked to libsqlite3.so.0.8.6).
> I'm not necessarily saying you shouldn't retire the epel8/epel9
> branches, but I am curious what the minimum version is and how it is
> enforced if not by soname.

In an alma+epel-9-x86_64 mock chroot, the syncthing test suite has a
lot of errors like this one:

```
CREATE TABLE IF NOT EXISTS schemamigrations (
    schema_version INTEGER NOT NULL PRIMARY KEY,
    applied_at INTEGER NOT NULL, -- unix nanos
    syncthing_version TEXT NOT NULL COLLATE BINARY
) STRICT): near "STRICT": syntax error
```

So this is not related to ABI, but missing support for "new" features APIs.
The error in question looks like it's caused by the use of the STRICT keyword,
which is a new feature since sqlite 3.37.0 - but RHEL 9 ships sqlite 3.34.1.
(https://sqlite.org/stricttables.html)

Fabio

[Carl George]

On Wed, Jul 1, 2026 at 3:01 PM Fabio Valentini  wrote:
> On Wed, Jul 1, 2026 at 9:43 PM Carl George  wrote:
> > FYI, it looks like an update to golang 1.26.4 is in the pipeline for RHEL 8.
> >
> > https://gitlab.com/redhat/centos-stream/rpms/golang/-/merge_requests/174
>
> Thanks, that's good to know. I was unsure whether that was still
> planned with there no longer being new minor releases for RHEL 8.
> But given that RHEL 8 ships an *even older* version of sqlite (3.26.0)
> than RHEL 9, it won't help.
> > What is the restriction with sqlite?  libsqlite3 is the same soname
> > across RHEL 8/9/10 (libsqlite3.so.0 symlinked to libsqlite3.so.0.8.6).
> > I'm not necessarily saying you shouldn't retire the epel8/epel9
> > branches, but I am curious what the minimum version is and how it is
> > enforced if not by soname.
>
> In an alma+epel-9-x86_64 mock chroot, the syncthing test suite has a
> lot of errors like this one:
> CREATE TABLE IF NOT EXISTS schemamigrations (
>     schema_version INTEGER NOT NULL PRIMARY KEY,
>     applied_at INTEGER NOT NULL, -- unix nanos
>     syncthing_version TEXT NOT NULL COLLATE BINARY
> ) STRICT): near "STRICT": syntax error
>
> So this is not related to ABI, but missing support for "new" features APIs.
> The error in question looks like it's caused by the use of the STRICT keyword,
> which is a new feature since sqlite 3.37.0 - but RHEL 9 ships sqlite 3.34.1.
> (https://sqlite.org/stricttables.html)

Fair enough, thanks for the insight.  Ironically, if it were a
different soname maybe it would be possible to create an sqlite compat
package to address this.  Given the factors I agree on retirement for
those branches.

I will suggest adding the minimum sqlite version you found to the
sqlite-devel build requirement in the spec file, with a corresponding
comment.  Once it's retired in epel8/epel9 I expect someone will try
to rebuild the epel10 package on el8/el9 for their own use, and I
think it would be nicer to have the build abort at the build
requirement step instead of later during the test suite.
> Fabio
>
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Michel Lind]

On Wed, 2026-07-01 at 22:01 +0200, Fabio Valentini wrote:
> On Wed, Jul 1, 2026 at 9:43 PM Carl George 
> wrote:
> > FYI, it looks like an update to golang 1.26.4 is in the pipeline
> > for RHEL 8.
> >
> > https://gitlab.com/redhat/centos-stream/rpms/golang/-/merge_requests/174
>
> Thanks, that's good to know. I was unsure whether that was still
> planned with there no longer being new minor releases for RHEL 8.
> But given that RHEL 8 ships an *even older* version of sqlite
> (3.26.0)
> than RHEL 9, it won't help.
> > What is the restriction with sqlite?  libsqlite3 is the same soname
> > across RHEL 8/9/10 (libsqlite3.so.0 symlinked to
> > libsqlite3.so.0.8.6).
> > I'm not necessarily saying you shouldn't retire the epel8/epel9
> > branches, but I am curious what the minimum version is and how it
> > is
> > enforced if not by soname.
>
> In an alma+epel-9-x86_64 mock chroot, the syncthing test suite has a
> lot of errors like this one:
> CREATE TABLE IF NOT EXISTS schemamigrations (
>     schema_version INTEGER NOT NULL PRIMARY KEY,
>     applied_at INTEGER NOT NULL, -- unix nanos
>     syncthing_version TEXT NOT NULL COLLATE BINARY
> ) STRICT): near "STRICT": syntax error

This is sadly similar to the issue with atuin in EPEL 9, except it's
with a different feature.

And despite sqlite's soname not changing - my quick experiment seeing
if EL10's sqlite is a drop in replacement on EL9's systems show that,
no, that causes DNF transactions to fail.

Best regards,

[Leon Fauster]

Am 19.06.26 um 22:03 schrieb Fabio Valentini:
> Hi all,
>
> TL;DR: I propose to make a technically "incompatible" update to
> syncthing v2 in EPEL 10.3 and 10.2, and to retire the package in EPEL
> 9 and 8 where it can no longer be updated.
>
> The major version bump signifies a change in the database backend,
> from LevelDB to SQLite. The migration is transparently handled on
> service startup, just like any other automatic database migration for
> schema changes. The syncthing web interface has no user facing changes
> in version 2.
>
> The packages in EPEL are currently affected by the following security
> issues due to having been built with golang 1.24.4 (or earlier):
> CVE-2025-47906: syncthing: Unexpected paths returned from LookPath in os/exec
> CVE-2025-58189: go crypto/tls ALPN negotiation error contains
>
> attacker controlled information
> CVE-2025-61723: encoding/pem: Quadratic complexity when parsing some
>
> invalid inputs in encoding/pem
> CVE-2025-58185: encoding/asn1: Parsing DER payload can cause memory
>
> exhaustion in encoding/asn1
> CVE-2025-58188: crypto/x509: golang: Panic when validating
>
> certificates with DSA public keys in crypto/x509
> CVE-2025-58183: golang: archive/tar: Unbounded allocation when
>
> parsing GNU sparse map
>
> I cannot rebuild the currently available packages with golang 1.26.3
> (which is now available in RHEL 10 and 9) due to compiler changes
> breaking the current package's build, but the current Fedora package
> rebuilds without problems in RHEL 10 / CentOS Stream 10 buildroots.

Did I it understand correctly, syncthing-1.30.0-1.el9 can't be 
recompiled with golang-1.26.4-1.el9_8 ??

[Fabio Valentini]

On Thu, Jul 2, 2026 at 11:53 PM Leon Fauster via epel-devel
 wrote:
> Did I it understand correctly, syncthing-1.30.0-1.el9 can't be
> recompiled with golang-1.26.4-1.el9_8 ??

Yes, that is what I found. The currently available syncthing packages
for EPEL 10 and 9 fail to rebuild today due to golang compiler
changes.

Fabio