Moritz Mühlenhoff wrote: > Am Thu, Jan 27, 2022 at 10:01:34AM +1100 schrieb Trent W. Buck: > > Alberto Garcia wrote: > > > Two WebKit ports are actively maintained, available in Debian and have > > > security support: WPE WebKit and WebKitGTK (the package is called > > > webkit2gtk for technical / historical reasons). > > > > > > Other WebKit ports available in Debian are not covered by security > > > support. I know there's at least QtWebKit, I don't know if there are > > > more. > > > > OK, so as I asked upthread: > > > > Am I misreading the Release Notes? > > > > > > https://www.debian.org/releases/bullseye/arm64/release-notes/ch-information.en.html#limited-security-support > > > > browsers built upon e.g. the webkit and khtml engines^[6] are > > included in bullseye, but not covered by security support. > > > > Are you saying that webkit2gtk is supported, but anything that USES > > webkit2gtk is unsupported? > > > > If the answer is "yes", then I guess instead of > > security-support-limited including src:webkitgtk it should include all > > browsers that USE src:webkitgtk? > > > > e.g. epiphany-browser, evolution, yelp, and webkitgtk (due to MiniBrowser). > > > > Or all this stuff *is* all fully supported by Debian Security team, then > > should I instead file a bug against the Release Notes? > > Any reverse dependency of webkit2gtk is supported (i.e. applications like > Epiphany, Evolution etc). > > Other browsers which use engines which are similarly named since they > share a common code history are not supported: > - qtwebkit (only present up to Buster) > - qtwebkit-opensource-src > - qtwebengine-opensource-src > - webkitgtk (only present up to Stretch) > > This e.g. means that the default browser in KDE (Konqueror) is entirely > unsupported with security updates. > > Note this isn't the case for any distro out there, we're just the only one > transparent about in in their release notes! > > E.g. qtwebengine rebases to Chromium releases from time to time, but > definitely not a pace which is needed and none of this reaches distros > properly. > > I understand this is probably a little confusing, so maybe we should > instead list specific browsers as examples for webengine related components > which are supported and which are not.
Definitely I am confused! :-) As a sysadmin shipping Debian in prisons, I want an easy way to detect and ban packages (especially browser engines/browsers) that are not security-supported. My initial reading of the Debian 11 release notes was "unless it is EXACTLY firefox-esr or chromium, it's not supported". So for example, I banned zenity because that uses webkit2gtk and that's not firefox-esr/chromium. I care a lot more about having a clear list (or simple heuristic), than about keeping any specific package in/out of the list. I *think* my life is simpler if I allow/block entire engines, because if there's a rule like "qtwebengine is supported as long as it only handles KDE help documents" then I have to fiddle-fart around proving that each app will ONLY use the engine for KDE help documents and not (for example) knewstuff content from https://autoconfig.kde.org/ocs/providers.xml (which Debian hasn't vetted).