[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: parsing a Type III directory.



On Sun, 2003-10-05 at 22:54, Peter Palfrader wrote:
> Hello everyone,
> 
> in the api-spec there is a mix3_directory_parse_from_string().
> 
> I wonder what the Right Thing is in the following cases:
> 	(1) a mandatory field is missing in the directory
> 	    (e.g. Recommended-Servers)
> 
> 	(2) a single server descriptor's signature does not verify
> 
> 	(3.1) a mandatory field is missing in a single server descriptor.
> 	(3.2) a mandatory field's value does not match the specified syntax
> 	      (e.g. Nickname)
> 	(3.3) an optional field's value does not match the specified syntax
> 	      (e.g. Contact-Fingerprint)
> 
> 	(4.1) a mandatory field is missing in an optional section of a
> 	      server descriptor.
> 	(4.2) a mandatory field's value in an optional section does not
> 	      match the specified syntax
> 	(4.3) an optional field's value in an optional section does not
> 	      match the specified syntax
> 
> 
> I think the following things should be done:
> 
> (1) reject the entire directory.

Agreed.

> (2) ignore this server descriptor

Disagree -- the directory should be rejected.  If a descriptor's
signature is invalid, then the directory server is malfunctioning or
corrupt.

> (3.1) ignore this server descriptor

Agreed.

> (3.2) ignore this server descriptor

Agreed.

> (3.3) ignore this entry

I don't think I agree.  Simply because a field is optional, we shouldn't
assume that processing it is optional.  IOW, "optional" doesn't mean
"always safe to ignore."

I would prefer "Ignore the server descriptor."

> (4.1) ignore this section

agreed.  Mixminion does not currently do this, however.

> (4.2) ignore this section

agreed.

> (4.3) ignore this entry

disagreed, for reasons above.  We should ignore the section as before.

> In theory all these cases should never happen, so it might also be
> feasible to reject the entire directory.

Maybe.  I don't want to specify ourselves out of keeping backward
compatibility when we choose to do so.  (Although 1.0 will drop backward
compatibility, I try to keep compatibility between succeeding releases
whenever doing so is less painful than shutting the entire network down
while everybody upgrades.)

> In any case, the recommended behaviour should be specified.

In fact, it should go into "dir-spec.txt".  Do you have time to write
this up?

Many thanks,
-- 
Nick

Attachment: signature.asc
Description: This is a digitally signed message part