On Mon, 15 Oct 2018 23:00:23 +0200 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= wrote:
> On Mon, Oct 15, 2018 at 10:41:25PM +0200, Steinar H. Gunderson wrote:
> > On Mon, Oct 15, 2018 at 10:33:11PM +0200, Moritz Muehlenhoff wrote:
> > > Ultimately this is up for Michael to decide, as he's dealing with
Chromium
> > > updates single-handedly.
> >
> > Agreed.
> >
> > > Personally I have no reservations against this entering unstable,
but this doesn't sound
> > > like something that should enter a stable release. If the Chrome
development team with
> > > it's hundreds of full time developers can't/wont commit to a
stable interface for these
> > > kinds of extensions, why should we kludge around this with our
sparse resources?
> >
> > I guess the answer is because software wants it. :-)
> >
> > CEF exists precisely to be an API-stable interface for this; it's
unfortunate
> > that Chrome doesn't care enough, but CEF is meant to be that layer,
and seems
> > to be doing pretty well (judging by the amount of software that
uses it).
>
> But our current infrastructure for security.debian.org doesn't scale
for this
> kind of API whack-a-mole. Any update to unbreak CEF after Chromium
major releases
> would need to go through the security team and sucks up our time
which is more
> usefully spend elsewhere.
>
> Realistically, to make this would we'd need $SOMEONE to implement
#817285, if
> that were in place we could simply push an ACL change and enable you
take care
> of CEF updates in buster-security on your own.
>
> Cheers,
> Moritz
>
>
I'm just coming up to speed on this (I'd never heard of CEF before, but
having a stable API for embedding chromium seems very sensible). I can
see a few different options here. I'm just going to document for
posterity as a followup to #893448. Please chime in if there's anything
else I should be considering.
1) Chromium adds a chromium-source binary package, with the
understanding that whoever packages CEF will keep it out of stable; or
perhaps kept out of stable by chromium itself, if chromium doesn't ship
in bookworm. It could be available in fasttrack or something, but we
won't make any attempt to have official mechanisms for CEF stable
updates. Pros: minimal effort on my part, no additional overhead by
release/security teams. Cons: packages that want to build against CEF
(obs-studio, casparcg-server, and possibly others) will be forced to
choose between optionally building against it but staying out of stable
releases, or splitting their source packages up into one that gets to
migrate to stable and one that doesn't.
2) Chromium adds a chromium-source binary package, whoever packages CEF
joins the chromium team (*waves to Sesse & pere*), and we work together
to push stable releases of chromium and CEF in a way that the security
team deems least objectionable (again, assuming chromium ships in
bookworm). Pros: packages that want to depend on CEF in stable can
safely do so. Cons: more effort on my part, more complicated testing
migrations, and the security team has already said that they don't like
this idea making it a non-starter until #817285 gets fixed. Also, it's
generally just kind of annoying to have two separate packages so tightly
bound together by an unstable API/ABI.
3) Chromium source package adds CEF to its source package. Chromium
builds CEF along with itself, and supplies a set of libcef-dev/libcef1
binary packages. Whoever wanted to package CEF joins the chromium team
and keeps the packaging updated in the chromium-team git repo. Pros: no
additional work needed by the security team. Packages that want to
depend on CEF in stable can safely do so. Cons: more effort on my part
(or maybe less if the team member starts helping w/ general chromium
stuff?), chromium will have to worry about CEF-depending packages during
testing migrations, already too-long chromium builds take longer, and we
could run into a situation where CEF upstream disappears and we're stuck
without updates (which could be potentially disasterous for bookworm
stable updates). And of course, I haven't actually tried doing a CEF
build so I don't know how feasible embedding it into the src:chromium
package is.
I don't have strong opinions either way, but if someone wanted to
experiment with implementing #3, I'd be open to considering it.
