Re: Qt4's Webkit in Stretch
On Fri, Jan 22, 2016 at 05:43:59PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > And now that the facts are on the table I will give you my personal opinion: > even if lots of important apps depend on it I would remove it at least from > testing. That's what I think we should do, too. -- Dmitry Shachnev signature.asc Description: PGP signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt4's Webkit in Stretch
On Fri, Jan 22, 2016 at 05:43:59PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > And now that the facts are on the table I will give you my personal opinion: > even if lots of important apps depend on it I would remove it at least from > testing. Removing it is probably best way forward for two reasons, 1. People that use software that needs webkit clearly can keep using it even if it is removed so I don't see a problem. 2. Qt5 webkit is available. Porting Qt4 -> Qt5 is not much of an issue (remember the much more difficult Qt3 -> qt4 transition?) So, remove it from testing and then later remove it completely. Cheers, Adam -- Adam Majer ad...@zombino.com -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt4's Webkit in Stretch
Hi Sandro! On Sunday 24 January 2016 03:22:47 Sandro Knauß wrote: > Hey, > > > And now that the facts are on the table I will give you my personal > > opinion: even if lots of important apps depend on it I would remove it at > > least from testing. > > I can understand your option and also think this is okay, but I would like > to get a exception for kdepim/kdepim-runtime. > > Mails are very important for users, so removing it from testing would make > it impossible for testing users to read their mails. On the same base that mails are important for users, should we ship something that might be security-compromised and with no upstream support for something so important as mails? And mails fall exactly in the category of "app that handles unstrusted data" I'm afraid :-/ -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt4's Webkit in Stretch
On Fri, Jan 22, 2016 at 05:16:26PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi everyone! I would like to discuss the current situation for Qt4's Webkit > in > Stretch. > > Let me first start with some facts: > > = Facts = > > - Both Qt4 and (by inclusion) Qt4's webkit are no longer supported upstream. > > - If a security bug appears in Qt4 during Stretch's lifetime I'm pretty sure > we will be able to come up with a patch. There is too much people depending > on > it out there so this won't be a problem for Stretch. > > - For Qt4's webkit the situation might probably be the other way around. > Actually we might already have (quite some?) security bugs out there. > > = Removal efforts and options = > > So last year we started to work on removing it [removal]. Progress is sadly > far from good. We still have quite a lot of apps depending on qebkit in order > to show things like doc. Most of them do not use it for web browsing. > > [removal] <https://wiki.debian.org/Qt4WebKitRemoval> > > This has been discussed in the Qt/KDE team quite a lot of times with > different > opinions. For what I could gather the possible options are: > > (keep) Keep Qt4's webkit as it is in Stretch and warn users that they will > get > *no* security support. > > (removeintesting) Remove Qt4's webkit from testing, file an RC bug against it > so it doesn't transition and let rdeps be removed from testing until they > switch. Of course we will need the RT's approval for this. > > (totalremove) Remove Qt4's webkit from the archive together with it's rdeps > (or leave the rdeps RC buggy in unstable). > > Does anyone has a better idea? > > = What do we do? = > > If we take the (keep) option we need a good way to ensure users get the fact. > > If we go for any of the other two options we will need the RT/FTP team to ACK > the move. > > So I would really like to hear the opinions of people in both teams. If you > really think a certain way forward should be taken please speak now. > > Kinds regards, Lisandro. >From my point of view, qtwebkit has never been covered by security support >upstream and in Debian. We even document this in the release notes (and for several releases already): https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security So (keep) is the status quo and we can keep just as well maintain it for stretch. Cheers, Moritz -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt4's Webkit in Stretch
Hey, > And now that the facts are on the table I will give you my personal opinion: > even if lots of important apps depend on it I would remove it at least from > testing. I can understand your option and also think this is okay, but I would like to get a exception for kdepim/kdepim-runtime. Mails are very important for users, so removing it from testing would make it impossible for testing users to read their mails. Additionally we have already a solution in experimental kdepim based kf5 + akonadi5. A first version is already uploaded to experimental and me is currently updating it to 15.12. Hopefully after that we can think about pushing it to unstable. But we have also have to handle the applications depend on kdepim, that also needs to be updated (zanshin, kopete,...). Regards, sandro -- Am Friday 22 January 2016, 17:43:59 schrieb Lisandro Damián Nicanor Pérez Meyer: > And now that the facts are on the table I will give you my personal opinion: > even if lots of important apps depend on it I would remove it at least from > testing. > > Why? Well, I have been the only one uploading qt4's webkit since 02 Sep > 2014, and suffering it's hardware build requirements and it's codebase. I > really don't want to continue suffering it (I will already have too much > with Qt5's one), so if keeping it is the selected option someone will have > to step in for maintaining it. > > So (keep) proponents, be aware that you might be offering to do the job > yourself ;) signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt4's Webkit in Stretch
And now that the facts are on the table I will give you my personal opinion: even if lots of important apps depend on it I would remove it at least from testing. Why? Well, I have been the only one uploading qt4's webkit since 02 Sep 2014, and suffering it's hardware build requirements and it's codebase. I really don't want to continue suffering it (I will already have too much with Qt5's one), so if keeping it is the selected option someone will have to step in for maintaining it. So (keep) proponents, be aware that you might be offering to do the job yourself ;) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt4's Webkit in Stretch
On Friday, January 22, 2016 05:24:41 PM Lisandro Damián Nicanor Pérez Meyer wrote: > On Friday 22 January 2016 17:16:26 Lisandro Damián Nicanor Pérez Meyer > wrote: [snip] > > > Does anyone has a better idea? > > Not necesarily better, but an idea after all: > > (partialremove) check which packages use qt4's webkit for web browsing and > only remove those from testing. It's say to process untrusted data (which could be more than just web browsing), but with the modification, I agree it would be an option. Scott K -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Qt4's Webkit in Stretch
Hi everyone! I would like to discuss the current situation for Qt4's Webkit in Stretch. Let me first start with some facts: = Facts = - Both Qt4 and (by inclusion) Qt4's webkit are no longer supported upstream. - If a security bug appears in Qt4 during Stretch's lifetime I'm pretty sure we will be able to come up with a patch. There is too much people depending on it out there so this won't be a problem for Stretch. - For Qt4's webkit the situation might probably be the other way around. Actually we might already have (quite some?) security bugs out there. = Removal efforts and options = So last year we started to work on removing it [removal]. Progress is sadly far from good. We still have quite a lot of apps depending on qebkit in order to show things like doc. Most of them do not use it for web browsing. [removal] <https://wiki.debian.org/Qt4WebKitRemoval> This has been discussed in the Qt/KDE team quite a lot of times with different opinions. For what I could gather the possible options are: (keep) Keep Qt4's webkit as it is in Stretch and warn users that they will get *no* security support. (removeintesting) Remove Qt4's webkit from testing, file an RC bug against it so it doesn't transition and let rdeps be removed from testing until they switch. Of course we will need the RT's approval for this. (totalremove) Remove Qt4's webkit from the archive together with it's rdeps (or leave the rdeps RC buggy in unstable). Does anyone has a better idea? = What do we do? = If we take the (keep) option we need a good way to ensure users get the fact. If we go for any of the other two options we will need the RT/FTP team to ACK the move. So I would really like to hear the opinions of people in both teams. If you really think a certain way forward should be taken please speak now. Kinds regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt4's Webkit in Stretch
On Friday 22 January 2016 17:16:26 Lisandro Damián Nicanor Pérez Meyer wrote: [snip] > Does anyone has a better idea? Not necesarily better, but an idea after all: (partialremove) check which packages use qt4's webkit for web browsing and only remove those from testing. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
