[Git][debian-proftpd-team/proftpd][master] 3 commits: New upstream version 1.3.7a+dfsg

Francesco Paolo Lovergine frankie at debian.org
Thu Dec 10 21:03:50 GMT 2020



Francesco Paolo Lovergine pushed to branch master at Debian ProFTPD Team / proftpd


Commits:
b57a967d by Francesco Paolo Lovergine at 2020-12-10T19:36:50+01:00
New upstream version 1.3.7a+dfsg
- - - - -
33cb94b8 by Francesco Paolo Lovergine at 2020-12-10T19:36:50+01:00
Update upstream source from tag 'upstream/1.3.7a+dfsg'

Update to upstream version '1.3.7a+dfsg'
with Debian dir d426c7cda4a791b96ff544bb855630a0eca42e95
- - - - -
c0388e58 by Francesco Paolo Lovergine at 2020-12-10T22:03:18+01:00
Fixed #977090

- - - - -


5 changed files:

- debian/changelog
- − doc/rfc/draft-bonachea-sftp-00.txt
- − doc/rfc/draft-ietf-ftpext-mlst-15.txt
- − doc/rfc/draft-ietf-ftpext-sec-consider-02.txt
- − doc/rfc/rfc0959.txt


Changes:

=====================================
debian/changelog
=====================================
@@ -1,3 +1,10 @@
+proftpd-dfsg (1.3.7a+dfsg-1) unstable; urgency=medium
+
+  * Re-uploaded without the upstream distributed IETF RFC docs.
+    (closes: #977090)
+
+ -- Francesco Paolo Lovergine <frankie at debian.org>  Thu, 10 Dec 2020 22:02:18 +0100
+
 proftpd-dfsg (1.3.7a-2) unstable; urgency=medium
 
   [ Hilmar Preusse ]


=====================================
doc/rfc/draft-bonachea-sftp-00.txt deleted
=====================================
@@ -1,276 +0,0 @@
-Network Working Group                                    D. Bonachea
-<draft-bonachea-sftp-00.txt>                             S. McPeak
-Updates: RFC 2228
-Internet-Draft
-Expires in January, 2000                                 June, 1999
-
-             Protocol Negotiation Extensions to Secure FTP
-
-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/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   This document presents refinements to RFC 2228, "FTP Security
-   Extensions" (October 1997) [1].  It lends support for more efficient
-   and secure protocol negotiation in the presence of multiple protocol
-   possibilities, by adding one new optional command and several new
-   reply codes.
-
-   The following new optional command is introduced in this
-   specification:
-
-   DIGT (Protocol Negotiation Digest)
-
-   This document also seeks to solidify several issues that were left
-   underspecified in RFC 2228.  Specifically, it adds additional reply
-   codes to cover cases not mentioned in the original specification and
-   it defines a legal naming convention for security mechanisms.
-
-
-
-
-Bonachea & McPeak                                               [Page 1]
-
-INTERNET DRAFT          Extensions to Secure FTP           June 18, 1999
-
-
-1.   Introduction
-
-   Recently, the authors implemented the RFC 2228 protocol, FTP Security
-   Extensions [1].  This protocol extends the basic File Transfer
-   Protocol (FTP) specified in RFC 959 [2], adding security services
-   including authentication and privacy.  We assume the reader is
-   familiar with RFC 2228.
-
-   During the implementation of RFC 2228 we found it necessary and
-   useful to make several changes to the protocol.  This memo details
-   those changes.
-
-   Section 2 describes changes which extend RFC 2228, to improve
-   security and efficiency.  Section 3 closes specification holes in RFC
-   2228 itself. Section 4 lifts a RFC 959 restriction, thereby improving
-   total system security.
-
-2.   Protocol Negotiation Improvements
-
-   DIGT (Protocol Negotiation Digest) command
-
-   This new command provides a way for a client to verify that an
-   attacker didn't interfere with the protocol negotiation sequence.
-   This is important because a client that supports multiple security
-   mechanisms might be "tricked" into using its weakest security
-   mechanism by an attacker who interferes with protocol negotiation
-   (i.e. by modifying the appropriate mechanism acceptance replies to
-   look like refusals).  The client may issue this optional command at
-   any time after authentication is complete, and the server will reply
-   with a secure hash digest computed over the entire protocol
-   negotiation exchange. The client can then compare this digest to the
-   locally computed digest to verify that both server and client
-   experienced the same protocol negotiation sequence (i.e. there was no
-   outside interference).  The hash function is Sha1, and is computed
-   over the entire negotiation sequence from the first character in the
-   first client command (usually an AUTH), to the last character in the
-   server reply which indicates the security data exchange is complete
-   (the LF character on a 234 or 235 reply). The form of the server
-   reply to DIGT will be:
-
-   211 DIGT=base64data
-      ; base64data is a placeholder for the actual digest block,
-      ; which must be encoded using the base64 format, as
-      ; described in RFC 2228 (see [1] for details).
-
-   The server may also send a 502 response if the DIGT command is not
-   implemented.
-
-
-
-
-Bonachea & McPeak                                               [Page 2]
-
-INTERNET DRAFT          Extensions to Secure FTP           June 18, 1999
-
-
-   Note the efficacy of this security measure depends on the client
-   asking for the digest faster than an attacker can compromise the
-   current (weaker) security mechanism and substitute a modified digest.
-
-   Efficiency improvements to protocol negotiation
-
-   RFC 2228 allows for the possibility of clients and servers that
-   implement a large number of security mechanisms, yet it provides no
-   efficient means for the client to discover and request a supported
-   mechanism.  Under the RFC 2228 specification, the client repeatedly
-   issues AUTH commands for each security mechanism it supports (in
-   order of preference) until finding one the server will accept.  For
-   clients that implement a large number of mechanisms, this could
-   potentially lead to an unreasonably large number of network round
-   trips in order to complete the protocol negotiation sequence.  In
-   order to alleviate this problem, this specification adds two new
-   optional server reply codes that allow the server to reveal a list of
-   acceptable security mechanisms in a single reply. This enables the
-   client to perform the search locally and select an acceptable
-   mechanism in a single network roundtrip.
-
-   The new reply codes to the AUTH command are:
-
-   504 Security mechanism unrecognized. [LIST=mechlist]
-   504 Security mechanism unrecognized. [ILST=mechlist]
-
-   Here, mechlist is a space-delimited list of security mechanisms that
-   the server understands and might accept from this client. The keyword
-   LIST indicates that mechlist is a complete list of acceptable
-   security mechanisms, and any mechanisms not listed will be refused.
-   The keyword ILST indicates that mechlist is an incomplete list of
-   acceptable security mechanisms, and that other acceptable unlisted
-   security mechanisms might exist.  The square brackets are not to be
-   included in the actual reply, but indicate that the mechanism list is
-   optional.
-
-3. Amendments to RFC 2228
-
-   New server replies
-
-   This section presents several new server reply codes which were
-   missing in the original specification.
-
-   234 Security data exchange complete. [ADAT=base64data]
-    ;  This reply to AUTH indicates the security data exchange
-    ;  completed successfully.  The square brackets are not to be
-    ;  included in the reply, but indicate that security data in
-    ;  the reply is optional.
-
-
-
-Bonachea & McPeak                                               [Page 3]
-
-INTERNET DRAFT          Extensions to Secure FTP           June 18, 1999
-
-
-   This reply code existed in RFC 2228, but did not allow for the
-   possibility of the server sending security data (for protocols where
-   the only data exchange necessary is for the server to send a block to
-   the client).
-
-   503 Reauthentication is prohibited.
-    ;  This reply code to an AUTH indicates that a successful
-    ;  security data exchange has completed, and this server is
-    ;  unwilling to begin a new authentication session (the
-    ;  client must "hang up" and reconnect)
-
-   RFC 2228 specifies that a server may prohibit the client from
-   reissuing the AUTH command in order to establish new authentication,
-   but provides no reply code to communicate this.
-
-   PBSZ Negotiation
-
-   During PBSZ (Protocol Buffer Size) negotiation, the client proposes a
-   buffer size, and the server may accept this size, reply with a
-   smaller size, or give an error. The size agreed upon is subsequently
-   used during data transfers as a maximum bound on the size of each
-   encrypted block.  However, some protocol mechanisms have a minimum
-   encrypted block size, and RFC 2228 doesn't provide a way for the
-   server to indicate that the proposed block size is too small.  To
-   remedy this, this specification adds a new reply code:
-
-   538 PBSZ too small. [PBSZmin=numBytes]
-    ;  This reply to PBSZ indicates the proposed buffer size is
-    ;  unacceptably small. The server may also include an optional
-    ;  string of the form PBSZmin=numBytes to indicate the smallest
-    ;  buffer size it will accept. The square brackets are not to be
-    ;  included in the reply, but indicate that the PBSZmin argument
-    ;  in the reply is optional.
-
-   Protocol Mechanism Naming Specification
-
-   The guidelines provided by RFC 2228 for the naming of new protocol
-   mechanisms are somewhat vague, and as such are insufficient for the
-   purposes of successful protocol negotiation as described in section
-   2.  Following is a revised, more rigorous specification for the
-   naming of protocol mechanisms:
-
-   The protocol mechanism name must not exceed 255 characters, and may
-   only contain the characters with codes 33...126 in the USASCII
-   character set.  Names are case-insensitive.  All names must be
-   registered with the IANA, except names beginning with "X-", which are
-   reserved for local use.
-
-
-
-
-Bonachea & McPeak                                               [Page 4]
-
-INTERNET DRAFT          Extensions to Secure FTP           June 18, 1999
-
-
-4. Miscellaneous changes to RFC 2228
-
-   Port 20 restriction for outgoing server data connections:
-
-   RFC 2228 is a superset specification of RFC 959 [2], which defines
-   the basic FTP protocol. RFC 959 requires that while in active mode,
-   all outgoing data connections from the FTP server must be bound to
-   port 20, as a weak form of authentication. However, most FTP clients
-   fail to enforce this port restriction (i.e. they don't check).
-   However, implementation experience has shown that the port
-   restriction is also the only hindrance to running a legitimate RFC
-   2228 server as an entirely user-level proxy (which augments overall
-   system security). Because RFC 2228 provides more comprehensive
-   support for strong, cryptographic authentication mechanisms, it has
-   made the port 20 restriction for outgoing server data connections
-   obsolete, and the restriction is hereby lifted.
-
-5.  Security Considerations
-
-   This entire memo is about security mechanisms.
-
-6.  References
-
-   [1] - M. Horowitz and S. J. Lunt.  FTP Security Extensions.
-        RFC 2228, October, 1997
-
-   [2] - J. Postel and J. Reynolds.  File Transfer Protocol (FTP).
-        RFC 959, October, 1985
-
-7.  Authors' Addresses
-
-   Dan Bonachea
-   Computer Science Division
-   566 Soda Hall
-   Berkeley, CA 94720   USA
-   Phone: +1 510 642-8493
-   Email: bonachea at cs.berkeley.edu
-
-
-   Scott McPeak
-   Computer Science Division
-   566 Soda Hall
-   Berkeley, CA 94720   USA
-   Phone: +1 510 642-8493
-   Email: smcpeak at cs.berkeley.edu
-
-
-
-
-
-
-Bonachea & McPeak                                               [Page 5]


=====================================
doc/rfc/draft-ietf-ftpext-mlst-15.txt deleted
=====================================
The diff for this file was not included because it is too large.

=====================================
doc/rfc/draft-ietf-ftpext-sec-consider-02.txt deleted
=====================================
@@ -1,415 +0,0 @@
-
-
-
-FTPEXT Working Group                                         Mark Allman
-Internet Draft                              NASA Lewis/Sterling Software
-Expires: October, 1998                                   Shawn Ostermann    
-                                                         Ohio University    
-                                                             April, 1999
-    
-        
-                      FTP Security Considerations
-                <draft-ietf-ftpext-sec-consider-02.txt>
-    
-
-Status of this Memo
-                                    
-    This document is an Internet-Draft.  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.''
-
-    To learn the current status of any Internet-Draft, please check the
-    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
-    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
-    munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
-    ftp.isi.edu (US West Coast).
-
-    Distribution of this document is unlimited.  Please send comments
-    to the FTP Extension working group (FTPEXT-WG) of the Internet
-    Engineering Task Force (IETF) at <ftp-wg at hethmon.com>.
-    Subscription address is <ftp-wg-request at hethmon.com>.
-    Discussions of the group are archived at
-    <URL:http://w3.hethmon.com/ftpext/>.
-
-Abstract
-    
-    The specification for the File Transfer Protocol contains a number
-    of mechanisms that can be used to compromise network security.  The
-    FTP specification allows a client to instruct a server to transfer
-    files to a third machine.  This third-party mechanism, known as
-    proxy FTP, causes a well known security problem.  The FTP
-    specification also allows an unlimited number of attempts at
-    entering a user's password.  This allows brute force "password
-    guessing" attacks.  This document provides suggestions for system
-    administrators and those implementing FTP servers that will decrease
-    the security problems associated with FTP.
-
-1   Introduction
-
-    The File Transfer Protocol specification [PR85] provides a mechanism
-    that allows a client to establish an FTP control connection and
-    transfer a file between two FTP servers.  This "proxy FTP" mechanism
-
-Expires: April, 1999                                            [Page 1]
-
-draft-ietf-ftpext-sec-consider-02.txt                       October 1998
-
-    can be used to decrease the amount of traffic on the network; the
-    client instructs one server to transfer a file to another server,
-    rather than transferring the file from the first server to the
-    client and then from the client to the second server.  This is
-    particularly useful when the client connects to the network using a
-    slow link (e.g., a modem).  While useful, proxy FTP provides a
-    security problem known as a "bounce attack" [CERT97:27].  In
-    addition to the bounce attack, FTP servers can be used by attackers
-    to guess passwords using brute force.
-
-    This document does not contain a discussion of FTP when used in
-    conjunction with strong security protocols, such as IP Security.
-    These security concerns should be documented, however they are out
-    of the scope of this document.
-
-    This paper provides information for FTP server implementers and
-    system administrators, as follows.  Section 2 describes the FTP
-    "bounce attack".  Section 3 provides suggestions for minimizing the
-    bounce attack.  Section 4 provides suggestions for servers which
-    limit access based on network address.  Section 5 provides
-    recommendations for limiting brute force "password guessing" by
-    clients.  Next, section 6 provides a brief discussion of mechanisms
-    to improve privacy.  Section 7 provides a mechanism to prevent user
-    identity guessing.  Section 8 discusses the practice of port
-    stealing.  Finally, section 9 provides an overview of other FTP
-    security issues related to software bugs rather than protocol
-    issues.
-
-2   The Bounce Attack
-
-    The version of FTP specified in the standard [PR85] provides a
-    method for attacking well known network servers, while making the
-    perpetrators difficult to track down.  The attack involves sending
-    an FTP "PORT" command to an FTP server containing the network
-    address and the port number of the machine and service being
-    attacked.  At this point, the original client can instruct the FTP
-    server to send a file to the service being attacked.  Such a file
-    would contain commands relevant to the service being attacked (SMTP,
-    NNTP, etc.).  Instructing a third party to connect to the service,
-    rather than connecting directly, makes tracking down the perpetrator
-    difficult and can circumvent network-address-based access
-    restrictions.
-
-    As an example, a client uploads a file containing SMTP commands to
-    an FTP server.  Then, using an appropriate PORT command, the client
-    instructs the server to open a connection to a third machine's SMTP
-    port.  Finally, the client instructs the server to transfer the
-    uploaded file containing SMTP commands to the third machine.  This
-    may allow the client to forge mail on the third machine without
-    making a direct connection.  This makes it difficult to track
-    attackers.
-
-    
-
-
-Expires: April, 1999                                            [Page 2]
-
-draft-ietf-ftpext-sec-consider-02.txt                       October 1998
-
-3   Protecting Against the Bounce Attack
-
-    The original FTP specification [PR85] assumes that data connections
-    will be made using the Transmission Control Protocol (TCP) [Pos81].
-    TCP port numbers in the range 0 - 1023 are reserved for well known
-    services such as mail, network news and FTP control connections
-    [RP94].  The FTP specification makes no restrictions on the TCP port
-    number used for the data connection.  Therefore, using proxy FTP,
-    clients have the ability to tell the server to attack a well known
-    service on any machine.
-
-    To avoid such bounce attacks, it is suggested that servers not open
-    data connections to TCP ports less than 1024.  If a server receives
-    a PORT command containing a TCP port number less than 1024, the
-    suggested response is 504 (defined as "Command not implemented for
-    that parameter" by [PR85]).  Note that this still leaves non-well
-    known servers (those running on ports greater than 1023) vulnerable
-    to bounce attacks.
-    
-    Several proposals (e.g., [AOM98] and [Pis94]) provide a mechanism
-    that would allow data connections to be made using a transport
-    protocol other than TCP.  Similar precautions should be taken to
-    protect well known services when using these protocols.
-
-    Also note that the bounce attack generally requires that a
-    perpetrator be able to upload a file to an FTP server and later
-    download it to the service being attacked.  Using proper file
-    protections will prevent this behavior.  However, attackers can also
-    attack services by sending random data from a remote FTP server
-    which may cause problems for some services.
-
-    Disabling the PORT command is also an option for protecting against
-    the bounce attack.  Most file transfers can be made using only the
-    PASV command [Bel94].  The disadvantage of disabling the PORT
-    command is that one loses the ability to use proxy FTP, but proxy
-    FTP may not be necessary in a particular environment.
-
-4   Restricted Access
-
-    For some FTP servers, it is desirable to restrict access based on
-    network address.  For example, a server might want to restrict
-    access to certain files from certain places (e.g., a certain file
-    should not be transferred out of an organization).  In such a
-    situation, the server should confirm that the network address of the
-    remote hosts on both the control connection and the data connection
-    are within the organization before sending a restricted file.  By
-    checking both connections, a server is protected against the case
-    when the control connection is established with a trusted host and
-    the data connection is not.  Likewise, the client should verify the
-    IP address of the remote host after accepting a connection on a port
-    opened in listen mode to verify that the connection was made by the
-    expected server.
-
-    
-
-Expires: April, 1999                                            [Page 3]
-
-draft-ietf-ftpext-sec-consider-02.txt                       October 1998
-
-    Note that restricting access based on network address leaves the FTP
-    server vulnerable to "spoof" attacks.  In a spoof attack, for
-    example, an attacking machine could assume the host address of
-    another machine inside an organization and download files that are
-    not accessible from outside the organization.  Whenever possible,
-    secure authentication mechanisms should be used, such as those
-    outlined in [HL97].
-
-5   Protecting Passwords 
-    
-    To minimize the risk of brute force password guessing through the
-    FTP server, it is suggested that servers limit the number of
-    attempts that can be made at sending a correct password.  After a
-    small number of attempts (3-5), the server should close the control
-    connection with the client.  Before closing the control connection
-    the server must send a return code of 421 ("Service not available,
-    closing control connection." [PR85]) to the client.  In addition, it
-    is suggested that the server impose a 5 second delay before replying
-    to an invalid "PASS" command to diminish the efficiency of a brute
-    force attack.  If available, mechanisms already provided by the
-    target operating system should be used to implement the above
-    suggestions.
-
-    An intruder can subvert the above mechanisms by establishing
-    multiple, parallel control connections to a server.  To combat the
-    use of multiple concurrent connections, the server could either
-    limit the total number of control connections possible or attempt to
-    detect suspicious activity across sessions and refuse further
-    connections from the site.  However, both of these mechanisms open
-    the door to "denial of service" attacks, in which an attacker
-    purposely initiates the attack to disable access by a valid user.
-
-    Standard FTP [PR85] sends passwords in clear text using the "PASS"
-    command.  It is suggested that FTP clients and servers use alternate
-    authentication mechanisms that are not subject to eavesdropping
-    (such as the mechanisms being developed by the IETF Common
-    Authentication Technology Working Group [HL97]).
-
-6   Privacy
-
-    All data and control information (including passwords) is sent
-    across the network in unencrypted form by standard FTP [PR85].  To
-    guarantee the privacy of the information FTP transmits, a strong
-    encryption scheme should be used whenever possible.  One such
-    mechanism is defined in [HL97].
-
-7   Protecting Usernames
-
-    Standard FTP [PR85] specifies a 530 response to the USER command
-    when the username is rejected.  If the username is valid and a
-    password is required FTP returns a 331 response instead.  In order
-    to prevent a malicious client from determining valid usernames on a
-    server, it is suggested that a server always return 331 to the USER
-    
-
-Expires: April, 1999                                            [Page 4]
-
-draft-ietf-ftpext-sec-consider-02.txt                       October 1998
-
-    command and then reject the combination of username and password for
-    an invalid username.
-
-8   Port Stealing
-
-    Many operating systems assign dynamic port numbers in increasing
-    order.  By making a legitimate transfer, an attacker can observe the
-    current port number allocated by the server and ``guess'' the next
-    one that will be used.  The attacker can make a connection to this
-    port, thus denying another legimate client the ability to make a
-    transfer.  Alternativly, the attacker can steal a file meant for a
-    legitimate user.  In addition, an attacker can insert a forged file
-    into a data stream thought to come from an authenticated client.
-    This problem can be mitigated by making FTP clients and servers use
-    random local port numbers for data connections, either by requesting
-    random ports from the operating system or using system dependent
-    mechanisms.
-
-    
-9   Software-Base Security Problems
-
-    The emphasis in this document is on protocol-related security
-    issues.  There are a number of documented FTP security-related
-    problems that are due to poor implementation as well.  Although the
-    details of these types of problems are beyond the scope of this
-    document, it should be pointed out that the following FTP features
-    has been abused in the past and should be treated with great care by
-    future implementers:
-
-    Anonymous FTP
-    
-        Anonymous FTP refers to the ability of a client to connect to an
-        FTP server with minimal authentication and gain access to public
-        files.  Security problems arise when such a user can read all
-        files on the system or can create files. [CERT92:09] [CERT93:06]
-
-    Remote Command Execution
-    
-        An optional FTP extension, "SITE EXEC", allows clients to
-        execute arbitrary commands on the server.  This feature should
-        obviously be implemented with great care.  There are several
-        documented cases of the FTP "SITE EXEC" command being used to
-        subvert server security [CERT94:08] [CERT95:16]
-
-    Debug Code
-    
-        Several previous security compromises related to FTP can be
-        attributed to software that was installed with debugging
-        features enabled [CERT88:01].
-
-    This document recommends that implementors of FTP servers with these
-    capabilities review all of the CERT advisories for attacks on these
-    or similar mechanisms before releasing their software.
-
-
-Expires: April, 1999                                            [Page 5]
-
-draft-ietf-ftpext-sec-consider-02.txt                       October 1998
-
-10  Conclusion
-
-    Using the above suggestions can decrease the security problems
-    associated with FTP servers without eliminating functionality.
-
-Acknowledgments
-
-    We would like to thank Alex Belits, Jim Bound, William Curtin,
-    Robert Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their
-    helpful comments on this paper.  Also, we thank the FTPEXT WG
-    members who gave many useful suggestions at the Memphis IETF
-    meeting.
-
-References
-
-    [AOM98] Mark Allman, Shawn Ostermann, Craig Metz.  FTP Extensions
-        for IPv6 and NATs, September 1998.  RFC 2428.
-
-    [Bel94] Steve Bellovin.  Firewall-Friendly FTP, February 1994.  RFC
-        1579.
-
-    [CERT88:01] CERT Advisory CA-88:01. ftpd Vulnerability. December,
-        1988 ftp://info.cert.org/pub/cert_advisories/
-      
-    [CERT92:09] CERT Advisory CA-92:09. AIX Anonymous FTP Vulnerability.
-        April 27, 1992. ftp://info.cert.org/pub/cert_advisories/
-      
-    [CERT93:06] CERT Advisory CA-93:06. Wuarchive ftpd Vulnerability.
-        September 19,1997 ftp://info.cert.org/pub/cert_advisories/
-      
-    [CERT94:08] CERT Advisory CA-94:08. ftpd Vulnerabilities. September
-        23, 1997.  ftp://info.cert.org/pub/cert_advisories/
-      
-    [CERT95:16] CERT Advisory CA-95:16. wu-ftpd Misconfiguration
-        Vulnerability.  September 23, 1997
-        ftp://info.cert.org/pub/cert_advisories/
-      
-    [CERT97:27] CERT Advisory CA-97.27. FTP Bounce.  January 8,
-        1998. ftp://info.cert.org/pub/cert_advisories/
-      
-    [HL97] M. Horowitz and S. J. Lunt.  FTP Security Extensions,
-        October 1997.  RFC 2228.
-    
-    [Pis94] D. Piscitello.  FTP Operation Over Big Address Records
-        (FOOBAR), June 1994.  RFC 1639.
-
-    [Pos81] J. Postel.  Transmission Control Protocol, September 1981.
-        RFC 793.
-
-    [PR85] J. Postel and J. Reynolds.  File Transfer Protocol (FTP),
-        October 1985.  RFC 959.
-    
-    [RP94] J. Reynolds and J. Postel.  Assigned Numbers, October 1994.
-        RFC 1700.  http://www.iana.org.
-
-Expires: April, 1999                                            [Page 6]
-
-draft-ietf-ftpext-sec-consider-02.txt                       October 1998
-
-
-Author's Addresses:
-    
-    Mark Allman
-    NASA Lewis Research Center/Sterling Software
-    21000 Brookpark Rd.  MS 54-2
-    Cleveland, OH  44135
-    mallman at lerc.nasa.gov
-
-    Shawn Ostermann
-    School of Electrical Engineering and Computer Science
-    Ohio University    
-    416 Morton Hall
-    Athens, OH  45701
-    ostermann at cs.ohiou.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires: April, 1999                                            [Page 7]
-


=====================================
doc/rfc/rfc0959.txt deleted
=====================================
The diff for this file was not included because it is too large.


View it on GitLab: https://salsa.debian.org/debian-proftpd-team/proftpd/-/compare/f0afd2417c1a4d2e80334a0519821e359e6b4225...c0388e583acf625c9a62129133bc52dbff92a64c

-- 
View it on GitLab: https://salsa.debian.org/debian-proftpd-team/proftpd/-/compare/f0afd2417c1a4d2e80334a0519821e359e6b4225...c0388e583acf625c9a62129133bc52dbff92a64c
You're receiving this email because of your account on salsa.debian.org.




More information about the Pkg-proftpd-maintainers mailing list