telnet & ftp official status

[Greg Hudson]

On Wed, 2008-10-01 at 11:03 -0700, Mike Patnode wrote:
> So the question is, what's the best way to deliver these changes back
> upstream?  I suppose we need to follow the formal proposal process for
> the API and feature changes.

We discussed this process a bit yesterday.  It's okay to informally
discuss an API or feature change on the list before you've assembled the
complete project proposal with detailed design and API documentation and
so on.  That way if it turns out we're not interested in a change, you
haven't gone through the whole rigamarole for nothing.

There downside is if the discussion peters out or rejects the proposal,
there is no discoverable artifact left behind, only a thread in the
mailing list archive which will quickly get lost.  When I get a bit more
settled, I will think about how best to record information about
"non-projects" so that they can be referred to later, either using RT or
the wiki.

>    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.

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.

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.

And, thank you!