[EPEL-devel] Fedora EPEL 7 updates-testing report

2023-05-10 Thread updates 
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0989e83e8a   
chromium-113.0.5672.63-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-7f7029b90d   
tcpreplay-4.4.3-3.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

gfal2-2.21.4-2.el7
python-rosdep-0.22.2-1.el7
python-rosinstall_generator-0.1.23-1.el7
python-rospkg-1.5.0-1.el7
rpki-client-8.4-2.el7

Details about builds:



 gfal2-2.21.4-2.el7 (FEDORA-EPEL-2023-a1be81c983)
 Grid file access library 2.0

Update Information:

Upstream release v2.21.4

ChangeLog:

* Tue May  9 2023 Mihai Patrascoiu  - 2.21.4-2
- Patch to correctly find cryptopp dependency on 32-bit architectures
* Mon May  8 2023 Mihai Patrascoiu  - 2.21.4-1
- Upgrade to upstream release 2.21.4




 python-rosdep-0.22.2-1.el7 (FEDORA-EPEL-2023-703f2815b4)
 ROS System Dependency Installer

Update Information:

Update to the latest ROS infrastructure package releases.

ChangeLog:

* Tue May  9 2023 Scott K Logan  - 0.22.2-1
- Update to 0.22.2 (rhbz#2180331)

References:

  [ 1 ] Bug #2115320 - python-catkin_lint-1.6.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2115320
  [ 2 ] Bug #2170020 - python-osrf-pycommon-2.1.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2170020
  [ 3 ] Bug #2174298 - python-rosinstall_generator-0.1.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2174298
  [ 4 ] Bug #2180331 - python-rosdep-0.22.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180331
  [ 5 ] Bug #2180332 - python-rospkg-1.5.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180332




 python-rosinstall_generator-0.1.23-1.el7 (FEDORA-EPEL-2023-703f2815b4)
 Generates rosinstall files

Update Information:

Update to the latest ROS infrastructure package releases.

ChangeLog:

* Tue May  9 2023 Scott K Logan  - 0.1.23-1
- Update to 0.1.23 (rhbz#2174298)

References:

  [ 1 ] Bug #2115320 - python-catkin_lint-1.6.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2115320
  [ 2 ] Bug #2170020 - python-osrf-pycommon-2.1.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2170020
  [ 3 ] Bug #2174298 - python-rosinstall_generator-0.1.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2174298
  [ 4 ] Bug #2180331 - python-rosdep-0.22.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180331
  [ 5 ] Bug #2180332 - python-rospkg-1.5.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180332




 python-rospkg-1.5.0-1.el7 (FEDORA-EPEL-2023-703f2815b4)
 Utilities for ROS package, stack, and distribution information

Update Information:

Update to the latest ROS infrastructure package releases.

ChangeLog:

* Tue May  9 2023 Scott K Logan  - 1.5.0-1
- Update to 1.5.0 (rhbz#2180332)

References:

  [ 1 ] Bug #2115320 - python-catkin_lint-1.6.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2115320
  [ 2 ] Bug #2170020 - python-osrf-pycommon-2.1.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2170020
  [ 3 ] Bug #2174298 - python-rosinstall_generator-0.1.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2174298
  [ 4 ] Bug #2180331 - python-rosdep-0.22.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180331
  [ 5 ] Bug #2180332 - python-rospkg-1.5.0 is available
https://bugzilla.redhat.com/show_bug.

[EPEL-devel] Fedora EPEL 8 updates-testing report

2023-05-10 Thread updates 
The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  55  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e00c3d01e   
cutter-re-2.2.0-1.el8 rizin-0.5.1-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f44d817bc9   
chromium-113.0.5672.63-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-6463a51c68   
tcpreplay-4.4.3-3.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

gfal2-2.21.4-2.el8
js-jsroot-7.3.1-1.el8
kitty-0.26.5-7.el8
mate-terminal-1.26.1-1.el8
python-catkin_lint-1.6.22-1.el8
python-osrf-pycommon-2.1.2-1.el8
python-rosdep-0.22.2-1.el8
python-rosinstall_generator-0.1.23-1.el8
python-rospkg-1.5.0-1.el8
resalloc-aws-1.4-1.el8
root-6.28.04-1.el8
rpki-client-8.4-2.el8
suricata-6.0.12-1.el8

Details about builds:



 gfal2-2.21.4-2.el8 (FEDORA-EPEL-2023-26ae7d0fb9)
 Grid file access library 2.0

Update Information:

Upstream release v2.21.4

ChangeLog:

* Tue May  9 2023 Mihai Patrascoiu  - 2.21.4-2
- Patch to correctly find cryptopp dependency on 32-bit architectures
* Mon May  8 2023 Mihai Patrascoiu  - 2.21.4-1
- Upgrade to upstream release 2.21.4




 js-jsroot-7.3.1-1.el8 (FEDORA-EPEL-2023-f235e125c8)
 JavaScript ROOT - Interactive numerical data analysis graphics

Update Information:

root 6.28.04

ChangeLog:

* Tue Mar 28 2023 Mattias Ellert  - 7.3.1-1
- Update to version 7.3.1




 kitty-0.26.5-7.el8 (FEDORA-EPEL-2023-1f39b04ca0)
 Cross-platform, fast, feature full, GPU based terminal emulator

Update Information:

fix clone-in-kitty + security fix #2196803

ChangeLog:

* Wed May 10 2023 Pavel Solovev  - 0.26.5-7
- add missing endif
* Wed May 10 2023 Pavel Solovev 
- RPMAUTOSPEC: unresolvable merge

References:

  [ 1 ] Bug #2196802 - kitty: should not handle application/x-sh mime type by 
executing the script
https://bugzilla.redhat.com/show_bug.cgi?id=2196802




 mate-terminal-1.26.1-1.el8 (FEDORA-EPEL-2023-73ccad1112)
 Terminal emulator for MATE

Update Information:

- update to 1.26.1

ChangeLog:

* Wed May 10 2023 Wolfgang Ulbrich  - 1.26.1-1
- update to 1.26.1




 python-catkin_lint-1.6.22-1.el8 (FEDORA-EPEL-2023-95959597f0)
 Check catkin packages for common errors

Update Information:

Update to the latest ROS infrastructure package releases.

ChangeLog:

* Tue May  9 2023 Scott K Logan  - 1.6.22-1
- Update to 1.6.22 (rhbz#2115320)

References:

  [ 1 ] Bug #2115320 - python-catkin_lint-1.6.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2115320
  [ 2 ] Bug #2170020 - python-osrf-pycommon-2.1.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2170020
  [ 3 ] Bug #2174298 - python-rosinstall_generator-0.1.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2174298
  [ 4 ] Bug #2180331 - python-rosdep-0.22.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180331
  [ 5 ] Bug #2180332 - python-rospkg-1.5.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2180332




 python-osrf-pycommon-2.1.2-1.el8 (FEDORA-EPEL-2023-95959597f0)
 Commonly needed Pytho

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

2023-05-10 Thread Troy Dawson 
We discussed this in the weekly EPEL Steering Committee meeting. We broke
this into two separate votes.

*Allow the epel 7 update : Passed*
Votes: All who voted, voted in favor of this.
Notes: No notes.

*Allow the epel 8 and 9 update - with a stern warning : Passed*
Votes: 4 for, 2 against, 1 abstaining -
Notes: Although your argument was that these needed the same breaking
configurations to prevent future security issues, that wasn't what swayed
the votes. The first reason was that having older versions in epel 8 and 9
causes more problems. The second reason was that we felt we didn't give you
a stern enough warning last time.

*WARNING / ADVISEMENT / ATTENTION*
This is the second time that apptainer has had breaking updates. The EPEL
Steering Committee feels that if this happens again, then apptainer isn't a
good fit for EPEL. We will pull apptainer from EPEL and recommend that you
release it in COPR  instead of EPEL.
Please inform the 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 setuid-mount extfs" to be "yes"
> instead of "no". That's all that would be required to disable the
> incompatible change.
>
> But as I said, I think it's a bad idea to make this behavior different
> on different OS versions.  Epel8 & 9 are still vulnerable to the same
> general issue; even though they're likely to get patches for future low
> or moderate level severity vulnerabilities, they don't get patches
> quickly and so admins will have to turn this off for the period of time
> between announcement and patch upstream.  Also the incompatibility is
> going to only affect a small percentage of epel8 & 9 users, and they
> should be able to quickly workaround it by adding the --userns option.
>
> The --userns option is already available everywhere.  Are you
> suggesting that it default to --userns option behavior on epel8 & 9, at
> least for ext3, when "allow setuid-mount extfs = no"?  I have thought
> of that but I believe that we cannot mix the setuid mode and the
> fuse2fs mount, at least not without a lot of major rework and careful
> investigation of the security implications.  I don't think it would be
> good to automatically switch fully to the --userns mode with a setuid
> installation and "allow setuid-mount extfs = no", because then users
> will get subtle differences with other behavior depending on whether or
> not they are requesting something that is using an ext3 filesystem.
>
> Dave
>
> On Mon, May 08, 2023 at 06:47:04AM -0700, Troy Dawson wrote:
> > That makes it more clear for epel7.
> > But it will be strange for epel7 to have a higher version than epel8 and
> 9.
> > Would the apptainer maintainers be willing to create an update that has
> the
> > --userns option, as well as the original option?
> > Then for epel7 the rpm's would have the original option turned off, but
> for
> > epel8 and 9 the option could be there and update wouldn't be a breaking
> > update.
> >
> > That would allow users that have machines 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 epel-devel <
> > epel-devel@lists.fedoraproject.org> wrote:
> >
> > > The NVD analysis at
> > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549
> > > is now finished and they agreed with the impact score that I gave it.
> > > They ended up with an even higher rating because they said the attack
> > > complexity was low.  I think the complexity is high, but in either
> case the
> > > overall 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 escalation, because it
> can
> > > normally only be exploited by someone with write access to the
> filesystem
> > > boots, that is, root.  Only with setuid-root apptainer/singularity
> does it
> > > become a privilege escalation.
> > > >
> > > > I have said that I think that CVE-2022-1184's "Privileges Required"
> was
> > > incorrect.  It was you who suggested USB automounts being available to
> > > users may have been their reason for setting it to "low".  If that's
> what
> > > they meant, then I think it makes perfect sense that they don't count
> that
> > > as a privilege escalation because physical access already gives
> privilege
> > > escalation in much easier ways.  I said that that's probably why they
> only
> > > counted it as denial of service since that was the only thing new.
> > > >
> > > > Dave
> > > >
> >

[EPEL-devel] Re: Bug 2188992 - Please branch and build sscep in epel8

2023-05-10 Thread Troy Dawson 
I just noticed this went to the the wrong mailling list.
Not many people are going to see this on epel-devel-owners.

On Wed, May 10, 2023 at 7:02 AM Stephen Smoogen  wrote:

>
>
> On Wed, 10 May 2023 at 09:46, Troy Dawson  wrote:
>
>> For those EPEL maintainers deciding on whether to take this or not.
>> sscep looks like it is still maintained and active upstream.[1]
>> Although the request bug listed here looks new, there is a much older
>> duplicate bug requesting it. [2]
>> sscep has been orphaned and retired in Fedora, around F31.  The problem
>> with orphaning is that it doesn't tell you why it was orphaned.
>>
>
> Going from the emails I could find, it was the reason you outlined. At
> that time it was needing a version of openssl we were no longer going to
> support for security reasons.
>
>
>> But if we try to build the latest Fedora version on epel8, it's easy to
>> see that it requires compat-openssl10-devel.  In other words, at the time,
>> it wasn't compatible with the latest openssl.
>> That has been fixed upstream.
>> So whoever takes it will need to update the rpm to the latest upstream.
>>
>> I'm not trying to discourage anyone from taking this package.  It's
>> maintained upstream, so that's good.  I'm just letting ya'll know what will
>> be involved.
>>
>>
> Troy
>>
>> [1] - https://github.com/certnanny/sscep
>> [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1741770
>>
>>
>>
>> On Wed, May 10, 2023 at 5:00 AM Kiran Suresh 
>> wrote:
>>
>>> Dear EPEL Community,
>>>
>>>
>>>
>>> Hope this email finds you well. I am writing to request your assistance
>>> with SSCEP package for EL8, looking for a packagers who would like to
>>> package and maintain SSCEP package on epel..
>>>
>>>
>>>
>>> We would like to request your help in addressing this issue so that we
>>> can proceed to utilize the package. If there are any packagers who would be
>>> willing to take over the maintenance of SSCEP package, we would be grateful
>>> for your support.
>>>
>>>
>>>
>>> We have submitted a bug for this request, and have not received any
>>> response on this.
>>>
>>>
>>>
>>> Here are some additional details about package request:
>>>
>>>
>>>
>>> Bug ID: 2188992
>>> Link to Bug: 2188992 – Please branch and build sscep in epel8
>>> (redhat.com) 
>>>
>>> Package name: sscep-0.6.1-5.20160525
>>>
>>> Purpose: Simple SCEP client
>>>
>>> Package for EL7: sscep-0.6.1-5.20160525git2052ee1.el7.src.rpm
>>>
>>>
>>>
>>> If someone from the community could pick up this bug and work on it, we
>>> would be more than happy to provide any additional information or
>>> assistance needed to resolve the issue. We believe that this package would
>>> be a valuable addition to the EPEL repository and would appreciate your
>>> help in making it available to others.
>>>
>>>
>>>
>>> Thank you for your time and consideration, and we look forward to
>>> hearing from you soon.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Thanks
>>>
>>> Kiran
>>>
>>> *Kiran Kumar Suresh*
>>>
>>> *TSS Infrastructure | *ksur...@vexcelco.com *| Mobile: (203) 822 3689*
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Ansible in EPEL 9

2023-05-10 Thread Josh Boyer 
On Tue, May 9, 2023 at 11:24 PM Maxwell G  wrote:
>
> Hello EPEL users and developers,
>
>
> RHEL 9.2 was released today,
> so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
> 9.2's ansible-core bump from 2.13.3 to 2.14.2.
> Each ansible major version is tied to a specific major version of
> ansible-core, and we keep them in sync.
>
> Along with this change, RHEL 9.2 builds ansible-core for the python3.11
> stack instead of the default python3 (3.9) stack.
> Therefore, ansible in EPEL now built for python3.11 as well.
>
> Here is the Bodhi update: 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1
> Please help test and give karma.

Thank you for your efforts and clear communication!  It is very much
appreciated.

josh

>
> Until this update is pushed to stable, you may receive an error like
> this when running dnf upgrade
>
> ```
> Error:
>  Problem: package ansible-6.3.0-2.el9.noarch requires 
> python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be 
> installed
>   - cannot install both ansible-core-2.14.2-4.el9.x86_64 and 
> ansible-core-2.13.3-2.el9_1.x86_64
>   - cannot install both ansible-core-2.14.2-4.el9.x86_64 and 
> ansible-core-2.13.3-1.el9.x86_64
>   - cannot install the best update candidate for package 
> ansible-core-2.13.3-2.el9_1.x86_64
>   - cannot install the best update candidate for package 
> ansible-6.3.0-2.el9.noarch
> (try to add '--allowerasing' to command line to replace conflicting packages 
> or '--skip-broken' to skip uninstallable packages or '--nobest' to use not 
> only best candidate packages)
> ```
>
> There are a couple potential solutions:
>
> 1. Run
>  $ dnf upgrade --exclude ansible-core
>to skip ansible-core and upgrade everything else.
> 2. In a couple hours from from now (now is 3:15 UTC), you'll be able to 
> install
>ansible 7.2.0 from testing with
>  $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
>and then run a plain `dnf upgrade` as usual.
>
>
> --
> Happy automating,
>
>
> Maxwell G (@gotmax23)
> Pronouns: He/They
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> 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/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue