telnet & ftp official status

[Mike Patnode]

>>    The question is do you want the diffs for
>> the Coverity & Valgrind issues against the 1.4.3 base, or do you just
>> want to wait until we do our 1.6 port?

>If the goal is to save effort on our end by avoiding duplicate work,
>then we'll want patches against the most recent Kerberos source
>code--ideally the trunk.

>Also, it's easiest to review patches when they are logically separated.
>I don't want 200 separate patches for 200 defects, but if they could be
>collected into categories (like "eliminate memory leaks") it will make
>my life easier.

The thought was we could leverage the investment we've already made with
Coverity to save you some time, unfortunately, we don't have the
resources to go back and repackage the changes in this manner.

>Based on a piece of mail from Tom in July, I believe our recommended
>method for delivering patches from non-commiters is to send mail to
>krb5-bugs at mit.edu to create a ticket in RT, including patches in
>attachments.

Sounds like the easiest strategy will be to start creating bugs for our
changes moving forward as we make them.   Potentially we'll have time
for a stronger push for integration sometime next year and we'll sync
with something closer to your trunk.

>Finally, if in any of your analysis you uncovered evidence of an
>exploitable security issue, we'd like to hear about it in (ideally
>PGP-encrypted) email to krbcore-security at mit.edu.  My experience is
that
>most Coverity-discovered defects are not security issues, but there may
>be a few hidden in there.

The double free's were mostly discovered by valgrind testing.   It's not
clear if those our issues outside of our usage scenario, but as they
come up again, we'll be sure to open bugs.

mp