INN commit: trunk (MANIFEST doc/Makefile doc/compliance-nntp)
INN Commit
Russ_Allbery at isc.org
Sat Dec 27 09:36:04 UTC 2008
Date: Saturday, December 27, 2008 @ 01:36:03
Author: iulius
Revision: 8264
Remove the document describing INN's compliance with standards.
It is now in a Trac report.
Modified:
trunk/MANIFEST
trunk/doc/Makefile
Deleted:
trunk/doc/compliance-nntp
---------------------+
MANIFEST | 1
doc/Makefile | 2
doc/compliance-nntp | 300 --------------------------------------------------
3 files changed, 1 insertion(+), 302 deletions(-)
Modified: MANIFEST
===================================================================
--- MANIFEST 2008-12-27 01:20:59 UTC (rev 8263)
+++ MANIFEST 2008-12-27 09:36:03 UTC (rev 8264)
@@ -128,7 +128,6 @@
doc/IPv6-info Nathan Lutchansky's IPv6 notes
doc/Makefile Makefile for documentation
doc/checklist Checklist for installing INN
-doc/compliance-nntp INN compliance with the NNTP standard
doc/config-design Configuration parser design principles
doc/config-semantics Configuration file semantics
doc/config-syntax Configuration file syntax
Modified: doc/Makefile
===================================================================
--- doc/Makefile 2008-12-27 01:20:59 UTC (rev 8263)
+++ doc/Makefile 2008-12-27 09:36:03 UTC (rev 8264)
@@ -10,7 +10,7 @@
TOPDOCS = CONTRIBUTORS HACKING INSTALL LICENSE NEWS README TODO
-DOCS = GPL compliance-nntp config-design config-semantics config-syntax \
+DOCS = GPL config-design config-semantics config-syntax \
external-auth history history-innfeed hook-perl hook-python \
sample-control
Deleted: doc/compliance-nntp
===================================================================
--- doc/compliance-nntp 2008-12-27 01:20:59 UTC (rev 8263)
+++ doc/compliance-nntp 2008-12-27 09:36:03 UTC (rev 8264)
@@ -1,300 +0,0 @@
-$Id$
-
-The following are outstanding issues regarding INN's compliance with the
-NNTP standard. The reference documents used in this analysis are RFC 3977,
-RFC 4642, RFC 4643 and RFC 4644.
-
-This file documents only compliance issues with the latest version of the
-standard NNTP protocol. It does not cover INN's private extensions or
-INN's implementation of widely available extensions not documented in the
-NNTP standard. Specifically, it does not cover the extensions listed in
-RFC 2980.
-
-------------------------------
-
- Summary: innd doesn't require whitespace between commands and arguments
- Standard: RFC 3977, section 3.1
- Version: 1.0 to CURRENT 2008-12-24
-Reference: innd/nc.c NCproc() and command handlers
- Severity: Accepts invalid input
-
-The standard states:
-
- Keywords and arguments MUST be each separated by one or more US-ASCII
- SPACE or US-ASCII TAB characters.
-
-This is not checked in NCproc or in the individual command handlers in
-innd. Commands followed immediately by their argument will be accepted by
-innd. For example:
-
- stat<9k6vjk.hg0 at example.com>
- 223 0 @0301543531000000000000079AAE0000006A@
-
-Impact: Should one command be a prefix of another, innd could dispatch
-the handling of the command to the wrong handler, treating the remainder
-of the command verb as an argument. This laxness also encourages sloppy
-client code. Internally, the lack of argument parsing in NCproc also
-results in code duplication in all of the command handlers.
-
-Suggested fix: Lift the argument parsing code into a function called from
-NCproc, breaking the command line into a vector of command and arguments.
-This will work for all commands implemented by innd and will simplify the
-implementation of command handlers, as well as fixing this problem. This
-is what nnrpd already does.
-
-Impact of fix: It's possible that some serving code is relying on this
-behavior and not sending spaces after commands. Fixing this problem would
-break interoperability with that code.
-
-------------------------------
-
- Summary: innd doesn't check argument length
- Standard: RFC 3977, section 3.1
- Version: 1.0 to CURRENT 2008-12-24
-Reference: innd/nc.c
- Severity: Accepts invalid input
-
-The standard says:
-
- Arguments MUST NOT exceed 497 octets.
-
-This is not checked by innd, although it checks that the command itself
-does not exceed 512 octets.
-
-Impact: Small. May accept invalid commands in extremely rare edge cases.
-
-Suggested fix: Probably not worth fixing separately, although if standard
-command parsing code is written to handle innd, it wouldn't hurt to check
-this along with everything else.
-
-------------------------------
-
- Summary: Reply codes other than x9x used for private extensions
- Standard: RFC 3977, section 3.2
- Version: 1.0 to CURRENT 2008-12-24
-Reference: include/nntp.h
- Severity: Violates SHOULD
-
-The standard says:
-
- Response codes not specified in this standard MAY be used for any
- installation-specific additional commands also not specified. These
- SHOULD be chosen to fit the pattern of x9x specified above.
-
-INN uses quite a few response codes that do not fit this pattern for
-various extensions. XGTITLE, MODE CANCEL and XBATCH should have used
-response codes in the x9x range.
-
-Impact: Additional ambiguity over the meaning of reply codes, as those
-reply codes could later be standardized as the reply codes for other
-commands.
-
-Suggested fix: For XGTITLE and probably XBATCH, there is no way to fix
-this now. Changing the reply codes would break all existing
-implementations. It may still be possible to change the reply codes for
-MODE CANCEL (which should probably be MODE XCANCEL or, even better,
-XCANCEL <msgid> without any mode), but it may not be worth the effort.
-
-------------------------------
-
- Summary: innd may return 480 instead of 500 for unrecognized commands
- Standard: RFC 3977, section 3.2.1
- Version: 1.0 to CURRENT 2008-12-24
-Reference: innd/nc.c NCauthinfo()
- Severity: Violates MUST
-
-The standard says:
-
- If the command is not recognized, or it is an optional command or
- extension that is not implemented by the server, the response code 500
- MUST be returned.
-
-In innd, if the connection is determined to need authentication, all
-incoming commands other than MODE are handed off to NCauthinfo() rather
-than their normal command handlers. NCauthinfo() responds with a 480
-reply code to anything other than AUTHINFO USER, AUTHINFO PASS, or QUIT.
-
-Impact: Unlikely to cause problems in practice, but may confuse clients
-that don't understand the rarely used innd-level authentication
-mechanisms.
-
-Suggested fix: Restructure the command table so that each command also
-has a flag indicating whether it requires authentication for peers that
-are required to authenticate. (Some commands, like HELP and MODE READER,
-should be allowed without authentication.) Then eliminate the special
-casing of the state CSgetauth (it may be better to store whether the peer
-has authenticated in the channel rather than in the channel state) and the
-special handling in NCauthinfo. This should also simplify the code.
-
-------------------------------
-
- Summary: innd always sends 200 for an accepted connection
- Standard: RFC 3977, section 5.1.2
- Version: 1.0 to CURRENT 2008-12-24
-Reference: innd/nc.c NCsetup() and rc.c RCreader()
- Severity: Violates MUST
-
-The standard says:
-
- If the server will accept further commands from the client including
- POST, the server MUST present a 200 greeting code. If the server will
- accept further commands from the client, but it is not authorized to
- post articles using the POST command, the server MUST present a 201
- greeting code.
-
-The implication is that the greeting code from innd (which doesn't
-implement POST and therefore is never going to allow it) should always be
-201, at least for the case where innd never spawns nnrpd. In the case
-where innd spawns nnrpd, it's unclear what the greeting code should be.
-
-The current implementation never send 201 unless one knows for certain
-that the connection will never be allowed to issue a POST command, which
-means that innd always sends 200.
-
-It's unknown whether there is any transit news software that would have
-difficulties with a 201 greeting. Both innxmit and innfeed handle it
-correctly in CURRENT 2001-07-04 and NNTPconnect() handles it correctly in
-INN 1.0, so it seems likely that if any such software exists, it's rare.
-
-Impact: It's almost certain that the current innd behavior isn't hurting
-anything. Even a confused client that thought 200 meant that it could
-send a POST command would then try and be rejected with no damage done.
-
-Suggested fix: The purpose of this return code is to give a hint to a
-reading client indicating whether it should even attempt POST, since
-attempting it may involve a lot of work by the user only to have the post
-rejected. It's only relevant to reading connections, not to transit
-connections.
-
-It's known that some clients, upon seeing a 201 response, will never
-attempt POST, even if MODE READER then returns 200. Therefore innd, when
-handing off connections to nnrpd, must return 200 to not confuse a client
-that will later send MODE READER. For connections where innd won't do
-that handoff, it makes sense to always send 201 if all transit feeds can
-handle that and won't interpret it as unwillingness to accept IHAVE or
-streaming feeds.
-
-RCreader() should therefore be modified to send 201 if noreader is set,
-and otherwise send 200.
-
-Impact of fix: Any feeding software that didn't consider 201 to be a
-valid greeting would be unable to feed a fixed innd unless that innd also
-allowed reading connections.
-
-------------------------------
-
- Summary: nnrpd doesn't return 420 errors for XOVER
- Standard: RFC 2980, section 2.8
- Version: 1.4 to CURRENT 2008-12-24
-Reference: nnrpd/article.c CMDover()
- Severity: Violates a MUST
-
-The standard says:
-
- If no articles are in the range specified, a 420 error response
- is returned by the server.
-
-nnrpd (from the beginning of the XOVER command) has always returned a 224
-response with an empty multiline response instead.
-Note that the OVER command properly returns 423 (no articles in that range)
-when that case occurs. 420 is sent when the urrent article number is
-invalid.
-
-Impact: Less information is communicated to the client about why there
-are no overview records returned. An error response indicating there are
-no valid articles in that range is possibly more informative.
-
-Suggested fix: Don't print out the initial 224 message until at least one
-overview entry has been found, so that CMDover() can print a 420 response
-instead if no overview records are found.
-
-Impact of fix: May confuse some clients that don't expect to get 420
-errors back from overview queries. Clients may be relying on the
-existing behavior (confirmed with Windows Mail for instance).
-
-------------------------------
-
- Summary: innd improperly caches DNS returns
- Standard: RFC 3977, section 12.4
- Version: 1.0 to CURRENT 2008-12-24
-Reference: innd/rc.c RCreadfile() and elsewhere
- Severity: Violates a MUST
-
-The standard says:
-
- If NNTP clients or servers cache the results of host name lookups in
- order to achieve a performance improvement, they MUST observe the TTL
- information reported by DNS.
-
-innd caches DNS lookups when reading incoming.conf and doesn't refresh its
-knowledge of DNS except when incoming.conf is reloaded.
-
-Impact: An explicit reload is required whenever the IP address of any
-peer changes, and in the presence of network renumbering innd is
-vulnerable to spoofing if DNS is the only authentication mechanism used.
-
-Suggested fix: This is hard to fix without unacceptable performance
-impact. The only good fix is to either fork a separate helper process to
-do DNS lookups (since gethostbyname may block for essentially an
-arbitrarily long period) or to use the direct resolver library so that one
-can get access to a file descriptor and throw it into the select loop.
-Either way, this requires keeping a DNS file descriptor in the main select
-loop and updating knowledge of DNS periodically, which is a substantial
-amount of additional complexity.
-
-------------------------------
-
- Summary: innd doesn't diagnose repeated AUTHINFO USER commands
- Standard: RFC 4643, section 2.3.2
- Version: 1.0 to CURRENT 2008-12-24
-Reference: innd/nc.c NCauthinfo()
- Severity: Violates a protocol description
-
-RFC 4643 says:
-
- If the server requires both username and password, the former MUST be
- sent before the latter. The server will need to cache the username
- until the password is received; it MAY require that the password be
- sent in the immediately next command (in other words, only caching
- the username until the next command is sent). The server:
- [...]
- - MUST return a 482 response to AUTHINFO PASS if there is no cached
- username;
-
-innd ignores AUTHINFO USER and just always returns a 381 response, however,
-since it doesn't care about the username. 482 is not send in reponse
-to AUTHINFO PASS.
-
-Impact: Probably none.
-
-Suggested fix: A long-term solution would be to add real authentication
-to innd, in which case it would start caring about the authenticated
-identity (and perhaps use that identity to map to an incoming.conf entry).
-It's unclear if this would be worthwhile. Failing that, innd would need
-to keep internal state to know whether AUTHINFO USER had already been
-sent.
-
-------------------------------
-
- Summary: innd and nnrpd do not advertise IHAVE for the entire session
- Standard: RFC 3977, section 3.4.1
- Version: 2.5.0
-Reference: innd/nc.c NCcapabilities() and nnrpd/nnrpd.c CMDcapabilities()
- Severity: Violates a MUST
-
-RFC 3977 says:
-
- Except as an effect of the MODE READER command (Section 5.3) on a
- mode-switching server, once a server advertises either or both of the
- IHAVE or READER capabilities, it MUST continue to advertise them for
- the entire session.
-
-If IHAVE has been advertised, it will not necessarily be advertised for
-the entire session. innd and nnrpd only advertise the IHAVE capability
-when it is really available.
-
-Impact: Probably none. It is sort of a weird edge case, since having
-such basic commands disappear after authentication is a little odd and
-would require an unusual configuration. It is probably not worth fixing.
-Besides, such a fix seems to partly defeat the point of the capability
-system.
More information about the inn-committers
mailing list