summaryrefslogtreecommitdiff
path: root/README
blob: 9bbe6abcdeb639603cf7c4c4663986c0e946ca81 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
This is bsd-finger-0.17 for Linux.

This package updates bsd-finger-0.16.

If you're reading this off a CD, go right away and check the net
archives for later versions and security fixes. As of this writing the
home site for NetKit is
	ftp://ftp.uk.linux.org/pub/linux/Networking/netkit

Contents: 
	finger		Program for printing user information
	fingerd		Daemon for remote finger access
	
Requires:
	Working compiler, libc, and kernel.

Security:
	bsd-finger-0.17 contains no new security fixes.

	bsd-finger-0.16 fixes some possible denial of service attacks
	against fingerd.

	bsd-finger-0.10 fixed a denial of service situation where
	users' .plan or .project files are named pipes.

	The NetKit-0.09 and earlier versions of this code fixed a
	number of now well-known security problems. Please don't use
	older versions.

Note:
	If you are using the finger daemon from this package with a 
	custom finger client, rather than the finger client in this
	package, you will need to update your client to send carriage
	returns (CR, or '\r' in C) before line feeds (LF, or '\n' in
	C) if the finger client's standard output is a socket.

	This is because as of bsd-finger-0.15, finger probes this
	condition and sends CRs itself instead of expecting fingerd
	to make an extra copy of all the data through a pipe just to
	add CRs in.

	Ignoring this circumstance and always sending LF instead of
	CR/LF will in most cases work, but is not RFC-compliant.

Installation:
	Do "./configure --help" and decide what options you want. The
	defaults should be suitable for most Linux systems. Then run
	the configure script.

	Do "make" to compile.
	Then (as root) do "make install".

	Save a backup copy of any mission-critical program in case the
	new one doesn't work, and so forth. We warned you.

	If you get gcc warnings from files in /usr/include, they are
	due to problems in your libc, not netkit. (You may only see
	them when compiling netkit because netkit turns on a lot of
	compiler warnings.)

DEC CC:
	The DEC compiler for the Alpha is now freely available. This
	is a much better compiler with gcc, that is, it generates much
	better code. If you have the DEC compiler, you can explicitly
	use the DEC compiler instead of gcc by configuring like this:

		./configure --with-c-compiler=ccc

	It is known to generate spurious warnings on some files. Also,
	some headers from some versions of glibc confuse it; that may
	prevent	netkit from working. Other problems should be reported
	as bugs.

Bugs:
	Please make sure the header files in /usr/include match the
	libc version installed in /lib and /usr/lib. If you have weird
	problems this is the most likely culprit.

	Also, before reporting a bug, be sure you're working with the
	latest version.

	If something doesn't compile for you, fix it and send diffs.
	If you can't, send the compiler's error output.

	If it compiles but doesn't work, send as complete a bug report as 
	you can. Patches and fixes are welcome, as long as you describe 
	adequately what they're supposed to fix. Please, one patch per
	distinct fix. Please do NOT send the whole archive back or
	reindent the source.

	Be sure to send all correspondence in e-mail to the netkit address.
	Postings to netnews or mailing lists will not be seen due to the 
	enormous volume. Also, anything that doesn't get filed in the bug
	database is quite likely to end up forgotten.

	Please don't report known bugs (see the BUGS file(s)) unless you
	are including fixes. :-)

	Mail should be sent to: netbug@ftp.uk.linux.org


Early in April 2000, a hacker broke into the machine that was hosting
the netkit bug database for me and trashed it. Unfortunately, it seems
backups hadn't gotten done for a while, so three months of mail (since
mid-January) was lost. So, if you sent something and didn't hear back,
or you sent something, heard back, but the changes failed to appear in
this release (unlikely but possible) - please resend.

Please see http://www.hcs.harvard.edu/~dholland/computers/netkit.html
if you are curious why it was so long between the 0.10 and 0.16 releases.

Future plans for netkit maintenance are still up in the air, but in the
meantime new releases will still appear from time to time. I don't have
a whole lot of cycles to spare to work on netkit, so things are likely
to continue to be fairly slow.

David A. Holland
23 July 2000