| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
Fix indentation and remove an inappropriate comment in add_subscriptions(),
both of which were the result of a botched merge a long time ago. The
actual logic was merged correctly and so does not change.
|
|
|
|
|
| |
Fix a leak in which we fail to free a Kerberos authentication context
in ZCheckSrvAuthentication if getting or setting the context flags fails.
|
|
|
|
|
|
|
|
|
|
| |
tkt_lookup() is supposed to quickly obtain a ticket for a foreign realm
if we already have a usable one, and quickly fail otherwise. Sending a
request to a KDC and waiting for a response, as krb5_get_credentials()
may do, defeats the purpose of tkt_retrieve() retrying failed requests
in the background. So, use krb5_cc_retrieve_cred() instead.
Extracted from Andrew zephyr/063
|
|
|
|
|
| |
memset new notice objects in subscr.c (really needed now since all
ZFormat* routines require z_num_hdr_fields to be valid or 0.)
|
|
|
|
|
|
|
|
| |
realm_sendit is responsible for sending notices that do not have useful
realm authentication, either because they are not authentic, or because
of kerberos problems acquiring a ticket for the foreign zephyr realm. In
either case, any authentication in the notice will not be usable to the
foreign server, and ought to be stripped out.
|
|
|
|
| |
To my knowledge, this hasn't been enabled by anyone in ages
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In addition to the packet length problem discussed last night, the
realm_auth_sendit_nacked refactor also had a cut-n-paste error. In the
unfragmented case, it passed in partnotice.z_uid instead of
newnotice.z_uid. In that branch of the if, partnotice is
uninitialized... My (derrick's) servers are no longer constantly
complaining (in new debug code) that realm_nack_cancel couldn't find
the nack to dequeue, so I think I'm done with this problem.
|
| |
|
|
|
|
|
| |
i.e. don't keep generated or foreign stuff in our source tree.
As a side effect, this lets us use a libtool, etc. from this century
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(thanks to wthrowe@mit.edu)
|
|
|
|
| |
wthrowe@mit.edu
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
nuke-trailing-whitespace.
|
|
|
|
|
|
|
| |
Some systems don't have it, having shaken off the shackles of fixed
lengths. Unfortunately rewriting these things "right" in a fashion
portable to unembraced-and-extended C libraries is aggravating. So do it
wrong until we decide to bite the bullet and demand glib.
|
|
|
|
| |
noticing)
|
|
|
|
| |
nelhage@mit.edu for noticing)
|
|
|
|
| |
(Thanks to nelhage@mit.edu for noticing the formatting problem)
|
|
|
|
|
|
|
|
| |
only send one sub per packet in braindump
refactor bdump_send_list_tcp and send_normal_tcp
brain dump can now cleanly receive overlarge encrypted packets
refactor subscr_send_subs and subscr_send_realm_subs
nuke trailing whitespace
|
| |
|
| |
|
|
|
|
|
| |
(which coincidentally keeps us from reporting the wrong function with an
error code)
|
|
|
|
| |
Also clean up some indentation and add error logging.
|
|
|
|
| |
turns out that derived-key stuff actually worked if you were using heimdal.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In valid_utf8_p(), uc was improperly typed and never initialized. On
64-bit systems, this means that success is dependent on previous
stack contents.
If the upper 32 bits are not zero, the null terminator is not caught
and the function continues reading past the end of the string until:
1) Invalid UTF-8 is encountered
2) An invalid unicode codepoint is encountered.
3) segfault
1 and 2 are much more likely, but 3 is a danger.
|
| |
|
| |
|
|
|
|
| |
"class_name"
|
|
|
|
| |
don't use din anyway
|
|
|
|
|
|
|
| |
deprecated sender_addr macro.)
Actually remove the code from realm.c:real_dispatch because nothing was using
the result.
Ran nuke-trailing-whitespace on all the files I touched, as usual.
|
|
|
|
| |
(also fiddle around with what krb4 checksums are available in krb5-only land)
|
| |
|
|
|
|
|
|
| |
keyusage stuff
such that it actually works.
|
| |
|
|
|
|
| |
figure out where it is
|
| |
|
| |
|
|
|
|
|
|
|
| |
Really, it almost terrifies me that servers have probably been sending
shutdown messages to stack-garbage address families for the past two
decades
|