The subject is a strawman proposal and goes from what was discussed from
today's meeting. There are a lot of golan packages which are FTBFS and not
a lot of people helping to fix. My original over-the-top subject was
'Retire golang' but since the compiler works, that is overkill.
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
Hi Fedorians and Gophers,
Later this week, I will be a doing a mass rebuild in F35 for all packages that
require `golang` and provide binaries to mitigate the following CVEs:
`golang` (affects all go binaries):
- CVE-2022-24675 golang: encoding/pem: fix stack overflow in Decode
- CVE-2022-28327 golang: crypto/elliptic: panic caused by oversized scalar
- CVE-2022-29526 golang: syscall: faccessat checks wrong group
(There are some Go CVEs that are a little bit older that will also be
mitigated by the rebuild for packages that haven't been updated recently)
CVEs in other golang libraries that affect a subset of Go packages:
- CVE-2022-21698 golang-github-prometheus-client: prometheus/client_golang:
Denial of service using InstrumentHandlerCounter
- CVE-2022-1996 go-restful: Authorization Bypass Through User-Controlled Key
Only packages that provide binaries need to be rebuilt, which will make this
rebuild less disruptive. Also, note that if your package uses vendored
dependencies that are affected by the latter two CVEs and haven't been patched,
you will need to handle this manually by querying upstream to update their
vendored dependencies (if the bundling is done upstream) and/or fix it
yourself. Thankfully, the packages don't need rebuilt in a specific order
(besides golang being first) due to the nature of go, so this will be less
complicated than, for example, the Python rebuilds.
No action will be required from you, unless your package is affected by the
aforementioned bundled dep issue, you'd like your package to receive special
treatment, or if the go-sig doesn't have permissions on your package (see
I have made a list of affected packages here. I didn't want to paste it into
this email, as it's pretty long. The list is split into 2 categories:
## go-sig packages
### mergable from Rawhide
For these packages, `rawhide` was determined to be mergable back to `f35`, as
they were up to date excluding the rebuild commit from when we rebuilt
`rawhide` a week or two ago.
### Not mergable
These packages were determined to not be mergable, as `rawhide` is ahead of
(or otherwise has diverged from) `f35`. Therefore, I will create a new rebuild
commit on `f35`. This will likely cause merge conflicts if you try to merge
`rawhide` back into `f35` after this change. Assuming the update would be
compatible and comply with the Updates Policy, I can move your package into
the other list and merge `rawhide` into `f35`. Please leave a comment on
https://pagure.io/GoSIG/go-sig/issue/41 if you would like me to do so.
Conversely, if you believe your package is incorrectly in `### mergeable`,
also let me know in the aforementioned ticket.
## non-go-sig packages
Neither I personally nor the go-sig has access to these packages, so I will
query a provenpackager to handle these. To the maintainers of these packages:
You really should really add go-sig to your package. Not having the
appropriate permissions delays us from mitigating CVEs in your package and
generally prevents us from effectively maintaining the Go stack. @fale has
already sent two reminders. Please see https://lists.fedoraproject.org/
A4NEHUW52ELDHDMPQDCBSRJXHDPJK2QX/ for more information.
For the benefit of the provenpackager who will handle this, I have compiled the
same mergable and not mergable lists.
Thank you for your cooperation. I understand that this is a bit disruptive for
a stable release, but we don't have much of a choice.
Maxwell G (@gotmax23)
So the change deadline is very soon, so I'd like a quick answer on this.
So Fedora is dropping i686 in the near future, only plsnning to support Wine related thingie
as far as I know. Could we too make a move toward this by dropping %ix86 from our supported
Most Go dev don't bother to do check build on 32 bits platforms and thus we find out many
bugs when building on these arches. arm32 was dropped, now we only have i686 as the
remaining 32 bits arch, removing it would reduce the time spent on bugs and failed builds.
What's your take on it Go Folks? Please answer relaively quickly as we don't have much time
before changes deadline.