Bug 1215808 - VUL-0: yq: go1.19 is EOL
Summary: VUL-0: yq: go1.19 is EOL
Status: RESOLVED FIXED
Alias: None
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 1215611
  Show dependency treegraph
 
Reported: 2023-09-28 12:15 UTC by Marcus Meissner
Modified: 2023-10-11 12:42 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2023-09-28 12:15:09 UTC
yk is still harcodding go1.19 ... should be updated to go1.20 or go1.21 now, or without go version rquires

+++ This bug was initially created as a clone of Bug #1215611 +++

as go1.19 is EOL, this is the tracker bug to link bugs referencing go packagds still linking go1.19.
Comment 1 Egbert Eich 2023-09-29 05:50:16 UTC
@Marcus: what's the request here?
Update yk in any released product and replace it with one built with a current go version?
Comment 2 Marcus Meissner 2023-09-29 08:12:19 UTC
it should be sufficient to do:

-BuildRequires:  golang(API) = 1.19
+BuildRequires:  golang(API) = 1.21


it still builds afterwards, so it might be only change needed.
Comment 3 Egbert Eich 2023-09-29 08:36:15 UTC
My question more whether this needs to be done for every code stream for the rest of the lifecycle of the product. 
In private communication the answer was 'yes'. So we should investigate whether it would be feasible to do an un-versioned build - without the use of
BuildRequires:  golang(API) = <version>
We should check what the majority of the go packages do.
Possibly, a:
BuildRequires:  golang(API) >= <version> 
would be more suitable.
Comment 5 Egbert Eich 2023-09-29 08:47:19 UTC
@Dirk: 
since you are one of the upstream maintainers of utilities/yq - would it be feasible to lessen the golang API restriction?
We would see when it breaks building in which case the package can either be updated or 2nd restriction added: 
 BuildRequires:  golang(API) <= <version_upper>
Comment 6 Christian Goll 2023-09-29 09:15:04 UTC
Upstream requires go1.20 but as go aims to be backward compatible, see
https://go.dev/blog/compat
using
 BuildRequires:  golang(API) <= 1.20
should be the best solution.
Comment 7 Dirk Mueller 2023-09-29 14:15:30 UTC
----------------------------------------------------------------------------
r1 | dmach | 2023-02-08 13:49:20 | b082d3f1125a39a31ddf8990110971a6 | 4.30.8 | rq289300

bugowner: group:hpc-team

Add package yq as a build dependency of
warewulf4: it is required to edit a config
file in yaml to support: (jsc#PED-3159).
Bugownership is purely assumed for yq as
build dependency for other packages, not
for a customer-facing package.


do we really need to fix this? it is fixed for tumbleweed.
Comment 8 Dirk Mueller 2023-09-29 14:17:58 UTC
anyway, submitted.
Comment 10 Marcus Meissner 2023-09-29 15:24:41 UTC
we shipped it on openSUSE 15.5 and PackageHub 15-SP5...
its arguable if the go version update fixes any relevant issues, true.
Comment 11 OBSbugzilla Bot 2023-09-29 16:35:02 UTC
This is an autogenerated message for OBS integration:
This bug (1215808) was mentioned in
https://build.opensuse.org/request/show/1114399 Factory / yq
Comment 13 Maintenance Automation 2023-10-06 16:29:08 UTC
SUSE-SU-2023:4000-1: An update that has one security fix can now be installed.

Category: security (moderate)
Bug References: 1215808
Sources used:
openSUSE Leap 15.5 (src): yq-4.35.2-150500.3.3.1
SUSE Package Hub 15 15-SP5 (src): yq-4.35.2-150500.3.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 14 Dirk Mueller 2023-10-11 12:42:50 UTC
(In reply to Egbert Eich from comment #5)

> since you are one of the upstream maintainers of utilities/yq - would it be
> feasible to lessen the golang API restriction?

I prefer not to do that as testing coverage wasn't enabled in the package (now done) and I prefer to use the version that upstream tested against. 

Starting with Go 1.21 there is promised a better backward compatibility so yeah, we could potentially look into that going forward. the bug reports have the added convenience that I have a reason to do a version update that includes bugfixes and new features also.