Bug 2161422 - Please create a build of proftpd-1.3.8 for epel8
Summary: Please create a build of proftpd-1.3.8 for epel8
Keywords:
Status: NEW
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: proftpd
Version: epel8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-16 21:45 UTC by Johan Almqvist
Modified: 2024-02-13 07:21 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Johan Almqvist 2023-01-16 21:45:42 UTC
Please create an rpm for the most recent stable version of proftpd, 1.3.8

It has some crucial features needed to manage/disable SSH and SSL ciphers that are considered as weak or vulnerable.

Comment 1 Paul Howarth 2023-01-17 17:29:41 UTC
I'm quite reluctant to do major version updates in existing Fedora/EPEL releases as they might cause behavioural changes for existing users.

However, I do have 1.3.8 builds available in my personal repo here:
http://www.city-fan.org/ftp/contrib/misc/

Another possibility would be to build it in COPR.

Would either of those work for you?

Comment 2 comsec 2024-02-06 19:14:20 UTC
(In reply to Paul Howarth from comment #1)
> I'm quite reluctant to do major version updates in existing Fedora/EPEL
> releases as they might cause behavioural changes for existing users.
> 
> However, I do have 1.3.8 builds available in my personal repo here:
> http://www.city-fan.org/ftp/contrib/misc/
> 
> Another possibility would be to build it in COPR.
> 
> Would either of those work for you?

Since 1.3.6 that is available in epel8 is no more originally patched, can you please confirm that all proftpd epel builds from epel 7 up to epel9 have all security patches backported?

redhat does this by routine with RHEL packages, but it's quite uncommon in EPEL ones.

Regards.

Comment 3 Paul Howarth 2024-02-07 09:03:06 UTC
(In reply to comsec from comment #2)
> Since 1.3.6 that is available in epel8 is no more originally patched, can
> you please confirm that all proftpd epel builds from epel 7 up to epel9 have
> all security patches backported?
> 
> redhat does this by routine with RHEL packages, but it's quite uncommon in
> EPEL ones.

I have addressed all CVEs since 1.3.6 became unsupported upstream.
Sometimes this involved no action because the CVE didn't apply to the EPEL build (see https://bugzilla.redhat.com/show_bug.cgi?id=2255052 for example).

Commit history for EPEL-8:
https://src.fedoraproject.org/rpms/proftpd/commits/epel8

Comment 4 comsec 2024-02-08 20:27:04 UTC
Thank you for confirming this.

While on the other side 1.3.5 that is in epel7 seems to miss at least latest CVE-2023-51713

But yes epel7 is dying on June this year togethere with RHEL7 standard support, even if you can have 4 more years with ELS.

Comment 5 Paul Howarth 2024-02-09 07:13:39 UTC
(In reply to comsec from comment #4)
> While on the other side 1.3.5 that is in epel7 seems to miss at least latest
> CVE-2023-51713

1.3.5 doesn't actually have that vulnerability: see https://bugzilla.redhat.com/show_bug.cgi?id=2255610

Comment 6 comsec 2024-02-12 18:05:21 UTC
Thank you very much for this clarification.
So the CVE declaration is way wrong on proftpd affected versions on this bug.

https://nvd.nist.gov/vuln/detail/CVE-2023-51713#range-10187534
https://www.cve.org/CVERecord?id=CVE-2023-51713

I think that I'll anyway try at least a 1.3.6 build on rhel7 as to have some more safe time after June in case a new CVE emerges.

Comment 7 Paul Howarth 2024-02-13 07:21:09 UTC
(In reply to comsec from comment #6)
> Thank you very much for this clarification.
> So the CVE declaration is way wrong on proftpd affected versions on this bug.
> 
> https://nvd.nist.gov/vuln/detail/CVE-2023-51713#range-10187534
> https://www.cve.org/CVERecord?id=CVE-2023-51713

Looks like whoever reported this CVE didn't look at when it was introduced.

> I think that I'll anyway try at least a 1.3.6 build on rhel7 as to have some more safe time after June in case a new CVE emerges.

If you're going to go with a different version, I'd suggest going with the latest one as you'd also benefit from improved TLS support and other new features. Bear in mind that only 1.3.8 is getting support/fixes from upstream now.


Note You need to log in before you can comment on or make changes to this bug.