See https://lists.webkit.org/pipermail/webkit-gtk/2014-October/002093.html We are redistributing on our mirrors the following files that we must not: webkitgtk-2.2.6.tar.xz webkitgtk-2.4.4.tar.xz 2.4.6 is clean, but 2.2.6 is last stable on arm for both SLOTs and 2.4.4 is last stable on every other arch. We need to hurry up 2.4.6 stabilization or more realistically convert old ebuilds with same keywords on a revbump to the "a" suffixed tarballs as explained in the upstream mailing list post.
This was also CCed to distributor-list@gnome.org, we should follow it better :)
I followed it... but I needed near a night for compiling 2.4.6 for both slots on my laptop, later I bumped it but didn't call for fast stabilization as I wanted to give it at least a week to catch any new problems that could appear and also to try to drop more stable keywords due arches other than amd64/x86 being really really slow to stable it (we depend in ago's availability for them)
In the meantime, could 2.2.6 and 2.4.4 be mirror restricted, please?
+ 06 Oct 2014; Pacho Ramos <pacho@gentoo.org> webkit-gtk-2.2.6-r200.ebuild, + webkit-gtk-2.2.6.ebuild, webkit-gtk-2.4.4-r200.ebuild, + webkit-gtk-2.4.4.ebuild: + Restrict mirror for old versions due bug 524584 +
They promise the a suffixed tarballs have no other changes. We should just revbump each with same keywords and use the suffixed tarball if it comes to restricting mirroring otherwise (which is understandable). With the mirror restriction effectively webkit-gtk is not installable on any architectures stable tree at the moment. These bad tarballs are not available anywhere else for manual fetching.
That is, SRC_URI target does not exist anymore either; RESTRICT=mirror will wipe them out of our mirrors too (which we do need to do)
+ 06 Oct 2014; Pacho Ramos <pacho@gentoo.org> webkit-gtk-2.2.6-r200.ebuild, + webkit-gtk-2.2.6.ebuild, webkit-gtk-2.4.4-r200.ebuild, + webkit-gtk-2.4.4.ebuild: + Upstream also dropped the old tarballs (#524584#c6) + Revert that then, but I don't have just now time to rebuild all them to verify we can bump them safely (not sure if bumping them "blindly" would be safe...)
I still had 2.4.4. I'll do a 2.4.4-r1 locally with the only change in SRC_URI. If that goes fine, I'll just do the same for everything and commit revbumps at same keywords (to get people off of the non-redistributable images) blindly. I'm sure people will love us for a stable revbump just for that. Off for 1-3 hours now on business, it will be building meanwhile
(In reply to Pacho Ramos from comment #7) > Revert that then, but I don't have just now time to rebuild all them to > verify we can bump them safely (not sure if bumping them "blindly" would be > safe...) I fear the mirror restriction must stay in place, even if that means that tarballs cannot be downloaded by users any more. The tarball contains copyrighted material that is not redistributable, and from the link posted in comment #0, I conclude that the copyright holder (which happens to be Apple) has been informed of the copyright violation. We are also aware of the situation now, so if we continue redistributing the tarballs then it could be argued that we are no longer acting in good faith. Disclaimer: IANAL, TINLA. CCing trustees.
OTOH, I wonder what these guys at Apple Computer thought, declaring their Webkit project as Open Source (see http://www.webkit.org/) and then hiding such an easter egg of copyrighted material deeply in it. :(
I have committed revbumps with equal keywords for each version and SLOT, that uses the fixed tarballs, and immediately removed the previous revisions. So from GNOME's side, we should be done, but licensing/trustees and Gentoo collectively should probably check the following: 1) Make sure the bad tarballs leave our mirroring system, potentially speeding that process up if needed? 2) Check all the other webkit libraries we have in our trees for the same issue and handle any issues found appropriately To that effect, I'll leave the bug open. licenses@ might want to reassign to self, or create a clone bug for this. I will try to help a bit with 2) though, preferably collaborating over IRC if appropriate.
Oh, and to avoid any doubt these images from old revisions were present in a supposedly free software library: webkit-gtk optimizes the images into the library itself via the GResource system instead of having them all as separate files in the filesystem, so you can't find them via qlist or similar -- https://developer.gnome.org/gio/stable/gio-GResource.html You can see them present there with e.g gresource list /usr/lib64/libwebkitgtk-3.0.so.0 |grep UserInterface/Images gresource list /usr/lib64/libwebkit2gtk-3.0.so |grep UserInterface/Images
(In reply to Mart Raudsepp from comment #11) > I have committed revbumps with equal keywords for each version and SLOT, > that uses the fixed tarballs, and immediately removed the previous > revisions. So from GNOME's side, we should be done, Thanks. > but licensing/trustees and Gentoo collectively should probably check the > following: > > 1) Make sure the bad tarballs leave our mirroring system, potentially > speeding that process up if needed? CCing infra for this. > 2) Check all the other webkit libraries we have in our trees for the same > issue and handle any issues found appropriately > > To that effect, I'll leave the bug open. licenses@ might want to reassign to > self, or create a clone bug for this. > I will try to help a bit with 2) though, preferably collaborating over IRC > if appropriate.
(In reply to Mart Raudsepp from comment #11) > 2) Check all the other webkit libraries we have in our trees for the same > issue and handle any issues found appropriately Pretty sure qtwebkit-opensource-src-5.3.2.tar.xz has similar problems. Some of the SVG files are a bit different XML, but carry a copyright notice and the Source/WebInspectorUI/APPLE_IMAGES_LICENSE.rtf file is also present. The webkit fork in qt-everywhere-opensource-src-4.8.5.tar.gz src/3rdparty/webkit/Source/WebCore/inspector/front-end/Images is less obvious. It might be an earlier iteration of those icons in there and really have the issue, but I can't find any apple license file in there to claim different license than the whole. Though what license files happen to claim might not necessarily reflect reality. Visually they look somewhat similar, but differently sized and relatedly different level of visual detail. Unfortunately I can't really look through 132 image files right now, as can't exactly byte-compare PNG files and claim difference in face of pngcrush, new files being in original SVG form and whatnot.
Forgot to CC qt@. qt: You need to fix licensing issues discussed above (do not mirror qtwebkit-5.3.2) and hopefully help identifying the situation with qtwebkit-4.8.5
Would RESTRICT=mirror in all dev-qt/qtwebkit versions in tree be enough?
(In reply to Davide Pesavento from comment #16) > Would RESTRICT=mirror in all dev-qt/qtwebkit versions in tree be enough? qtwebkit-5.3.2 should be mirror restricted, and the issue should be sorted out upstream. For qtwebkit-4.8.5 we need to know where the icons originate from and if we can distribute them (and under what license). If it turns out that they are not redistributable, then all packages using the qt-everywhere-opensource-src-4.8.5.tar.gz tarball would have to be mirror restricted.
<hat type="infra"> Files removed from primary mirror, please allow some hours for propagation. </hat>
(In reply to Ulrich Müller from comment #17) > qtwebkit-5.3.2 should be mirror restricted, and the issue should be sorted > out upstream. 07 Oct 2014; Davide Pesavento <pesa@gentoo.org> qt5-build.eclass: Restrict mirror for qtwebkit wrt bug #524584
(In reply to Davide Pesavento from comment #19) > 07 Oct 2014; Davide Pesavento <pesa@gentoo.org> qt5-build.eclass: > Restrict mirror for qtwebkit wrt bug #524584 This doesn't look correct: [[ ${PN} == qtwebkit ]] && RESTRICT="mirror" # bug 524584 [[ ${QT5_BUILD_TYPE} == release && ${QT5_MINOR_VERSION} -le 3 ]] && RESTRICT="test" # bug 457182 For qtwebkit-5.3.2-r1 the second test evaluates as true, so RESTRICT will be overwritten again.
(In reply to Ulrich Müller from comment #20) You're right, sorry. Should be fixed now.
CCing infra again. Please remove also the following file from mirrors: qtwebkit-opensource-src-5.3.2.tar.xz
(In reply to Ulrich Müller from comment #22) > CCing infra again. Please remove also the following file from mirrors: > > qtwebkit-opensource-src-5.3.2.tar.xz With my infra hat on, file removed from master mirror. Please wait a few hours for propagation.
Any news on qt4 situation..?
(In reply to Mart Raudsepp from comment #24) > Any news on qt4 situation..? No. I contacted upstream ~3 months ago but received no reply.
Nothing further for the trustees here.
(In reply to Mart Raudsepp from comment #24) > Any news on qt4 situation..? qtwebkit:4 has been treecleaned, so I suppose we can close this one.
