[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: please add a chromium-source binary package



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.


Reply to: