Re: Confusing our users - who is supporting LTS?
On Wed, Oct 24, 2018 at 4:15 AM Sean Whitton wrote: > > On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote: > > > > In short: Make it very clear if you want to provide long-term support > > for your project. Talk to the LTS team in case you need help. Nobody is > > forced to do anything. > > This is a good idea, but ISTM the assumption should be that the > subproject does not participate unless it explicitly says that it does. This thread started because users have the opposite assumption. So I think it would be better to be explicit about support teams and timelines. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#911709: tomcat7: Security update broke apps with AccessControlException for org.apache.tomcat.util.http
Hello,
Am 23.10.18 um 21:20 schrieb Anthony DeRobertis:
> Package: tomcat7
> Version: 7.0.56-3+really7.0.91-1
> Severity: important
>
> After applying the recent security update, the web app we're running
> (which is unfortunately a proprietary product provided by a vendor) no
> longer works. Instead, I get an exception and a blank page.
> Interestingly, in /etc/tomcat7/policy.d/40_«redacted».policy, there is a
> grant:
>
> grant codeBase "file:/srv/hm/HPM54/WebApp-«Redacted»/-" {
>⋮
>permission java.lang.RuntimePermission
> "accessClassInPackage.org.apache.tomcat";
> }
>
> ... adding another grant for accessClassInPackage.org.apache.tomcat.util.http
> seems to get it working again, but that's not something you'd expect without
> warning from a security update.
We follow upstream releases of Tomcat 7 closely. Unfortunately I can't
tell why your webapp needs those permissions without having a look at
the source code. It is quite possible that your previous security
permissions were insufficient and just worked because of a bug in Tomcat
7 that got fixed alongside the last security update. I recommend to file
an upstream bug report instead because Debian ships the latest upstream
release without making any behavioral changes. [1] The upstream
developers will more likely be able to track this issue down.
Regards,
Markus
[1] https://tomcat.apache.org/bugreport.html
signature.asc
Description: OpenPGP digital signature
Re: Confusing our users - who is supporting LTS?
Hello Markus, On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote: > I believe LTS is not a black and white issue as it is depicted in this > thread so far. Yes, that is fair enough. > This is the first time that someone expresses concern how LTS affects > other subprojects but I don't think it is correct to assume that it is a > general issue which can only be solved by making LTS less integrated > into Debian. I feel the best way to deal with such situations is to > communicate very clearly that "subproject X" does not support LTS > releases and recommends to make an upgrade instead. If subproject X is > general in favor of LTS support but lacks time and energy to make it > happen, we should determine whether it is possible and desired that the > LTS team steps in and lends a helping hand. > > In short: Make it very clear if you want to provide long-term support > for your project. Talk to the LTS team in case you need help. Nobody is > forced to do anything. This is a good idea, but ISTM the assumption should be that the subproject does not participate unless it explicitly says that it does. -- Sean Whitton signature.asc Description: PGP signature
Bug#911709: tomcat7: Security update broke apps with AccessControlException for org.apache.tomcat.util.http
Package: tomcat7
Version: 7.0.56-3+really7.0.91-1
Severity: important
After applying the recent security update, the web app we're running
(which is unfortunately a proprietary product provided by a vendor) no
longer works. Instead, I get an exception and a blank page.
Interestingly, in /etc/tomcat7/policy.d/40_«redacted».policy, there is a
grant:
grant codeBase "file:/srv/hm/HPM54/WebApp-«Redacted»/-" {
⋮
permission java.lang.RuntimePermission
"accessClassInPackage.org.apache.tomcat";
}
... adding another grant for accessClassInPackage.org.apache.tomcat.util.http
seems to get it working again, but that's not something you'd expect without
warning from a security update.
Oct 23, 2018 2:58:47 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing HardMetrics action servlet.
Oct 23, 2018 2:58:54 PM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.security.AccessControlException: access denied
("java.lang.RuntimePermission"
"accessClassInPackage.org.apache.tomcat.util.http")
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at
java.security.AccessController.checkPermission(AccessController.java:684)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1525)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:320)
at java.lang.ClassLoader.loadClass(ClassLoader.java:417)
at java.lang.ClassLoader.loadClass(ClassLoader.java:363)
at
org.apache.coyote.http11.AbstractHttp11Processor.prepareResponse(AbstractHttp11Processor.java:1677)
at
org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:825)
at org.apache.coyote.Response.action(Response.java:171)
at
org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:185)
at org.apache.coyote.Response.doWrite(Response.java:495)
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:405)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:442)
at
org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:488)
at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:273)
at
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:540)
at
org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:152)
at
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:336)
at java.io.Writer.write(Writer.java:157)
at org.apache.jsp.base.logon.logon_jsp._jspService(logon_jsp.java:877)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:453)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:548)
at
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
at
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.re
Re: backported gnutls28 3.3.30 packages availabled for jessie LTS
On 2018-10-23 19:26:32, Ben Hutchings wrote: > On Tue, 2018-10-23 at 14:00 -0400, Antoine Beaupré wrote: >> Hi, >> >> After the lengthy discussion[1] regarding the pending security issues in >> GnuTLS (CVE-2018-10844, CVE-2018-10845, CVE-2018-10846), I have >> determined it might be simpler to just upgrade to the latest upstream >> 3.3.x version for which upstream is still providing updates. Upstream >> agrees with the approach. This removes 35 Debian-specific, backported >> patches and fixes other unrelated bugs. The API/ABI *changes*, but it >> only adds *new* symbols so the soname versions do not change. > [...] > > I don't know exactly what gnutls's policy is for stable updates, but > based on a quick look at the NEWS file it seems like these changes are > probably suitable for a stable/LTS update. > > I did spot some incompatible changes in behaviour which might need to > be called out in the Debian changelog or NEWS file, or even reverted, > depending on how many users they might affect: > > ** libgnutls: Refuse to import v1 or v2 certificates that contain > extensions. > > ** libgnutls: ARCFOUR (RC4) is no longer included in the default priorities >list. It has to be explicitly enabled, e.g., with a string like >"NORMAL:+ARCFOUR-128". The previous behavior can be restored using >the flag --with-arcfour128 to configure. > > ** libgnutls: SSL 3.0 is no longer included in the default priorities >list. It has to be explicitly enabled, e.g., with a string like >"NORMAL:+VERS-SSL3.0". The previous behavior can be restored using >the flag --with-ssl3 to configure. > > ** libgnutls: require strict DER encoding for certificates, OCSP requests, > private >keys, CRLs and certificate requests. This backports the already default > behavior >from the 3.5.x branch, in order to reduce issues due to the complexity of > BER rules. Good catches. I should really go through those again with a NEWS.Debian update in mind. One thing they did to fix those 'pseudo-constant time' vulnerabilities is to remove certain algorithms as well, and I don't see those above. So we shold probably warn about that as well. A. -- That's one of the remarkable things about life: it's never so bad that it can't get worse. - Calvin
Re: backported gnutls28 3.3.30 packages availabled for jessie LTS
On Tue, 2018-10-23 at 14:00 -0400, Antoine Beaupré wrote: > Hi, > > After the lengthy discussion[1] regarding the pending security issues in > GnuTLS (CVE-2018-10844, CVE-2018-10845, CVE-2018-10846), I have > determined it might be simpler to just upgrade to the latest upstream > 3.3.x version for which upstream is still providing updates. Upstream > agrees with the approach. This removes 35 Debian-specific, backported > patches and fixes other unrelated bugs. The API/ABI *changes*, but it > only adds *new* symbols so the soname versions do not change. [...] I don't know exactly what gnutls's policy is for stable updates, but based on a quick look at the NEWS file it seems like these changes are probably suitable for a stable/LTS update. I did spot some incompatible changes in behaviour which might need to be called out in the Debian changelog or NEWS file, or even reverted, depending on how many users they might affect: ** libgnutls: Refuse to import v1 or v2 certificates that contain extensions. ** libgnutls: ARCFOUR (RC4) is no longer included in the default priorities list. It has to be explicitly enabled, e.g., with a string like "NORMAL:+ARCFOUR-128". The previous behavior can be restored using the flag --with-arcfour128 to configure. ** libgnutls: SSL 3.0 is no longer included in the default priorities list. It has to be explicitly enabled, e.g., with a string like "NORMAL:+VERS-SSL3.0". The previous behavior can be restored using the flag --with-ssl3 to configure. ** libgnutls: require strict DER encoding for certificates, OCSP requests, private keys, CRLs and certificate requests. This backports the already default behavior from the 3.5.x branch, in order to reduce issues due to the complexity of BER rules. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Re: backported gnutls28 3.3.30 packages availabled for jessie LTS
Ah, and I pushed my changes here: https://salsa.debian.org/debian/gnutls/tree/gnutls28_jessie_3.3.30+ A. -- We should act only in such away that if everyone else acted as we do, we would accept the results. - Emmanuel Kant
backported gnutls28 3.3.30 packages availabled for jessie LTS
Hi, After the lengthy discussion[1] regarding the pending security issues in GnuTLS (CVE-2018-10844, CVE-2018-10845, CVE-2018-10846), I have determined it might be simpler to just upgrade to the latest upstream 3.3.x version for which upstream is still providing updates. Upstream agrees with the approach. This removes 35 Debian-specific, backported patches and fixes other unrelated bugs. The API/ABI *changes*, but it only adds *new* symbols so the soname versions do not change. [1]: CABY6=0nu1qg9beb5qc-mbzfubmqgxp9dbgnicfupppiwz+o...@mail.gmail.com I have uploaded the test package in the usual location here: https://people.debian.org/~anarcat/debian/jessie-lts/ Direct link to the .changes file: https://people.debian.org/~anarcat/debian/jessie-lts/gnutls28_3.3.30-1+deb8u_amd64.changes The debdiff is obviously quite large so I haven't audited the whole diff, which would have basically meant reviewing all the releases between upstream 3.3.8 and 3.3.0: 2151 files changed, 65784 insertions(+), 60661 deletions(-) Note that about 3000 lines of those are from debian/patches removals that were now unnecessary. The upstream changelog details all the changes: https://gitlab.com/gnutls/gnutls/blob/gnutls_3_3_x/NEWS Our branch point was 3.3.8, over four years ago. The latest 3.3.30 release was last july. It should be possible to backport the upstream patches for those issues as well. But considering the amount of work that represented and how sensitive the issue is, I felt more confident going with upstream's recommendation. Extensive testing is recommended. The test suite obviously passes here (otherwise the package does not build) but there might be other problems that I haven't foreseen. Thanks for any feedback. A. -- Information is not knowledge. Knowledge is not wisdom. Wisdom is not truth. Truth is not beauty. Beauty is not love. Love is not music. Music is the best. - Frank Zappa
Re: Confusing our users - who is supporting LTS?
[I am trimming the CC list a little. Steve is subscribed to debian-lts. Our leader is subscribed to debian-lts and debian-devel and drowns in emails anyway. I hope you agree.] Am 23.10.18 um 15:47 schrieb Sean Whitton: [...] > The more LTS is integrated with the regular project, the more that teams > will feel they have to spend time on LTS matters. Even if paid LTS team > members are the ones writing the patches to do the actual integration, > the relevant Debian team will still have to review those patches, engage > in design discussion and keep LTS needs in mind while doing their other > work. Indeed, that's what you're asking for in the paragraphs of your > e-mail I've quoted. Reducing integration avoids this problem. I believe LTS is not a black and white issue as it is depicted in this thread so far. We neither solve such a problem by hiding LTS nor by reducing the integration within the Debian project. The goals of the LTS project have been clearly communicated from the beginning and nobody was ever forced to work on them. [1] Our main goal is to extend the lifetime of stable releases by providing security support and bug fixes for all packages except those which are marked as unsupported in our debian-security-support package. That has never implied that we support every official or non-official subproject that bases its work on the availability of LTS. This is the first time that someone expresses concern how LTS affects other subprojects but I don't think it is correct to assume that it is a general issue which can only be solved by making LTS less integrated into Debian. I feel the best way to deal with such situations is to communicate very clearly that "subproject X" does not support LTS releases and recommends to make an upgrade instead. If subproject X is general in favor of LTS support but lacks time and energy to make it happen, we should determine whether it is possible and desired that the LTS team steps in and lends a helping hand. In short: Make it very clear if you want to provide long-term support for your project. Talk to the LTS team in case you need help. Nobody is forced to do anything. Regards, Markus P.S.: As a first step I'm going to create a LTS/Jessie subpage on our wiki that will outline what we currently (don't) support in Jessie. [1] https://wiki.debian.org/LTS/ signature.asc Description: OpenPGP digital signature
Re: Confusing our users - who is supporting LTS?
Hi Steve! On 2018-10-23 04:26:18, Steve McIntyre wrote: > So I'm worried that those of us who have *not* volunteered to support > LTS are being pressured into spending our time on it anyway. What can > we do to fix that? How/where do we clarify for our users (and > developers!) what LTS means, and what expectations are fair? TL;DR: Why not just delegate image management to the LTS team once oldstable because LTS just like we do with security? Zobel also provided a good template for the images life cycle which could clarify this on debian-cloud@, which I fully support. I acknowledge this is, indeed, a problem Debian volunteers have sometimes mentioned. It's a broader issue than just the cloud team of course, but if I may, I would like to try and fix that specific issue in itself. I know there's the larger debate of separation of duty and infrastructure, paid-vs-unpaid work and other questions, but I do not think it's productive to fix that particular issue by addressing the larger ones up front, as they seem intractable unless we address specific cases. In this case, it seems to me we have a flawed assumption in the way we handle Debian LTS: we assume people will not actually install it and instead just upgrade machines installed when LTS was "stable". It's a fair assumption in the case of workstations and long-lived, "pet" servers. I know I wouldn't install a new bare-metal server with an unsupported release: I would install stretch, if not buster, not jessie. But in the cloud infrastructure, things are slightly different. The base image isn't as important as the application and/or data that runs on top. In the cloud, we install new "machines" all the time, sometimes as part of CI/CD processes and those machines are not "pets", they are "cattle" and recycled constantly. In that sense, switching the base OS is, paradoxically, a big deal so it actually makes sense to install an older release for newer machines. This is why Travis CI still supports Ubuntu LTS Precise (12.04) and Trusty (14.04), the former which isn't supported by Canonical, and it's missing *two* more recent LTS releases, Xenial (16.04) and Bionic (18.04). So while we haven't taken up the work of managing the debian-installer parts of Debian LTS (because there was no need or demand for it), it seems to me like a fair request that the Debian LTS team should manage the Debian Cloud images once the official support window closes. Just like the security team delegates oldstable to LTS, the cloud team could hand off unsupported images to the LTS team. In a way, just like APT and the normal archive, "cloud images" are just another way to "upgrade" an existing Debian install. It seems like a nice, symmetrical approach to solve the problem: just punt this over to the LTS team. We have some capacity and knowledge. I know I would be happy to work on those images. That's for the expectations part of the question. As for how to clarify this to our users, Martin Zobel-Helas made a good proposal for a workflow of how and when the team updates the images and when they become unsupported. The /etc/motd in the images could mention this, for example and the last build could add a warning pointing to it. If we agree to delegate to the LTS team, the document should also mention that transition. Sorry for the long email, I hope it's useful! a. -- We have to talk about liberating minds as well as liberating society. - Angela Davis
Re: Confusing our users - who is supporting LTS?
Hello Raphael, On Tue 23 Oct 2018 at 09:52AM +0200, Raphael Hertzog wrote: > Instead we are rather aiming to integrate LTS more and more everywhere. > However, when LTS is becoming a burden on other teams, we should > definitely look how the LTS team can help to alleviate that burden. > Because as you know the LTS team has paid contributors to do that kind > of work. > > I invite you to start a conversation between debian-lts and debian-cloud > to discuss how the LTS team can help you with the workload that you would > rather get rid of. Maybe we need to allocate some time each month to > update LTS images, maybe you need our help to improve your tooling to better > support LTS and that would be enough, etc. I don't know. Let's discuss. Unfortunately, I don't think this suggestion could help with the issues raised by Steve. The more LTS is integrated with the regular project, the more that teams will feel they have to spend time on LTS matters. Even if paid LTS team members are the ones writing the patches to do the actual integration, the relevant Debian team will still have to review those patches, engage in design discussion and keep LTS needs in mind while doing their other work. Indeed, that's what you're asking for in the paragraphs of your e-mail I've quoted. Reducing integration avoids this problem. -- Sean Whitton signature.asc Description: PGP signature
Xen 4.4 updates - request for feedback
Hello, everyone, I prepared another set of fixes based on the current Xen package on jessie-security (4.4.4lts2-0+deb8u1, DLA-1549). These fixes include CVE-2017-15595 / xsa 240 CVE-2017-15593 / xsa 242 CVE-2017-15592 / xsa 243 CVE-2017-16693 / xsa 244 CVE-2017-17044 / xsa 246 CVE-2017-17045 / xsa 247 CVE-2018-10472 / xsa 258 CVE-2018-10981 / xsa 262 The testing packages are available here: https://share.credativ.com/~pdr/xen-test/ These testing packages are auto generated by our new build system, so the package name is somewhat cryptic as it reflects the date and time of build as well as parts of the git hash it is based on. You can find the repository here: https://github.com/credativ/xen-lts dpkg might tell you about a potential downgrade, but you can ignore this for testing purposes safely. I expect them to be working but I would appreciate some feedback on this version before passing them to the public repository. I will head on to the next issues to fix. Kind regards Peter -- Peter Dreuw Teamleiter Tel.: +49 2166 9901-155 Fax: +49 2166 9901-100 E-Mail: peter.dr...@credativ.de gpg fingerprint: 33B0 82D3 D103 B594 E7D3 53C7 FBB6 3BD0 DB32 ED41 https://www.credativ.de/ credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Re: Confusing our users - who is supporting LTS?
Hi Steve, On Tue, 23 Oct 2018, Steve McIntyre wrote: > So I'm worried that those of us who have *not* volunteered to support > LTS are being pressured into spending our time on it anyway. What can > we do to fix that? How/where do we clarify for our users (and > developers!) what LTS means, and what expectations are fair? FWIW, I don't think that the right answer is to make LTS even more clearly separate. We want to be able to say that Debian is supported for 5 years and we don't want to have to put an asterisk pointing to a long list of exceptions. Instead we are rather aiming to integrate LTS more and more everywhere. However, when LTS is becoming a burden on other teams, we should definitely look how the LTS team can help to alleviate that burden. Because as you know the LTS team has paid contributors to do that kind of work. I invite you to start a conversation between debian-lts and debian-cloud to discuss how the LTS team can help you with the workload that you would rather get rid of. Maybe we need to allocate some time each month to update LTS images, maybe you need our help to improve your tooling to better support LTS and that would be enough, etc. I don't know. Let's discuss. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ signature.asc Description: PGP signature
