The infamous to-do list
olaf at bigred.inka.de
Sun Jun 25 12:39:21 UTC 2000
> > This way you generate a useful header whether encryption routines are
> > available at install time or not.
> The interactions with the O flag in newsfeeds need to be considered too,
Good point. So take the first item of X-Trace out of the encrpytion,
it is not privacy sensitive anyway.
> plus it would be nice if X-Trace could be used by remote sites for rate
> limiting (a la NNTP-Posting-Host) even in encoded form. The same dialup
> line encrypted and base64-encoded still provides a constant string to
> filter against.
This can be done by formatting the (rest of) the header in a way that
fields are always a multiple of 8 bytes and applying a 64 bit block
cipher in ECB mode on it. But then we would be better off using binary
fields, as the timestamp is 9 bytes and an IP address 10-12 bytes.
Combining the timestamp and PID into one block, adding an
authenticated user field and omitting the redundant formatted time
would give the following format:
X-Trace: g212.hadiko.de 961612202 5887 172.20.48.42 (21 Jun 2000 18:30:02 GMT)
becomes (the  are 64-bit blocks in hex):
X-Trace: g212.hadiko.de [395109AA000016FF] [AC14302A00000000] [...]
time | pid ip |reserved user
This needs more careful consideration, however.
> > I still favor the approach to drop the self-expire/non-self-expire
> > distinction completely and treat the disappearing of articles as
> > something which just does happen. This way you can use alternate expire
> > programs, which may suit local policies or installation issues better,
> > and the code gets less complex.
> The problem is that this has other undesireable side effects. LIST ACTIVE
> and GROUP return different high/low marks, some clients see a bunch of
> nonexistant articles, etc.
GROUP should use the marks from the active file. Of course one can
argue the real problem is that nnrpdcheckart is too slow. We have this
problem with CNFS too. A cleanup deamon which continually monitors the
existence of articles and purges old entries from overview would help.
The expire job should be split into three separate processes for the
three separate jobs it does: expiring articles, history entries and
overview, and in my imagined ideal world these three should be truly
independent from another.
> > would need all databases, including history, in a format which allows
> > delete operations.)
> This is definitely the direction that I'm heading. The history file will
> acquire such an interface with the next rewrite.
Good. :-) Hopefully we can finally do away with dbz and the text file
(which today really is only a bloated-by-hex-conversion binary file
anyway). I expect to test a Berkeley DB based history as soon as I
More information about the inn-workers