whitelisting "read" DSNs

Vernon Schryver vjs@calcite.rhyolite.com
Mon Sep 12 20:30:30 UTC 2005


> From: Georg Graf 

> > perhaps, but only if I added that source to the DCC source.
>
> I dont understand. regex.h on Linux is in
> glibc-headers-2.3.2-95.33.rpm, on FreeBSD it's also in the libc.
> Also on AIX there is regex in the system libc. I suppose on
> solaris as well. 

which says little about old versions of those systems, not to
mention AUX, the old System V varients, etc.
It also says little about the real compatitility of POSIX regular
expression libraries.  POSIX standards are merely paper...and test
suites with uncountable variations, ambiguities, bugs, and exceptions.


>                  Not quite sure about Win32. 

It might be in some Microsoft DLL, but would you rely on Microsot's
reading of a POSIX standard to be recognizable?
Just now I read some of the hits from
http://www.google.com/search?q=site:microsoft.com+"regular+expression"+posix
and was *not* encouraged.

Never mind that some of those hits sound like it would require the
".NET Framework."  Maybe you would have no qualms about that, but I do.

I don't think much of Microsoft software, but I must give them credit
for paying real attention to upward compatilibity.  That's something
the Linux community seems to have no clue about, as demonstrated by
incompatibilities among versions of rrdtool, wget, shells, etc



>                                              Why would you put
> that into the dcc source?

so that it is always there and fits with the calling code.

MD5 might be a good example of how non-standard standard things are.
I ship MD5 source because of incompatibilites in trivial "standard"
MD5 libraries, as well as systems that don't have any MD5 library.



> > you can't successfully ship an open source package that requires
> > users to fetch, install, and maintain bits from other places.
>
> This would not be necessary, IMHO.

Not for you, but there are probably far more than 40,000 DCC installations
running on all kinds of more or less UNIX-like systems, including
WIN32.  When I'm writing code for my own use, I use all sorts of handy
extensions, but when I'm trying to portable, I try not to use anything
that wasn't almost universal 10 or 15 years ago.


> > > I see the point that dccd would not be able to use regexes. do
> > > dccm / dccproc / dccifd internally work on checksums?
> > 
> > yes.
>
> What about exempting some whiteclnt options (e.g. ok regex
> "bla-bla") and handling them differently?

There are issues including storing and re-compiling the compiled regular
expressions, error cases, and so forth.  It would only be a SMOP (small
matter of programming) to do something, but at the end I would have
nothing that is not already available and far more mature in procmail,
SpamAssassin, and other regular rexpression based filters.  Instead
of re-inventing other people's wheels, I think it is better to use
their wheels.

Judging from
http://www.google.com/search?q=procmail+milter
there are milters for procmail.



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.