Bug 2161422

Summary:	Please create a build of proftpd-1.3.8 for epel8
Product:	[Fedora] Fedora EPEL	Reporter:	Johan Almqvist <johan.almqvist>
Component:	proftpd	Assignee:	Paul Howarth <paul>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	epel8	CC:	comsec, ingvar, paul
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.