https://bugs.kde.org/show_bug.cgi?id=470544
--- Comment #2 from Pedro V <voidpointertonull+bugskde...@gmail.com> --- (In reply to Harald Sitter from comment #1) > What exactly do you want to happen here? Assuming that there's an implicit understanding of what the problem with inquiry about expected resolution, I see the first step being someone with authority deciding how this long standing problem is supposed to be handled instead of just letting user experience suffer, and keeping around bug reports where the issue is clearly understood, there's just no plan to do anything about the problem. Not necessarily an exhaustive list of possible decisions, but I can see one of the following paths being chosen: - The whole problem is decided not to be on KDE, considering libssh issues not to be relevant here despite them impacting KDE user experience. In that case the relevant issues should be closed as not planned to be resolved here. - Depending on libssh might be still desired, but it either gets forked so issues can be patched bypassing upstream issues, or part of the functionality like known_hosts handling gets replaced with code not using libssh. - Deciding that libssh is not sufficient, so replacing it with another library or a new implementation (not really seeing this happening, but still a possibility). Take this as more of a pushing for decision with possibly cleanup effort. Ideally a task would be made outlining the chosen plan of resolving the problem, and all related bug reports could be closed as a duplicate of that. Even if there would be no fix any soon, it could at least centralize all the different bug reports into a larger "libssh limitations" topic, so users could be pointed there instead of letting each bug reporter individually discover looking at yet another manifestation of SSH config options just simply being ignored instead of KDE having some really weird bug. -- You are receiving this mail because: You are watching all bug changes.
