Karl Kornel <akkor...@stanford.edu> writes: > The problem with that is, if I do that I'm putting all of my faith that > GSSAPI will be working on both ends. I don't want to trust in GSSAPI > not working if something goes wrong on my client. For example, if > Kerberos is messed up on my workstation, I could still securely log in > to the server, I'd just have a coworker log in and get the host key > fingerprint for me.
I thought you said that your policy required Kerberos authentication? If Kerberos is messed up on your workstation, that's not going to work. :) But in any event there will certainly be people who want to enable GSSAPI but not require it, so it seems like a useful fix. > I was wondering if this would need to go upstream, but from what I > understood, bug reporters are supposed to report bugs directly to > Debian. There isn't any particular policy about this. It's always okay to report the bug directly to upstream (well, unless upstream doesn't want the bug reports, but pretty sure that's not the case here). Some Debian package maintainers really prefer reporters to send the bug there first. I think Debian should accept bugs for its packages, but once identified as an upstream bug, often it's more effective for the reporter to talk to upstream directly instead of Debian being in the middle of the discussion. > Could you please tell me where "upstream" is in this case? https://github.com/SimonWilkinson/gss-openssh/ so far as I know. I'm not sure why the latest commit there is from 2011, since I know there's a newer version of the patch than that. Maybe Colin did the last update himself? > Yeah, it's really depressing, but I guess that's what's gonna > happen. Could it possibly make it into jessie-backports, or is that also > too much to hope for? That's certainly possible. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
