Comment 164 for bug 727064

Since there is no ETA from Adobe, I think we should consider a fix for the time being. I'm just trying to brainstorm the problem. Possible solutions could be:

1) Revert the glibc change. While I don't think that a perfectly good change in glibc should be reverted to placate a proprietary plugin, this is not a perfectly good change. It's essentially a workaround for a defect in some Intel processors. It may improve benchmarks, but we can and should ask about real life benefits. While operations on short arrays may become faster in some very specific cases, copying of large and well-aligned arrays is likely be slowed down by going backwards.

2) Add a wrapper to Firefox to use memmove() instead of memcpy(). Users of other browsers will do it for themselves.

3) I don't know if it's feasible, but maybe nspluginwrapper could be changed to intercept the memcpy() call from the plugins. Maybe another wrapper could be bundled with nspluginwrapper.

4) Another wrapper could be written for flash plugin. That wrapper should be part of the flash-plugin package, and it should be very strongly recommended by the fedora Flash page (http://fedoraproject.org/wiki/Flash)

5) The flash-plugin package should patch the plugin on install. rpm verification will fail, but perhaps it's OK. We could mark the plugin as a "configuration file".

6) The flash-plugin package should patch the plugin at the build time. This could have legal consequences, but I don't think Adobe would actually enforce them considering that the change is purely to fix a flaw in their product.