[go-rpm-macros] Issue #46: %gobuildflags missing double quotation marks
by Petr Hruska
hruskape reported a new issue against the project: `go-rpm-macros` that you are following:
``
It seems that commit https://pagure.io/go-rpm-macros/c/359d80bbfe7f0490fc51c43af8d986863516c5b... breaking %gobuildflags usage in spec file.
Getting error, as double quotation marks are removed.
Specfile section
unset LDFLAGS
%make_build GOBUILDFLAGS="%{gobuildflags}"
Error:
+ /usr/bin/make -O -j16 V=1 VERBOSE=1 'GOBUILDFLAGS=-buildmode pie -compiler gc -tags=rpm_crashtraceback' ' -ldflags ' -B 0x3433f3bcad171c4e7f8f736da295a9fac8289b8c -compressdwarf=false -extldflags '-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -a -v -x'
/usr/bin/make: invalid option -- 'c'
/usr/bin/make: invalid option -- 'x'
Usage: make [options] [target] ...
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/46
1 month
[go-rpm-macros] Issue #3: %goprep should apply patches automatically
by Nicolas Mailhot
nim reported a new issue against the project: `go-rpm-macros` that you are following:
``
`%goprep` should apply patches automatically, so there is no convenience gap with `%autosetup`.
This is generic work that should be done *redhat-rpm-config* side in forge macros and then reused in`%goprep`. Basically:
1. define a `patch_flags<suffix>` rpm variable holding the parameters that should be passed to `%patch<suffix>`
2. define a `default_flags<suffix>` fallback
3. define a `source_patches<suffix>` holding an ordered space separated list of patch suffixes associated with a particular forge/go source.
And then write the usual lua loops to apply it all at the right moment in the spec.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/3
4 months, 3 weeks
Hashicorp Consul Packages
by Mark E. Fuller
In my continuing work on building terraform[0], I have a what appears to
be a version conflict between two hashicorp consul packages:
...
Error: Transaction test error:
file /usr/share/gocode/src/github.com/hashicorp/consul/.goipath
conflicts between attempted installs of
golang-github-hashicorp-consul-sdk-devel-0.7.0-5.fc37.noarch and
golang-github-hashicorp-consul-api-devel-1.9.1-7.fc38.noarch
file /usr/share/gocode/src/github.com/hashicorp/consul/CHANGELOG.md
conflicts between attempted installs of
golang-github-hashicorp-consul-sdk-devel-0.7.0-5.fc37.noarch and
golang-github-hashicorp-consul-api-devel-1.9.1-7.fc38.noarch
file /usr/share/gocode/src/github.com/hashicorp/consul/go.mod
conflicts between attempted installs of
golang-github-hashicorp-consul-sdk-devel-0.7.0-5.fc37.noarch and
golang-github-hashicorp-consul-api-devel-1.9.1-7.fc38.noarch
...
Both of these packages (see [1] and [2]) are derived from the same repo,
github.com/hashicorp/consul.
My question is, why are there two packages pointing to the same repo?
(Yes, I realize it is two different modules within it, but could they be
merged?)
Second, is there a way I can address this conflict on my end or are
modifications to one or both of the consul packages required to resolve
the issue?
[0]
https://download.copr.fedorainfracloud.org/results/fuller/terraform/fedor...
[1]
https://src.fedoraproject.org/rpms/golang-github-hashicorp-consul-sdk/blo...
[2]
https://src.fedoraproject.org/rpms/golang-github-hashicorp-consul-api/blo...
--
Mark E. Fuller, Ph.D.
fuller(a)fedoraproject.org
fuller(a)mefuller.dev
@fuller:fedora.im
@fuller:one.ems.host
https://www.stossrohr.net
PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60
1 year, 5 months
CVE Tracking Bugs
by Maxwell G
Hi Fedorians,
I think the security tracking bug filing process needs to be amended. The
current process is quite frustrating for me and other contributors. This
is especially bad for Go CVEs, which there are lot of.
Red Hat Product Security creates a single tracking bug for Fedora{, EPEL}
_and_ all Red Hat products and CCs a bunch of Fedora maintainers. They
then create separate bugs for each package that they deem affected. The
affected packages are oftened determined in a manner that appears
overzealous and arbitrary.
After the bugs are created, we get spammed with a bunch of notifications
about private bugs, RH product errata, and various other things that are
completely irrelevant to Fedora. These messages flood my Bugzilla mailbox
and obscure actual issues that I need to address. I do not really care
whether a Go CVE has been mitigated in Red Hat Advanced Cluster
Management for Kubernetes 2.4 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8."
---
Some particularly egregious examples:
I maintain an Ansible kubernetes collection, and they reported it as
vulnerable to some CVE with a specific Openshift component. The
collection not vulnerable. They provided no actionable information, and
the description was unclear. When I asked why it was reported, they said
that the package "used OpenShift."
A couple Go CVEs ago[^1], they created bugs against hundreds of Go
libraries. They arbitrarily chose branches and packages. The bugs were
not actionable by packagers of individual go libraries. Only applications
that provide binaries need to be rebuilt. They were reported shortly
before the F34 EOL, so we got a huge amount of emails after the bugs were
automatically closed. In fact, a Go packager reported that these messages
from the _security_ team DOSed their mail server. To their credit, they
have fixed this issue after one of the other Go SIG people talked to
them. Now, these bugs are only filed against the golang component.
[^1]: Really, it was a couple Go releases ago. There are multiple CVEs
reported with each Go release these days.
Another time, their automation posted the exact same comment over 200
times.
---
First and foremost, there needs to be a clear way for packagers to report
problems with this process to prodsec.
I don't think Fedora packagers should be CCed on these global trackers.
We could create a separate "Security Response" component under the
"Fedora" Bugzilla product to create tracker bugs for CVEs that affect
multiple Fedora components, or we could ask prodsec to only CC Fedora
maintainers on the child, package-level bugs. I guess I could acomplish
what I'm proposing by filtering out mails with "X-Bugzilla-Product:
Security Response" headers and not have gone on this rant, but I still
think this needs to be addressed.
Does anyone know how to reach prodsec about this?
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
1 year, 5 months