Re: [vchkpw] 5.4.18 release candidate

[John Simpson]

On 2006-12-26, at 1111, Joshua Megerman wrote:

That is correct - this patch actually helps eliminate race conditions by reducing the frequency of CDB update. Because an address that is covered

by a static rule will never be overridden by a dynamic one (since
tcpserver is supposed to  use the first rule it finds),

actually, tcpserver uses the MOST SPECIFIC rule it finds. for example, if there are three rules matching a given IP (a /28 rule, a / 24 rule, and a specific /32 rule) then it will go with the specific / 32 rule. if there are multiple identical keys in the cdb file, the order in which they are retrieved is undefined (per djb's original spec.) and even the example above is not fully accurate... because of the fact that tcprules builds the cdb file with keys whose values are based on octet boundaries, a /28 rule in the text file actually appears as 16 /32 rules in the cdb file... so in my example above, there's actually a 50/50 chance whether the /32 rule or the /28 rule would end up being followed. so whatever process is building the cdb file, it should probably take steps to ensure that any given key is not added more than once- otherwise there is no guarantee which rule will actually be used.) i wonder how hard it would be to rewrite tcprules and tcpserver to implement real CIDR-based rules in the cdb file, instead of breaking each entry which is not a perfect /8, /16, or /24 into multiple cdb keys which are? and unfortunately, because the order is undefined, there is a chance that a dynamic rule could "override" a static rule, if they both have identical keys in the cdb file.

However, IMHO SMTP-AUTH should be used instead as it's
both more reliable and more secure,

i couldn't agree more.

I'm not sure how to best address it, but I see 3 choices: 1) exclude the

patch from the main tree but publish it as an add-on (not great); 2)
include the patch and document the changes in how the CDB is built and

sure how to do it, but I'd guess it's pretty simple to change...

works (better, but may cause breakage for some people); or 3) put the code inside an #ifdef and make it a configure option (I'd enable it by default, but it could go either way). I know nothing about configure, so I'm not

----------------------------------------------------------------
| John M. Simpson    ---   KG4ZOW   ---    Programmer At Large |
| http://www.jms1.net/                         <[EMAIL PROTECTED]> |
----------------------------------------------------------------
| http://video.google.com/videoplay?docid=-4312730277175242198 |
----------------------------------------------------------------

i would agree with either #1 or #3- if it's going to be added to the main-stream code, it should be something which can be electively enabled and disabled on the ./configure command line. it doesn't affect me directly either way (i've been using AUTH for years) but i'm not real crazy about the idea of forcibly changing the behaviour of existing programs without a good reason- and the fact that it CAN be made an optional thing means that this isn't a good enough reason to force the change on all of the people who may be using this feature now and would be affected by the change when/if they upgrade.

PGP.sig
Description: This is a digitally signed message part