ViewVC logotype

Contents of /vendor/ircservices-5.1.24/docs/tech/11.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 3389 - (show annotations)
Fri Apr 25 14:12:15 2014 UTC (6 years, 2 months ago) by michael
File MIME type: application/xhtml+xml
File size: 23752 byte(s)
- Imported ircservices-5.1.24

1 <?xml version="1.0" encoding="ISO-8859-1"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
4 <head>
5 <meta http-equiv="Content-Style-Type" content="text/css"/>
6 <style type="text/css">@import "style.css";</style>
7 <title>IRC Services Technical Reference Manual - 11. Future work</title>
8 </head>
10 <body>
11 <h1 class="title" id="top">IRC Services Technical Reference Manual</h1>
13 <h2 class="section-title">11. Future work</h2>
15 <p class="section-toc">
16 11-1. <a href="#s1">Design issues</a>
17 <br/>11-2. <a href="#s2">User interface issues</a>
18 <br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-1. <a href="#s2-1">NickServ issues</a>
19 <br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-2. <a href="#s2-2">ChanServ issues</a>
20 <br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-3. <a href="#s2-3">MemoServ issues</a>
21 <br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-4. <a href="#s2-4">OperServ issues</a>
22 <br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-5. <a href="#s2-5">StatServ issues</a>
23 <br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-6. <a href="#s2-6">Other issues</a>
24 <br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-7. <a href="#s2-7">Rejected suggestions</a>
25 </p>
27 <p class="backlink"><a href="10.html">Previous section: Compilation</a> |
28 <a href="index.html">Table of Contents</a></p>
30 <!------------------------------------------------------------------------>
31 <hr/>
33 <h3 class="subsection-title" id="s1">11-1. Design issues</h3>
35 <ul>
37 <li class="spaced">Services currently operates under the assumption that
38 enough memory will be available for its needs, and simply aborts the
39 program in most cases if a memory allocation fails (the <tt>smalloc()</tt>
40 function). On modern systems this should be true most of the time anyway,
41 but a better design would eliminate <tt>smalloc()</tt> and friends, and
42 instead degrade gracefully when out of resources (for example, returning an
43 "internal error" or "out of resources" message to a pseudoclient command).</li>
45 <li class="spaced">Services ignores the possibility of truncation when
46 using the <tt>snprintf()</tt> and <tt>vsnprintf()</tt> functions. In most
47 cases, such truncation would only result in the user seeing a truncated
48 response string, and I have (at least in recent development) made an effort
49 to check for overflow in security-related situations before calling
50 <tt>snprintf()</tt>, but I cannot rule out the possibility that some
51 security issues related to string truncation exist. The code should be
52 rewritten to (1) use an <tt>snprintf()</tt> that follows the POSIX
53 standard of returning the number of bytes that would be written given an
54 infinite buffer and (2) check the return value for overflow where
55 pertinent.</li>
57 <li class="spaced">As also mentioned in <a href="10.html#s5">section
58 10-5</a>, the module callback implementation relies on the very flaky
59 assumption that any type can be passed through a <tt>void&nbsp;*</tt> and
60 come out unscathed on the other side, regardless of the parameter types
61 used by the called function. This happens to work on the Intel x86
62 architecture because everything is 32 bits, and on the AMD x86-64
63 architecture because the first five parameters (the maximum supported for
64 callbacks in the current implementation) are passed in registers rather
65 than on the stack, but there is no guarantee that this will also work on
66 future (or other existing) architectures. The implementation also assumes
67 that a function can be passed more parameters than it actually accepts
68 without any harm. One possible alternative is to use variadic argument
69 lists, but this would require changing all callback functions to take a
70 <tt>va_list</tt> argument and retrieve the arguments manually; due to the
71 amount of work this would take, the current implementation has been left
72 alone for this release, and a redesign is left for future work.</li>
74 <li class="spaced">Services defines its own types for integers of specific
75 sizes: <tt>int8</tt>, <tt>uint32</tt>, and the like. The standard header
76 file <tt>stdint.h</tt> declares similar types, using names like
77 <tt>int8_t</tt> and <tt>uint32_t</tt>; however, these are not used because
78 this header file did not exist (or was not standardized, at least) during
79 the early stages of Services' development, when the need for sized integer
80 types arose. Changing the code to use the standard types would remove the
81 need to define those types in the <tt>configure</tt> script.</li>
83 <li class="spaced">It has been suggested from time to time that Services
84 use a full-fledged database management system such as MySQL for database
85 storage, to allow easy access to the data by other programs such as CGI
86 scripts on a web server. In fact, the major services programs I am aware
87 of which are currently (October 2007) under development seem to be taking
88 this route. However, Services has been designed from the start with the
89 assumption that its data will never be modified by any outside process, and
90 in fact, even the change from periodic expiration to expiration on access
91 made during 5.0 alpha development caused several dangling-pointer bugs to
92 surface. Attempting to use external databases that could be modified by
93 other programs within the current Services framework would at best cause
94 such modified data to be overwritten when Services saved its databases, and
95 at worst cause Services to crash when it tried to access data that had been
96 modified without its knowledge. That said, this design decision enforces a
97 single-threaded execution model for the entire program, and for that reason
98 alone is a good target for redesign. (With respect to read-only access to
99 Services data, XML-based data export was added in version 5.0.)</li>
101 <li class="spaced">In relation to the above, XML has also been suggested as
102 a native database format. I have been reluctant to do this, both from the
103 practical point of view that writing the databases in a textual format
104 takes considerably longer than doing so in a binary format and would impair
105 Services' responsiveness, and because I see XML as a data interchange
106 format rather than a data storage format and believe that the two should be
107 handled separately. However, the former issue may well be moot for smaller
108 networks, and the latter is a matter of taste; in addition, the current XML
109 import and export modules lack the flexibility of the database system, as
110 discussed at the top of <a href="8.html#s4-1">section 8-4-1</a>, so I leave
111 this issue here for consideration.</li>
113 <li class="spaced">Currently, Services records all log messages to a single
114 log file, in a format intended for human perusal rather than machine
115 processing. This could be improved with an "event log" system and logging
116 modules, whereby a common log function is called with some sort of event
117 identifier and event data, and the log module(s) then perform appropriate
118 actions; this would allow, for example, the creation of a log file with
119 all nickname-related events stored in a format easily parsable by other
120 programs, or the creation of an online "log channel" to which nickname and
121 channel operations are sent.</li>
123 <li class="spaced">ChanServ currently requires a password for founder-level
124 access to registered channels. However, since those privileges are also
125 granted to the founder him/herself upon nickname identification, channel
126 passwords could be considered optional; deliberately not setting a password
127 on a channel would thus prevent the channel from being taken over by
128 password theft. However, the password also serves as an extra measure to
129 prevent accidental dropping of channels (the <tt>DROP</tt> command requires
130 password authentication), so an alternate method would have to be
131 considered if channel passwords were made optional.</li>
133 <li class="spaced">As mentioned in <a href="7.html#s4-1-4">section
134 7-4-1-4</a>, it may be desirable to include "successor" channels in a
135 user's owned-channel count. This would alleviate the potential for a
136 channel with a successor to nonetheless disappear on deletion of the
137 founder's nickname (because the successor owned too many channels at that
138 particular time).</li>
140 <li class="spaced">Services has used a level-based access system since its
141 inception, in which channel users are assigned a single numeric access
142 level; this level then determines what privileges (if any) the user is
143 allowed on the channel. While more flexible than a simple system like the
144 XOP command set, the use of numbers can prove confusing and difficult to
145 understand, and there is no way to selectively grant higher-level
146 privileges without also granting lower-level ones. A system such as the
147 "role" system used in PTlink Services 3.x, in which privileges are
148 individually granted to users, could help solve these problems.</li>
150 <li class="spaced">The use of binary bitfields to represent channel modes
151 allows for efficient processing; however, it causes problems when changing
152 from one protocol to another, because channels' mode lock data is stored
153 using those same bitfields. One way around this is to simply export and
154 re-import the data using XML (which is probably a good idea in any case, to
155 compensate for things like different processing of nicknames and channel
156 names). An alternative approach would be to store the modes as strings, at
157 the cost of additional processing and storage requirements. Still another
158 approach might define a common set of mode bits among all protocols,
159 allowing other protocols' modes to be interpreted properly; in essence, the
160 set of modes defined in the core mode handling would be the union of all
161 those defined in the standard protocol modules, rather than the
162 intersection. However, this would require wider data fields to handle the
163 necessity of giving every mode its own unique bit, and would leave
164 third-party protocol modules without a way to express their own custom
165 modes. The wisdom of including protocol-specific data in the Services core
166 is also questionable.</li>
168 <li class="spaced">The OperServ privilege system is currently very coarse.
169 It essentially provides only three distinct classes: no privileges,
170 Services operator, and Services administrator. (The super-user class is
171 identical to the administrator class except for the ability to modify the
172 Services administrator list and to bypass the NSSecureAdmins security
173 restrictions.) Moreover, the privileges granted to Services operators are
174 very limited, while those granted to Services administrators are extremely
175 powerful, leaving no "middle ground". At least one user of Services has
176 noted that the inability to view user information, for example to resolve
177 disputes between users, without also granting full administrator privileges
178 is problematic. Services would benefit from a review of these privilege
179 classes; for example, it might be wise to require super-user privileges for
180 dangerous commands such as <tt>JUPE</tt> and <tt>SHUTDOWN</tt>, which would
181 then allow the administrator class to be used for tasks such as viewing
182 user information.</li>
184 <li class="spaced">Related to the above, it might be useful to allow
185 OperServ privileges and related commands (such as NickServ and ChanServ
186 <tt>FORBID</tt> or <tt>INFO ALL</tt>) to be assigned to different classes
187 based on configuration settings. For example, one network might decide to
188 allow Services operators to use information retrieval commands (currently
189 limited to Services administrators), while another might choose to let all
190 IRC operators use the OperServ <tt>AKILL</tt> command. Note that allowing
191 this sort of configuration will require dynamically-generated help messages
192 (since the required privilege class may change at runtime), in addition to
193 new OperServ privilege-checking functions similar to
194 <tt>is_services_oper()</tt> and <tt>is_services_admin()</tt>.</li>
196 <li class="spaced">Configuration directives have been added somewhat
197 haphazardly over the course of Services' development, and could probably
198 use a review and overhaul. In particular, there are several "negative
199 options", including <tt>NoBouncyModes</tt>, <tt>NoSplitRecovery</tt>, and
200 <tt>NoAdminPasswordCheck</tt>, which were added as negatives to avoid
201 changing Services' behavior in the middle of a release series. These have
202 the unintuitive effect that <i>enabling</i> the option <i>disables</i> a
203 particular behavior; ideally, such options should be written as positives
204 (<i>e.g.,</i> <tt>BouncyModeCheck</tt> or <tt>SplitRecovery</tt>) and
205 enabled in the default configuration file.</li>
207 <li class="spaced" id="s1-gmake">As described in
208 <a href="10.html#s3-2">section 10-3-2</a>, the module compilation process
209 makes use of several time-consuming tricks to simplify the individual
210 modules' Makefiles. However, version 3.81 of GNU <tt>make</tt> introduced
211 the special target <tt>.SECONDEXPANSION</tt>, which causes dependency lists
212 in subsequent rules to be expanded twice; for example, a rule
213 <div class="code">%.so: %.o $$(OBJECTS-$$@)</div>
214 (note the escaped <tt>$</tt> characters, to prevent expansion on the first
215 pass) would do what it looks like&mdash;supply a dependency list using a
216 variable name derived from the target module name. Use of this feature
217 could substantially simplify the <tt>modules/Makerules</tt> file, at the
218 expense of incompatibility with versions 3.79 and 3.80 of GNU
219 <tt>make</tt>.</li>
221 </ul>
223 <p>There are also several issues listed in <a href="../d.html">Appendix
224 D</a> of the user's manual.</p>
226 <p class="backlink"><a href="#top">Back to top</a></p>
228 <!------------------------------------------------------------------------>
229 <hr/>
231 <h3 class="subsection-title" id="s2">11-2. User interface issues</h3>
233 <p>A number of possible functionality additions or changes have been
234 considered by the author or suggested by users over the years. These are
235 summarized by subsystem below, in no particular order.</p>
237 <p class="backlink"><a href="#top">Back to top</a></p>
240 <h4 class="subsubsection-title" id="s2-1">11-2-1. NickServ issues</h4>
242 <ul>
243 <li class="spaced">Allow certain nicknames (specified by wildcard mask)
244 to be used but not registered. <i>Suggested by Mark Hetherington
245 <tt>&lt;mark@ctcp.net&gt;</tt></i></li>
246 <li class="spaced">Include successor channels in the output of the
247 <tt>LISTCHANS</tt> command. <i>Suggested by Marc-Andre A. Fuentes
248 <tt>&lt;nothing@psychopat.org&gt;</tt></i></li>
249 <li class="spaced">When using the <tt>nickserv/mail-auth</tt> module,
250 perform a DNS (MX) lookup on the domain in the E-mail address given
251 to the <tt>REGISTER</tt> or <tt>SET EMAIL</tt> address before
252 actually trying to send the authentication code message.
253 <i>Suggested by Brian <tt>&lt;n1uro@n1uro.com&gt;</tt></i></li>
254 <li class="spaced">Include Services administrator or operator status in
255 the output from the <tt>INFO</tt> command. <i>Suggested by Yusuf
256 Iskenderoglu <tt>&lt;uhc0@stud.uni-karlsruhe.de&gt;</tt></i></li>
257 <li class="spaced">When the <tt>NSForceNickChange</tt> configuration option
258 is set, have the <tt>GHOST</tt> command change target users' nicks
259 rather than killing them outright. <i>Suggested by Mark
260 Hetherington <tt>&lt;mark@ctcp.net&gt;</tt></i></li>
261 <li class="spaced">An option to warn users via E-mail when a nickname is
262 about to expire. <i>Suggested by Hans v Steenbergen
263 <tt>&lt;thebeast@xs4all.nl&gt;</tt></i></li>
264 <li class="spaced">An option to allow users to change their "fake usermask"
265 (username and hostname shown in <tt>/whois</tt> output) to their
266 registered E-mail address, on servers supporting such a feature.</li>
267 <li class="spaced">Allow Services administrators to modify other nicknames'
268 access lists. <i>Suggested by Mauritz Antunes
269 <tt>&lt;mauritz@brasnet.org&gt;</tt></i></li>
270 <li class="spaced">An option to limit the set of languages users are
271 allowed to select with <tt>SET LANGUAGE</tt>. <i>Suggested by
272 Mauritz Antunes <tt>&lt;mauritz@brasnet.org&gt;</tt></i></li>
273 </ul>
275 <p class="backlink"><a href="#top">Back to top</a></p>
278 <h4 class="subsubsection-title" id="s2-2">11-2-2. ChanServ issues</h4>
280 <ul>
281 <li class="spaced">Better integration of channel keys with ChanServ; for
282 example, authorized users should have a way to enter even if a
283 channel key is set, much like they can use the <tt>UNBAN</tt> or
284 <tt>INVITE</tt> commands to get around channel bans or mode
285 <tt>+i</tt>.</li>
286 <li class="spaced">An option to autokill users entering a forbidden
287 channel (<i>e.g.,</i> to efficiently remove botnets from a
288 network).</li>
289 <li class="spaced">Allow autokick exceptions. <i>Suggested by Dionisios
290 K. <tt>&lt;admin@vonitsanet.gr&gt;</tt></i></li>
291 <li class="spaced">A configuration option listing channel modes that uers
292 are not allowed to change, like a mode lock enforced on all
293 channels. <i>Suggested by <tt>&lt;medice@gmx.at&gt;</tt></i></li>
294 <li class="spaced">A ChanServ <tt>LINK</tt> command, like the NickServ
295 command of the same name but for channels. <i>Suggested by Craig
296 McLure <tt>&lt;Craig@chatspike.net&gt;</tt></i></li>
297 <li class="spaced">A <tt>VERBOSE</tt> option, causing ChanServ to send
298 notices (like for <tt>OPNOTICE</tt>) to the channel for all
299 ChanServ commands. <i>Suggested by
300 <tt>&lt;martin@e-tech.us&gt;</tt></i></li>
301 <li class="spaced">A command to look up channels by E-mail address.
302 <i>Suggested by Finny Merrill <tt>&lt;griever@t2n.org&gt;</tt></i></li>
303 <li class="spaced">More intelligent handling of a missing "<tt>#</tt>" in
304 the channel name parameter for <tt>REGISTER</tt>. <i>Suggested by
305 <tt>&lt;jollino@sogno.net&gt;</tt></i></li>
306 <li class="spaced">A better method of determining a channel's "last-used"
307 time than the last time a user was auto-opped (but avoiding overly
308 sensitive schemes that update the last-used time even for
309 spambots).</li>
310 <li class="spaced">An option to send an explanatory notice to a user who
311 tries to use a restricted ChanServ command on a channel with the
312 <tt>SECURE</tt> option set, without identifying for their
313 nickname.</li>
314 <li class="spaced">Record the nickname of the user that added each access
315 entry and the last time the access entry was used.</li>
316 <li class="spaced">Display access entries ordered by level.</li>
317 <li class="spaced">Allow modification of (adding modes from or removing
318 modes to) channel mode locks, rather than wholesale replacement
319 only.</li>
320 <li class="spaced">When switching IRC server types that do not share the
321 same set of channel modes, graceful degradation of locked modes not
322 available with the new protocol. <i>Suggested by Yusuf
323 Iskenderoglu <tt>&lt;uhc0@stud.uni-karlsruhe.de&gt;</tt></i></li>
324 <li class="spaced">Treat the <tt>/topic</tt> IRC command identically to the
325 ChanServ <tt>TOPIC</tt> command when determining whether to allow a
326 topic change on a channel with <tt>TOPICLOCK</tt> set. <i>Suggested
327 by Casey <tt>&lt;caseyclaydon@fastmail.com.au&gt;</tt></i></li>
328 </ul>
330 <p class="backlink"><a href="#top">Back to top</a></p>
333 <h4 class="subsubsection-title" id="s2-3">11-2-3. MemoServ issues</h4>
335 <ul>
336 <li class="spaced">A setting to reverse the meaning of the ignore list, so
337 that only users on the list are allowed to send memos.</li>
338 </ul>
340 <p class="backlink"><a href="#top">Back to top</a></p>
343 <h4 class="subsubsection-title" id="s2-4">11-2-4. OperServ issues</h4>
345 <ul>
346 <li class="spaced">A command to kill nicknames matching a wildcard or
347 regular expression. <i>Suggested by Guy Antony Halse
348 <tt>&lt;guy@rucus.ru.ac.za&gt;</tt></i></li>
349 <li class="spaced">An option to send a notice to autokilled users of the
350 autokill expiration time before performing the actual kill.
351 <i>Suggested by <tt>&lt;saturn@jetirc.net&gt;</tt></i></li>
352 <li class="spaced">The ability to use full regular expressions, not just
353 simple wildcards, in autokill and other wildcard masks.
354 <i>Suggested by Aragon Gouveia
355 <tt>&lt;aragon@phat.za.net&gt;</tt></i></li>
356 </ul>
358 <p class="backlink"><a href="#top">Back to top</a></p>
361 <h4 class="subsubsection-title" id="s2-5">11-2-5. StatServ issues</h4>
363 <ul>
364 <li class="spaced">Keep track of the number of users per domain on each
365 server. <i>Suggested by Ali Sor
366 <tt>&lt;alisor@softhome.net&gt;</tt></i></li>
367 <li class="spaced">Keep track of statistics such as the number of joins
368 and kicks for each channel and the number of connections made by
369 each user or nickname. <i>Suggested by
370 <tt>&lt;Georges@Berscheid.lu&gt;</tt></i></li>
371 </ul>
373 <p class="backlink"><a href="#top">Back to top</a></p>
376 <h4 class="subsubsection-title" id="s2-6">11-2-6. Other issues</h4>
378 <ul>
379 <li class="spaced">An option or module to log all <tt>WALLOPS</tt> (and
380 <tt>GLOBOPS</tt>, etc.) messages. <i>Suggested by Andrew
381 Kempe.</i></li>
382 <li class="spaced">An in-program method to clear one or more databases
383 (currently, this can only be done by removing the corresponding
384 database files). <i>Suggested by
385 <tt>&lt;RealCFC@chatfirst.com&gt;</tt></i></li>
386 <li class="spaced">A network status page, possibly with graphs (see for example
387 <a href="http://irc.netsplit.de/"><tt>irc.netsplit.de</tt></a>).
388 <i>Suggested by <tt>&lt;jollino@sogno.net&gt;</tt></i></li>
389 <li class="spaced">An option to autokill users who are killed repeatedly
390 for bad passwords. <i>Suggested by Jonathan Morton
391 <tt>&lt;chromi@cyberspace.org&gt;</tt></i></li>
392 <li class="spaced">The ability to reconnect to the uplink server if
393 disconnected.</li>
394 <li class="spaced">A way to send commands to OperServ (or possibly other
395 pseudoclients) from another process.</li>
396 </ul>
398 <p class="backlink"><a href="#top">Back to top</a></p>
401 <h4 class="subsubsection-title" id="s2-7">11-2-7. Rejected suggestions</h4>
403 <p>In addition to the above, the author has explicitly rejected a few
404 feature suggestions as unnecessary or inappropriate for inclusion in
405 Services; however, they are recorded here for the consideration of future
406 developers.</p>
408 <ul>
409 <li class="spaced"><b>Automatic opping/voicing/etc. of users on channel
410 access list changes.</b> For example, automatically setting
411 <tt>+o</tt> on a user added to the access list with auto-op
412 privileges. While this is certainly not a useless feature, access
413 list changes are typically one-time events, and do not warrant the
414 added complexity of including such a feature; the user can be
415 manually opped or voiced just as easily.</li>
416 <li class="spaced"><b>Allow identification to multiple nicknames.</b>
417 This can result in ambiguities when handling channel access levels.
418 For example, suppose a user has identified to two nicknames,
419 GoodNick and BadNick. If on a certain channel, GoodNick has an
420 access level of 50 but BadNick has an access level of -10, what
421 access level should the user be granted? The answer varies with
422 the particular channel and user, and rather than attempting to
423 invent a system of options and rules to handle every possible
424 circumstance, Services simply disallows identification to multiple
425 nicknames entirely. (Services will remember whether a user has
426 identified for a nickname if the user temporarily switches to
427 another nickname.)</li>
428 <li class="spaced"><b>A channel option or configuration file setting to
429 make ChanServ join channels, or a BotServ pseudoclient to do the
430 same thing.</b> This is one of the most common feature requests,
431 but it has consistently been rejected as incompatible with the
432 design of Services as a streamlined network tool rather than a
433 users' toy, and also because standard bots can provide equivalent
434 functionality much more flexibly than a single Services
435 pseudoclient could.</li>
436 </ul>
438 <p class="backlink"><a href="#top">Back to top</a></p>
440 <!------------------------------------------------------------------------>
441 <hr/>
443 <p class="backlink"><a href="10.html">Previous section: Compilation</a> |
444 <a href="index.html">Table of Contents</a></p>
446 </body>
447 </html>

ViewVC Help
Powered by ViewVC 1.1.28