Re: The GSS-API split
On Wed, Nov 13, 2024 at 11:00:11AM -0300, Andreas Hasenack wrote:
> On Tue, Nov 12, 2024 at 12:44 PM Colin Watson <cjwatson@debian.org> wrote:
> > On Tue, Nov 12, 2024 at 09:33:14AM -0300, Andreas Hasenack wrote:
> > > Yeah, the merge is behind.
> > >
> > > I was hoping to start this change now, for 25.04, or 25.10 at the
> > > latest, so that it would have stabilized for 26.04.
> >
> > Well, you'd need to get the empty *-gssapi binary packages into 26.04 in
> > order to be able to do the second stage of the split for 28.04.
> > Otherwise anyone actually using GSS-API in Ubuntu won't have a
> > reasonable upgrade path.
>
> If I understood it correctly, the plan is to let people know via
> d/NEWS (already in 1:9.8p1-5), and via release notes, that they should
> install *-gssapi packages if they rely on that authentication
> mechanism. If they don't use the new packages, when a release to
> trixie+1 happens they will lose the ability to authenticate via
> gssapi. So there is a user-driven component here: they have to be
> aware, and take action. Across release boundaries that is ok, is the
> thinking?
If we don't have a release boundary, then there's very little chance
users will notice, and the likely effect will be that GSS-API support
will be dropped without them having a chance to prepare for it and cause
their systems to break (possibly in ways that render them unable to log
in remotely and fix them).
If we have a release boundary, then that certainly doesn't guarantee
users will notice and prepare, but at least it gives them a fair chance.
> > Is there really a good reason that the unique-ccache patch needs to
> > block on proceeding further with the package split? Yes, in theory it
> > would reduce the risk a bit, but it's already mostly behind a new
> > off-by-default configuration option. I think that rushing the package
>
> That patch is quite intrusive as well, and there is a risk it might
> not apply cleanly on top of a new openssh version, or on top of
> another security patch that might come. We have been testing it for
> jammy and noble, and such a case hasn't happened yet in all the
> openssh updates we released so far, but it's a concern. Probably the
> same one you had when you imported the key-exchange patch way back.
>
> I wouldn't want to be in a position where this patch is delaying a
> security update to openssh because it's not applying and needs
> refactoring. If it's only applied in the other openssh source package,
> we would still be able to release the main one quickly, while the
> patch is being worked on. But maybe I can't avoid this.
I agree this is a somewhat valid concern, but in this case the patch is
only 600 lines or so, and it doesn't touch many of the sorts of places
that tend to get refactored extensively by upstream. I don't think it's
likely to be too bad in practice.
The GSS-API key exchange patch is much more invasive.
> > > There is no indication of when trixie will be released yet, right,
> > > just "sometime in 2025"?
> >
> > Not yet, no. But if you look at
> > https://en.wikipedia.org/wiki/Debian_version_history, Debian's had a
> > fairly reliable two-year cadence (plus or minus a few months) since
> > 2005, so mid-2025 seems like a pretty good bet.
> >
> > Given that, I expect that Ubuntu 26.04 will be the blocker for
> > proceeding with the second stage of the split, not trixie.
>
> But 26.04 will be based on debian testing from late 2025, likely Forky
> already, where the second phase split will be done, or due to be done.
That's up to me. I was expecting to wait until both trixie and 26.04
had released with the first phase of the split before proceeding with
the second phase, which should still give me plenty of time to get it
into forky.
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: