On Tue, 2009-01-13 at 02:30 +0000, entr...@users.sourceforge.net wrote:
> + * ircd/m_gline.c (ms_gline): Default lastmod to the known lastmod
> + time for GLINE_LOCAL_{DE,}ACTIVATE.
> + (mo_gline): Check that expiration times parse as expected. Reject
> + "*" as a target for GLINE_LOCAL_{DE,}ACTIVATE. Require reason and
> + expiration time for new G-lines. Allow deactivation of an unknown
> + G-line without creating it ("so-and-so ... creating new G-line" is
> + a confusing message for a deactivation).It may be confusing, but it was a deliberate design choice at the time. The time when a gline interpreted as a 0.0.0.0/0 got set was a case in point--I was able to set up a server to not link, set a deactivated copy of the G-line in question, then reconnect it to the net and have that deactivated G-line propagate to the other servers. Removing that ability also creates a corner case where a deactivated G-line could suddenly pop back up on the network on some servers--a G-line desync: Let's assume that a G-line on *...@example.com is set, then deactivated. Now, a server that never saw the original *...@example.com G-line links to the network. It gets the advertisement for the deactivated G-line and propagates it to all its linked leafs, but does not add the G-line itself. Now let's assume a server that has the *...@example.com G-line but not the deactivation update then links to our first server; it will set the G-line and propagate it around the net. We're at least guaranteed that the G-line won't stay active for long on our hypothetical server, as it'll get the deactivation advertisement again based on the lastmod mismatch...but it will have already kicked off everyone matching *...@example.com. I think it would be far better to not have that happen in the first place, which means that the server would have to allow the addition of the deactivated G-line to its G-line database. In this discussion, I've been assuming a global G-line deactivation, as opposed to a local deactivation of a global G-line; for local deactivations, the server should just forward or ignore, depending on whether or not it's the target. -- Kevin L. Mitchell <klmi...@mit.edu>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Coder-com mailing list Coder-com@undernet.org http://undernet.sbg.org/mailman/listinfo/coder-com
