-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address issues with host switcher removal before releasing Cockpit with this feature #20823
Comments
Let's figure out what it would mean to fix this in such a way where it's not blocking release:
Timeline: This should all be finished before mid-October? Unblocking release would be steps 1 - 3. |
The delta is effectively "keep it on for Fedora 40". Arch is a rolling release like rawhide, and there it should be disabled first.
Note that we were running out of time about disabling the feature for RHEL 10. We can change the looks of it all the way through the next 4 years.
Not sure what this means. The relnotes enumerate exactly which ones change (development series) and which don't (LTS/stable releases).
The release note in #20749 does list the alternatives that we have.
That seems fine, yes.
There's nothing special about mid-October. The only time-critical thing is point 1 (but that's also trivial to do) |
@mvollmer and had a meeting and took notes. Adapting to the host switcher removalGoals
Planning
|
The modal that prevents connecting should probably mention the alternatives in the top comment @ #20749 (comment):
So people using Cockpit are aware and can transition over, instead of just outright breaking their years-old workflows with no warning whatsoever. |
"Off" on the upcoming releases, "keep on" for existing stables.
Nothing about this problem is RHEL specific. RHEL 9 is a place where we can't turn off the host switcher without (rightfully) risking the anger of customers, but we have no such obligation for Fedora (and not even for RHEL 10 beta for the next two weeks -- afterwards the feature goes public). Also, if we have a solution that is good enough for RHEL, it's surely good enough for all the other OSes.
That's what we've had since 2023.
The first version of the warning introduced in #19409 had a more scary appearance FTR. But you know full well user psychology -- that doesn't really work well. We've had a recent customer call and despite that warning they were absolutely shocked when we explained the potential impact. Re-enabling this needs to take more effort than ignoring a little yellow warning line. Hence the config option: you have to read the documentation for it, have more information, and are in much less of a psychological hurry to get to you sweets than in the dialog.
Yes, that's my concern as well, and it collides with "Remove the “mixed mode”" -- that is the much more painful part. Ripping it out right away gives people no transition period for existing setups.
This dialog is only shown for hosts unknown to SSH. Once you ack the fingerprint, it's marked as trusted. FTR: I've announced the analysis in https://issues.redhat.com/browse/COCKPIT-870 multiple times in our weekly meetings since May, and begged for feedback. I also discussed it in Brno (granted, neither Marius nor Garrett was there), with just about zero interest. But oh well that's fine -- at least now the pressure is to justify introducing weaknesses again, instead of justifying to plug them. |
No. Not at all I thought we have a warning during the key exchange, not when connecting to existing hosts? Someone who already has added hosts in the past would never see the issue if we remove the only place where the warning is shown from being accessed.
You did not ask for design feedback specifically, and whenever I asked about it from a design standpoint, I was always told that you were still hashing out the implementation details and weren't sure which direction it would go... this was even as recent as this past Monday in the meeting and also even Tuesday in Matrix. I have so many other things to work on, and if something that is still talked about as being in an "exploratory" prototype stage to see what's "technically possible" and design consideration is also dismissed the multiple times when I keep asking, then I really have to still concentrate on other things.
Right, Marius and I weren't there in person, and this also wasn't mentioned on the video call at all, which I did attend as much as possible while you all had the meeting.
Right, but the problem is also mainly theoretical, as a machine that someone connects to has to also be compromised. Obviously, an Enterprise environment is different from a hobby environment (home servers and such), and restricting it in RHEL10 like this makes sense. And businesses migrating from RHEL9 (and prior) to RHEL10 is a big deal and will have lots of changes anyway, so they will expect some things to be different from before. But we shouldn't handle a removal of a feature in the community side of things by immediately breaking it halfway, especially in a non-obvious way, for non-obvious reasons. We need to provide a migration path and let people ahead of time. And we need to let them know why. Not everyone reads the docs or our website (and, in fact, I'd argue most don't, as that's the way it generally works for nearly all projects and products)... most people will see the change in Cockpit, be confused as to why things are broken and then not know what to do, causing frustration. We can, and should, handle this better as to avoid that. |
As a community project, we have good will from people using it in the community. Breaking a popular feature we've had for years without warning means we're burning some good will from people, and I want for us to avoid that. (It's totally different compared to a big RHEL upgrade, where admins expect and plan for changes. And the changes are batched up over years across lots of projects.) |
This gets challenged/debated heavily, see cockpit-project#20823 Reopens https://issues.redhat.com/browse/COCKPIT-1149 and https://issues.redhat.com/browse/COCKPIT-870 This reverts commit ee3262e.
Right, because it'd be silly to warn about connecting to hosts which you already know and connected to in the past.
"Design" in the sense of "what do we do about this whole topic: That's all I ever talked about. I laid out an analysis and possible directions. "Design" in the sense of "pixels", no -- there are many aspects of this (magic triangle choices and priorities, existing users, workflows, what are we able to support, providing alternatives for RHCERT and talking to them, etc.), but I never considered dropping that triangle as a "design" thing. I sent PR #20829 to revert this and assigned https://issues.redhat.com/browse/COCKPIT-870 to @garrett and @mvollmer for continuing this. With my almost-zero availability in the past and next few weeks, and the obvious turmoil I created, I think it's better if I reset to the previous state and we start from scratch. And as I've been unable to raise any interest about this in the past few months, I obviously did that wrong. Sorry about that, and I hope you have more luck with this. Please talk your solution over with https://issues.redhat.com/secure/ViewProfile.jspa?name=rhn-engineering-thoger Thanks! |
This gets challenged/debated heavily, see cockpit-project#20823 Reopens https://issues.redhat.com/browse/COCKPIT-1149 and https://issues.redhat.com/browse/COCKPIT-870 This reverts commit ee3262e.
It's just as theoretical that those machines could've been hacked as a new machine.
I hope you're feeling better soon! Sorry for the added drama! |
I need an alternative to do this key feature, that I use for virtual machines being removed? Do I now have to be restricted to tunneling each device that I was originally using this for? |
@tek-aevl https://cockpit-project.org/blog/cockpit-322.html lists three alternatives and how to turn it back on -- but you must know what you are doing. |
Looks simple enough, my main issue would be that tye keyboard does not always launch when selecting a machines vnc console, therfore this was the back up way into my virtual machines. |
Originally posted by @garrett in #20749 (comment)
The text was updated successfully, but these errors were encountered: