OpenH264 in Fedora

[Adam Jackson]

On Wed, 2013-11-06 at 17:08 +0100, Nicolas Mailhot wrote:
> Le Mer 6 novembre 2013 16:05, Adam Jackson a écrit :
> > On Wed, 2013-11-06 at 09:36 +0100, Roberto Ragusa wrote:
> >> On 11/04/2013 07:30 PM, Alberto Ruiz wrote:
> >>
> >> > A media codec should not be a system wide component (I'd go as far as
> >> > saying it should not be user-session wide, but application bundled).
> >>
> >> ???
> >> Would you so apply the same reasoning to libjpeg and libtiff?
> >> Security nightmare.
> >
> > It's only a nightmare because we've steadfastly refused to build the
> > tools to a) track library bundling inside app-bundles b) automate bundle
> > rebuilds c) force replacement of bundle contents either by sysadmin
> > action or by policy.
> 
> If you could do c there would be no reason not to depend on a system lib
> in the first place. Depending on system libs is painful because upstreams
> make replacement hard (hardcoding versions, depending on private patches
> to system libs, etc)

Again: don't stop the solution short based on what the current code
happens to implement.

If we're building the bundles - and there's reasons we would want to -
then we know the patches we need to apply.  And if we're not, then the
policy decision to potentially break functionality in the name of
security is an entirely reasonable thing a site admin or an end-user
might want to do; and more to the point, the tools we'd build for
managing and updating our own bundles would be reusable components that
third parties could use too.  Which would be a far sight better than
rpm, which is effectively _not_ how third parties distribute software,
for reasons which by now must be bleedingly obvious.

You may as well say git can't ever have a 'rebase' verb because
different branches might have different patches applied so of course it
can't ever work.

Don't throw your hands up in resignation.  Write code.  Fix problems.

- ajax