Hi,

As mentioned on pkg-chromium-browser@, it would be useful if chromium-browser
shipped a chromium-browser source package; it would allow packaging and building
CEF (Chromium Embedded Framework) against Debian's (patched) sources instead of
off some random git checkout. I've added a patch.

Patch updated for Chromium 66 (trivial; really just unfuzzed).

There's an issue in that chromium/BUILD.gn:749 has an assignment which
according to gn “had no effect”, though.

/* Steinar */

control: tag -1 moreinfo

Are you intending CEF to make it into a stable release?  Since
chromium's source is updated every few weeks for security updates,
won't CEF need to be updated just as often?  If so, I'm not sure that
will be supportable over the lifetime of a stable release.

Best wishes,
Mike

control: tag -1 moreinfo

Are you intending CEF to make it into a stable release?  Since
chromium's source is updated every few weeks for security updates,
won't CEF need to be updated just as often?  If so, I'm not sure that
will be supportable over the lifetime of a stable release.

Best wishes,
Mike

Yes.

Yes. CEF generally follows Chromium fairly closely (support for a Chromium
branch begins when it enters the beta channel, and ends when it exits the
stable channel).

It's an open question to what degree we can give it security support, indeed.
The intention is for this to go through binNMUs for minor Chromium versions;
you'd have to actually upgrade CEF when major version bumps happen, which
means CEF security support would probably lag a week or two behind Chromium
security support in such cases.

Note that in many of the use cases CEF covers, you only run trusted code.
In particular, in the two possible downstream users in Debian that I know of
(nageru and obs-browser), Chromium is simply used as a rendering engine for
animation/graphics, not presented as a browser with a UI. Thus, it wouldn't
be a big loss to declare end of CEF security support if we run into
insurmountable troubles upgrading it in stable.

/* Steinar */

Yes.

Yes. CEF generally follows Chromium fairly closely (support for a Chromium
branch begins when it enters the beta channel, and ends when it exits the
stable channel).

It's an open question to what degree we can give it security support, indeed.
The intention is for this to go through binNMUs for minor Chromium versions;
you'd have to actually upgrade CEF when major version bumps happen, which
means CEF security support would probably lag a week or two behind Chromium
security support in such cases.

Note that in many of the use cases CEF covers, you only run trusted code.
In particular, in the two possible downstream users in Debian that I know of
(nageru and obs-browser), Chromium is simply used as a rendering engine for
animation/graphics, not presented as a browser with a UI. Thus, it wouldn't
be a big loss to declare end of CEF security support if we run into
insurmountable troubles upgrading it in stable.

/* Steinar */

Yes.

Yes. CEF generally follows Chromium fairly closely (support for a Chromium
branch begins when it enters the beta channel, and ends when it exits the
stable channel).

It's an open question to what degree we can give it security support, indeed.
The intention is for this to go through binNMUs for minor Chromium versions;
you'd have to actually upgrade CEF when major version bumps happen, which
means CEF security support would probably lag a week or two behind Chromium
security support in such cases.

Note that in many of the use cases CEF covers, you only run trusted code.
In particular, in the two possible downstream users in Debian that I know of
(nageru and obs-browser), Chromium is simply used as a rendering engine for
animation/graphics, not presented as a browser with a UI. Thus, it wouldn't
be a big loss to declare end of CEF security support if we run into
insurmountable troubles upgrading it in stable.

/* Steinar */

Chromium 67 was similarly trivial, so I didn't bother updating. CEF required
a tiny bit more work (Widevine no longer seems to be supported), but was
fairly easy, too.

New CEF packages (source and binary) at

http://storage.sesse.net/cef/

/* Steinar */

I am more concerned about major version updates.  I anticipate nearly
each one will cause CEF to fail to build from source, causing new RC
bugs often in the stable release.

Major updates to chromium in stable have so far been contingent on it
being a leaf package, where there is no chance for it to break
anything else.  Adding CEF as a reverse dependency would change that.

This is more of a question for the release team, it would need their approval.

Best wishes,
Mike

I am more concerned about major version updates.  I anticipate nearly
each one will cause CEF to fail to build from source, causing new RC
bugs often in the stable release.

Major updates to chromium in stable have so far been contingent on it
being a leaf package, where there is no chance for it to break
anything else.  Adding CEF as a reverse dependency would change that.

This is more of a question for the release team, it would need their approval.

Best wishes,
Mike

Yes, CEF will definitely need upgrading on major version updates. That's the
bad news -- the good news is that CEF upstream is usually very much on top of
that, doing the necessary changes well before a version hits the stable
channel.

Agreed.

/* Steinar */

Yes, CEF will definitely need upgrading on major version updates. That's the
bad news -- the good news is that CEF upstream is usually very much on top of
that, doing the necessary changes well before a version hits the stable
channel.

Agreed.

/* Steinar */

Yes, CEF will definitely need upgrading on major version updates. That's the
bad news -- the good news is that CEF upstream is usually very much on top of
that, doing the necessary changes well before a version hits the stable
channel.

Agreed.

/* Steinar */

I realize I should have Cc-ed debian-release :-)

Release team, for the short recap: Would it be acceptable to have chromium
provide a chromium-source binary package, and then package CEF (Chromium
Embedded Framework) Build-Depending on that package, and then have other
packages depend on CEF? CEF aims to provide a stable API/ABI on top of
Chromium for other software to use, but needs updating whenever Chromium
releases a new major version. See #893448 for some more details.

/* Steinar */

I realize I should have Cc-ed debian-release :-)

Release team, for the short recap: Would it be acceptable to have chromium
provide a chromium-source binary package, and then package CEF (Chromium
Embedded Framework) Build-Depending on that package, and then have other
packages depend on CEF? CEF aims to provide a stable API/ABI on top of
Chromium for other software to use, but needs updating whenever Chromium
releases a new major version. See #893448 for some more details.

/* Steinar */

I realize I should have Cc-ed debian-release :-)

Release team, for the short recap: Would it be acceptable to have chromium
provide a chromium-source binary package, and then package CEF (Chromium
Embedded Framework) Build-Depending on that package, and then have other
packages depend on CEF? CEF aims to provide a stable API/ABI on top of
Chromium for other software to use, but needs updating whenever Chromium
releases a new major version. See #893448 for some more details.

/* Steinar */

Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we
could add a CEF package in unstable only (ie., with a testing blocker bug)
for the time being.

FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required was
to patch out installation of Swiftshader (since Debian's packages now disable it).

/* Steinar */

Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we
could add a CEF package in unstable only (ie., with a testing blocker bug)
for the time being.

FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required was
to patch out installation of Swiftshader (since Debian's packages now disable it).

/* Steinar */

Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we
could add a CEF package in unstable only (ie., with a testing blocker bug)
for the time being.

FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required was
to patch out installation of Swiftshader (since Debian's packages now disable it).

/* Steinar */

I'm not sure we (RT) need to make any decision here.

Adding a chromium-src for other packages to build against is not special in any
way, we don't approve this for other packages.

As for the security support concerns, that's up to the security team.

Cheers,
Emilio

Hi,

Emilio Pozuelo Monfort wrote:

^^

However, you do have some say in whether a package is able to have
non-trivial updates in stable.  Can we infer from your reply that
you're still okay with this for Chromium even if CEF relies on it,
provided security team is okay with it?

Therefore cc-ing security team.

Thanks,
Jonathan

Ultimately this is up for Michael to decide, as he's dealing with Chromium
updates single-handedly.

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?

This is rather that kind of wacky not-really-suitable-for-stable-but-still-kinda-nice stuff
we should have PPAs for.

Cheers,
        Moritz

Agreed.

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).

/* Steinar */

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

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.

Hi,
I'm new maintainer of casparcg-server after pere.

Could we try this option 1) to make some progress at least in unstable and testing
and later with more experience see if we can continue to other option?

[Filip Hanes]

And I am very happy to have a replacement who actually use the
package. :)  The package is also moved under the Debian Multimedia
umbrella, allowing more people to particiate. :)

I suggest you give it a go locally, and see if you can get it working,
as well as report your progress on #debian-multimedia, to see if others
can help. :)

I've just completed packaging chromium-embedded-framework (ITP #915400),
which required extracting Debian Chromium sources as a build dependency.

The current approach uses a separate chromium_*.orig.tar.xz that must be
manually placed alongside the CEF sources. A chromium-source binary
package would simplify this significantly - CEF could simply
Build-Depends: chromium-source.

This is a concrete use case demonstrating usefulness and demand of this
package.
The CEF packaging documentation describes the workaround currently
required:
https://vejeta.com/packaging-chromium-embedded-framework-for-debian-a-technical-deep-dive/

The packages are available in an unofficial repository
https://debian.vejeta.com/
so users can start testing early and I can receive feedback.