+Report forwarded to debian-bugs-dist@lists.debian.org, Francesco Paolo Lovergine <frankie@debian.org>:
+Bug#326799; Package proftpd.
+Full text and rfc822 format available.
+
+Acknowledgement sent to Jens Nachtigall <nachtigall@web.de>:
+New Bug report received and forwarded. Copy sent to Francesco Paolo Lovergine <frankie@debian.org>.
+Full text and rfc822 format available.
Package: proftpd
+Severity: minor
+Tags: l10n patch
+
+Please find a translation of the debconf template into German attached.
+Please copy the file de.po to debian/po/ (I assume your package uses
+po-debconf(7))
+
+Let me know if the templates changes, so that I can adjust the
+translation. Warning translators before uploading the package and
+leaving them a delay for translation updates is the best approach.
+
+"grep Last-Translator debian/po/*po" will give you the needed addresses.
+
+
+-- System Information:
+Debian Release: testing/unstable
+ APT prefers unstable
+ APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
+Architecture: i386 (i686)
+Shell: /bin/sh linked to /bin/bash
+Kernel: Linux 2.6.12
+Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
+
+
+
+ Debian bug tracking system administrator <owner@bugs.debian.org>.
+ Last modified:
+
+ Sun, 11 Sep 2005 10:05:32 UTC
+
+
+
+ Debian Bug tracking system
+ copyright 1999 Darren O. Benham,
+ 1997, 2003 nCipher Corporation Ltd,
+ 1994-7 Ian Jackson.
+
+
--- proftpd-1.2.10.orig/debian/rules
+++ proftpd-1.2.10/debian/rules
@@ -0,0 +1,229 @@
+#!/usr/bin/make -f
+# -*- makefile -*- made with the aid of debmake, by Christoph Lameter,
+
+package = proftpd
+
+SHELL = /bin/bash
+CC = gcc
+#
+# HAVE_OPENSSL is required by mod_sql.c.
+# See #233031 for details.
+#
+CFLAGS := -O3 -Wall -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_OPENSSL -DUSE_LDAP_TLS
+IE := install -m755 -s
+ID := install -m644
+
+# Some special build options
+ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
+ CFLAGS += -g
+ ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
+ IE := install -m755
+ endif
+endif
+
+DH_COMPAT=4
+export DH_COMPAT
+
+# the dbs rules
+TAR_DIR := proftpd-1.2.10
+include debian/scripts/dbs-build.mk
+
+# dpkg-arch rules
+ifeq (,$(DEB_BUILD_GNU_TYPE))
+ include debian/scripts/dpkg-arch.mk
+endif
+
+DOC = usr/share/doc
+MAN = usr/share/man
+
+# This is the suite of modules maintained in debian/, not upstream CVS.
+# To enable mod_pgsql, put it after or in place of mod_mysql.
+# Always keep in order modules. If in doubt ask to #proftpd ...
+#EXTRAMODS = mod_mysql:mod_ratio:
+QUOTAMOD = mod_quotatab:
+EXTRAMODS = mod_ratio:mod_tls:mod_rewrite:mod_radius:mod_wrap:mod_quotatab_file:mod_delay:
+MYSQLMODS = mod_sql:mod_sql_mysql:mod_quotatab_sql:
+PGSQLMODS = mod_sql:mod_sql_postgres:mod_quotatab_sql:
+LDAPMODS = mod_ldap:mod_quotatab_ldap:
+
+# This should be commented out for the build to succeed.
+#DEBUG = -DDEBUG_NOFORK -g3
+
+configure_args := --prefix=/usr --cache-file=../config.cache \
+ --sysconfdir=/etc --localstatedir=/var/run --enable-autoshadow \
+ --with-includes=$(shell pg_config --includedir) \
+ --srcdir=../.. --enable-ipv6 --enable-sendfile
+
+ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
+ configure_args += --build $(DEB_HOST_GNU_TYPE)
+else
+ configure_args += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
+endif
+
+stampdir/build: stampdir/configure $(dh_mak_deps)
+ dh_testdir
+ # The -DLINUX bit is cause ./configure doesnt detect alpha
+ ( cd build-tree/$(TAR_DIR)/build/pam && $(MAKE) all PLATFORM=-DLINUX )
+ ( cd build-tree/$(TAR_DIR)/build/mysql && $(MAKE) proftpd PLATFORM=-DLINUX )
+ ( cd build-tree/$(TAR_DIR)/build/pgsql && $(MAKE) proftpd PLATFORM=-DLINUX )
+ ( cd build-tree/$(TAR_DIR)/build/ldap && $(MAKE) proftpd PLATFORM=-DLINUX )
+ touch stampdir/build
+
+build: stampdir/build
+
+stampdir/configure: $(unpacked) $(patched)
+ for d in pam mysql pgsql ldap ; do mkdir -p build-tree/$(TAR_DIR)/build/$$d/contrib/dist/rpm ; done
+ cd build-tree/$(TAR_DIR)/modules ; for m in mod_{ratio,sql,sqlpw,mysql,pgsql}.c ; do if [ ! -e $$m ] ; then ln -s ../contrib/$$m . ; fi ; done
+
+ ( cd build-tree/$(TAR_DIR)/build/pam && CC="$(CC) -Wall $(CFLAGS) $(DEBUG) -I.. -I../../.." \
+ ../../configure $(configure_args) --with-modules=$(QUOTAMOD)$(EXTRAMODS)mod_readme:mod_ifsession )
+ ( cd build-tree/$(TAR_DIR)/build/mysql && CC="$(CC) -Wall $(CFLAGS) $(DEBUG) -I.. -I../../.." \
+ ../../configure $(configure_args) --with-modules=$(QUOTAMOD)$(MYSQLMODS)$(EXTRAMODS)mod_readme:mod_ifsession )
+ ( cd build-tree/$(TAR_DIR)/build/pgsql && CC="$(CC) -Wall $(CFLAGS) $(DEBUG) -I.. -I../../.." \
+ ../../configure $(configure_args) --with-modules=$(QUOTAMOD)$(PGSQLMODS)$(EXTRAMODS)mod_readme:mod_ifsession )
+ ( cd build-tree/$(TAR_DIR)/build/ldap && CC="$(CC) -Wall $(CFLAGS) $(DEBUG) -I.. -I../../.." \
+ ../../configure $(configure_args) --with-modules=$(QUOTAMOD)$(LDAPMODS)$(EXTRAMODS)mod_readme:mod_ifsession )
+ touch stampdir/configure
+
+clean:
+ dh_testdir
+ dh_clean
+
+ -test -r /usr/share/misc/config.sub && \
+ cp -f /usr/share/misc/config.sub build-tree/$(TAR_DIR)/config.sub
+ -test -r /usr/share/misc/config.guess && \
+ cp -f /usr/share/misc/config.guess build-tree/$(TAR_DIR)/config.guess
+
+ rm -rf stampdir build-tree
+ rm -f stamp-build stamp-configure debian/files.saved debian/files
+ rm -rf build
+ rm -f $$(find . -type l) $$(find . -name "*~" -o -name "*.o")
+ rm -f proftpd config.cache config.log lib/*.a ftpshut Make.rules
+ rm -rf debian/proftpd debian/proftpd-{doc,common,ldap,pgsql,mysql}
+ rm -rf debian/{files*,*substvars*,*.gz} core
+ rm -f debian/proftpd-{mysql,pgsql,ldap}.{postinst,postrm,prerm,config,init}
+ rm -f $$(find * -name "*.orig") modules/mod_ratio.c
+ rm -f contrib/dist/rpm/proftpd.spec
+
+binary-indep: checkroot build
+ dh_testdir
+ dh_clean -k -i
+ dh_installdirs -i $(DOC) -pproftpd-doc
+ dh_installdocs -i debian/copyright
+ dh_installchangelogs -i build-tree/$(TAR_DIR)/ChangeLog
+ rm -f build-tree/$(TAR_DIR)/README.AIX build-tree/$(TAR_DIR)/README.cygwin \
+ build-tree/$(TAR_DIR)/README.FreeBSD build-tree/$(TAR_DIR)/README.Solaris2.5x \
+ build-tree/$(TAR_DIR)/README.Unixware
+ dh_installdocs -i build-tree/$(TAR_DIR)/README* \
+ debian/*.txt \
+ $$(find build-tree/$(TAR_DIR)/doc/* -maxdepth 0 -type f | egrep -v "Get|Show|license") \
+ $$(find build-tree/$(TAR_DIR)/contrib -maxdepth 1 -name "*.html" -type f -maxdepth 1) \
+ build-tree/$(TAR_DIR)/contrib/README.mod_wrap \
+ build-tree/$(TAR_DIR)/contrib/README.ratio build-tree/$(TAR_DIR)/contrib/UPGRADE.mod_sql \
+ build-tree/$(TAR_DIR)/contrib/README.mod_quotatab \
+ build-tree/$(TAR_DIR)/doc/howto \
+ build-tree/$(TAR_DIR)/doc/modules \
+ build-tree/$(TAR_DIR)/doc/faq.html \
+ build-tree/$(TAR_DIR)/doc/Configuration.*
+ dh_installexamples -i build-tree/$(TAR_DIR)/sample-configurations/* build-tree/$(TAR_DIR)/doc/mod_sample.c
+ dh_compress -i
+ dh_fixperms -i
+ dh_installdeb -i
+ dh_gencontrol -i -u-isp
+ dh_md5sums -i
+ dh_fixperms -i
+ dh_builddeb -i
+
+binary-arch: checkroot build
+ dh_testdir
+ dh_clean -k -i
+ dh_installdirs -a $(DOC) $(MAN)
+ dh_installdocs -a debian/copyright
+ dh_installchangelogs -a build-tree/$(TAR_DIR)/ChangeLog
+
+ for t in mysql pgsql ldap ; do \
+ for d in postinst postrm prerm config init ; do \
+ sed -e "s,usr/share/doc/proftpd,usr/share/doc/proftpd-$$t,g" \
+ < debian/proftpd.$$d > debian/proftpd-$$t.$$d ; \
+ done ; \
+ ln -sf proftpd.templates debian/proftpd-$$t.templates ; \
+ done
+
+ for d in pam mysql pgsql ldap ; do \
+ case $$d in \
+ pam) \
+ packagename="proftpd" ;\
+ ;; \
+ *) \
+ packagename="proftpd-$$d" ;\
+ ;; \
+ esac ;\
+ cwd=`pwd` ; \
+ set -e ; \
+ dh_installdirs -p$$packagename etc/pam.d etc/init.d etc/default ;\
+ ( cd build-tree/$(TAR_DIR)/build/$$d && $(MAKE) install-proftpd \
+ rundir=var/run/proftpd \
+ mandir=usr/share/man \
+ sbindir=usr/sbin \
+ bindir=usr/bin \
+ sysconfdir=etc INSTALL=install DESTDIR=$$cwd/debian/$$packagename/ ) ;\
+ rm -f debian/$$packagename/usr/sbin/in.proftpd ;\
+ mkdir -p debian/$$packagename/usr/share/doc/$$packagename/examples ;\
+ cp debian/basic.conf debian/$$packagename/usr/share/doc/$$packagename/examples/proftpd.conf ;\
+ cp debian/welcome.msg debian/$$packagename/usr/share/doc/$$packagename/examples/welcome.msg ;\
+ cp debian/ftpusers debian/$$packagename/etc ;\
+ install -m 755 debian/proftpd.init debian/$$packagename/etc/init.d/proftpd ;\
+ install -m 644 debian/proftpd.pam debian/$$packagename/etc/pam.d/proftpd ;\
+ install -m 644 debian/default debian/$$packagename/etc/default/proftpd ;\
+ done
+
+ dh_installdirs -pproftpd-common usr/bin \
+ usr/share/man usr/share/man/man1 usr/share/man/man5 usr/share/man/man8
+ cwd=`pwd` ;\
+ ( cd build-tree/$(TAR_DIR)/build/pam && $(MAKE) install-utils install-man \
+ rundir=var/run/proftpd \
+ mandir=usr/share/man \
+ sbindir=usr/sbin \
+ bindir=usr/bin \
+ sysconfdir=etc INSTALL=install DESTDIR=$$cwd/debian/proftpd-common/ )
+
+ dh_installdirs -pproftpd-common usr/sbin etc/cron.monthly
+ install debian/ftpusers.5 debian/proftpd-common/usr/share/man/man5/ftpusers.5
+ install debian/proftpd.conf.5 debian/proftpd-common/usr/share/man/man5/proftpd.conf.5
+ install debian/ftpasswd.8 debian/proftpd-common/usr/share/man/man8/ftpasswd.8
+ install build-tree/$(TAR_DIR)/contrib/xferstats.holger-preiss \
+ debian/proftpd-common/usr/sbin/ftpstats
+
+ install -m 755 build-tree/$(TAR_DIR)/contrib/ftpasswd debian/proftpd-common/usr/sbin/ftpasswd
+ install -m 755 build-tree/$(TAR_DIR)/contrib/ftpquota debian/proftpd-common/usr/sbin/ftpquota
+ install -m 755 build-tree/$(TAR_DIR)/contrib/diskuse debian/proftpd-common/usr/sbin/diskuse
+ install -m 755 debian/proftpd.cron.monthly debian/proftpd-common/etc/cron.monthly/proftpd
+ cp debian/ftpstats.8 debian/proftpd-common/usr/share/man/man8
+ cp debian/diskuse.8 debian/proftpd-common/usr/share/man/man8
+
+ dh_installdebconf -a
+ dh_compress -a
+ dh_fixperms -a
+ dh_installdeb -a
+ dh_shlibdeps -a
+ dh_perl -a
+ dh_gencontrol -a -u-isp
+ dh_strip -a
+ dh_md5sums -a
+ dh_fixperms -a
+ dh_builddeb -a
+ if egrep "^DEBUG" debian/rules; then false; fi
+
+binary: binary-indep binary-arch
+
+checkroot:
+ dh_testdir
+ dh_testroot
+
+.PHONY: binary binary-arch binary-indep clean checkroot
+
+tidy:
+ rm -f o *~ debian/*~
+ - cd debian && indent -v mod_mysql.c mod_pgsql.c mod_ratio.c
+ cd debian && makeinfo --no-headers -o mod_mysql.txt mod_mysql.texi
+ cd debian && makeinfo --no-headers -o mod_pgsql.txt mod_pgsql.texi
--- proftpd-1.2.10.orig/debian/proftpd.conf.5
+++ proftpd-1.2.10/debian/proftpd.conf.5
@@ -0,0 +1,27 @@
+.TH PROFTPD.CONF 5 "28 August 2005" "proftpd.conf" "Debian proftpd"
+.SH NAME
+proftpd.conf - Configuration file for ProFTPD
+.SH DESCRIPTION
+The full documentation for
+.B /etc/proftpd.conf
+is maintained as a HTML file in the package
+.B proftpd-doc
+. If a browser like
+.B w2m
+and the
+.B proftpd-doc
+package are properly installed on your system, the command
+.IP
+.B w3m /usr/share/doc/proftpd-doc/Configuration.html
+.PP
+would give you access to the complete manual.
+.PP
+.SH DISCLAIMER
+The whole documentation of proftpd is maintained by the Proftpd Team as a bounce of text files and/or
+HTML pages. A few man pages are written and maintained for Debian by its maintainer
+Francesco P. Lovergine , but the final source of information
+are the upstream documentation, and in some cases the sources.
+.PP
+.SH "SEE ALSO"
+\fBproftpd\fR(8)
+.PP
--- proftpd-1.2.10.orig/debian/proftpd.config
+++ proftpd-1.2.10/debian/proftpd.config
@@ -0,0 +1,19 @@
+#!/bin/sh -e
+
+# Source debconf library.
+. /usr/share/debconf/confmodule
+
+action=$1
+version=$2
+
+db_title ProFTPd configuration
+
+if dpkg --compare-versions "$version" lt "1.2.8-1" ; then
+ if test -f /etc/proftpd.conf ; then
+ db_input critical shared/proftpd/warning || true
+ db_go
+ fi
+fi
+
+db_input high shared/proftpd/inetd_or_standalone || true
+db_go
--- proftpd-1.2.10.orig/debian/NEWS.Debian
+++ proftpd-1.2.10/debian/NEWS.Debian
@@ -0,0 +1,32 @@
+proftpd (1.2.10-16) unstable; urgency=low
+
+ Currently mod_ldap >2.8.14 obsoleted LDAPHomedirOnDemand, it now has a couple of new
+ directives to manage home directories:
+
+ LDAPGenerateHomedir
+ LDAPGenerateHomedirPrefix
+
+ they can be used to create/mount/whatelse home directories on demand.
+ Currently mod_ldap and other contributed modules are heavily under-documented, sources
+ are the last-resort source of information. "Use the Source, Luke!"
+
+ -- Francesco Paolo Lovergine Mon, 6 Jun 2005 14:39:04 +0200
+
+proftpd (1.2.10-1) unstable; urgency=low
+
+ A patch introduced by the old maintainer for mod_ldap and ported up to 1.2.9
+ in Debian has been removed. It was not documented at all indeed, so it should not
+ create problems. Anyway equivalent features can be obtained differently:
+
+ ExecOnEvent core.create-home /path/to/script
+
+ allows the execution of a script on home dir creation. This requires a
+ post-1.2.10 patch which is already integrated in debian edition.
+ Also, mod_ldap_conf and mod_ifsession can be used to allow/deny access to
+ specific LDAP users by IP address.
+
+ Directives dropped are LDAPHomedirOnDemandScript, LDAPCheckAllow, LDAPCheckDeny
+ respectively.
+
+ -- Francesco Paolo Lovergine Sat, 9 Oct 2004 14:39:04 +0200
+
--- proftpd-1.2.10.orig/debian/ftpquota.8
+++ proftpd-1.2.10/debian/ftpquota.8
@@ -0,0 +1,128 @@
+.TH FTPQUOTA "8" "August 2005" "Proftpd" "Proftpd Utilities"
+.SH NAME
+ftpquota \- An utility to manage Proftpd quotas
+.SH SYNOPSIS
+ftpquota [options]
+.SH DESCRIPTION
+This utility can be used to create quota tables and manage their records
+in order to control the mod_quotatab module behavior in Proftpd.
+.SH OPTIONS
+.PP
+The following options describe the type of operation to be performed:
+.TP
+\fB\-\-add\-record\fR
+Create a new record with the specified limits. Any
+limits left unspecified with have their default
+values. This option requires the \fB\-\-name\fR and
+\fB\-\-quota\-type\fR options.
+.TP
+\fB\-\-create\-table\fR
+Create the table if not present. Used to initialize
+a table. The default limit table path is
+"./ftpquota.limittab". The default tally table path is
+"./ftpquota.tallytab".
+.TP
+\fB\-\-delete\-record\fR
+Deletes a quota record from the table. This option
+requires the \fB\-\-name\fR and \fB\-\-quote\-type\fR options.
+.TP
+\fB\-\-show\-records\fR
+Prints out all of the quota records in the table in
+a legible format.
+.TP
+\fB\-\-update\-record\fR
+Updates a quota record with the specified limits. Any
+limits left unspecified will be updated with their
+default value. This option requires the \fB\-\-name\fR and
+\fB\-\-quota\-type\fR options.
+.PP
+The following option describes the type of table on which to operate:
+.TP
+\fB\-\-type\fR
+Specifies a table type to use. The allowable options
+are: "limit" or "tally". This is required.
+.IP
+The following options are used to specify specific quota limits:
+.TP
+\fB\-\-Bu\fR, \fB\-\-bytes\-upload\fR
+Specifies the limit of the number of bytes that may be
+uploaded. Defaults to \fB\-1\fR (unlimited).
+.TP
+\fB\-\-Bd\fR, \fB\-\-bytes\-download\fR
+Specifies the limit of the number of bytes that may be
+downloaded. Defaults to \fB\-1\fR (unlimited).
+.TP
+\fB\-\-Bx\fR, \fB\-\-bytes\-xfer\fR
+Specifies the limit of the number of bytes that may be
+transferred. Note that this total includes uploads,
+downloads, AND directory listings. Defaults to
+\fB\-1\fR (unlimited).
+.TP
+\fB\-\-Fu\fR, \fB\-\-files\-upload\fR
+Specifies the limit of the number of files that may be
+uploaded. Defaults to \fB\-1\fR (unlimited).
+.TP
+\fB\-\-Fd\fR, \fB\-\-files\-download\fR
+Specifies the limit of the number of files that may be
+downloaded. Defaults to \fB\-1\fR (unlimited).
+.TP
+\fB\-\-Fx\fR, \fB\-\-files\-xfer\fR
+Specifies the limit of the number of files that may be
+transferred, including uploads and downloads. Defaults
+to \fB\-1\fR (unlimited).
+.TP
+\fB\-L\fR, \fB\-\-limit\-type\fR
+Specifies the type of limit, "hard" or "soft", of
+the bytes limits. If "hard", any uploaded files that
+push the bytes used counter past the limit will be
+automatically deleted; if "soft", those extra bytes
+will be allowed, but future uploads will be denied.
+This option only makes sense if \fB\-\-type\fR is "limit".
+.TP
+\fB\-N\fR, \fB\-\-name\fR
+Specifies a name for the quota record. This name
+will be the user/login name, group name, or class
+name, depending on the quota type. This option
+is ignored if the quota type specified is "all".
+.HP
+\fB\-P\fR, \fB\-\-per\-session\fR
+Specifies that the quota limit is to be applied only
+to each session, rather than persisting across
+sessions. By default, quotas are persistent.
+Specifies a "quota type" for this record, where
+.TP
+\fB\-Q\fR, \fB\-\-quota\-type\fR
+the type means to which category of FTP users this
+quota will apply. The quota type must be one of:
+"user", "group", "class", or "all".
+.PP
+The following options are miscellaneous:
+.TP
+\fB\-\-help\fR
+Displays this message.
+.TP
+\fB\-\-table\-path\fR
+Specifies the path to a quota table file to use.
+.TP
+\fB\-\-units\fR
+Specifies whether to treats bytes as is, in kilobytes,
+megabytes, or gigabytes. Allowable options are:
+"B" or "byte", "Kb" or "kilo", "Mb" or "mega",
+and "Gb" or "giga". Defaults to "byte".
+.TP
+\fB\-\-verbose\fR
+Toggles more verbose information about the doings of
+the tool as it works.
+.SH AUTHORS
+The Proftpd team. See http://www.proftpd.org/ for information.
+.SH COPYRIGHT
+Copyright (C) 2000-2002 TJ Saunders .
+.P
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+.SH NOTES
+Manual page written for Debian GNU/Linux by
+Francesco P. Lovergine , Aug 2005
+
--- proftpd-1.2.10.orig/debian/proftpd.pam
+++ proftpd-1.2.10/debian/proftpd.pam
@@ -0,0 +1,11 @@
+#%PAM-1.0
+auth required pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
+@include common-auth
+
+# This is disabled because anonymous logins will fail otherwise,
+# unless you give the 'ftp' user a valid shell, or /bin/false and add
+# /bin/false to /etc/shells.
+#auth required pam_shells.so
+
+@include common-account
+@include common-session
--- proftpd-1.2.10.orig/debian/proftpd.templates
+++ proftpd-1.2.10/debian/proftpd.templates
@@ -0,0 +1,26 @@
+Template: shared/proftpd/inetd_or_standalone
+Type: select
+_Choices: inetd, standalone
+Default: standalone
+_Description: Run proftpd from inetd or standalone?
+ ProFTPd can be run either as a service from inetd, or as a standalone
+ server. Each choice has its own benefits. If you have only a few ftp
+ connections per day, it is probably better to run proftp from inetd in
+ order to save resources.
+ .
+ On the other hand, if your ftp site is visited frequently, you should
+ rather run proftp as a standalone server (because with inetd, each
+ time a connection is opened, a new process is spawned).
+
+Template: shared/proftpd/warning
+Type: note
+_Description: Warning on syntax changes in ProFTPd configuration.
+ You are upgrading from a pre-1.2.8 version. Probably you will need
+ to revise your previous configuration to be compliant with
+ current directives. Please, consult documentation available
+ in proftpd-doc and change /etc/proftpd.conf as needed.
+ .
+ Unfortunately, it is nearly impossible for me to convert your setup
+ automatically, but for some elementary issues. You will have to do
+ it yourself. ProFTPd could also be unable to use the resulting
+ configuration, and it would not restart after upgrading.
--- proftpd-1.2.10.orig/debian/scripts/CVS/Root
+++ proftpd-1.2.10/debian/scripts/CVS/Root
@@ -0,0 +1 @@
+:ext:frankie@cvs.alioth.debian.org:/cvsroot/pkg-proftpd
--- proftpd-1.2.10.orig/debian/scripts/CVS/Repository
+++ proftpd-1.2.10/debian/scripts/CVS/Repository
@@ -0,0 +1 @@
+debian/scripts
--- proftpd-1.2.10.orig/debian/scripts/CVS/Entries
+++ proftpd-1.2.10/debian/scripts/CVS/Entries
@@ -0,0 +1,4 @@
+/dbs-build.mk/1.1.1.1/Sat Apr 17 18:16:02 2004//
+/dpkg-arch.mk/1.1.1.1/Sat Apr 17 18:16:02 2004//
+/file2cat/1.1.1.1/Sat Apr 17 18:16:02 2004//
+D
--- proftpd-1.2.10.orig/debian/scripts/dbs-build.mk
+++ proftpd-1.2.10/debian/scripts/dbs-build.mk
@@ -0,0 +1,87 @@
+#!/usr/bin/make -f
+# Separate tarball/patch build system by Adam Heath
+# Modified by Ben Collins
+
+SHELL := /bin/bash -e
+SOURCE_DIR := build-tree
+STAMP_DIR := stampdir
+PATCH_DIR := debian/patches
+
+patched := $(STAMP_DIR)/patch
+unpacked := $(STAMP_DIR)/unpack
+
+ifdef TAR_DIR
+ BUILD_TREE := $(SOURCE_DIR)/$(TAR_DIR)
+else
+ BUILD_TREE := $(SOURCE_DIR)
+endif
+
+
+setup: $(dh_mak_deps)
+ dh_testdir
+ @-up-scripts
+ $(MAKE) -f debian/rules $(unpacked) $(patched)
+
+$(patched)/: $(STAMP_DIR)/created $(unpacked)
+ test -d $(STAMP_DIR)/patches || mkdir -p $(STAMP_DIR)/patches
+ @if [ -d "$(PATCH_DIR)" ]; then \
+ mkdir -p $(STAMP_DIR)/log/patches; \
+ for f in `(cd $(PATCH_DIR); find -type f ! -name 'chk-*' ! -path "./CVS/*") | sort | \
+ sed s,'\./',,g`; do \
+ stampfile=$(STAMP_DIR)/patches/$$f; \
+ log=$(STAMP_DIR)/log/patches/$$f; \
+ if [ ! -e $$stampfile ]; then \
+ echo -n "Applying patch $(PATCH_DIR)/$$f ... "; \
+ if $(SHELL) debian/scripts/file2cat $(PATCH_DIR)/$$f | \
+ (cd $(BUILD_TREE);patch -p1 --no-backup-if-mismatch) > $$log 2>&1; then \
+ echo successful.; \
+ touch $$stampfile; \
+ else \
+ echo "failed! (check $$log for reason)"; \
+ exit 1; \
+ fi; \
+ else \
+ echo Already applied $(PATCH_DIR)/$$f.; \
+ fi; \
+ done; \
+ fi
+ touch $@
+
+$(unpacked): $(STAMP_DIR)/created
+ mkdir -p $(STAMP_DIR)/sources $(SOURCE_DIR) $(STAMP_DIR)/log/sources
+ @for f in `find upstream/tarballs -type f -maxdepth 1 -name \*.tgz -o -name \*.tar.gz -o \
+ -name \*.tar.bz -o -name \*.tar.bz2 | sort | sed s,'\./',,g`; do \
+ stampfile=$(STAMP_DIR)/sources/`basename $$f`; \
+ log=$(STAMP_DIR)/log/sources/`basename $$f`; \
+ if [ ! -e $$stampfile ]; then \
+ echo -n "Extracting source $$f ... "; \
+ if $(SHELL) debian/scripts/file2cat $$f | \
+ (cd $(SOURCE_DIR); tar xv) > $$log 2>&1; then \
+ echo successful.; \
+ touch $$stampfile; \
+ else \
+ echo failed!; \
+ exit 1; \
+ fi; \
+ else \
+ echo Already unpacked $$f.; \
+ fi; \
+ done
+ touch $@
+
+make_patch:
+ mv $(BUILD_TREE) $(BUILD_TREE).new
+ rm -rf $(STAMP_DIR)
+ $(MAKE) -f debian/rules $(unpacked) $(patched)
+ifndef TAR_DIR
+ diff -urN $(BUILD_TREE) $(BUILD_TREE).new > new.diff
+else
+ (cd $(SOURCE_DIR) && diff -urN $(TAR_DIR) $(TAR_DIR).new || true) > new.diff
+endif
+ rm -rf $(BUILD_TREE)
+ mv $(BUILD_TREE).new $(BUILD_TREE)
+ @echo; ls -l new.diff
+
+$(STAMP_DIR)/created:
+ test -d $(STAMP_DIR) || mkdir $(STAMP_DIR)
+ touch $(STAMP_DIR)/created
--- proftpd-1.2.10.orig/debian/scripts/file2cat
+++ proftpd-1.2.10/debian/scripts/file2cat
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+if [ "$1" = "" ]; then
+ echo "Usage: file2cat "
+ exit 1
+fi
+
+case "$1" in
+ *.gz|*.Z|*.tgz) cmd=zcat;;
+ *.bz|*.bz2) cmd=bzcat;;
+ *.uue) cmd="uudecode -o -";;
+ *) cmd=cat;;
+esac
+$cmd $1
--- proftpd-1.2.10.orig/debian/scripts/dpkg-arch.mk
+++ proftpd-1.2.10/debian/scripts/dpkg-arch.mk
@@ -0,0 +1,7 @@
+# see dpkg-architecture(8)
+DEB_BUILD_ARCH := $(shell dpkg-architecture -qDEB_BUILD_ARCH)
+DEB_BUILD_GNU_CPU := $(shell dpkg-architecture -qDEB_BUILD_GNU_CPU)
+DEB_BUILD_GNU_SYSTEM := $(shell dpkg-architecture -qDEB_BUILD_GNU_SYSTEM)
+DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+DEB_HOST_GNU_SYSTEM := $(shell dpkg-architecture -qDEB_HOST_GNU_SYSTEM)
+DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
--- proftpd-1.2.10.orig/debian/proftpd.cron.monthly
+++ proftpd-1.2.10/debian/proftpd.cron.monthly
@@ -0,0 +1,11 @@
+#!/bin/sh
+#
+# cron script to rotate the proftpd server logfile, based on the
+# wu-ftpd script by Peter Tobias .
+
+[ -x /usr/sbin/ftpstats ] || exit 0
+
+cd /var/log
+savelog -q -u root -g adm -m 640 -c 12 /var/log/xferreport
+ftpstats -a -r -l 2 -d 2>/dev/null >/var/log/xferreport
+savelog -q -u root -g adm -m 640 -c 7 /var/log/xferlog
--- proftpd-1.2.10.orig/debian/proftpd.postrm
+++ proftpd-1.2.10/debian/proftpd.postrm
@@ -0,0 +1,9 @@
+#!/bin/sh -e
+
+if [ "$1" = "purge" -o "$1" = "remove" ]
+then
+ update-inetd --disable ftp /dev/tty
+fi
+
+#DEBHELPER#
+
--- proftpd-1.2.10.orig/debian/mod_mysql.texi
+++ proftpd-1.2.10/debian/mod_mysql.texi
@@ -0,0 +1,19 @@
+This module is contained in the mod_mysql.c file, and is not compiled in
+by default. It provides the backend support to connect to MySQL
+databases.
+
+@heading MySQL Database Directives
+
+@subheading @anchor{MySQLInfo} MySQLInfo
+
+@format
+Syntax: MySQLInfo host user pass dbname
+Default: none
+Context: server config, virtual host
+@end format
+
+Configures the MySQL database driver (the database may be remote). A
+connection isn't made until use of a SQL feature requires it, after
+which it may be held open for the lifetime of the FTP session
+depending on the directives in use. Use @kbd{""} to specify a null
+password.
--- proftpd-1.2.10.orig/debian/ftpstats.8
+++ proftpd-1.2.10/debian/ftpstats.8
@@ -0,0 +1,101 @@
+.\" Copyright (C) 1999 Darren Benham
+.\"
+.\" This manual page is free software. It is distributed under the
+.\" terms of the GNU General Public License as published by the Free
+.\" Software Foundation; either version 2 of the License, or (at your
+.\" option) any later version.
+.\"
+.\" This manual page is distributed in the hope that it will be useful,
+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+.\" GNU General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public License
+.\" along with this manual page; if not, write to the Free Software
+.\" Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+.\" USA
+.\"
+.TH FTPSTATS 8 "October 30, 2002" "Debian GNU/Linux"
+
+.SH NAME
+ftpstats \- FTP Log summarizer
+.SH SYNOPSIS
+.B ftpstats
+.RI [ options ]
+.SH DESCRIPTION
+.PP
+Ftpstats dissects the defined ftp log and reports various
+statistics as requested.
+This manual page was written for the Debian GNU/Linux distribution
+because the original program does not have a manual page.
+.P
+.SH OPTIONS
+.P
+.TP
+.BR \-f " filename"
+Use
+.IR filename
+rather than the default
+.IR /var/log/xferlog
+.
+.TP
+.BR \-r
+Include real users.
+.TP
+.BR \-a
+Include anonymous users.
+.TP
+.BR \-h
+Include report on hourly traffic.
+.TP
+.BR \-d
+Include report on domain traffic.
+.TP
+.BR \-t
+Report on total traffic by section.
+.TP
+.BR \-i
+Report on incoming traffic only (uploads).
+.TP
+.BR \-o
+Report on outgoing traffic only (downloads).
+.TP
+.BR \-D "domain"
+Report only on traffic from
+.IR domain
+. This option leads to problems with the local domain: e.g. test.com is
+encountered under test and not recognized under com, -D com will give you only
+stats about com excluding test.com! Use -A com for correct results.
+
+.TP
+.BR \-A "address"
+Report only on traffic from addresses whose end matches
+.IR address
+. e.g. -A test.domain.com will report on address ending with test.domain.com
+
+.TP
+.BR \-l "depth"
+Depth of path detail for sections
+
+.TP
+.BR \-s "section"
+Section to report on. e.g. -s /pub will report only on paths under /pub
+.SH BUGS
+No known bugs at this time.
+If you discover any bugs, please report at http://bugs.proftpd.org/
+For help/support, try the ProFTPD mailing lists, detailed on
+http://www.proftpd.org/lists.html
+.br
+.SH SEE ALSO
+.BR proftpd (8), proftpd.conf (5), xferlog (5)
+.SH AUTHORS
+ProFTPD is written and maintained by a number of people, full credits
+can be found on http://www.proftpd.org/credits.html
+.br
+.SH CREDITS
+This manual page was written by
+Francesco P. Lovergine and other Debian developers,
+for the Debian GNU/Linux system (but may be used by others).
+.br
+Please use the most appropriate mailing list listed on
+http://www.proftpd.org/lists.html for ftpstats related comments.
--- proftpd-1.2.10.orig/debian/proftpd.postinst
+++ proftpd-1.2.10/debian/proftpd.postinst
@@ -0,0 +1,154 @@
+#!/bin/sh -e
+
+# summary of how this script can be called:
+# * `configure'
+# * `abort-upgrade'
+# * `abort-remove' `in-favour'
+# * `abort-deconfigure' `in-favour'
+# `removing'
+#
+# for details, see /usr/share/doc/packaging-manual/
+#
+# quoting from the policy:
+# Any necessary prompting should almost always be confined to the
+# post-installation script, and should be protected with a conditional
+# so that unnecessary prompting doesn't happen if a package's
+# installation fails and the `postinst' is called with `abort-upgrade',
+# `abort-remove' or `abort-deconfigure'.
+
+
+CONF="/etc/proftpd.conf"
+CONF_NEW="/etc/proftpd.conf.proftpd-new"
+
+installftp()
+{
+ if ! grep -q "^ftp:" /etc/passwd
+ then
+ adduser --system ftp || true
+ if [ -f /usr/share/doc/proftpd/examples/welcome.msg -a -d ~ftp ] ; then
+ cp -p -v /usr/share/doc/proftpd/examples/welcome.msg ~ftp/welcome.msg.proftpd-new || true
+ do_update ~ftp/welcome.msg || true
+ fi
+ fi
+}
+
+list_options()
+{
+ if [ -f $CONF_NEW ] ; then
+ sed -e "s/lsdefaultoptions/ListOptions/i" $CONF_NEW > $CONF_NEW.tmp
+ mv -f $CONF_NEW.tmp $CONF_NEW
+ fi
+}
+
+tcpwin_options()
+{
+ if [ -f $CONF_NEW ] ; then
+ sed -e "s/tcpreceivewindow/SocketOptions rcvbuf/i" \
+ -e "s/tcpsendwindow/SocketOptions sndbuf/i" \
+ $CONF_NEW > $CONF_NEW.tmp
+ mv -f $CONF_NEW.tmp $CONF_NEW
+ fi
+}
+
+scoreboard()
+{
+ if [ -f $CONF_NEW ] ; then
+ sed -e "s/\(scoreboardpath.*\)/#\n#ScoreboardPath is deprecated in 1.2.9, use ScoreboardFile instead\n#\1\n#\n#ScoreboardFile\t\/var\/run\/proftpd.scoreboard\n#/i" \
+ $CONF_NEW > $CONF_NEW.tmp
+ mv -f $CONF_NEW.tmp $CONF_NEW
+ fi
+}
+
+
+switch_on()
+{
+ if [ -f $CONF_NEW ] ; then
+ sed -e 's/^\(ServerType.*\)inetd/\1standalone/' $CONF_NEW >$CONF_NEW.tmp
+ mv -f $CONF_NEW.tmp $CONF_NEW
+ fi
+}
+
+switch_off()
+{
+ if [ -f $CONF_NEW ] ; then
+ sed -e 's/^\(ServerType.*\)standalone/\1inetd/' $CONF_NEW >$CONF_NEW.tmp
+ mv -f $CONF_NEW.tmp $CONF_NEW
+ fi
+}
+
+replace_file () {
+ file=$1
+ if [ ! -f ${file} ] ; then
+ mv ${file}.proftpd-new ${file}
+ else
+ cp $file ${file}.proftpd-old
+ ucf --debconf-ok ${file}.proftpd-new $file
+ fi
+}
+
+do_update () {
+ file=$1
+ if diff -q ${file} ${file}.proftpd-new >/dev/null 2>&1; then
+ # Old file and new file are identical
+ rm -f ${file}.proftpd-new
+ else
+ replace_file $file
+ fi
+}
+
+DONTSTART=0
+
+. /usr/share/debconf/confmodule
+
+if [ "$1" = "configure" ]; then
+
+ # use current configuration or generate a new one from scratch
+ if [ ! -f /etc/proftpd.conf ] ; then
+ cp /usr/share/doc/proftpd/examples/proftpd.conf $CONF_NEW
+ else
+ cp $CONF $CONF_NEW
+ fi
+
+ update-inetd --group STANDARD --add 'ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/proftpd' /dev/null
+ if [ $DONTSTART -eq 0 ] ; then
+ set +e; /usr/sbin/proftpd -t >/dev/null 2>&1; set -e
+ if [ $? = 0 ]; then
+ invoke-rc.d proftpd start
+ else
+ echo "Cannot start proftpd, please check syntax of your configuration file $CONF"
+ fi
+ fi
+fi
+
+#DEBHELPER#
+
--- proftpd-1.2.10.orig/debian/mod_pgsql.txt
+++ proftpd-1.2.10/debian/mod_pgsql.txt
@@ -0,0 +1,30 @@
+This module is contained in the mod_pgsql.c file, and is not compiled in
+by default. It provides the backend support to connect to Postgresql
+databases.
+
+Postgres Database Directives
+============================
+
+PostgresInfo
+------------
+
+Syntax: PostgresInfo host user pass dbname
+Syntax: PostgresInfo host dbname
+Default: none
+Context: server config, virtual host
+
+ Configures the Posgresql database driver (the database may be
+remote). A connection isn't made until use of a SQL feature requires
+it, after which it may be held open for the lifetime of the FTP session
+depending on the directives in use.
+
+PostgresPort
+------------
+
+Syntax: PostgresPort [num]
+Default: 5432
+Context: server config, virtual host
+
+ Specifies which TCP/IP port to use for connecting. Default is 5432,
+or UNIX socket for localhost.
+
--- proftpd-1.2.10.orig/debian/proftpd.prerm
+++ proftpd-1.2.10/debian/proftpd.prerm
@@ -0,0 +1,11 @@
+#! /bin/sh
+
+if [ -x "/usr/sbin/invoke-rc.d" ]; then
+ invoke-rc.d proftpd stop
+else
+ if [ -x "/etc/init.d/proftpd" ]; then
+ /etc/init.d/proftpd stop
+ fi
+fi
+
+#DEBHELPER#
--- proftpd-1.2.10.orig/debian/mod_mysql.txt
+++ proftpd-1.2.10/debian/mod_mysql.txt
@@ -0,0 +1,19 @@
+This module is contained in the mod_mysql.c file, and is not compiled in
+by default. It provides the backend support to connect to MySQL
+databases.
+
+MySQL Database Directives
+=========================
+
+MySQLInfo
+---------
+
+Syntax: MySQLInfo host user pass dbname
+Default: none
+Context: server config, virtual host
+
+ Configures the MySQL database driver (the database may be remote). A
+connection isn't made until use of a SQL feature requires it, after
+which it may be held open for the lifetime of the FTP session depending
+on the directives in use. Use `""' to specify a null password.
+
--- proftpd-1.2.10.orig/debian/basic.conf
+++ proftpd-1.2.10/debian/basic.conf
@@ -0,0 +1,103 @@
+#
+# /etc/proftpd.conf -- This is a basic ProFTPD configuration file.
+# To really apply changes reload proftpd after modifications.
+#
+
+ServerName "Debian"
+ServerType standalone
+DeferWelcome off
+
+MultilineRFC2228 on
+DefaultServer on
+ShowSymlinks on
+
+TimeoutNoTransfer 600
+TimeoutStalled 600
+TimeoutIdle 1200
+
+DisplayLogin welcome.msg
+DisplayFirstChdir .message
+ListOptions "-l"
+
+DenyFilter \*.*/
+
+# Uncomment this if you are using NIS or LDAP to retrieve passwords:
+#PersistentPasswd off
+
+# Uncomment this if you would use TLS module:
+#TLSEngine on
+
+# Uncomment this if you would use quota module:
+#Quotas on
+
+# Uncomment this if you would use ratio module:
+#Ratios on
+
+# Port 21 is the standard FTP port.
+Port 21
+
+# To prevent DoS attacks, set the maximum number of child processes
+# to 30. If you need to allow more than 30 concurrent connections
+# at once, simply increase this value. Note that this ONLY works
+# in standalone mode, in inetd mode you should use an inetd server
+# that allows you to limit maximum number of processes per service
+# (such as xinetd)
+MaxInstances 30
+
+# Set the user and group that the server normally runs at.
+User nobody
+Group nogroup
+
+# Umask 022 is a good standard umask to prevent new files and dirs
+# (second parm) from being group and world writable.
+Umask 022 022
+# Normally, we want files to be overwriteable.
+AllowOverwrite on
+
+# Delay engine reduces impact of the so-called Timing Attack described in
+# http://security.lss.hr/index.php?page=details&ID=LSS-2004-10-02
+# It is on by default.
+#DelayEngine off
+
+# A basic anonymous configuration, no upload directories.
+
+#
+# User ftp
+# Group nogroup
+# # We want clients to be able to login with "anonymous" as well as "ftp"
+# UserAlias anonymous ftp
+# # Cosmetic changes, all files belongs to ftp user
+# DirFakeUser on ftp
+# DirFakeGroup on ftp
+#
+# RequireValidShell off
+#
+# # Limit the maximum number of anonymous logins
+# MaxClients 10
+#
+# # We want 'welcome.msg' displayed at login, and '.message' displayed
+# # in each newly chdired directory.
+# DisplayLogin welcome.msg
+# DisplayFirstChdir .message
+#
+# # Limit WRITE everywhere in the anonymous chroot
+#
+#
+# DenyAll
+#
+#
+#
+# # Uncomment this if you're brave.
+# #
+# # # Umask 022 is a good standard umask to prevent new files and dirs
+# # # (second parm) from being group and world writable.
+# # Umask 022 022
+# #
+# # DenyAll
+# #
+# #
+# # AllowAll
+# #
+# #
+#
+#
--- proftpd-1.2.10.orig/debian/proftpd.preinst
+++ proftpd-1.2.10/debian/proftpd.preinst
@@ -0,0 +1,34 @@
+#!/bin/sh -e
+
+# summary of how this script can be called:
+# * `install'
+# * `install'
+# * `upgrade'
+# * `abort-upgrade'
+#
+
+if [ "$1" = "upgrade" ]; then
+ if [ -e /usr/sbin/invoke-rc.d ]; then
+ invoke-rc.d proftpd stop >/dev/null 2>&1 || true
+ else
+ /etc/init.d/proftpd stop >/dev/null 2>&1 || true
+ fi
+
+ # Scoreboard file format changed in 1.2.9
+ # Now stopping all inetd sessions and removing it to ensure
+ # a clean upgrade
+ if dpkg --compare-versions "$2" lt "1.2.9-1"; then
+ if [ `pgrep proftpd|wc -l` -ne 0 ]; then
+ pkill proftpd
+ sleep 2
+ fi
+ rm -f /var/run/proftpd/proftpd.scoreboard
+ fi
+fi
+
+exit 0
+
+#DEBHELPER#
+
+
+
--- proftpd-1.2.10.orig/debian/ftpusers.5
+++ proftpd-1.2.10/debian/ftpusers.5
@@ -0,0 +1,42 @@
+.\" Copyright (c) 1994 Peter Tobias (tobias@server.et-inf.fho-emden.de),
+.\" 2001 Ivo Timmermans
+.\" This file may be distributed under the GNU General Public License.
+.\"
+.Dd April 19, 2001
+.Dt FTPUSERS 5
+.Os "Debian proftpd"
+.Sh NAME
+.Nm ftpusers
+.Nd file which lists users who are not allowed to use ftp
+.Sh DESCRIPTION
+.Pa /etc/ftpusers
+is used by
+.Xr proftpd 8 ;
+the file contains a list of users who are not allowed to use the
+ftp command. For security reasons at least users like ``root'', ``bin'',
+``uucp'' and ``news'' should be listed in this file.
+Blank lines and lines beginning with `#' are ignored.
+.Pp
+Note: a lines with `#' in the
+.Em middle
+is
+.Em not
+a comment. Don't put `#' after a name to comment it; use another line,
+or things will silently fail on you.
+.Sh EXAMPLES
+.Pa /etc/ftpusers
+might contain the following entries:
+.Bd -literal
+#
+# /etc/ftpusers
+#
+root
+bin
+uucp
+news
+.Ed
+.Sh FILES
+.Pa /etc/ftpusers
+.Sh SEE ALSO
+.Xr ftp 1 ,
+.Xr proftpd 8
--- proftpd-1.2.10.orig/debian/patches/CVS/Root
+++ proftpd-1.2.10/debian/patches/CVS/Root
@@ -0,0 +1 @@
+:ext:frankie@cvs.alioth.debian.org:/cvsroot/pkg-proftpd
--- proftpd-1.2.10.orig/debian/patches/CVS/Repository
+++ proftpd-1.2.10/debian/patches/CVS/Repository
@@ -0,0 +1 @@
+debian/patches
--- proftpd-1.2.10.orig/debian/patches/CVS/Entries
+++ proftpd-1.2.10/debian/patches/CVS/Entries
@@ -0,0 +1,19 @@
+/14.quotatab_modules.diff/1.4/Sat Apr 17 18:16:02 2004//
+/01.contrib.mod_ldap.c.diff/1.14/Sat Aug 28 16:42:57 2004/-kb/
+/02.mod_pam.c.change.pam.name.diff/1.1/Sat Aug 28 16:42:57 2004/-kb/
+/03.mod_ldap.c.diff/1.1/Sat Aug 28 16:42:57 2004/-kb/
+/04.mod_sql_postgres.c.diff/1.1/Sat Aug 28 16:42:57 2004/-kb/
+/06.man.diff/1.1/Sat Aug 28 16:42:57 2004/-kb/
+/07.autoconf.diff/1.2/Sat Aug 28 16:42:58 2004/-kb/
+/08.misc.diff/1.1/Sat Aug 28 16:42:59 2004/-kb/
+/09.mod_xfer.c.diff/1.1/Sat Aug 28 16:42:59 2004/-kb/
+/10.mod_unixpw.c.ldap.fix.diff/1.1/Sat Aug 28 16:42:59 2004/-kb/
+/11.mod_auth.c.shell.null.segfault.diff/1.1/Sat Aug 28 16:42:59 2004/-kb/
+/12.ftpasswd.cracklib.location.diff/1.1/Sat Aug 28 16:42:59 2004/-kb/
+/13.mod_sql_mysql.c.diff/1.1/Sat Aug 28 16:42:59 2004/-kb/
+/15.mod_quotatab_sql.c.diff/1.1/Sat Aug 28 16:43:00 2004/-kb/
+/16.dirtree.c.diff/1.1/Thu Aug 26 18:30:21 2004//
+/17.netio.c.diff/1.1/Sat Aug 28 16:43:00 2004/-kb/
+/18.mod_auth_file.c.diff/1.1/Thu Aug 26 18:30:21 2004//
+/19.main.c.ipv6.diff/1.1/Thu Aug 26 18:30:21 2004//
+D
--- proftpd-1.2.10.orig/debian/patches/29.misc-sql.diff
+++ proftpd-1.2.10/debian/patches/29.misc-sql.diff
@@ -0,0 +1,237 @@
+diff -ruN proftpd-1.2.10-old/contrib/mod_sql.c proftpd-1.2.10/contrib/mod_sql.c
+--- proftpd-1.2.10-old/contrib/mod_sql.c 2004-08-03 02:44:31.000000000 +0200
++++ proftpd-1.2.10/contrib/mod_sql.c 2005-08-31 11:23:13.000000000 +0200
+@@ -111,6 +111,8 @@
+ MODRET sql_lookup(cmd_rec *);
+
+ pool *sql_pool;
++static pr_netaddr_t *sql_local_addr = NULL;
++static pr_netaddr_t *sql_remote_addr = NULL;
+
+ /*
+ * cache typedefs
+@@ -1447,7 +1449,7 @@
+
+ case 'a':
+ argp = arg;
+- sstrncpy(argp, pr_netaddr_get_ipstr(session.c->remote_addr), sizeof(arg));
++ sstrncpy(argp, pr_netaddr_get_ipstr(sql_remote_addr), sizeof(arg));
+ break;
+
+ case 'b':
+@@ -1576,7 +1578,7 @@
+
+ case 'L':
+ argp = arg;
+- sstrncpy(argp, pr_netaddr_get_ipstr(session.c->local_addr), sizeof(arg));
++ sstrncpy(argp, pr_netaddr_get_ipstr(sql_local_addr), sizeof(arg));
+ break;
+
+ case 'l':
+@@ -3898,7 +3900,9 @@
+ *****************************************************************/
+
+ static void sql_exit_cb(void) {
+- config_rec *c = NULL;
++ config_rec *c;
++ cmd_rec *cmd;
++ modret_t *mr;
+
+ /* Note: most of this code hacked out of log_master(), which
+ * brings to mind the idea of reorganizing the code a little, so
+@@ -3944,6 +3948,10 @@
+ c = find_config_next(c, c->next, CONF_PARAM, "SQLLog_EXIT", FALSE);
+ }
+
++ cmd = _sql_make_cmd(session.pool, 0);
++ mr = _sql_dispatch(cmd, "sql_exit");
++ _sql_check_response(mr);
++
+ sql_closelog();
+ return;
+ }
+@@ -4287,6 +4295,10 @@
+ sql_log(DEBUG_INFO, "sql_bcred : %s", cmap.sql_bcred);
+ }
+
++ /* Make a copy of netaddrs for later. */
++ sql_local_addr = pr_netaddr_dup(sql_pool, session.c->local_addr);
++ sql_remote_addr = pr_netaddr_dup(sql_pool, session.c->remote_addr);
++
+ sql_log(DEBUG_FUNC, "%s", "<<< sql_getconf");
+
+ /* get rid of the temp pool */
+diff -ruN proftpd-1.2.10-old/contrib/mod_sql_mysql.c proftpd-1.2.10/contrib/mod_sql_mysql.c
+--- proftpd-1.2.10-old/contrib/mod_sql_mysql.c 2005-08-31 11:15:44.000000000 +0200
++++ proftpd-1.2.10/contrib/mod_sql_mysql.c 2005-08-31 11:15:44.000000000 +0200
+@@ -88,9 +88,6 @@
+ * connection policy, connections may be closed at any time and may need
+ * to be reopened for any call.
+ *
+- * All backends should register an event handler for "core.exit", to close
+- * any open connections. See the function sql_mysql_exit_ev() as an example.
+- *
+ * CONNECTION TIMERS
+ *
+ * Backends are required to handle connection timers; when a connection is
+@@ -288,25 +285,6 @@
+ return 0;
+ }
+
+-/* sql_mysql_exit_ev: walks the connection cache and closes every
+- * open connection, resetting their connection counts to 0.
+- */
+-static void sql_mysql_exit_ev(const void *event_data, void *user_data) {
+- register unsigned int i = 0;
+-
+- for (i = 0; i < conn_cache->nelts; i++) {
+- conn_entry_t *entry = ((conn_entry_t **) conn_cache->elts)[i];
+-
+- if (entry->connections > 0) {
+- cmd_rec *cmd = _sql_make_cmd(conn_pool, 2, entry->name, "1");
+- cmd_close(cmd);
+- SQL_FREE_CMD(cmd);
+- }
+- }
+-
+- return;
+-}
+-
+ /*
+ * _build_error: constructs a modret_t filled with error information;
+ * mod_sql_mysql calls this function and returns the resulting mod_ret_t
+@@ -682,6 +660,35 @@
+ }
+
+ /*
++ * cmd_exit: closes all open connections.
++ *
++ * Inputs:
++ * None
++ *
++ * Returns:
++ * A simple non-error modret_t.
++ */
++static modret_t *cmd_exit(cmd_rec *cmd) {
++ register unsigned int i = 0;
++
++ sql_log(DEBUG_FUNC, "%s", "entering \tmysql cmd_exit");
++
++ for (i = 0; i < conn_cache->nelts; i++) {
++ conn_entry_t *entry = ((conn_entry_t **) conn_cache->elts)[i];
++
++ if (entry->connections > 0) {
++ cmd_rec *cmd = _sql_make_cmd(conn_pool, 2, entry->name, "1");
++ cmd_close(cmd);
++ destroy_pool(cmd->pool);
++ }
++ }
++
++ sql_log(DEBUG_FUNC, "%s", "exiting \tmysql cmd_exit");
++
++ return HANDLED(cmd);
++}
++
++/*
+ * cmd_select: executes a SELECT query. properly constructing the query
+ * based on the inputs. See mod_sql.h for the definition of the _sql_data
+ * structure which is used to return the result data.
+@@ -1343,6 +1350,7 @@
+ { CMD, "sql_open", G_NONE, cmd_open, FALSE, FALSE },
+ { CMD, "sql_close", G_NONE, cmd_close, FALSE, FALSE },
+ { CMD, "sql_defineconnection", G_NONE, cmd_defineconnection, FALSE, FALSE },
++ { CMD, "sql_exit", G_NONE, cmd_exit, FALSE, FALSE },
+ { CMD, "sql_select", G_NONE, cmd_select, FALSE, FALSE },
+ { CMD, "sql_insert", G_NONE, cmd_insert, FALSE, FALSE },
+ { CMD, "sql_update", G_NONE, cmd_update, FALSE, FALSE },
+@@ -1364,8 +1372,6 @@
+ conn_cache = make_array(make_sub_pool(session.pool), DEF_CONN_POOL_SIZE,
+ sizeof(conn_entry_t));
+
+- pr_event_register(&sql_mysql_module, "core.exit", sql_mysql_exit_ev, NULL);
+-
+ return 0;
+ }
+
+diff -ruN proftpd-1.2.10-old/contrib/mod_sql_postgres.c proftpd-1.2.10/contrib/mod_sql_postgres.c
+--- proftpd-1.2.10-old/contrib/mod_sql_postgres.c 2004-05-08 05:21:46.000000000 +0200
++++ proftpd-1.2.10/contrib/mod_sql_postgres.c 2005-08-31 11:15:44.000000000 +0200
+@@ -190,25 +190,6 @@
+ return 0;
+ }
+
+-/* sql_postgres_exit_ev: walks the connection cache and closes every
+- * open connection, resetting their connection counts to 0.
+- */
+-static void sql_postgres_exit_ev(const void *event_data, void *user_data) {
+- register unsigned int i = 0;
+-
+- for (i = 0; i < conn_cache->nelts; i++) {
+- conn_entry_t *entry = ((conn_entry_t **) conn_cache->elts)[i];
+-
+- if (entry->connections > 0) {
+- cmd_rec *cmd = _sql_make_cmd(conn_pool, 2, entry->name, "1");
+- cmd_close(cmd);
+- SQL_FREE_CMD(cmd);
+- }
+- }
+-
+- return;
+-}
+-
+ /*
+ * _build_error: constructs a modret_t filled with error information;
+ * mod_sql_postgres calls this function and returns the resulting mod_ret_t
+@@ -552,6 +533,35 @@
+ }
+
+ /*
++ * cmd_exit: closes all open connections.
++ *
++ * Inputs:
++ * None
++ *
++ * Returns:
++ * A simple non-error modret_t.
++ */
++static modret_t *cmd_exit(cmd_rec *cmd) {
++ register unsigned int i = 0;
++
++ sql_log(DEBUG_FUNC, "%s", "entering \tpostgres cmd_exit");
++
++ for (i = 0; i < conn_cache->nelts; i++) {
++ conn_entry_t *entry = ((conn_entry_t **) conn_cache->elts)[i];
++
++ if (entry->connections > 0) {
++ cmd_rec *cmd = _sql_make_cmd(conn_pool, 2, entry->name, "1");
++ cmd_close(cmd);
++ destroy_pool(cmd->pool);
++ }
++ }
++
++ sql_log(DEBUG_FUNC, "%s", "exiting \tpostgres cmd_exit");
++
++ return HANDLED(cmd);
++}
++
++/*
+ * cmd_select: executes a SELECT query. properly constructing the query
+ * based on the inputs. See mod_sql.h for the definition of the _sql_data
+ * structure which is used to return the result data.
+@@ -1211,6 +1221,7 @@
+ { CMD, "sql_open", G_NONE, cmd_open, FALSE, FALSE },
+ { CMD, "sql_close", G_NONE, cmd_close, FALSE, FALSE },
+ { CMD, "sql_defineconnection", G_NONE, cmd_defineconnection, FALSE, FALSE },
++ { CMD, "sql_exit", G_NONE, cmd_exit, FALSE, FALSE },
+ { CMD, "sql_select", G_NONE, cmd_select, FALSE, FALSE },
+ { CMD, "sql_insert", G_NONE, cmd_insert, FALSE, FALSE },
+ { CMD, "sql_update", G_NONE, cmd_update, FALSE, FALSE },
+@@ -1232,8 +1243,6 @@
+ conn_cache = make_array(make_sub_pool(session.pool), DEF_CONN_POOL_SIZE,
+ sizeof(conn_entry_t));
+
+- pr_event_register(&sql_postgres_module, "core.exit", sql_postgres_exit_ev,
+- NULL);
+ return 0;
+ }
+
--- proftpd-1.2.10.orig/debian/patches/12.ftpasswd.cracklib.location.diff
+++ proftpd-1.2.10/debian/patches/12.ftpasswd.cracklib.location.diff
@@ -0,0 +1,13 @@
+diff -ruN proftpd-1.2.10-old/contrib/ftpasswd proftpd-1.2.10/contrib/ftpasswd
+--- proftpd-1.2.10-old/contrib/ftpasswd 2004-03-24 22:55:44.000000000 +0100
++++ proftpd-1.2.10/contrib/ftpasswd 2004-09-14 23:25:32.000000000 +0200
+@@ -37,7 +37,8 @@
+ my $default_passwd_file = "./ftpd.passwd";
+ my $default_group_file = "./ftpd.group";
+ my $shell_file = "/etc/shells";
+-my $default_cracklib_dict = "/usr/lib/cracklib_dict";
++#my $default_cracklib_dict = "/usr/lib/cracklib_dict";
++my $default_cracklib_dict = "/var/cache/cracklib";
+ my $cracklib_dict;
+ my $output_file;
+ my $version = "1.1.3";
--- proftpd-1.2.10.orig/debian/patches/32.mod_tls.c.diff
+++ proftpd-1.2.10/debian/patches/32.mod_tls.c.diff
@@ -0,0 +1,15 @@
+diff -ruN proftpd-1.2.10-old/contrib/mod_tls.c proftpd-1.2.10/contrib/mod_tls.c
+--- proftpd-1.2.10-old/contrib/mod_tls.c 2004-07-01 03:06:09.000000000 +0200
++++ proftpd-1.2.10/contrib/mod_tls.c 2005-11-16 11:31:09.000000000 +0100
+@@ -567,7 +567,11 @@
+ }
+ }
+
++#if OPENSSL_VERSION_NUMBER < 0x00908001
+ PEMerr(PEM_F_DEF_CALLBACK, PEM_R_PROBLEMS_GETTING_PASSWORD);
++#else
++ PEMerr(PEM_F_PEM_DEF_CALLBACK, PEM_R_PROBLEMS_GETTING_PASSWORD);
++#endif
+ pr_memscrub(buf, buflen);
+ return -1;
+ }
--- proftpd-1.2.10.orig/debian/patches/08.misc.diff
+++ proftpd-1.2.10/debian/patches/08.misc.diff
@@ -0,0 +1,2038 @@
+diff -ruN proftpd-1.2.10-old/contrib/xferstats.holger-preiss proftpd-1.2.10/contrib/xferstats.holger-preiss
+--- proftpd-1.2.10-old/contrib/xferstats.holger-preiss 2002-05-30 18:22:46.000000000 +0200
++++ proftpd-1.2.10/contrib/xferstats.holger-preiss 2004-09-14 23:22:09.000000000 +0200
+@@ -250,14 +250,14 @@
+
+ Total Transfers from each Archive Section (By bytes)
+
+- ---- Percent Of ----
+- Archive Section Files Sent Bytes Sent Files Sent Bytes Sent
+-------------------------- ---------- ----------- ---------- ----------
++ ---- Percent Of ----
++ Archive Section Files Sent Bytes Sent Files Sent Bytes Sent
++------------------------- ---------- ------------- ---------- ----------
+ .
+
+ format line2 =
+-@<<<<<<<<<<<<<<<<<<<<<<<< @>>>>>>>>> @>>>>>>>>>> @>>>>>>> @>>>>>>>
+-$section, $files, $bytes, $pctfiles, $pctbytes
++@<<<<<<<<<<<<<<<<<<<<<<<< @>>>>>>>>> @>>>>>>>>>>>> @>>>>>>> @>>>>>>>
++$section, $files, $bytes, $pctfiles, $pctbytes
+ .
+
+ $| = 1;
+diff -ruN proftpd-1.2.10-old/doc/draft-murray-auth-ftp-ssl-06.txt proftpd-1.2.10/doc/draft-murray-auth-ftp-ssl-06.txt
+--- proftpd-1.2.10-old/doc/draft-murray-auth-ftp-ssl-06.txt 1970-01-01 01:00:00.000000000 +0100
++++ proftpd-1.2.10/doc/draft-murray-auth-ftp-ssl-06.txt 2004-09-14 23:22:09.000000000 +0200
+@@ -0,0 +1,1920 @@
++
++
++
++
++
++
++ Paul Ford-Hutchinson
++ IBM UK Ltd
++ Martin Carpenter
++ Verisign Ltd
++ Tim Hudson
++INTERNET-DRAFT (draft) RSA Australia Ltd
++ Eric Murray
++ Wave Systems Inc
++ Volker Wiegand
++ SuSE Linux
++
++ 18th September, 2000
++This document expires on 17th March, 2001
++
++
++ Securing FTP with TLS
++
++
++Status of this Memo
++
++ This document is an Internet-Draft and is in full conformance with
++ all provisions of Section 10 of RFC2026.
++
++ Internet-Drafts are working documents of the Internet Engineering
++ Task Force (IETF), its areas, and its working groups. Note that
++ other groups may also distribute working documents as Internet-
++ Drafts.
++
++ Internet-Drafts are draft documents valid for a maximum of six months
++ and may be updated, replaced, or obsoleted by other documents at any
++ time. It is inappropriate to use Internet-Drafts as reference
++ material or to cite them other than as "work in progress."
++
++ The list of current Internet-Drafts can be accessed at
++ http://www.ietf.org/1id-abstracts.txt
++
++ The list of Internet-Draft Shadow Directories can be accessed at
++ http://www.ietf.org/shadow.html
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 1]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++Index
++ 1. .......... Abstract
++ 2. .......... Introduction
++ 3. .......... Audience
++ 4. .......... Session negotiation on the control port
++ 5. .......... Response to FEAT command
++ 6. .......... Data Connection Behaviour
++ 7. .......... Mechanisms for the AUTH Command
++ 8. .......... SASL Considerations
++ 9. .......... Data Connection Security
++ 10. ......... A discussion of negotiation behaviour
++ 11. ......... Who negotiates what, where and how
++ 12. ......... Timing Diagrams
++ 13. ......... Implications of [FTP-EXT]
++ 14. ......... Discussion of the 'REIN' command
++ 15. ......... Security Considerations
++ 16. ......... IANA Considerations
++ 17. ......... Network Management
++ 18. ......... Internationalization
++ 19. ......... Scalability & Limits
++ 20. ......... Applicability
++ 21. ......... Acknowledgements
++ 22. ......... References
++ 23. ......... Authors' Contact Addresses
++ Appendices
++ A. .......... Summary of [RFC-2246]
++ B. .......... Summary of [RFC-2228]
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 2]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++1. Abstract
++
++ This document describes a mechanism that can be used by FTP clients
++ and servers to implement security and authentication using the TLS
++ protocol defined by [RFC-2246] and the extensions to the FTP protocol
++ defined by [RFC-2228]. It describes the subset of the extensions
++ that are required and the parameters to be used; discusses some of
++ the policy issues that clients and servers will need to take;
++ considers some of the implications of those policies and discusses
++ some expected behaviours of implementations to allow interoperation.
++ This document is intended to provide TLS support for FTP in a similar
++ way to that provided for SMTP in [RFC-2487].
++
++ TLS is not the only mechanism for securing file transfer, however it
++ does offer some of the following positive attributes:-
++
++ - Flexible security levels. TLS can support privacy, integrity,
++ authentication or some combination of all of these. This allows
++ clients and servers to dynamically, during a session, decide on
++ the level of security required for a particular data transfer,
++
++ - It is possible to use X.509 certificates to authenticate client
++ users and not just client hosts.
++
++ - Formalised public key management. By use of X.509 public
++ certificates during the authentication phase, certificate
++ management can be built into a central function. Whilst this may
++ not be desirable for all uses of secured file transfer, it offers
++ advantages in certain structured environments such as access to
++ corporate data sources.
++
++ - Co-existence and interoperation with authentication mechanisms
++ that are already in place for the HTTPS protocol. This allows web
++ browsers to incorporate secure file transfer using the same
++ infrastructure that has been set up to allow secure web browsing.
++
++ The TLS protocol is a development of the Netscape Communication
++ Corporation's SSL protocol and this document can be used to allow the
++ FTP protocol to be used with either SSL or TLS. The actual protocol
++ used will be decided by the negotiation of the protected session by
++ the TLS/SSL layer.
++
++ Note that this specification is in accordance with the FTP RFC
++ [RFC-959] and relies on the TLS protocol [RFC-2246] and the FTP
++ security extensions [RFC-2228].
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 3]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++2. Introduction
++
++ This document is an attempt to describe how three other documents
++ should combined to provide a useful, interoperable, secure file
++ transfer protocol. Those documents are:-
++
++
++ RFC 959 [RFC-959]
++
++ The description of the Internet File Transfer Protocol
++
++ RFC 2246 [RFC-2246]
++
++ The description of the Transport Layer Security protocol
++ (developed from the Netscape Secure Sockets Layer (SSL)
++ protocol version 3.0).
++
++ RFC 2228 [RFC-2228]
++
++ Extensions to the FTP protocol to allow negotiation of security
++ mechanisms to allow authentication, privacy and message
++ integrity.
++
++ The File Transfer Protocol (FTP) currently defined in [RFC-959] and
++ in place on the Internet is an excellent mechanism for exchanging
++ files. The security extensions to FTP in [RFC-2228] offer a
++ comprehensive set of commands and responses that can be used to add
++ authentication, integrity and privacy to the FTP protocol. The TLS
++ protocol is a popular (due to its wholesale adoption in the HTTP
++ environment) mechanism for generally securing a socket connection.
++ There are many ways in which these three protocols can be combined
++ which would ensure that interoperation is impossible. This document
++ describes one method by which FTP can operate securely in such a way
++ as to provide both flexibility and interoperation. This necessitates
++ a brief description of the actual negotiation mechanism (if used); a
++ much more detailed description of the policies and practices that
++ would be required and a discussion of the expected behaviours of
++ clients and servers to allow either party to impose their security
++ requirements on the FTP session.
++
++
++3. Audience
++
++ This document is aimed at developers who wish to use TLS as a
++ security mechanism to secure FTP clients and/or servers.
++
++
++4. Session negotiation on the control port
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 4]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ 4.1 Negotiated Session Security
++
++ In this scenario, the server listens on the normal FTP control
++ port {FTP-PORT} and the session initiation is not secured at all.
++ Once the client wishes to secure the session, the AUTH command is
++ sent and the server may then allow TLS negotiation to take place.
++
++ 4.1.1 Client wants a secured session
++
++ If a client wishes to attempt to secure a session then it
++ should, in accordance with [RFC-2228] send the AUTH command with
++ the parameter requesting TLS or SSL {TLS-PARM}.
++
++
++ The client then needs to behave according to its policies
++ depending on the response received from the server and also the
++ result of the TLS negotiation. i.e. A client which receives an
++ 'AUTH' rejection may choose to continue with the session
++ unprotected if it so desires.
++
++ 4.1.2 Server wants a secured session
++
++ The FTP protocol does not allow a server to directly dictate
++ client behaviour, however the same effect can be achieved by
++ refusing to accept certain FTP commands until the session is
++ secured to an acceptable level to the server.
++
++ 4.2 Implicit Session Security
++
++ In this scenario, the server listens on a distinct port {FTP-
++ TLSPORT} to the normal unsecured FTP server. Upon connection, the
++ client is expected to start the TLS negotiation. If the
++ negotiation fails or succeeds at an unacceptable level of security
++ then it will be a client and/or server policy decision to
++ disconnect the session.
++
++5. Response to the FEAT command
++
++ The FEAT command (introduced in [RFC-2389]) allows servers with
++ additional features to advertise these to a client by responding to
++ the FEAT command. If a server supports the 'FEAT' command then it
++ MUST advertise supported 'AUTH', 'PBSZ' and 'PROT' commands in the
++ reply as described in section 3.2 of [RFC-2389]. Additionally, the
++ 'AUTH' command should have a reply that identifies 'TLS' as one of
++ the possible parameters to 'AUTH'. It is not necessary to identify
++ the 'SSL', 'TLS-P' or 'TLS-C' parameters separately.
++
++ Example reply (in same style is [RFC-2389])
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 5]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ C> FEAT
++ S> 211-Extensions supported
++ S> AUTH TLS
++ S> PBSZ
++ S> PROT
++ S> 211 END
++
++
++6. Data Connection Behaviour
++
++ The Data Connection in the FTP model can be used in one of three
++ ways. (Note: these descriptions are not necessarily placed in exact
++ chronological order, but do describe the steps required. - See
++ diagrams later for clarification)
++
++ i) Classic FTP client/server data exchange
++
++ - The client obtains a port, sends the port number to the
++ server, the server connects to the client. The client issues a
++ send or receive request to the server on the control connection
++ and the data transfer commences on the data connection.
++
++ ii) Firewall-Friendly client/server data exchange (as discussed
++ in [RFC-1579]) using the PASV command to reverse the direction
++ of the data connection.
++
++ - The client requests that the server open a port, the server
++ obtains a port and returns the address and port number to the
++ client. The client connects to the server on this port. The
++ client issues a send or receive request on the control
++ connection and the data transfer commences on the data
++ connection.
++
++ iii) Client initiated server/server data exchange (proxy or
++ PASV connections)
++
++ - The client requests that server A opens a port, server A
++ obtains a port and returns it to the client. The client sends
++ this port number to server B. Server B connects to server A.
++ The client sends a send or receive request to server A and the
++ complement to server B and the data transfer commences. In
++ this model server A is the proxy or PASV host and is a client
++ for the Data Connection to server B.
++
++ For i) and ii) the FTP client will be the TLS client and the FTP
++ server will be the TLS server.
++
++ That is to say, it does not matter which side initiates the
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 6]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ connection with a connect() call or which side reacts to the
++ connection via the accept() call, the FTP client as defined in
++ [RFC-959] is always the TLS client as defined in [RFC-2246].
++
++ In scenario iii) there is a problem in that neither server A nor
++ server B is the TLS client given the fact that an FTP server must act
++ as a TLS server for Firewall-Friendly FTP [RFC-1579]. Thus this is
++ explicitly excluded in the security extensions document [RFC-2228],
++ and in this document.
++
++
++
++7. Mechanisms for the AUTH Command
++
++ The AUTH command takes a single parameter to define the security
++ mechanism to be negotiated. As the SSL/TLS protocols self-negotiate
++ their levels there is no need to distinguish SSL vs TLS in the
++ application layer. The proposed mechanism name for negotiating
++ SSL/TLS will be the character string 'TLS'. This will allow the
++ client and server to negotiate SSL or TLS on the control connection
++ without altering the protection of the data channel. To protect the
++ data channel as well, the PBSZ, PROT command sequence should be used.
++ We call this "Explicit Data Channel Protection".
++
++ However, there are clients and servers that exist today which use the
++ string 'SSL' to indicate that negotiation should take place on the
++ control connection and that the data connection should be implicitly
++ protected (i.e. the PBSZ 0, PROT P command sequence is not required
++ but the client and server will protect the data channel as if it
++ had). This is "Implicit Data Channel Protection" and is included
++ primarily for backward compatibility.
++
++ To allow for streamlining of the negotiation, whilst allowing the
++ 'SSL' string to sink peacefully into disuse, the strings 'TLS-P' and
++ 'TLS-C' will also be defined. 'TLS-C' will be a synonym for 'TLS'
++ and 'TLS-P' a synonym for 'SSL'. Thus we allow for strict compliance
++ with [RFC-2228] by use of 'TLS' or 'TLS-C' and a quicker (2 less
++ commands) and perhaps more sensible option 'TLS-P' which will
++ implicitly secure the data connection at the same time as securing
++ the control connection.
++
++ Note: Regardless of the manner in which the data connection is
++ secured (either implicitly by use of 'TLS-P', 'SSL' or connection to
++ a well-known port for FTP protocol over TLS, or explicitly by use of
++ the PBSZ/PROT sequence) the data connection state may be modified by
++ the client issuing the PROT command with the new desired level of
++ data channel protection and the server replying in the affirmative.
++ This data channel protection negotiation can happen at any point in
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 7]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ the session (even straight after a PORT or PASV command) and as often
++ as is required.
++
++ See also Section 16, "IANA Considerations".
++
++
++8. SASL Considerations
++
++ SASL is the Simple Authentication Security Layer. Currently, its
++ definition can be found in the internet draft [RFC-2222]. This
++ document attempts to define the means by which a connection-based
++ protocol may identify and authenticate a client user to a server,
++ with additional optional negotiation of protection for the remainder
++ of that session.
++
++ Unfortunately, the SASL paradigm does not fit in neatly with the FTP-
++ TLS protocol, mainly due to the fact that FTP uses two (independent)
++ connections, and under FTP-TLS these may be at different (and
++ possibly renegotiable) protection levels. Consequently, it is
++ envisaged that SASL will sit underneath TLS on the control
++ connection, and TLS (on both, either or neither connection) will be
++ used for privacy and integrity (with optional authentication from TLS
++ on either connection).
++
++
++9. Data Connection Security
++
++ The Data Connection security level is determined by two factors.
++
++ 1) The mechanism used to negotiate security on the control
++ connection will dictate the default (i.e. un-negotiated) security
++ level of the data port.
++
++ 2) The PROT command, as specified in [RFC-2228] allows
++ client/server negotiation of the security level of the data
++ connection. Once a PROT command has been issued by the client and
++ accepted by the server by returning the '200' reply, the security
++ of subsequent data connections should be at that level until
++ another PROT command is issued and accepted; the session ends; or
++ the security of the session (via an AUTH command) is re-
++ negotiated).
++
++ Data Connection Security Negotiation (the PROT command)
++
++ Note: In line with [RFC-2228], there is no facility for securing
++ the Data connection with an insecure Control connection.
++
++ The command defined in [RFC-2228] to negotiate data connection
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 8]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ security is the PROT command. As defined there are four values
++ that the PROT command parameter can take.
++
++ 'C' - Clear - neither Integrity nor Privacy
++
++ 'S' - Safe - Integrity without Privacy
++
++ 'E' - Confidential - Privacy without Integrity
++
++ 'P' - Private - Integrity and Privacy
++
++ As TLS negotiation encompasses (and exceeds) the
++ Safe/Confidential/Private distinction, only Private (use TLS) and
++ Clear (don't use TLS) are used.
++
++ For TLS, the data connection can have one of two security levels.
++
++ 1) Clear
++
++ 2)Private
++
++ With 'Clear' protection level, the data connection is made without
++ TLS at all. Thus the connection is unauthenticated and has no
++ privacy or integrity. This might be the desired behaviour for
++ servers sending file lists, pre-encrypted data or non-sensitive
++ data (e.g. for anonymous FTP servers).
++
++ If the data connection security level is 'Private' then a TLS
++ negotiation must take place, to the satisfaction of the Client and
++ Server prior to any data being transmitted over the connection.
++ The TLS layers of the Client and Server will be responsible for
++ negotiating the exact TLS Cipher Suites that will be used (and
++ thus the eventual security of the connection).
++
++
++ In addition, the PBSZ (protection buffer size) command, as
++ detailed in [RFC-2228], is compulsory prior to any PROT command.
++ This document also defines a data channel encapsulation mechanism
++ for protected data buffers. For FTP-TLS, which appears to the FTP
++ application as a streaming protection mechanism, this is not
++ required. Thus the PBSZ command must still be issued, but must
++ have a parameter of '0' to indicate that no buffering is taking
++ place and the data connection should not be encapsulated. Note
++ that PBSZ 0 is not in the grammar of [RFC-2228], section 8.1,
++ where it is stated:
++ PBSZ ::= any
++ decimal integer from 1 to (2^32)-1
++ However it should be noted that using a value of '0' to mean a
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 9]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ streaming protocol is a reasonable use of '0' for that parameter
++ and is not ambiguous.
++
++ Initial Data Connection Security
++
++ For backward compatibility and ease of implementation the
++ following rules govern the initial expected protection setting of
++ the data connection.
++
++ Connections accepted on the 'secure FTP' port (see
++ {FTP-TLSPORT}).
++ The initial state of the data connection will be 'Private'
++ (Although this does not follow [RFC-2228], this is how such
++ clients tend to work today).
++
++ Connections accepted on the normal FTP port {FTP-PORT} with
++ TLS/SSL negotiated via an 'AUTH SSL' command.
++ The initial state of the data connection will be 'Private'
++ (Although this does not follow [RFC-2228], this is how such
++ clients tend to work today).
++
++ Connections accepted on the normal FTP port {FTP-PORT} with
++ TLS/SSL negotiated via an 'AUTH TLS' command.
++ The initial state of the data connection will be 'Clear'
++ (this is the correct behaviour as indicated by [RFC-2228].)
++
++ Note: Connections made on other ports may be still behave in one
++ of these ways, but that will be a local configuration issue.
++
++
++10. A Discussion of Negotiation Behaviour
++
++ All these discussions assume that the negotiation has taken place by
++ issuing the AUTH command with a mechanism that does not implicitly
++ protect the data channel. Using a mechanism which does implicitly
++ secure the data channel or connecting to a port which is implicitly
++ protected will have similar issues.
++
++ 10.1. The server's view of the control connection
++
++ A server may have a policy statement somewhere that might:
++
++ - Deny any command before TLS is negotiated (this might cause
++ problems if a SITE or some such command is required prior to
++ login)
++ - Deny certain commands before TLS is negotiated (such as USER,
++ PASS or ACCT)
++ - Deny insecure USER commands for certain users (e.g. not
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 10]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ ftp/anonymous)
++ - Deny secure USER commands for certain users (e.g.
++ ftp/anonymous)
++ - Define the level(s) of TLS/SSL to be allowed
++ - Define the CipherSuites allowed to be used (perhaps on a per
++ host/domain/... basis)
++ - Allow TLS authentication as a substitute for local
++ authentication.
++ - Define data connection policies (see next section)
++
++ Note: The TLS negotiation may not be completed satisfactorily
++ for the server, in which case it can be one of these states.
++
++ The TLS negotiation failed completely
++
++ In this case, the control connection should still be up in
++ unprotected mode and the server should issue an unprotected
++ '421' reply to end the session.
++
++ The TLS negotiation completed successfully, but the server
++ decides that the session parameters are not acceptable (e.g.
++ Distinguished Name in the client certificate is not
++ permitted to use the server)
++
++ In this case, the control connection should still be up in a
++ protected state, so the server can either continue to refuse to
++ service commands or issue a '421' reply and close the
++ connection.
++
++ The TLS negotiation failed during the TLS handshake
++
++ In this case, the control connection is in an unknown state and
++ the server should simply drop the control connection.
++
++ Server code will be responsible for implementing the required
++ policies and ensuring that the client is prevented from
++ circumventing the chosen security by refusing to service those
++ commands that are against policy.
++
++ 10.2. The server's view of the data connection
++
++ The server can take one of four basic views of the data connection
++
++ 1 - Don't allow encryption at all (in which case the PROT
++ command should not allow any value other than 'C' - if it is
++ allowed at all)
++ 2 - Allow the client to choose protection or not
++ 3 - Insist on data protection (in which case the PROT command
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 11]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ must be issued prior to the first attempted data transfer)
++ 4 - Decide on one of the above three for each and every data
++ connection
++
++ The server should only check the status of the data protection
++ level (for options 3 and 4 above) on the actual command that will
++ initiate the data transfer (and not on the PORT or PASV). The
++ following commands cause data connections to be opened and thus
++ may be rejected (before any 1xx) message due to an incorrect PROT
++ setting.
++
++
++ STOR
++ RETR
++ NLST
++ LIST
++ STOU
++ APPE
++ MLST (if [FTP-EXT] is implemented)
++ MLSD (if [FTP-EXT] is implemented)
++
++
++ The reply to indicate that the PROT setting is incorrect is
++ '521 data connection cannot be opened with this PROT setting'
++ If the protection level indicates that TLS is required, then it
++ should be negotiated once the data connection is made. Thus, the
++ '150' reply only states that the command can be used given the
++ current PROT level. Should the server not like the TLS
++ negotiation then it will close the data port immediately and
++ follow the '150' command with a '522' reply indicating that the
++ TLS negotiation failed or was unacceptable. (Note: this means
++ that the application can pass a standard list of CipherSuites to
++ the TLS layer for negotiation and review the one negotiated for
++ applicability in each instance).
++
++ It is quite reasonable for the server to insist that the data
++ connection uses a TLS cached session. This might be a cache of a
++ previous data connection or of the control connection. If this is
++ the reason for the the refusal to allow the data transfer then the
++ '522' reply should indicate this.
++ Note: this has an important impact on client design, but allows
++ servers to minimise the cycles used during TLS negotiation by
++ refusing to perform a full negotiation with a previously
++ authenticated client.
++
++ It should be noted that the TLS authentication of the server will
++ be authentication of the server host itself and not a user on the
++ server host.
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 12]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ 10.3. The client's view of the control connection
++
++ In most cases it is likely that the client will be using TLS
++ because the server would refuse to interact insecurely. To allow
++ for this, clients must be able to be flexible enough to manage the
++ securing of a session at the appropriate time and still allow the
++ user/server policies to dictate exactly when in the session the
++ security is negotiated.
++
++ In the case where it is the client that is insisting on the
++ securing of the session, it will need to ensure that the
++ negotiations are all completed satisfactorily and will need to be
++ able to inform the user sensibly should the server not support, or
++ be prepared to use, the required security levels.
++
++ Clients must be coded in such a manner as to allow the timing of
++ the AUTH, PBSZ and PROT commands to be flexible and dictated by
++ the server. It is quite reasonable for a server to refuse certain
++ commands prior to these commands, similarly it is quite possible
++ that a SITE or quoted command might be needed by a server prior to
++ the AUTH. A client must allow a user to override the timing of
++ these commands to suit a specific server.
++ For example, a client should not insist on sending the AUTH as the
++ first command in a session, nor should it insist on issuing a
++ PBSZ, PROT pair directly after the AUTH. This may well be the
++ default behaviour, but must be overridable by a user.
++
++ Note: The TLS negotiation may not be completed satisfactorily for
++ the client, in which case it will be in one of these states:
++
++ The TLS negotiation failed completely
++
++ In this case, the control connection should still be up in
++ unprotected mode and the client should issue an unprotected
++ QUIT command to end the session.
++
++ The TLS negotiation completed successfully, but the client
++ decides that the session parameters are not acceptable (e.g.
++ Distinguished Name in certificate is not the actual server
++ expected)
++
++ In this case, the control connection should still be up in a
++ protected state, so the client should issue a protected QUIT
++ command to end the session.
++
++ The TLS negotiation failed during the TLS handshake
++
++ In this case, the control connection is in an unknown state
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 13]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ and the client should simply drop the control connection.
++
++ 10.4. The client's view of the data connection
++
++ Client security policies
++
++ Clients do not typically have 'policies' as such, instead they
++ rely on the user defining their actions and, to a certain extent,
++ are reactive to the server policy. Thus a client will need to
++ have commands that will allow the user to switch the protection
++ level of the data connection dynamically, however, there may be a
++ general 'policy' that attempts all LIST and NLST commands on a
++ Clear connection first (and automatically switches to Private if
++ it fails). In this case there would need to be a user command
++ available to ensure that a given data transfer was not attempted
++ on an insecure data connection.
++
++ Clients also need to understand that the level of the PROT setting
++ is only checked for a particular data transfer after that transfer
++ has been requested. Thus a refusal by the server to accept a
++ particular data transfer should not be read by the client as a
++ refusal to accept that data protection level in toto, as not only
++ may other data transfers be acceptable at that protection level,
++ but it is entirely possible that the same transfer may be accepted
++ at the same protection level at a later point in the session.
++
++ It should be noted that the TLS authentication of the client
++ should be authentication of a user on the client host and not the
++ client host itself.
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 14]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++11. Who negotiates what, where and how
++
++ 11.1. Do we protect at all ?
++
++ Client issues AUTH , server accepts or rejects.
++ If server needs AUTH, then it refuses to accept certain commands
++ until it gets a successfully protected session.
++
++ 11.2. What level of protection do we use on the Control connection ?
++
++ Decided entirely by the TLS CipherSuite negotiation.
++
++ 11.3. Do we protect data connections in general ?
++
++ Client issues PROT command, server accepts or rejects.
++
++
++ 11.4. Is protection required for a particular data transfer ?
++
++ A client would already have issued a PROT command if it required
++ the connection to be protected.
++ If a server needs to have the connection protected then it will
++ reply to the STOR/RETR/NLST/... command with a '522' indicating
++ that the current state of the data connection protection level is
++ not sufficient for that data transfer at that time.
++
++ 11.5. What level of protection is required for a particular data
++ transfer ?
++
++ Decided entirely by the TLS CipherSuite negotiation.
++
++ Thus it can be seen that, for flexibility, it is desirable for the
++ FTP application to be able to interact with the TLS layer upon which
++ it sits to define and discover the exact TLS CipherSuites that are to
++ be/have been negotiated and make decisions accordingly. However it
++ should be entirely possible, using the mechanisms described in this
++ document, to have a TLS client or server sitting on top of a generic
++ 'TLS socket layer'. In this case, interoperability for a client with
++ a smart TLS-aware server may not be possible due to server policies.
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 15]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++12. Timing Diagrams
++
++ 12.1. Establishing a protected session
++
++ Client Server
++ control data data control
++====================================================================
++
++ socket()
++ bind()
++ socket()
++ connect() ----------------------------------------------> accept()
++ AUTH TLS ---------------------------------------------->
++ <---------------------------------------------- 234
++ TLSneg() <----------------------------------------------> TLSneg()
++ PBSZ 0 ---------------------------------------------->
++ <---------------------------------------------- 200
++ PROT P ---------------------------------------------->
++ <---------------------------------------------- 200
++ USER fred ---------------------------------------------->
++ <---------------------------------------------- 331
++ PASS pass ---------------------------------------------->
++ <---------------------------------------------- 230
++
++Note: the order of the PBSZ/PROT pair and the USER/PASS pair (with
++respect to each other) is not important (i.e. the USER/PASS can happen
++prior to the PBSZ/PROT - or indeed the server can refuse to allow a
++PBSZ/PROT pair until the USER/PASS pair has happened).
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 16]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ 12.2. A standard data transfer without protection.
++
++ Client Server
++ control data data control
++====================================================================
++
++ socket()
++ bind()
++ PORT w,x,y,z,a,b ----------------------------------------->
++ <----------------------------------------------------- 200
++ STOR file ------------------------------------------------>
++ socket()
++ bind()
++ <----------------------------------------------------- 150
++ accept() <----------- connect()
++ write() -----------> read()
++ close() -----------> close()
++ <----------------------------------------------------- 226
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 17]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ 12.3. A firewall-friendly data transfer without protection
++
++ Client Server
++ control data data control
++====================================================================
++
++ PASV -------------------------------------------------------->
++ socket()
++ bind()
++ <------------------------------------------ 227 (w,x,y,z,a,b)
++ socket()
++ STOR file --------------------------------------------------->
++ connect() ----------> accept()
++ <-------------------------------------------------------- 150
++ write() ----------> read()
++ close() ----------> close()
++ <-------------------------------------------------------- 226
++
++
++ Note: Implementors should be aware that then connect()/accept()
++ function is performed prior to the receipt of the reply from the
++ STOR command. This contrasts with situation when (non-firewall-
++ friendly) PORT is used prior to the STOR, and the accept()/connect()
++ is performed after the reply from the aforementioned STOR has been
++ dealt with.
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 18]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ 12.4. A standard data transfer with protection
++
++ Client Server
++ control data data control
++====================================================================
++
++ socket()
++ bind()
++ PORT w,x,y,z,a,b -------------------------------------------->
++ <-------------------------------------------------------- 200
++ STOR file --------------------------------------------------->
++ socket()
++ bind()
++ <-------------------------------------------------------- 150
++ accept() <---------- connect()
++ TLSneg() <----------> TLSneg()
++ TLSwrite() ----------> TLSread()
++ close() ----------> close()
++ <-------------------------------------------------------- 226
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 19]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ 12.5. A firewall-friendly data transfer with protection
++
++ Client Server
++ control data data control
++====================================================================
++
++ PASV -------------------------------------------------------->
++ socket()
++ bind()
++ <------------------------------------------ 227 (w,x,y,z,a,b)
++ socket()
++ STOR file --------------------------------------------------->
++ connect() ----------> accept()
++ <-------------------------------------------------------- 150
++ TLSneg() <---------> TLSneg()
++ TLSwrite() ---------> TLSread()
++ close() ---------> close()
++ <-------------------------------------------------------- 226
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 20]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++13. Implications of [FTP-EXT]
++
++ 13.1. MLST and MLSD
++
++ MLST and MLSD are directory listing commands and should be treated
++ in the same manner as NLST and LIST for the purposes of this
++ document.
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 21]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++14. Discussion of the 'REIN' command
++
++ The 'REIN' command, defined in [RFC-959], allows the user to reset
++ the state of the FTP session.
++ REINITIALIZE (REIN)
++ This command terminates a USER, flushing all I/O and account
++ information, except to allow any transfer in progress to be
++ completed. All parameters are reset to the default settings
++ and the control connection is left open. This is identical to
++ the state in which a user finds himself immediately after the
++ control connection is opened. A USER command may be expected
++ to follow.
++ The defined behaviour for TLS protected FTP sessons will depend on
++ the manner of session initialisation.
++ If the session has been explicity protected (see section 4.1) then
++ the TLS session(s) will be cleared and the control and data
++ connections revert to unprotected, clear communications. It will be
++ acceptable to use cached TLS sessions for subsequent connections,
++ however a server should not mandate this.
++ If the session is implicitly protected (see section 4.2) then the
++ control connection will continue to be protected using the exisiting
++ negotiated TLS session and the data connection will revert to being
++ implicitly protected, irrespective of any 'PROT' commands preceding
++ the 'REIN'.
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 22]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++15. Security Considerations
++
++ This entire document deals with security considerations related to
++ the File Transfer Protocol.
++
++ 15.1. Verification of Authentication tokens
++
++ 15.1.1. Server Certificates
++
++ Although it is entirely an implementation decision, it is
++ recommended that certificates used for server authentication of
++ the TLS session contain the server identification information
++ in a similar manner to those used for http servers. (i.e.
++ SubjectCommonName or SubjectAltName of type dNSName).
++
++ Note that, if there is any future extensions to the FTP
++ protocol to allow multi-homed servers, then the interaction of
++ such a mechanism, the REIN commands and the certificate
++ presented by the server in the TLS handshake will need to be
++ considered carefully.
++
++ 15.1.2. Client Certificates
++
++ - Deciding which client certificates to allow and defining
++ which fields define what authentication information is entirely
++ a server implementation issue.
++
++ - It is also server implementation issue to decide if the
++ authentication token presented for the data connection must
++ match the one used for the corresponding control connection.
++
++ 15.2. Addressing FTP Security Considerations [RFC-2577]
++
++ 15.2.1. Bounce Attack
++
++ A bounce attack should be harder in a secured FTP environment
++ because:
++
++ - The FTP server that is being used to initiate a false
++ connection will always be a 'server' in the TLS context.
++ Therefore, only services that act as 'clients' in the TLS
++ context could be vulnerable. This would be a counter-
++ intuitive way to implement TLS on a service.
++
++ - The FTP server would detect that the authentication
++ credentials for the data connection are not the same as
++ those for the control connection, thus the server policies
++ could be set to drop the data connection.
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 23]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ - Genuine users are less likely to initiate such attacks
++ when the authentication is strong and malicious users are
++ less likely to gain access to the FTP server if the
++ authentication is not easily subverted (password guessing,
++ network tracing, etc...)
++
++ 15.2.2. Restricting Access
++
++ This document presents a strong mechanism for solving the issue
++ raised in this section.
++
++ 15.2.3. Protecting Passwords
++
++ The twin solutions of strong authentication and data
++ confidentiality ensure that this is not an issue when TLS is
++ used to protect the control session.
++
++ 15.2.4. Privacy
++
++ The TLS protocol ensures data confidentiality by encryption.
++ Privacy (e.g. access to download logs, user profile
++ information, etc...) is outside the scope of this document (and
++ [RFC-2577] presumably)
++
++ 15.2.5. Protecting Usernames
++
++ This is not an issue when TLS is used as the primary
++ authentication mechanism.
++
++ 15.2.6. Port Stealing
++
++ This proposal will do little for the Denial of Service element
++ of this section, however, strong authentication on the data
++ connection will prevent unauthorised connections retrieving or
++ submitting files.
++
++ 15.2.7. Software-Base Security Problems
++
++ Nothing in this proposal will affect the discussion in this
++ section.
++
++
++
++
++16. IANA Considerations
++
++ {FTP-PORT} - The port assigned to the FTP control connection is 21.
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 24]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ {FTP-TLSPORT} - A port to be assigned by the IANA for native TLS FTP
++ connections on the control socket. This has been provisionally
++ reserved as port 990.
++
++ {TLS-PARM} - A parameter for the AUTH command to indicate that TLS is
++ required. It is recommended that 'TLS', 'TLS-C', 'SSL' and 'TLS-P'
++ are acceptable, and mean the following :-
++
++ 'TLS' or 'TLS-C' - the TLS protocol or the SSL protocol will be
++ negotiated on the control connection. The default protection
++ setting for the Data connection is 'Clear'.
++
++ 'SSL' or 'TLS-P' - the TLS protocol or the SSL protocol will be
++ negotiated on the control connection. The default protection
++ setting for the Data connection is 'Private'. This is primarily
++ for backward compatibility.
++
++ Note - [RFC-2228] states that these parameters are case-
++ insensitive.
++
++
++17. Network Management
++
++ NONE
++
++
++18. Internationalization
++
++ NONE
++
++
++19. Scalability & Limits
++
++ There are no issues other than those concerned with the ability of
++ the server to refuse to have a complete TLS negotiation for each and
++ every data connection, which will allow servers to retain throughput
++ whilst using cycles only when necessary.
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 25]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++20. Applicability
++
++ This mechanism is generally applicable as a mechanism for securing
++ the FTP protocol. It is unlikely that anonymous FTP clients or
++ servers will require such security (although some might like the
++ authentication features without the privacy).
++
++
++21. Acknowledgements
++
++ o Netscape Communications Corporation for the original SSL protocol.
++
++ o Eric Young for the SSLeay libraries.
++
++ o University of California, Berkley for the original implementations
++ of FTP and ftpd on which the initial implementation of these
++ extensions were layered.
++
++ o IETF CAT working group.
++
++ o IETF TLS working group.
++
++ o IETF FTPEXT working group.
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 26]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++22. References
++
++ [RFC-959] J. Postel, "File Transfer Protocol"
++ RFC 959, October 1985.
++
++ [RFC-1579] Bellovin, S., "Firewall-Friendly FTP"
++ RFC 1579, February 1994.
++
++ [RFC-2222] J. Myers, "Simple Authentication and Security Layer"
++ RFC 2222, October 1997.
++
++ [RFC-2228] M. Horowitz, S. Lunt, "FTP Security Extensions"
++ RFC 2228, October 1997.
++
++ [RFC-2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0"
++ RFC 2246, January 1999.
++
++ [RFC-2389] P Hethmon, R.Elz, "Feature Negotiation Mechanism for the
++ File Transfer Protocol"
++ RFC 2389, August 1998.
++
++ [RFC-2487] P Hoffman, "SMTP Service Extension for Secure SMTP over
++ TLS"
++ RFC 2487, January 1999.
++
++ [RFC-2577] M Allman, S Ostermann "FTP Security Considerations"
++ RFC 2577, May 1999.
++
++ [FTP-EXT] R Elz, P Hethmon "Extensions to FTP"
++ draft-ietf-ftpext-mlst-07.txt, June 1999.
++
++ [SRA-FTP] "SRA - Secure RPC Authentication for TELNET and FTP Version
++ 1.1"
++ file://ftp.funet.fi/security/login/telnet/doc/sra/sra.README
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 27]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++23. Authors' Contact Addresses
++
++Please send comments to Paul Ford-Hutchinson at the address below
++
++ Tim Hudson Paul Ford-Hutchinson
++ RSA Data Security IBM UK Ltd
++ Australia Pty Ltd PO Box 31
++ Birmingham Road
++ Warwick
++ United Kingdom
++ tel - +61 7 3227 4444 +44 1926 462005
++ fax - +61 7 3227 4400 +44 1926 496482
++email - tjh@rsasecurity.com.au paulfordh@uk.ibm.com
++
++ Martin Carpenter Eric Murray
++ Verisign Ltd Wave Systems Inc.
++email - mcarpenter@verisign.com ericm@lne.com
++
++ Volker Wiegand
++ SuSE Linux
++email - wiegand@suse.de
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 28]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ Appendices
++
++A. Summary of [RFC-2246]
++
++ The TLS protocol was developed by the IETF TLS working group. It is
++ based on the SSL protocol proposed by Netscape Communications
++ Corporation. The structure of the start of a TLS session allows
++ negotiation of the level of the protocol to be used - in this way, a
++ client or server can simultaneously support TLS and SSL and negotiate
++ the most appropriate for the connection.
++
++ The TLS protocol defines three security mechanisms that may be used
++ (almost) independently. They are Authentication, Integrity and
++ Privacy. It is possible to have an Authenticated session with no
++ Privacy and with or without Integrity (useful for anonymous FTP
++ sites, or sites with pre-encrypted data). For example, sessions with
++ Authentication, Privacy and Integrity would be useful for control
++ connections over an insecure network and data connections
++ transferring confidential material.
++
++ The TLS protocol allows unauthenticated sessions; server
++ authentication or client and server authentication. There is no
++ mechanism for authenticating a client without first authenticating
++ the server.
++
++ The basic mechanism of the TLS protocol is that (for an
++ Authenticated, Private session) asymmetric encryption is used to
++ authenticate clients and servers and exchange a session key for
++ symmetric encryption which is to be used for the rest of the session.
++
++ The structure of the TLS session initialisation is that the client
++ initiates the session with a 'ClientHello' message. The server will
++ respond with a 'ServerHello' and the session negotiation will
++ continue.
++
++ The TLS protocol allows session caching which is achieved by the
++ client requesting that the server re-use a session context (Cipher
++ Suite and symmetric key) in the ClientHello message. There is no
++ reason why a second connection could not request a 'cached' session
++ with the same context as an existing session.
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 29]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++B. Summary of [RFC-2228]
++
++
++
++ Extensions to FTP
++
++ The FTP Security Extensions document has 8 new commands to enhance
++ the FTP protocol to allow negotiation of security and exchange of
++ security data. Three of these commands (the AUTH, PBSZ and PROT
++ commands) are used by this document to allow an FTP client to
++ negotiate TLS with the server. The other commands are not required.
++
++ i) AUTH
++
++ This command is a request by the client to use an authentication
++ and/or security mechanism.
++
++ The client will issue an 'AUTH ' command
++ which will be a request to the server to secure the control
++ connection using the TLS (or SSL) protocol. It also governs the
++ initial protection setting of the data channel (which may be
++ changed by a subsequent PROT command).
++
++ ii) ADAT
++
++ This command is used to transmit security data required by the
++ security mechanism agreed in a preceding AUTH command.
++ This document does not use the ADAT command.
++
++ iii) PROT
++
++ This command is used by the client to instruct the type of
++ security that is required on the Data connection.
++
++ The 'PROT C' command will mean that TLS should not be used to
++ secure the data connection; 'PROT P' means that TLS should be
++ used. 'PROT E' and 'PROT S' are not defined and generate
++ a '536' reply from the server.
++
++ iv) PBSZ
++
++ This command is used to negotiate the size of the buffer to be
++ used during secured data transfer.
++
++ The PBSZ command must be issued prior to the PROT command. The
++ PBSZ command cannot be sent on an insecure control connection.
++ For FTP and TLS the only valid value for the parameter is '0', all
++ other values should receive a '200' reply with the text 'PBSZ=0'
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 30]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++ included.
++
++ v) CCC
++
++ This command is used to specify that the control channel no longer
++ requires protection.
++ This document does not use the CCC command.
++
++ vi) MIC
++
++ This command is used to send a normal FTP command with integrity
++ protection.
++ This document does not use the MIC command.
++
++ vii) CONF
++
++ This command is used to send a normal FTP command with
++ confidentiality protection (encrypted).
++ This document does not use the CONF command.
++
++ viii) ENC
++
++ This command is used to send a normal FTP command with
++ confidentiality and integrity protection.
++ This document does not use the ENC command.
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 31]
++
++
++
++
++
++Internet-Draft Secure FTP using TLS 18th September, 2000
++
++
++Full Copyright Statement
++
++ Copyright (C) The Internet Society (2000). All Rights Reserved.
++
++ This document and translations of it may be copied and furnished to
++ others, and derivative works that comment on or otherwise explain it
++ or assist in its implementation may be prepared, copied, published
++ and distributed, in whole or in part, without restriction of any
++ kind, provided that the above copyright notice and this paragraph are
++ included on all such copies and derivative works. However, this
++ document itself may not be modified in any way, such as by removing
++ the copyright notice or references to the Internet Society or other
++ Internet organizations, except as needed for the purpose of
++ developing Internet standards in which case the procedures for
++ copyrights defined in the Internet Standards process must be
++ followed, or as required to translate it into languages other than
++ English.
++
++ The limited permissions granted above are perpetual and will not be
++ revoked by the Internet Society or its successors or assigns.
++
++ This document and the information contained herein is provided on an
++ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
++ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
++ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
++ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
++ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
++
++This document expires on 17th March, 2001
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand [Page 32]
++
++
+diff -ruN proftpd-1.2.10-old/include/buildstamp.h proftpd-1.2.10/include/buildstamp.h
+--- proftpd-1.2.10-old/include/buildstamp.h 1970-01-01 01:00:00.000000000 +0100
++++ proftpd-1.2.10/include/buildstamp.h 2004-09-14 23:22:09.000000000 +0200
+@@ -0,0 +1 @@
++#define BUILD_STAMP "do mrt 22 18:28:32 CET 2001"
+diff -ruN proftpd-1.2.10-old/README.ftpasswd proftpd-1.2.10/README.ftpasswd
+--- proftpd-1.2.10-old/README.ftpasswd 1970-01-01 01:00:00.000000000 +0100
++++ proftpd-1.2.10/README.ftpasswd 2004-09-14 23:22:09.000000000 +0200
+@@ -0,0 +1,82 @@
++---------------------------------------------------------------------------
++TJ Saunders
++2000-01-09
++---------------------------------------------------------------------------
++
++usage: ftpasswd [ -h ] [ --group | --passwd ]
++
++ If used with --passwd, ftpasswd creates a file in the passwd(5) format,
++ suitable for use with proftpd's AuthUserFile configuration directive.
++ You will be prompted for the password to use of the user, which will be
++ encrypted, and written out as the encrypted string.
++
++ By default, using --passwd will write output to "./ftpd.passwd".
++
++ Options:
++ -F write output to specified file, rather than "./ftpd.passwd"
++ --file
++
++ -f if the file to be used already exists, delete it and write a
++ --force new one.
++
++ --gid primary group ID for this user (optional, will default to
++ given --uid value if absent)
++
++ -h displays this message
++ --help
++
++ --home home directory for the user (required)
++
++ --name name of the user account (required). If the name does not
++ exist in the specified output-file, an entry will be created
++ for her. Otherwise, the given fields will be updated.
++
++ --shell shell for the user (required). Recommended: /bin/false
++
++ --uid numerical user ID (required)
++
++ --use-cracklib
++ causes ftpasswd to use Alec Muffet's cracklib routines in
++ order to determine and prevent the use of bad or weak
++ passwords. The optional path to this option specifies
++ the path to the dictionary files to use -- default path
++ is "/usr/lib/cracklib_dict". This requires the Perl
++ Crypt::Cracklib module to be installed on your system.
++
++ If used with --group, ftpasswd creates a file in the group(5) format,
++ suitable for use with proftpd's AuthGroupFile configuration directive.
++
++ By default, using --group will write output to "./ftpd.group".
++
++ Options:
++ --enable-group-passwd
++ prompt for a group password. This is disabled by default.
++
++ -F write output to specified file, rather than "./ftpd.group"
++ --file
++
++ -f if the file be used already exists, delete it and write a new
++ --force one.
++
++ --gid numerical group ID (required)
++
++ -h
++ --help displays this message
++
++ -m
++ --member user to be a member of the group. This argument may be used
++ multiple times to specify the full list of users to be members
++ of this group.
++
++ --name name of the group (required). If the name does not exist in
++ the specified output-file, an entry will be created for them.
++ Otherwise, the given fields will be updated.
++
++ --use-cracklib
++ causes ftpasswd to use Alec Muffet's cracklib routines in
++ order to determine and prevent the use of bad or weak
++ passwords. The optional path to this option specifies
++ the path to the dictionary files to use -- default path
++ is "/usr/lib/cracklib_dict". This requires the Perl
++ Crypt::Cracklib module to be installed on your system.
++
--- proftpd-1.2.10.orig/debian/patches/02.mod_pam.c.change.pam.name.diff
+++ proftpd-1.2.10/debian/patches/02.mod_pam.c.change.pam.name.diff
@@ -0,0 +1,12 @@
+diff -urN proftpd-1.2.8/modules/mod_auth_pam.c proftpd-1.2.8-debian/modules/mod_auth_pam.c
+--- proftpd-1.2.8/modules/mod_auth_pam.c 2003-01-02 19:25:20.000000000 +0100
++++ proftpd-1.2.8-debian/modules/mod_auth_pam.c 2003-03-17 15:09:28.000000000 +0100
+@@ -57,7 +57,7 @@
+ #endif /* HAVE_PAM_PAM_APPL_H */
+
+ static pam_handle_t * pamh = NULL;
+-static char * pamconfig = "ftp";
++static char * pamconfig = "proftpd";
+ static char * pam_user = NULL;
+ static char * pam_pass = NULL;
+ static size_t pam_user_len = 0;
--- proftpd-1.2.10.orig/debian/patches/33.documentation.diff
+++ proftpd-1.2.10/debian/patches/33.documentation.diff
@@ -0,0 +1,211 @@
+diff -ruN proftpd-1.2.10-old/doc/Configuration.html proftpd-1.2.10/doc/Configuration.html
+--- proftpd-1.2.10-old/doc/Configuration.html 2003-10-30 21:38:16.000000000 +0100
++++ proftpd-1.2.10/doc/Configuration.html 2006-01-11 15:09:12.000000000 +0100
+@@ -6068,8 +6068,10 @@
+ >Determines the directory a user is placed in after logging in.
+ By default, the user is put in their home directory. The specified
+ directory can be relative to the user's home directory.
+-NOTE: if the specified directory is not available
+-the user will not be able to log in.