Bug#825987: /usr/sbin/update-java-alternatives: Re: /usr/sbin/update-java-alternatives: doesn't detect openjdk-8 xjc
On Thu, Jun 23, 2016 at 03:07:50PM +0100, Dominic Hargreaves wrote: > Control: retitle -1 update-java-alternatives: doesn't recognise new jdkhl > label in jinfo files > Control: tags -1 + patch confirmed > Control: severity -1 normal > > On Fri, Jun 03, 2016 at 11:42:27AM +1000, Jayen Ashar wrote: > > Package: java-common > > Version: 0.57 > > Followup-For: Bug #825987 > > > > Dear Maintainer, > > > > javac seems to have the same issue: > > > > $ sudo update-java-alternatives -v -l | grep javac > > listing java alternatives: > > jdk javac /usr/lib/jvm/java-6-openjdk-i386/bin/javac > > jdk javac /usr/lib/jvm/java-7-openjdk-i386/bin/javac > > jdk javac /usr/lib/jvm/java-6-sun/bin/javac > > jdk javac /usr/lib/jvm/jdk-7-oracle-i586/bin/javac > > This is because, as of openjdk-8 8u72-b15-3[1] a new 'jdkhl' label > was added to the jinfo files, but update-java-alternatives was not > updated to take account of this. > > This affects the following commands: > > extcheck, idlj, jar, jarsigner, javac, javadoc, javah, javap, jcmd, jdb, > jdeps, jhat, jinfo, jmap, jps, jrunscript, jsadebugd, jstack, jstat, > jstatd, native2ascii, rmic, schemagen, serialver, wsgen, wsimport, xjc > > I've attached a patch which restores the expected behaviour. Ping? Is there any chance of getting this included into stretch? It would be nice to to have to manually patch this ourselves through its life. Best, Dominic. __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#825987: /usr/sbin/update-java-alternatives: Re: /usr/sbin/update-java-alternatives: doesn't detect openjdk-8 xjc
Control: retitle -1 update-java-alternatives: doesn't recognise new jdkhl label
in jinfo files
Control: tags -1 + patch confirmed
Control: severity -1 normal
On Fri, Jun 03, 2016 at 11:42:27AM +1000, Jayen Ashar wrote:
> Package: java-common
> Version: 0.57
> Followup-For: Bug #825987
>
> Dear Maintainer,
>
> javac seems to have the same issue:
>
> $ sudo update-java-alternatives -v -l | grep javac
> listing java alternatives:
> jdk javac /usr/lib/jvm/java-6-openjdk-i386/bin/javac
> jdk javac /usr/lib/jvm/java-7-openjdk-i386/bin/javac
> jdk javac /usr/lib/jvm/java-6-sun/bin/javac
> jdk javac /usr/lib/jvm/jdk-7-oracle-i586/bin/javac
This is because, as of openjdk-8 8u72-b15-3[1] a new 'jdkhl' label
was added to the jinfo files, but update-java-alternatives was not
updated to take account of this.
This affects the following commands:
extcheck, idlj, jar, jarsigner, javac, javadoc, javah, javap, jcmd, jdb,
jdeps, jhat, jinfo, jmap, jps, jrunscript, jsadebugd, jstack, jstat,
jstatd, native2ascii, rmic, schemagen, serialver, wsgen, wsimport, xjc
I've attached a patch which restores the expected behaviour.
Since openjdk-8 has been backported into stable, a fixed java-common
should also be backported with this fix.
Cheers,
Dominic.
[1] <http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/revision/668>
>From 31e435b842b10fceb6e3bcc07f5f49f344cec050 Mon Sep 17 00:00:00 2001
From: Dominic Hargreaves <d...@earth.li>
Date: Thu, 23 Jun 2016 15:02:37 +0100
Subject: [PATCH] Support the jdkhl alternatives type
Since 8u72-b15-3 a new jdkhl label was introduced into the jinfo files
used by update-java-alternatives. Without this change, some alternatives
will not be updated correctly.
Bug-Debian: https://bugs.debian.org/825987
---
scripts/update-java-alternatives | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/scripts/update-java-alternatives b/scripts/update-java-alternatives
index 9eea19c..6684bad 100755
--- a/scripts/update-java-alternatives
+++ b/scripts/update-java-alternatives
@@ -8,7 +8,7 @@ usage()
{
rv=$1
cat >&2 <<-EOF
- usage: $prog [--jre-headless] [--jre] [--plugin] [-v|--verbose]
+ usage: $prog [--jre-headless] [--jre] [--jdk-headless] [--plugin] [-v|--verbose]
-l|--list []
-s|--set
-a|--auto
@@ -27,6 +27,8 @@ while [ "$#" -gt 0 ]; do
action=auto;;
-hl|--jre-headless)
hlonly=yes;;
+ -jdkhl|--jdk-headless)
+ jdkhlonly=yes;;
-j|--jre)
jreonly=yes;;
--plugin)
@@ -63,10 +65,11 @@ done
[ "$#" -eq 0 ] || usage 1
[ -n "$action" ] || usage 1
-which='^(hl|jre|jdk|plugin|DUMMY) '
+which='^(hl|jre|jdk|jdkhl|plugin|DUMMY) '
if [ -n "$hlonly$jreonly$pluginonly" ]; then
which='^('
[ -n "$hlonly" ] && which="${which}hl|"
+[ -n "$jdkhlonly" ] && which="${which}jdkhl|"
[ -n "$jreonly" ] && [ -n "$hlonly" ] && which="${which}jre|"
[ -n "$jreonly" ] && [ -z "$hlonly" ] && which="${which}hl|jre|"
[ -n "$pluginonly" ] && which="${which}plugin|"
--
2.1.4
__
This is the maintainer address of Debian's Java team
<http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
Please use
debian-j...@lists.debian.org for discussions and questions.
Bug#782635: tomcat8-admin: Default upload limit for manager app too small with no way to override
On Wed, Apr 15, 2015 at 11:10:45PM +0200, Emmanuel Bourg wrote:
Le 15/04/2015 16:05, Dominic Hargreaves a écrit :
Here's a useful response from someone on the tomcat-users list, who seems
to agree that this is something that should be changed at the Debian side.
Here is the link for the reference:
http://mail-archives.apache.org/mod_mbox/tomcat-users/201504.mbox/%3C552E688C.6080600%40apache.org%3E
As I understand, the web.xml file of the manager application should be
moved to /etc/tomcat8, symlinked to
/usr/share/tomcat8-admin/manager/WEB-INF. Do you think you could provide
a patch implementing this change?
There are some other suggestions which are probably better than moving
the whole of web.xml?
One option would be for Debian to use external entities for the
configurable elements and place the file that defines those entities
somewhere where users can edit it.
Another option (I think) is to use the property replacement feature. I.e.
${property.name} in web.xml and property.name=foo in catalina.properties
The only question is if this works in web.xml which I don't recall and I don't
have easy access to the source to check. If it doesn't work we should be able to
fix that easily.
Dominic.
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers.
Please use
debian-j...@lists.debian.org for discussions and questions.
Bug#782635: tomcat8-admin: Default upload limit for manager app too small with no way to override
On Wed, Apr 15, 2015 at 11:22:26AM +0100, Dominic Hargreaves wrote: On Wed, Apr 15, 2015 at 12:13:56PM +0200, Emmanuel Bourg wrote: The web.xml file of the manager application is packaged as is, there is no difference with the file distributed upstream. I suggest that you raise this question on the Tomcat user list, someone should be able to help you with this configuration issue there. I'll ask, but the impression I get from reading around is that web.xml should simply be edited. I don't think we can do much at the packaging level to help you though. If it turns out that the above is correct, then I think that the Debian package should be able to enable this (eg by making web.xml a symlink to somewhere where it can be a conffile). I'll report back here either way! Hi, Here's a useful response from someone on the tomcat-users list, who seems to agree that this is something that should be changed at the Debian side. Dominic. ---BeginMessage--- On 15/04/2015 05:28, Dominic Hargreaves wrote: Hello, This is reposted from [1] and [2]; the Debian maintainers of the package suggested I ask for advice here. I am running the Tomcat manager application via a Debian package (tomcat8-admin), which deploys the webapp from /usr/share/tomcat8-admin/manager. We ran into a problem hitting th maximum upload size (configured as the multipart-config element in the HTMLManager servlet block). This is easy to fix if you're willing to edit Debian-packaged files, but this is incorrect: files in /usr/share are owned exclusively by dpkg. Is there a way to override this element from somewhere in tomcat's conf directory (which is symlinked to /etc/tomcat8 in Debian)? No. The web application setting would take priority. Searching for this problem on the web only results in suggestions about editing web.xml directly (eg http://www.giantgeek.com/blog/?p=1000) or about different programming approaches using context parameters (if I understand correctly; I'm not especially familiar with the jargon). If it's not possible to override this at the moment, then is this a bug in Tomcat, or the Debian packaging? I'd say the bug is in the Debian packaging (but I would say that wouldn't I). Without know how Tomcat is packaged in Debian, I would expect the following: - the Manager web application to be a separate, optional package - the web.xml to be placed in an appropriate location for users to be able to edit it. I took a quick look through the web.xml for the Manager app. There are plenty of settings I wouldn't expect to change but there are a handful of things that users might want to tweak. In theory, it should be possible to move those settings to context.xml but that would require code changes and would mean do things that were contrary to the spirit of the servlet spec so there would likely be resistance to such changes from the Tomcat community. One option would be for Debian to use external entities for the configurable elements and place the file that defines those entities somewhere where users can edit it. Of course I could maintain a local version of the Debian package with this overriden, but for such an apparently-obvious piece of configuration that seems wrong too. Agreed. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org ---End Message--- __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#782635: tomcat8-admin: Default upload limit for manager app too small with no way to override
On Wed, Apr 15, 2015 at 12:13:56PM +0200, Emmanuel Bourg wrote: The web.xml file of the manager application is packaged as is, there is no difference with the file distributed upstream. I suggest that you raise this question on the Tomcat user list, someone should be able to help you with this configuration issue there. I'll ask, but the impression I get from reading around is that web.xml should simply be edited. I don't think we can do much at the packaging level to help you though. If it turns out that the above is correct, then I think that the Debian package should be able to enable this (eg by making web.xml a symlink to somewhere where it can be a conffile). I'll report back here either way! Cheers, Dominic. __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#782635: tomcat8-admin: Default upload limit for manager app too small with no way to override
Package: tomcat8-admin Version: 8.0.14-1 Severity: normal Hi, I found that the manager app file upload limit was too small for our purposes. As per [1] I've been unable to find a way to override the maximum file upload size defined in web.xml without editing web.xml directly, which is obviously the wrong thing to do. At the moment this feels like a bug either in the packaging of tomcat8-admin or Tomcat itself, but it's equally possible that the bug is in my understanding of how configuring Tomcat is supposed to work, in which case any hints would be appreciated. Cheers, Dominic. [1] http://serverfault.com/questions/681211/overriding-parts-of-a-webapps-web-xml-in-tomcat-eg-manager-application-max-fil __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#523054: Any likely update for mod_jk?
Hi, I wondered if any fix is likely to be available for CVE-2008-5519 (information disclosure, looks potentially quite severe) any time soon or if any more help is needed? Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#503309: tomcat6: Several security issues in Tomcat
On Fri, Oct 24, 2008 at 05:41:39PM +0200, Moritz Muehlenhoff wrote: Several vulnerabilities have been fixed in Apache Tomcat 6.0.18, see below. BTW, do we really need two Tomcat versions in Lenny? Is Tomcat 6 incompatible with 5.5? It doesn't look like the tomcat6 source package actually supplies the main tomcat6 server as binary packages (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413906 for details). I believe that this means that theses issues are not present in Debian, and that the severity of this bug should therefore be lowered. Java maintainers, do you agree, and if so could you lower this from RC severity? Thanks, Dominic. low: Cross-site scripting CVE-2008-1232 The message argument of HttpServletResponse.sendError() call is not only displayed on the error page, but is also used for +the reason-phrase of HTTP response. This may include characters that are illegal in HTTP headers. It is possible for a +specially crafted message to result in arbitrary content being injected into the HTTP response. For a successful XSS attack, +unfiltered user supplied data must be included in the message argument. This was fixed in revision 673834. Affects: 6.0.0-6.0.16 low: Cross-site scripting CVE-2008-1947 The Host Manager web application did not escape user provided data before including it in the output. This enabled a XSS +attack. This application now filters the data before use. This issue may be mitigated by logging out (closing the browser) of +the application once the management tasks have been completed. This was fixed in revision 662585. Affects: 6.0.0-6.0.16 important: Information disclosure CVE-2008-2370 When using a RequestDispatcher the target path was normalised before the query string was removed. A request that included a+specially crafted request parameter could be used to access content that would otherwise be protected by a security constraint +or by locating it in under the WEB-INF directory. This was fixed in revision 673839. Affects: 6.0.0-6.0.16 important: Directory traversal CVE-2008-2938 If a context is configured with allowLinking=true and the connector is configured with URIEncoding=UTF-8 then a +malformed request may be used to access arbitrary files on the server. If the connector is configured with URIEncoding=UTF-8 +then a malformed request may be used to access arbitrary files within the docBase of a context such as web.xml. It should also +be noted that setting useBodyEncodingForURI=true has the same effect as setting URIEncoding=UTF-8 when processing requests +with bodies encoded with UTF-8. This was fixed in revision 678137. Affects: 6.0.0-6.0.16 -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
