proftp-user — User support list for ProFTPD

Re: [Proftpd-user] can't connect to mariadb database, when the user requires SSL after update from 1.3.9 to 1.3.9a

[Dieter B. <pr...@bl...>]

Hi,

On Fri, May 01, Preuße, Hilmar via Proftp-user wrote:

> Am 30.04.2026 um 17:54 schrieb TJ Saunders:
> 
> Hello,
> 
> > When developing that patch to use the newer, non-deprecated APIs, I
> > verified locally against a MySQL database, using libmysqlclient, but
> > did not think to try using libmariadb and a MariaDB.  This
> > difference in behavior makes me wonder what the libmariadb
> > implementations, old and new, might look like.  I would have
> > expected that configuring the trusted CAs would (and should) have
> > been required from the beginning, regardless of the internal API
> > change in 1.3.9a.
> > 
> Thanks for explanation. So, what I understand it is quite unsure, why it
> happened now not earlier. Anyway I'll drop a note in the debian/NEWS file
> just any case anybody else runs into the issue. The OP did not mention a
> MariaDB change or something.

there was no change in the environment.
So it looks to me like the commit TJ mentioned caused the unexpected
behavior.

Till version 1.3.9 I didn't have to add the "ssl-ca:/etc/ssl/certs"
phrase to SQLConnectInfo

-- 
Regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.

Re: [Proftpd-user] can't connect to mariadb database, when the user requires SSL after update from 1.3.9 to 1.3.9a

[Preuße, H. <hi...@we...>]

Am 30.04.2026 um 17:54 schrieb TJ Saunders:

Hello,

> When developing that patch to use the newer, non-deprecated APIs, I
> verified locally against a MySQL database, using libmysqlclient, but
> did not think to try using libmariadb and a MariaDB.  This
> difference in behavior makes me wonder what the libmariadb
> implementations, old and new, might look like.  I would have
> expected that configuring the trusted CAs would (and should) have
> been required from the beginning, regardless of the internal API
> change in 1.3.9a.
> 
Thanks for explanation. So, what I understand it is quite unsure, why it 
happened now not earlier. Anyway I'll drop a note in the debian/NEWS 
file just any case anybody else runs into the issue. The OP did not 
mention a MariaDB change or something.

Hilmar

Re: [Proftpd-user] can't connect to mariadb database, when the user requires SSL after update from 1.3.9 to 1.3.9a

[TJ S. <tj...@ca...>]

>> >> There was a change to the mod_sql_mysql implementation with regards to configuring the client side TLS setup, for connecting via TLS to a MySQL/MariaDB; see:
>> >>
>> >>    https://github.com/proftpd/proftpd/issues/340
>> >>    https://github.com/proftpd/proftpd/commit/89becd5eee7dc857580addd71459655cc59d507b
>> >>
>> >> However, there was no intended change of user-visible behavior; the goal was simply to use the newer API provided by the client library in order to maintain the same TLS behavior.
>> >>
>> >> I'll try to reproduce the behavior you're seeing locally, try to narrow down what might be happening.
>> > 
>> > Thank you for the hint.
>> > After I added ssl-ca:/etc/ssl/certs to the SQLConnectInfo line,
>> > the mysql connection is encrypted and I can login to the mariadb.
>> > 
>> > Thank you very much for the link to the commit
>> > 
>> 
>> Is that new in proftp 1.3.9a in comparison to 1.3.9? I.e. should I 
>> mention that in the NEWS file?
>> 
>> Thanks,
>>    Hilmar
>
> I kind of have to chip in now, because:
>
> - this was already the case in 1.3.9 and I think even in some late 
> 1.3.8x version (I may be wrong on the last one)
> - this is not MariaDB-exclusive, I have had that with an Percona XtraDB 
> cluster as well

Correct.  Support for configuring the TLS setup in the SQLConnectInfo directive has been present since ProFTPD 1.3.6rc2; see:

  http://bugs.proftpd.org/show_bug.cgi?id=4200

What changed between 1.3.9 and 1.3.9a here is the internal MySQL/MariaDB client library API used to configure that TLS support, when connecting to the database.  I don't know why the original reporter's existing configuration worked, but did not after updating to 1.3.9a; that suggests that the client library used itself had some implementation differences.

When developing that patch to use the newer, non-deprecated APIs, I verified locally against a MySQL database, using libmysqlclient, but did not think to try using libmariadb and a MariaDB.  This difference in behavior makes me wonder what the libmariadb implementations, old and new, might look like.  I would have expected that configuring the trusted CAs would (and should) have been required from the beginning, regardless of the internal API change in 1.3.9a.

Cheers,
TJ

Re: [Proftpd-user] can't connect to mariadb database, when the user requires SSL after update from 1.3.9 to 1.3.9a

[Malte S. <m...@ma...>]

Am Donnerstag, April 30, 2026 14:39 CEST, schrieb Preuße, Hilmar via Proftp-user <pro...@li...>:

> Am 29.04.2026 um 07:39 schrieb Dieter Bloms via Proftp-user:
> > On Tue, Apr 28, TJ Saunders wrote:
> 
> Hello,
> 
> >> There was a change to the mod_sql_mysql implementation with regards to configuring the client side TLS setup, for connecting via TLS to a MySQL/MariaDB; see:
> >>
> >>    https://github.com/proftpd/proftpd/issues/340
> >>    https://github.com/proftpd/proftpd/commit/89becd5eee7dc857580addd71459655cc59d507b
> >>
> >> However, there was no intended change of user-visible behavior; the goal was simply to use the newer API provided by the client library in order to maintain the same TLS behavior.
> >>
> >> I'll try to reproduce the behavior you're seeing locally, try to narrow down what might be happening.
> > 
> > Thank you for the hint.
> > After I added ssl-ca:/etc/ssl/certs to the SQLConnectInfo line,
> > the mysql connection is encrypted and I can login to the mariadb.
> > 
> > Thank you very much for the link to the commit
> > 
> 
> Is that new in proftp 1.3.9a in comparison to 1.3.9? I.e. should I 
> mention that in the NEWS file?
> 
> Thanks,
>    Hilmar

I kind of have to chip in now, because:

- this was already the case in 1.3.9 and I think even in some late 1.3.8x version (I may be wrong on the last one)
- this is not MariaDB-exclusive, I have had that with an Percona XtraDB cluster as well

Best regards,

M

Re: [Proftpd-user] can't connect to mariadb database, when the user requires SSL after update from 1.3.9 to 1.3.9a

[Preuße, H. <hi...@we...>]

Am 29.04.2026 um 07:39 schrieb Dieter Bloms via Proftp-user:
> On Tue, Apr 28, TJ Saunders wrote:

Hello,

>> There was a change to the mod_sql_mysql implementation with regards to configuring the client side TLS setup, for connecting via TLS to a MySQL/MariaDB; see:
>>
>>    https://github.com/proftpd/proftpd/issues/340
>>    https://github.com/proftpd/proftpd/commit/89becd5eee7dc857580addd71459655cc59d507b
>>
>> However, there was no intended change of user-visible behavior; the goal was simply to use the newer API provided by the client library in order to maintain the same TLS behavior.
>>
>> I'll try to reproduce the behavior you're seeing locally, try to narrow down what might be happening.
> 
> Thank you for the hint.
> After I added ssl-ca:/etc/ssl/certs to the SQLConnectInfo line,
> the mysql connection is encrypted and I can login to the mariadb.
> 
> Thank you very much for the link to the commit
> 

Is that new in proftp 1.3.9a in comparison to 1.3.9? I.e. should I 
mention that in the NEWS file?

Thanks,
   Hilmar

Re: [Proftpd-user] can't connect to mariadb database, when the user requires SSL after update from 1.3.9 to 1.3.9a

[Dieter B. <pr...@bl...>]

Hello,

On Tue, Apr 28, TJ Saunders wrote:

> > I run the proftpd 1.3.9 with a mariadb backend.
> > In the database I force the use of ssl for mysql connection.
> >
> > After an update to version 1.3.9a the user can't login to the datebase
> > anymore.
> >
> > When I disable SSL on database (ALTER USER loginuser@'%' require none),
> > then proftpd can login with the version 1.3.9a.
> >
> > Is there a new parameter I have to the in the proftpd config file
> 
> There was a change to the mod_sql_mysql implementation with regards to configuring the client side TLS setup, for connecting via TLS to a MySQL/MariaDB; see:
> 
>   https://github.com/proftpd/proftpd/issues/340
>   https://github.com/proftpd/proftpd/commit/89becd5eee7dc857580addd71459655cc59d507b
> 
> However, there was no intended change of user-visible behavior; the goal was simply to use the newer API provided by the client library in order to maintain the same TLS behavior.
> 
> I'll try to reproduce the behavior you're seeing locally, try to narrow down what might be happening.

Thank you for the hint.
After I added ssl-ca:/etc/ssl/certs to the SQLConnectInfo line,
the mysql connection is encrypted and I can login to the mariadb.

Thank you very much for the link to the commit

-- 
Regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

Re: [Proftpd-user] can't connect to mariadb database, when the user requires SSL after update from 1.3.9 to 1.3.9a

[TJ S. <tj...@ca...>]

> I run the proftpd 1.3.9 with a mariadb backend.
> In the database I force the use of ssl for mysql connection.
>
> After an update to version 1.3.9a the user can't login to the datebase
> anymore.
>
> When I disable SSL on database (ALTER USER loginuser@'%' require none),
> then proftpd can login with the version 1.3.9a.
>
> Is there a new parameter I have to the in the proftpd config file

Hmm.  This is unexpected.

There was a change to the mod_sql_mysql implementation with regards to configuring the client side TLS setup, for connecting via TLS to a MySQL/MariaDB; see:

  https://github.com/proftpd/proftpd/issues/340
  https://github.com/proftpd/proftpd/commit/89becd5eee7dc857580addd71459655cc59d507b

However, there was no intended change of user-visible behavior; the goal was simply to use the newer API provided by the client library in order to maintain the same TLS behavior.

I'll try to reproduce the behavior you're seeing locally, try to narrow down what might be happening.

Cheers,
TJ

[Proftpd-user] can't connect to mariadb database, when the user requires SSL after update from 1.3.9 to 1.3.9a

[Dieter B. <pr...@bl...>]

Hello,

I run the proftpd 1.3.9 with a mariadb backend.
In the database I force the use of ssl for mysql connection.

After an update to version 1.3.9a the user can't login to the datebase
anymore.

When I disable SSL on database (ALTER USER loginuser@'%' require none),
then proftpd can login with the version 1.3.9a.

Is there a new parameter I have to the in the proftpd config file

proftpd is compiled as follow:

--snip--
# proftpd -V
Compile-time Settings:
  Version: 1.3.9a (maint)
  Platform: LINUX [Linux 5.14.0-687.el9.x86_64 x86_64]
  OS/Release:
    PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
    NAME="Debian GNU/Linux"
    VERSION_ID="12"
    VERSION="12 (bookworm)"
    VERSION_CODENAME=bookworm
    ID=debian
  Built: Di Apr 28 2026 08:45:13 CEST
  Built With:
    configure  '--prefix=/usr' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--localstatedir=/var/lib/proftpd' '--mandir=/usr/share/man' '--disable-sendfile' '--disable-devel' '--disable-auth-pam' '--disable-ident' '--disable-ncurses' '--enable-timeout-idle=3600' '--enable-timeout-no-transfer=3600' '--enable-openssl' '--enable-nls' '--with-modules=mod_sftp:mod_quotatab:mod_quotatab_file:mod_sql:mod_sql_mysql:mod_quotatab_sql:mod_sftp_sql:mod_tls:mod_site_misc:mod_readme:mod_rewrite:mod_exec' 'CFLAGS=-g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong -Wformat -Werror=format-security'
 
  CFLAGS: -g2 -g -O2 -fdebug-prefix-map=/tmp=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-omit-frame-pointer -fno-strict-aliasing
  LDFLAGS: -Wl,-L$(top_srcdir)/lib,-L$(top_builddir)/lib -Wl,-z,relro -Wl,-z,now -rdynamic  -L/usr/lib/x86_64-linux-gnu/
  LIBS:  -lssl -lcrypto -lsodium -lssl  -lm -lmysqlclient -lz  -lcrypto -lcrypt  -pthread
 
  Files:
    Configuration File:
      /etc/proftpd.conf
    Pid File:
      /var/lib/proftpd/proftpd.pid
    Scoreboard File:
      /var/lib/proftpd/proftpd.scoreboard
 
  Info:
    + Max supported UID: 4294967295
    + Max supported GID: 4294967295
 
  Features:
    - Autoshadow support
    - Controls support
    - curses support
    - Developer support
    - DSO support
    + IPv6 support
    + Largefile support
    - Lastlog support
    - Memcache support
    - ncurses support
    + NLS support
    + OpenSSL support (OpenSSL 3.0.19 27 Jan 2026)
    - PCRE support
    - PCRE2 support
    - POSIX ACL support
    - Redis support
    - Sendfile support
    + Shadow file support
    + Sodium support
    + Trace support
    + xattr support
 
  Tunable Options:
    PR_TUNABLE_BUFFER_SIZE = 1024
    PR_TUNABLE_DEFAULT_RCVBUFSZ = 65536
    PR_TUNABLE_DEFAULT_SNDBUFSZ = 65536
    PR_TUNABLE_ENV_MAX = 2048
    PR_TUNABLE_GLOBBING_MAX_MATCHES = 100000
    PR_TUNABLE_GLOBBING_MAX_RECURSION = 8
    PR_TUNABLE_HASH_TABLE_SIZE = 40
    PR_TUNABLE_LOGIN_MAX = 256
    PR_TUNABLE_NEW_POOL_SIZE = 512
    PR_TUNABLE_PATH_MAX = 4096
    PR_TUNABLE_SCOREBOARD_BUFFER_SIZE = 80
    PR_TUNABLE_SCOREBOARD_SCRUB_TIMER = 30
    PR_TUNABLE_SELECT_TIMEOUT = 30
    PR_TUNABLE_TIMEOUTIDENT = 10
    PR_TUNABLE_TIMEOUTIDLE = 3600
    PR_TUNABLE_TIMEOUTLINGER = 10
    PR_TUNABLE_TIMEOUTLOGIN = 300
    PR_TUNABLE_TIMEOUTNOXFER = 3600
    PR_TUNABLE_TIMEOUTSTALLED = 3600
    PR_TUNABLE_XFER_SCOREBOARD_UPDATES = 10
--snip--

-- 
Regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

[Proftpd-user] ProFTPD 1.3.9a released!

[TJ S. <tj...@ca...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, ProFTPD community. The ProFTPD Project team is pleased to announce
that the first maintenance release for ProFTPD 1.3.9 is now available for
public consumption.

You can download 1.3.9a, including PGP signatures and SHA256 sums, from GitHub:

  https://github.com/proftpd/proftpd/archive/v1.3.9a.tar.gz

Alternatively, you can download proftpd from the main site:

  ftp://ftp.proftpd.org/distrib/source

The 1.3.9a release is a maintenance release, containing various fixes
backported from the 1.3.10 development cycle.

Please read the included NEWS and RELEASE_NOTES files for the full details.

The SHA256 sum for the source tarball is:

  bc3c7c47033ecff29f010efc18315d5906eb942d2e673ebce0138a96f11af0b4 proftpd-1.3.9a.tar.gz

The PGP signature for the source tarball is:

  proftpd-1.3.9a.tar.gz:

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRpfmhNFmjWloQoQFy3jok/pRGXagUCae/wrgAKCRC3jok/pRGX
    anVRAKC7DksemDuVm42kjbTW3LasjeGrBgCgjBdq78O4fBUem1bZgsQ6doxurzs=
    =d4O2
    -----END PGP SIGNATURE-----

My PGP key has been used to sign the source tarballs as well as this
announcement; it is available via MIT's public keyserver.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQRpfmhNFmjWloQoQFy3jok/pRGXagUCae/w/gAKCRC3jok/pRGX
avpZAJ9Ic84fGSWoUOgjGWgPwg1G90+HIQCg52nhQwdw0/73TEEkrPbnfZkqP8M=
=f8iS
-----END PGP SIGNATURE-----

[Proftpd-user] ProFTPD 1.3.10rc1 released!

[TJ S. <tj...@ca...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, ProFTPD community. The ProFTPD Project team is pleased to
announce that the first release candidate for ProFTPD 1.3.10 is now
available for public consumption.

You can download 1.3.10rc1, including PGP signature, from GitHub:

  https://github.com/proftpd/proftpd/archive/v1.3.10rc1.tar.gz

Alternatively, you can download proftpd from the main site:

  ftp://ftp.proftpd.org/distrib/source

The 1.3.10rc1 release includes major new features and numerous bugfixes,
including:

  + Fix for SQL injection (CVE-2026-42167)
  + Disable Nagle algorithm for FTP data transfers
  + New mod_systemd module for richer systemd interaction

Please read the included NEWS and RELEASE_NOTES files for the full
details.

The SHA256 sum for the source tarball is:

  90e32076f175467771b3fd76e8de83b7692d76118f1db3328635866b74bb3785 proftpd-1.3.10rc1.tar.gz

The PGP signature for the source tarball is:

  proftpd-1.3.10rc1.tar.gz:

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRpfmhNFmjWloQoQFy3jok/pRGXagUCae/prwAKCRC3jok/pRGX
    ak1nAKDCRaI8ma9hsMzXzJgXanHwzTjpWQCgwWgB98MprWssK/W1egRdi2yjDBQ=
    =RNUQ
    -----END PGP SIGNATURE-----

My PGP key has been used to sign the source tarballs as well as this
announcement; it is available via MIT's public keyserver.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQRpfmhNFmjWloQoQFy3jok/pRGXagUCae/qEwAKCRC3jok/pRGX
alRcAKD+27IHT/eKsvu2vuA2+/lisDwcNwCfVDFi0JZShRhWY0ojGk4u0FsvPzE=
=B1V7
-----END PGP SIGNATURE-----

Re: [Proftpd-user] Aging state of ProFTPD Project infrastructure

[<m...@ma...>]

Hi TJ and core team,

I have reached out 2 times on the GitHub Issue tracker and once a couple
months ago via mail, to offer my help to the project and update that very
project infrastructure to modern standards.

If moving things to GitHub makes it better/easier, then I guess why not.

Though sometimes there is actually useful information on the forums of old
software projects such as ProFTPd, especially for legacy setups that get
updated only now or later in time. I would recommend to keep the forums and
an archive-version of the website running, on an updated software stack. I
understand this requires infrastructure, which I believe some companies are
happy to provide to open source projects pro bono. If this is not wanted, at
least I would somehow archive the data (maybe involving archiveteam.org?)
for historical reference. It appears to me that FTP/FTPS/SFTP is far from
dead and we will have to deal with it on an enterprise scale for at least 20
more years (who knows...).

Glad to see some movement here. Let me know what I can do, I would like to
support the project. From the other mails I see there are people wanting to
step in. Would be great to organize a little!

Best regards

-----Ursprüngliche Nachricht-----
Von: William David Edwards via Proftp-user
<pro...@li...> 
Gesendet: Dienstag, 7. April 2026 19:40
An: pro...@li...; tj...@ca...
Cc: William David Edwards <wed...@cy...>; ProFTPD Developers
<pro...@li...>
Betreff: Re: [Proftpd-user] Aging state of ProFTPD Project infrastructure

Hi TJ,

TJ Saunders schreef op 2026-04-07 19:25:
> As many of you are aware, the state of the ProFTPD Project's 
> infrastructure is in desperate need of maintenance/upgrading.  The VMs 
> which host the project's website, Bugzilla instance, forums, FTP 
> downloads, etc are all quite old -- this is why, for example, the 
> website, Bugzilla, forums currently do not have great HTTPS support.
> (The underlying VM image has an OpenSSL package which predates 
> TLSv1.2, among other things.)
> 
> These VMs are currently running in a provider's network, which has 
> been quite generous in allowing these to run.  However, that provider 
> has gone through different company acquisitions; the fact that the VMs 
> are still running is, honestly, more by luck than by intention.  Now, 
> the current company has indicated that these VMs _will_ be shut down 
> by September of this year, if not sooner.
> 
> I know that maintaining infrastructure, in my spare time, is not very 
> appealing -- I have to do it too much already for my day job.  No 
> excuses, just commenting on why nothing really has been done on this 
> front.  But now we have a forcing function.
> 
> The project core team has discussed this situation.  Right now, we are 
> leaning toward shutting down the website, Bugzilla, and forums, and 
> relying on the existing GitHub repo for most needs.  Most bug 
> reports/issues are already filed there, and there have been no 
> significant forums postings for more than a year now.  Most modern 
> browsers are unhappy about the plain HTTP website, and update the lack 
> of TLSv1.2 certificates for the forums.
> 
> This all demonstrates that GitHub meets most of the project needs with 
> regard to infrastructure.  It also means fewer moving parts for future 
> maintainers of the project to maintain, going forward.
> 
> With this in mind, I'd like to solicit your thoughts/feedback on what 
> sort of things you'd want to see in the GitHub repo (if anything), 
> knowing that these changes are coming.  Feel free to respond to me 
> personally if you prefer.
> 
> I don't have any particular dates/times when we'll shut those VMs down 
> (other than before September), but it'll be happening this year, one 
> way or another.
> 

I think it makes perfect sense to move downloads & bug tracker to GitHub.

I do however believe that having a website is still very useful for a mature
project. The same case could be made for forums, having multiple potential
communication channels for interaction with other users. 
People may not want to sign up to GitHub.

If you need a VM to that purpose, feel free to give us - a hosting company
from Europe - a shout off-list.

> Cheers,
> TJ
> 
> 
> _______________________________________________
> ProFTPD Users List   <pro...@pr...>
> Unsubscribe problems?
> http://www.proftpd.org/list-unsub.html

Met vriendelijke groeten,

William David Edwards



_______________________________________________
ProFTPD Users List   <pro...@pr...>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

Re: [Proftpd-user] Aging state of ProFTPD Project infrastructure

[William D. E. <wed...@cy...>]

Hi TJ,

TJ Saunders schreef op 2026-04-07 19:25:
> As many of you are aware, the state of the ProFTPD Project's 
> infrastructure is in desperate need of maintenance/upgrading.  The VMs 
> which host the project's website, Bugzilla instance, forums, FTP 
> downloads, etc are all quite old -- this is why, for example, the 
> website, Bugzilla, forums currently do not have great HTTPS support.  
> (The underlying VM image has an OpenSSL package which predates TLSv1.2, 
> among other things.)
> 
> These VMs are currently running in a provider's network, which has been 
> quite generous in allowing these to run.  However, that provider has 
> gone through different company acquisitions; the fact that the VMs are 
> still running is, honestly, more by luck than by intention.  Now, the 
> current company has indicated that these VMs _will_ be shut down by 
> September of this year, if not sooner.
> 
> I know that maintaining infrastructure, in my spare time, is not very 
> appealing -- I have to do it too much already for my day job.  No 
> excuses, just commenting on why nothing really has been done on this 
> front.  But now we have a forcing function.
> 
> The project core team has discussed this situation.  Right now, we are 
> leaning toward shutting down the website, Bugzilla, and forums, and 
> relying on the existing GitHub repo for most needs.  Most bug 
> reports/issues are already filed there, and there have been no 
> significant forums postings for more than a year now.  Most modern 
> browsers are unhappy about the plain HTTP website, and update the lack 
> of TLSv1.2 certificates for the forums.
> 
> This all demonstrates that GitHub meets most of the project needs with 
> regard to infrastructure.  It also means fewer moving parts for future 
> maintainers of the project to maintain, going forward.
> 
> With this in mind, I'd like to solicit your thoughts/feedback on what 
> sort of things you'd want to see in the GitHub repo (if anything), 
> knowing that these changes are coming.  Feel free to respond to me 
> personally if you prefer.
> 
> I don't have any particular dates/times when we'll shut those VMs down 
> (other than before September), but it'll be happening this year, one 
> way or another.
> 

I think it makes perfect sense to move downloads & bug tracker to 
GitHub.

I do however believe that having a website is still very useful for a 
mature project. The same case could be made for forums, having multiple 
potential communication channels for interaction with other users. 
People may not want to sign up to GitHub.

If you need a VM to that purpose, feel free to give us - a hosting 
company from Europe - a shout off-list.

> Cheers,
> TJ
> 
> 
> _______________________________________________
> ProFTPD Users List   <pro...@pr...>
> Unsubscribe problems?
> http://www.proftpd.org/list-unsub.html

Met vriendelijke groeten,

William David Edwards

[Proftpd-user] Aging state of ProFTPD Project infrastructure

[TJ S. <tj...@ca...>]

As many of you are aware, the state of the ProFTPD Project's infrastructure is in desperate need of maintenance/upgrading.  The VMs which host the project's website, Bugzilla instance, forums, FTP downloads, etc are all quite old -- this is why, for example, the website, Bugzilla, forums currently do not have great HTTPS support.  (The underlying VM image has an OpenSSL package which predates TLSv1.2, among other things.)

These VMs are currently running in a provider's network, which has been quite generous in allowing these to run.  However, that provider has gone through different company acquisitions; the fact that the VMs are still running is, honestly, more by luck than by intention.  Now, the current company has indicated that these VMs _will_ be shut down by September of this year, if not sooner.

I know that maintaining infrastructure, in my spare time, is not very appealing -- I have to do it too much already for my day job.  No excuses, just commenting on why nothing really has been done on this front.  But now we have a forcing function.

The project core team has discussed this situation.  Right now, we are leaning toward shutting down the website, Bugzilla, and forums, and relying on the existing GitHub repo for most needs.  Most bug reports/issues are already filed there, and there have been no significant forums postings for more than a year now.  Most modern browsers are unhappy about the plain HTTP website, and update the lack of TLSv1.2 certificates for the forums.

This all demonstrates that GitHub meets most of the project needs with regard to infrastructure.  It also means fewer moving parts for future maintainers of the project to maintain, going forward.

With this in mind, I'd like to solicit your thoughts/feedback on what sort of things you'd want to see in the GitHub repo (if anything), knowing that these changes are coming.  Feel free to respond to me personally if you prefer.

I don't have any particular dates/times when we'll shut those VMs down (other than before September), but it'll be happening this year, one way or another.

Cheers,
TJ

Re: [Proftpd-user] running proftp under non-privileged user

[Matus U. - f. <uh...@fa...>]

>> So, it has to be owned by the running user, or at readable it we relax the
>> permission check:
>>
>> SFTPOptions InsecureHostKeyPerms
>> SFTPHostKey /etc/proftpd/ssh_host_rsa_key
>>
>> It works although complains in log as well:
>>
>> Mar 20 15:54:37 server proftpd[175306]: Checking syntax of
>> configuration file
>> Mar 20 15:54:37 server proftpd[175306]: 2026-03-20 15:54:37,411 server
>> proftpd[175306]: mod_sftp/1.1.1: unable to use
>> '/etc/proftpd/ssh_host_rsa_key' as host key, as it is group- or
>> world-accessible

On 21.03.26 10:30, TJ Saunders wrote:
> Even with "SFTPOptions InsecureHostKeyPerms", I wanted to log something, at 
> config parse time, so that admins would be aware of the insecure 
> permissions on those files.  Perhaps that is overkill?  At the very least, 
> I will change the log level from NOTICE to INFO (perhaps DEBUG?), and 
> change the wording to be more accurate, as "unable to use" when, in fact, 
> the key _is_ used is wrong.

That makes sense, thanks for explanation.

-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Remember half the people you know are below average.

Re: [Proftpd-user] running proftp under non-privileged user

[TJ S. <tj...@ca...>]

> So, it has to be owned by the running user, or at readable it we relax the 
> permission check:
>
> SFTPOptions InsecureHostKeyPerms
> SFTPHostKey /etc/proftpd/ssh_host_rsa_key
>
> It works although complains in log as well:
>
> Mar 20 15:54:37 server proftpd[175306]: Checking syntax of 
> configuration file
> Mar 20 15:54:37 server proftpd[175306]: 2026-03-20 15:54:37,411 server 
> proftpd[175306]: mod_sftp/1.1.1: unable to use 
> '/etc/proftpd/ssh_host_rsa_key' as host key, as it is group- or 
> world-accessible

Even with "SFTPOptions InsecureHostKeyPerms", I wanted to log something, at config parse time, so that admins would be aware of the insecure permissions on those files.  Perhaps that is overkill?  At the very least, I will change the log level from NOTICE to INFO (perhaps DEBUG?), and change the wording to be more accurate, as "unable to use" when, in fact, the key _is_ used is wrong.

Cheers,
TJ

Re: [Proftpd-user] running proftp under non-privileged user

[Matus U. - f. <uh...@fa...>]

Of course I forgot:

- SFTPHostKey must be readable by unauthorized user as well.

So, it has to be owned by the running user, or at readable it we relax the 
permission check:

SFTPOptions InsecureHostKeyPerms
SFTPHostKey /etc/proftpd/ssh_host_rsa_key

It works although complains in log as well:

Mar 20 15:54:37 server proftpd[175306]: Checking syntax of configuration file
Mar 20 15:54:37 server proftpd[175306]: 2026-03-20 15:54:37,411 server proftpd[175306]: mod_sftp/1.1.1: unable to use '/etc/proftpd/ssh_host_rsa_key' as host key, as it is group- or world-accessible
Mar 20 15:54:37 server proftpd[175308]: 2026-03-20 15:54:37,433 server proftpd[175308]: mod_sftp/1.1.1: unable to use '/etc/proftpd/ssh_host_rsa_key' as host key, as it is group- or world-accessible
Mar 20 15:54:37 server systemd[1]: Started proftpd.service - ProFTPD FTP Server.

Perhaps we could have "RelaxedHostKeyPerms" option?


On 20.03.26 16:33, Matus UHLAR - fantomas wrote:
>It did help, I'd like to add a few points:
>
>- mod_vroot can be used to simulate chroot when not running proftpd as root
>  You can enable is using:
>
>  LoadModule mod_vroot.c
>  VRootEngine on
>  and by using DefaultRoot directive.
>
>Link: http://www.castaglia.org/proftpd/modules/mod_vroot.html
>(btw: why can't I find this module in proftpd.org?)
>
>
>- init/rc script or systemd unit can be modified to execute proftpd 
>under   given user instead of (or in affition to) using User and Group 
>directives
>  (works here)
>
>- having log directory (e.g. /var/log/proftpd) and run directory (e.g.    
>/run/proftpd) writable by proftpd makes it easier to fullfill writable   
>requirements for:
>
>  PidFile
>  ScoreboardFile
>  DelayTable   TransferLog   SystemLog
>  ServerLog
>  SFTPLog
>
>  and others.
>- logrotate script should be changed to create log file(s) as configured user
>  ...or not create the file and let proftpd do that
>
>- systemd unit must be configured to use pid file configured above
>
>- use:
>
>  AuthOrder       mod_auth_file.c*
>
>  to skip system authentication
>  (not sure if the * is required, but shouldn't hurt)
>
>
>- In case of using virtual hosts, many of directives should be either   
>repeated in <VirtualHost> or placed into <Global> secion, because
>  of how Proftpd's virtual hosts work.
>
>  This applies to directives mentioned above or in referenced document
>  http://www.proftpd.org/docs/howto/Nonroot.html
>
>  SystemLog
>  WtmpLog
>  TransferLog
>  AuthUserFile
>  AuthGroupFile
>  AuthPAM
>  AuthOrder
>  VRootEngine
>  DefaultRoot
>     ...and all other directives applicable in <VirtualHost> anf 
><Global>   context.

-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Atheism is a non-prophet organization.

Re: [Proftpd-user] running proftp under non-privileged user

[Matus U. - f. <uh...@fa...>]

>> Did anyone try to run ProFTPD completely under pon-privileged user?
>>
>> I guess It would need:
>>
>> - changing init script/systemd unit
>>    (directive User doesn't prevent from being able to setuid() etc)
>> - using mod_vroot
>>
>> - listen on port>1024
>> - non-system user database (I guess even for single anonymous user)
>> - setting paths/permissions for log, lock, pid files
>>
>> Does it need any changes more than that?
>> Does it work?

On 13.03.26 09:24, TJ Saunders wrote:
>It can be done, yes -- depending on the desired configuration, of course.  
> This might help:
>
>  http://www.proftpd.org/docs/howto/Nonroot.html

It did help, I'd like to add a few points:

- mod_vroot can be used to simulate chroot when not running proftpd as root
   You can enable is using:

   LoadModule mod_vroot.c
   VRootEngine on
   
   and by using DefaultRoot directive.

Link: http://www.castaglia.org/proftpd/modules/mod_vroot.html
(btw: why can't I find this module in proftpd.org?)


- init/rc script or systemd unit can be modified to execute proftpd under 
   given user instead of (or in affition to) using User and Group directives
   (works here)

- having log directory (e.g. /var/log/proftpd) and run directory (e.g.  
   /run/proftpd) writable by proftpd makes it easier to fullfill writable 
   requirements for:

   PidFile
   ScoreboardFile
   DelayTable 
   TransferLog 
   SystemLog
   ServerLog
   SFTPLog

   and others.
   
- logrotate script should be changed to create log file(s) as configured user
   ...or not create the file and let proftpd do that

- systemd unit must be configured to use pid file configured above

- use:

   AuthOrder       mod_auth_file.c*

   to skip system authentication
   (not sure if the * is required, but shouldn't hurt)


- In case of using virtual hosts, many of directives should be either 
   repeated in <VirtualHost> or placed into <Global> secion, because
   of how Proftpd's virtual hosts work.

   This applies to directives mentioned above or in referenced document
   http://www.proftpd.org/docs/howto/Nonroot.html

   SystemLog
   WtmpLog
   TransferLog
   AuthUserFile
   AuthGroupFile
   AuthPAM
   AuthOrder
   VRootEngine
   DefaultRoot
   
   ...and all other directives applicable in <VirtualHost> anf <Global> 
   context.

-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I drive way too fast to worry about cholesterol.

Re: [Proftpd-user] is it possible to deactivate the support for dsa keys

[Dieter B. <pr...@bl...>]

Hello TJ,

On Mon, Mar 16, TJ Saunders wrote:

> > I would like to disable DSA Key support so that no user can use
> > this key type anymore.
> > Is it possible to disable this via the configuration?
> 
> I'm assuming this is referring to SSH public key authentication?  If so, you should be able to use the SFTPPublicKeys directive to configure the list of algorithms you'd like, omitting the DSA algorithm, i.e. "ssh-dss"; see:
> 
>   http://www.proftpd.org/docs/contrib/mod_sftp.html#SFTPAuthPublicKeys
> 
> Hope this helps,

Yes, this will help.
Thank you for the hind!


-- 
Regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

Re: [Proftpd-user] is it possible to deactivate the support for dsa keys

[TJ S. <tj...@ca...>]

> I would like to disable DSA Key support so that no user can use
> this key type anymore.
> Is it possible to disable this via the configuration?

I'm assuming this is referring to SSH public key authentication?  If so, you should be able to use the SFTPPublicKeys directive to configure the list of algorithms you'd like, omitting the DSA algorithm, i.e. "ssh-dss"; see:

  http://www.proftpd.org/docs/contrib/mod_sftp.html#SFTPAuthPublicKeys

Hope this helps,
TJ

[Proftpd-user] is it possible to deactivate the support for dsa keys

[Dieter B. <pr...@bl...>]

Hello,

I would like to disable DSA Key support so that no user can use
this key type anymore.
Is it possible to disable this via the configuration?


-- 
Regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

Re: [Proftpd-user] running proftp under non-privileged user

[Matus U. - f. <uh...@fa...>]

>> Did anyone try to run ProFTPD completely under pon-privileged user?
>>
>> I guess It would need:
>>
>> - changing init script/systemd unit
>>    (directive User doesn't prevent from being able to setuid() etc)
>> - using mod_vroot
>>
>> - listen on port>1024
>> - non-system user database (I guess even for single anonymous user)
>> - setting paths/permissions for log, lock, pid files
>>
>> Does it need any changes more than that?
>> Does it work?

On 13.03.26 09:24, TJ Saunders wrote:
>It can be done, yes -- depending on the desired configuration, of course.  This might help:
>
>  http://www.proftpd.org/docs/howto/Nonroot.html

Oh my... I completely missed that.
Thanks!
-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Chernobyl was an Windows 95 beta test site.

Re: [Proftpd-user] running proftp under non-privileged user

[TJ S. <tj...@ca...>]

> Did anyone try to run ProFTPD completely under pon-privileged user?
>
> I guess It would need:
>
> - changing init script/systemd unit
>    (directive User doesn't prevent from being able to setuid() etc)
> - using mod_vroot
>
> - listen on port>1024
> - non-system user database (I guess even for single anonymous user)
> - setting paths/permissions for log, lock, pid files 
>
> Does it need any changes more than that?
> Does it work?

It can be done, yes -- depending on the desired configuration, of course.  This might help:

  http://www.proftpd.org/docs/howto/Nonroot.html

Cheers,
TJ

[Proftpd-user] running proftp under non-privileged user

[Matus U. - f. <uh...@fa...>]

Hello,

Did anyone try to run ProFTPD completely under pon-privileged user?

I guess It would need:

- changing init script/systemd unit
   (directive User doesn't prevent from being able to setuid() etc)
- using mod_vroot

- listen on port>1024
- non-system user database (I guess even for single anonymous user)
- setting paths/permissions for log, lock, pid files 

Does it need any changes more than that?
Does it work?

-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows found: (R)emove, (E)rase, (D)elete

Re: [Proftpd-user] mod_auth_web

[John S. <jo...@st...>]

>>>>> "Brad" == Brad Knorr <br...@kn...> writes:

> Trying to understand,

Trying to help!  :-)  Hopefully this isn't totally off the wall or
redundant.  But it would also help if you post your configuration
settings so we can look them over as well. 

> So the basic functionality of this module is to receive two parameters
> Username and password.  If the endpoint returns a 200, we are good, if it returns
> 403 we are not good.  Pretty simple.

Yup.  I admit I don't use this, so I'm curious how you configure
this.  I assume following the examples in the docs? 

> Where I am struggling, is about how to direct proftp to allow the
> permitted user to only access their files.

So are these real system users or virtual users?  If they're virtual
users, you should just have them isolated to their own directory tree
using the option:

      DefaultRoot ~

which will lock them into their home directory.  So you might need to
add this info into your mod_auth_web setup, so that the lookup returns
a 200 code with the directory to use for that user.  I personally just use
local group and passwd files in a seperate proftpd only area, setup in
the <global> block:

   <global>
     # That '*' makes that module authoritative and prevents proftpd from
     # falling through to system logins, etc
     RequireValidShell off
     AuthOrder mod_auth_file.c*
     AuthUserFile /ftp/etc/passwd
     AuthGroupFile /ftp/etc/group

     <Directory /ftp/customers>
       HideNoAccess on
     </Directory>
   </global>

But I also have to configure a per-user cfg file that gives the
various access permissions.  All the files are owned by a single
account, but proftpd does all the work of keeping stuff seperate from
each other.

So my main proftpd.conf file I have:

  # Per-user configuration files, not server setup configs, must be generated for each user.
  Include /ftp/etc/customers/*.cfg

And an exmaple file looks like this:

    $ cat /ftp/etc/customers/customer.cfg
   <Directory /ftp/customers/customer>
     HideNoAccess on
     <Limit ALL>
       DenyAll
     </Limit>
     <Limit INFO REALPATH LSTAT CWD PWD LIST MLST STAT READ OPENDIR READDIR>
       AllowUser customer
       AllowGroup customer
     </Limit>
   </Directory>

Does this help?


> The files are in a dir structure as follows:

>  

> /userdata/jimmy

>                     /bob

>  

> Jimmy and bobs files have a uid and gid of 1000,1001 respectively.

>  

> How does proftp know which dir to authorized the user to?

>  

> If this mod doesn’t support this, I have a mongo db auth db. If I were to write

> A mod that will auth to mongo, can I send proftpd, this relevant information?

[Proftpd-user] mod_auth_web

[Brad K. <br...@kn...>]

Trying to understand,



So the basic functionality of this module is to receive two parameters

Username and password.  If the endpoint returns a 200, we are good, if it
returns

403 we are not good.  Pretty simple.



Where I am struggling, is about how to direct proftp to allow the permitted
user to only access their files.

The files are in a dir structure as follows:



/userdata/jimmy

                    /bob



Jimmy and bobs files have a uid and gid of 1000,1001 respectively.



How does proftp know which dir to authorized the user to?



If this mod doesn’t support this, I have a mongo db auth db. If I were to
write

A mod that will auth to mongo, can I send proftpd, this relevant
information?



Thanks

Brad