[28] in Kerberos-V5-bugs
Re: Diffs to krb5 alpha1.
daemon@ATHENA.MIT.EDU (Bill Sommerfeld)
Thu Oct 18 15:41:12 1990
Date: Thu, 18 Oct 90 15:27:43 EDT
From: Bill Sommerfeld <sommerfeld@apollo.com>
To: jtkohl@ATHENA.MIT.EDU
Cc: krb5-testers@ATHENA.MIT.EDU, raeburn@ATHENA.MIT.EDU
In-Reply-To: John T Kohl's message of Thursday, October 18, 1990 11:31:01 am (EDT)
Here are my rationale for why I did things the way I did:
Does const void * differ from void const *? If not, why define
krb5_const_pointer rather than using const krb5_pointer?
"const krb5_pointer" is the same as "void * const", not "const void *".
(i.e., the pointer is constant, not the target of the pointer).
*** I'd like opinions from others on whether we should worry about compiler
warnings of structure alignments ***
I'd prefer it if the structures were "naturally" aligned without
shims; shims are ugly. This can sometimes be done by reordering
fields.
(The reason I did this was that our compilers issue warnings about
both some stuff I was interested in *and* alignment problems at the
same "info level"; because I wanted to see the other warnings
warnings, it was easiest to shut up the alignment warnings this way).
The include file ".." problem can be quite troublesome. Remember we
can't depend on symlinks being available (the cray folks have already
moaned about this), and all the include files that a user application
sees should be somewhere under <krb5/...>. If we can't use the ..
names, then we should move the include files to include/krb5/asn.1/
Given the build environment that OSF is pushing on us, having ".." in
include pathnames is Right Out; the includes should all be in one
tree. I suspect that the "right" thing to do may involve something
similar to the way the AFS tree is built: that is, the "include"
directory is built at compile time.
> include/krb5/wordsize.h {allow include of krb5.h w/o special defs}
I'm not sure that defaulting to BITS32 is quite right, but neither is
defaulting to BITS16 or BITS64 or ....
*** suggestions/comments? ***
I'm one of these crazy people who thinks that source should be in
source files, not on the command line. Given the primary target
environment for Kerberos, "BITS32" is the right default. (Yes, I know
the evils of "all the world's a VAX, and all that..", but let's be
pragmatic here.. the ASN.1 stubs alone would have a hard time fitting
on a PDP-11).
> lib/os/sendto_kdc.c {allow multihomed kdcs}
The existing code will pick up all the "homes" of a KDC as long as
gethostbyname() returns all such addresses.
*** Perhaps we should not restrict the address comparison search to only
the last n-1 hosts, but allow it to match any of the KDC's? ***
No. Not everyone's nameserver is set up to return all addresses of
multi-homed hosts. Some systems return "127.0.0.1" as the "from"
address of a looped-back UDP packet, which breaks things if the KDC
and the client just happen to be on the same host.
The check is not necessary, and it serves no purpose from the
point of view of security -- Anyone who is really serious about
attacking will be able to forge source protocol addresses.
- Bill
