:51:10AM -0500, Dave Dykstra wrote:
> To Troy and the rest of the EPEL Steering Committee:
>
> Thank you very much for granting the request.
>
> The apptainer maintainers promise to do our best to avoid incompatible
> updates in the future. However if we discover ano
golang-1.19.6 is now available in epel-testing for EPEL7, an update of a
minor version from 1.18.9. I expect it to be promoted in about a week
unless karma changes that.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ba899b9717
My policy for updating golang in EPEL7 is to follow
/FEDORA-EPEL-2023-efd9bbf67e
Dave
On Wed, May 17, 2023 at 04:04:30PM -0500, Dave Dykstra wrote:
> golang-1.19.6 is now available in epel-testing for EPEL7, an update of a
> minor version from 1.18.9. I expect it to be promoted in about a week
> unless karma changes that.
&g
while following
> Fedora and EPEL update policies, then apptainer can too. Asking you
> to follow these policies is not a punishment. If you're unwilling to
> follow these policies, then I agree with Troy that copr will be a
> better fit for apptainer.
>
> On Thu, May 11, 2023 at 1
This change has now been approved by the EPEL Steering Committee and
requested to be pushed to stable. I expect it to be in stable sometime
tomorrow.
Dave
On Wed, Apr 26, 2023 at 01:07:32PM -0500, Dave Dykstra wrote:
> The apptainer-suid package version 1.1.8 now in epel-testing
e upstream maintainers of this.
>
>
> Troy
>
> On Mon, May 8, 2023 at 7:29 AM Dave Dykstra wrote:
>
> > Hi Troy,
> >
> > If required, the epel8 & epel9 builds could have a patch added that
> > changes the default of the new "allow setui
chines on RHEL 7,8 and 9 to use the same
> version and secure options.
> Users that only have machines on RHEL 8 and 9, would then have the option
> to move to the more secure option when the time is good for them.
>
> Troy
>
> On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via
severity
is rated High.
Dave
On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote:
> DT,
>
> I am not all arguing that CVE-2022-1184 impact score was incorrect. I can't
> imagine why you think that.
>
> By itself, CVE-2022-1184 is not a privilege escalati
g new.
Dave
On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote:
> Dave,
>
> On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel wrote:
> > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote:
> > > On Thu, Apr 27, 2023 at 10:20
On Wed, May 03, 2023 at 02:48:05PM -0500, Carl George wrote:
> On Thu, Apr 27, 2023 at 9:42 AM Dave Dykstra via epel-devel
> wrote:
> >
> > We believe that it is important to apply this change to all EPEL releases,
> > for these reasons:
> > 1. The general vulne
On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote:
> On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel
> wrote:
> >
> > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote:
...
> > > The Red Hat CVSS score for CVE-2022-1184 has the same brea
On Thu, Apr 27, 2023 at 12:00:47PM +0100, David Trudgian wrote:
> On Thu, Apr 27, 2023, at 8:11 AM, Carl George wrote:
> > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the
> > NVD CVSS score. Both rate the "privileges required" property as low.
> > From what I can tell that
On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote:
> On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel
...
> > The summary of the CVE is that the way that apptainer & singularity
> > allow mounts of ext3 filesystems in setuid mode raises the severi
On Thu, Apr 27, 2023 at 09:09:57AM +0100, Nick Howitt via epel-devel wrote:
> On 2023-04-27 08:42, Carl George wrote:
...
> > should be modified to set the "allow setuid-mount extfs" option to yes
> > for compatibility, even if that isn't the upstream default.
>
> Can you not set the option to no
We believe that it is important to apply this change to all EPEL releases,
for these reasons:
1. The general vulnerability described in this CVE applies equally to all
currently supported Linux distributions. The Singularity/Apptainer
community has long been aware that making setuid-root
The apptainer-suid package version 1.1.8 now in epel-testing has an
incompatible change because of a security vulnerability. The change is
that a new option "allow setuid-mount extfs" was added which defaults to
no, preventing ordinary users from mounting ext3 filesystems in
setuid-root mode.
DT is correct, this change is subject to the EPEL incompatible change
policy. apptainer-suid-1.1.8 by default disables mounting of ext3
filesystems, because of CVE-2023-30549
https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
Most users don't use this feature,
golang-1.18.4 is now available in epel-testing for EPEL7, an update of a
minor version from 1.17.12. I expect it to be promoted in about a week
unless karma changes that.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-96dbad9cd3
My policy for updating golang is to follow the
upgrading
the minor version number once or twice a year. There is a golang
fedoraproject.org mailing list. Maybe it's enough to announce minor
release upgrades there instead of epel-announce.
Dave
On Thu, Oct 20, 2022 at 01:18:30PM -0700, Troy Dawson wrote:
> On Wed, Oct 19, 2022 at 5:42 PM D
Hello all,
It is been pointed out to me that I pushed out an update of a package to
EPEL that did not follow the incompatible upgrades policy:
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
That's because I wasn't aware of the policy until it was pointed out to
me
I asked for a review swap on this on fedora-devel but so far did not
get any takers. I'm thinking maybe a lot of Fedora people don't care
that much about an epel7-only package. The package is fuse2fs and
this is the request:
https://bugzilla.redhat.com/show_bug.cgi?id=2104533
The tool is
Is anybody else having trouble with using kerberos with fedpkg on el7?
It is working for me on el8, and it used to work for me on el7, but now
on my el7 machine any time I try to do an upload I get
Could not execute upload: Request is unauthorized.
and with fedpkg build I get
Kerberos
At the moment this is their landing page:
https://github.com/rocky-linux/organization/wiki/Contributing
and they're working on a home page today for rockylinux.org.
Dave
On Wed, Dec 09, 2020 at 03:53:12PM +0100, Christopher Engelhard wrote:
> On 09.12.20 15:20, Troy Dawson wrote:
> > Does
Why are el6 builds now showing up as el6_10? For example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=39443320
In order to do fedpkg update I had to change the el6 in the first line
to el6_10 by hand, otherwise I get an error
Could not execute update: Could not generate update
It seems to be worse than that. When I tried around 2 weeks ago,
building a version in epel8-playground blocked building the same version
in epel8.
https://pagure.io/releng/issue/8925
I did similar builds earlier and didn't have the problem.
I have packages.cfg that targets epel8 in the
Dawson wrote:
> On Fri, Aug 16, 2019 at 7:18 AM Dave Dykstra wrote:
> >
> > So that did get the epel8-playground branch created for me, in this
> > issue:
> > https://pagure.io/releng/fedora-scm-requests/issue/15267
> >
> > I was able to successfully
g fedpkg --release epel8 build but that just moved it over
to the epel8 branch; when used with --skip-nvr-check it said
Building singularity-3.3.0-1.el8 for epel8-candidate
Can you figure out what's still not right?
Dave
On Thu, Aug 15, 2019 at 05:47:57PM -0500, Dave Dykstra wrote:
> Troy,
>
issue,
> then something is wrong with your fedpkg.
>
> On Wed, Aug 14, 2019 at 3:25 PM Dave Dykstra wrote:
> >
> > Hi Troy!
> >
> > I created my branch for singularity from epel8, but that wouldn't make a
> > difference, would it? When I do fedpkg push from
you want.
>
> Troy
>
> On Mon, Aug 12, 2019 at 2:17 PM Dave Dykstra wrote:
> >
> > Hi Kevin,
> >
> > I have fedpkg-1.37-4.el7, the latest version. My yum log shows I
> > updated it from 1.37-2 on August 6 an hour and a half before I started
> &g
, Aug 11, 2019 at 10:01:47AM -0700, Kevin Fenzi wrote:
> On 8/8/19 11:40 AM, Dave Dykstra wrote:
> > Stephen,
> >
> > The package is singularity.
> >
> > The term "branch" in this context is not very clear to me. All I know
> > is that there's no git
ogen wrote:
> On Tue, 6 Aug 2019 at 15:10, Dave Dykstra wrote:
>
> > I don't think I understand how epel8-playground is envisioned to be
> > used. I did the fedpkg request-branch epel8 and got it created for my
> > package. I also ran fedpkg request-branch epel8-pla
I don't think I understand how epel8-playground is envisioned to be
used. I did the fedpkg request-branch epel8 and got it created for my
package. I also ran fedpkg request-branch epel8-playground as in the
script below, but that was rejected:
Could not execute request_branch: You cannot
32 matches
Mail list logo
