Bug#675485: libcommons-validator-java: please rebuild to fix your copy of #477751

[Helmut Grohne]

Source: libcommons-validator-java
Severity: serious

Dear maintainer(s) of libcommons-validator-java,

TL;DR: Please upload a new version of this package closing this bug.

Problem
~~~
Your package uses the dh_installcatalogs helper from debhelper. This helper
added code to the postinst that unconditionally overwrites files in /etc which
is a policy violation. The corresponding bug #477751 is now solved in
debhelper. Nevertheless the code overwriting files in /etc is still present in
a binary package built from this source package, so your package needs a
rebuild. Unfortunately the binary package in question is Architecture: all, so
a binNMU is not enough.

How to solve

This bug tracks the progress of the rebuild and should be closed by any upload
of this package. Before building, please ensure that your debhelper version is
at least 9.20120528 which should be the case if you are running sid. 


Is my package really/still affected?

Any binary package using the dh_installcatalogs helper will add a versioned
dependency on sgml-base. If the depended upon version is at least 1.26+nmu2,
your package is not affected. In that case, just close this bug.


If you have any further questions concerning this issue, please don't hesitate
to contact me.

Thanks for your help

Helmut




__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#692035: CVE-2012-3155: vulnerability in the CORBA ORB component

[Helmut Grohne]

Package: src:glassfish
Version: 1:2.1.1-b31g-3
Severity: serious
Tags: security

Dear glassfish maintainers,

Please determine whether and how glassfish as present in Debian is
affected by CVE-2012-3155. Please adjust the severity of this bug
accordingly.

| Unspecified vulnerability in the CORBA ORB component in Sun GlassFish
| Enterprise Server 2.1.1, Oracle GlassFish Server 3.0.1 and 3.1.2, and
| Sun Java System Application Server 8.1 and 8.2 allows remote attackers
| to affect availability, related to CORBA ORB.

Oracle mentions it on this page:
http://www.oracle.com/technetwork/topics/security/cpuoct2012-1515893.html

Ubuntu has classified the issue medium and affected thus far:
http://people.canonical.com/~ubuntu-security/cve/2012/CVE-2012-3155.html

Neither Red Hat nor Gentoo track the issue at the time of this writing.

Helmut

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#700268: libhttpclient-java: overly broad certificate wildcard match

[Helmut Grohne]

Package: libhttpclient-java
Version: 4.2.1-1
Severity: grave
Tags: security

In the version above the common name match of the certificate check was
rewritten. So the versions in squeeze and wheezy are not affected. The
rewritten version contains a bug (uses length of wrong object) and
thereby accepts ssl certificates where it should not.

Let me quote the relevant bits from the upstream bug
https://issues.apache.org/jira/browse/HTTPCLIENT-1255
> According to the findings of [1], the hostname verification in 
> AbstractVerifier.java is not correct. The wildcard prefix extraction uses the 
> dimension of the dotted parts array instead of the length of the first part 
> itself.
> 
> String prefix = parts[0].substring(0, parts.length-2); // e.g. server
> should be
> String prefix = parts[0].substring(0, parts[0].length()-1); // e.g. server
> 
> (This is line 208 of 
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient/src/main/java/org/apache/http/conn/ssl/AbstractVerifier.java
>  as of Revision 1402320)
> 
> [1] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

Helmut

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#701163: jenkins-external-job-monitor and libjenkins-java share jenkins-core-1.447.2.jar

[Helmut Grohne]

Package: jenkins-external-job-monitor, libjenkins-java
Version: 1.447.2+dfsg-3
Severity: wishlist

Those packages share[1] 99% of their data which basically boils down to
both of them shipping jenkins-core-1.447.2.jar[2]. Would it be possible
to turn libjenkins-java into a dependency of
jenkins-external-job-monitor and turn the latter copy into a symbolic
link?

Helmut

[1] http://dedup.debian.net/binary/libjenkins-java
[2] http://dedup.debian.net/compare/libjenkins-java/jenkins-external-job-monitor

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#726997: findbugs: reduce package size by 3.3M or 40%

[Helmut Grohne]

Package: findbugs
Version: 2.0.2-1
Severity: wishlist

Dear Maintainer,

The findbugs package contains an excellent opportunity to reduce space
on the mirrors and installations. The findbugs.jar, which makes up
almost half of the package, is shipped twice in the binary package[1].
Can you replace one copy with a symbolic link to the other? For details
on shrinking packages see https://wiki.debian.org/dedup.debian.net. If
you need assistance, please ask.

Helmut

[1] http://dedup.debian.net/compare/findbugs/findbugs

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#751006: yui-compressor: missing Multi-Arch: foreign

[Helmut Grohne]

Package: yui-compressor
Version: 2.4.7-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Dear Maintainers,

yui-compressor currently makes doxygen FTCBFS, because it lacks
M-A:foreign.

$ dpkg --print-architecture
amd64
$ apt-get -s --arch-only -ai386 build-dep doxygen
NOTE: This is only a simulation!
  apt-get needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree   
Reading state information... Done
E: Build-Depends dependency for doxygen cannot be satisfied because the package 
yui-compressor cannot be found
$

Please consider applying the attached patch.

Helmut
diff -Nru yui-compressor-2.4.7/debian/changelog 
yui-compressor-2.4.7/debian/changelog
--- yui-compressor-2.4.7/debian/changelog   2012-05-12 23:07:54.0 
+0200
+++ yui-compressor-2.4.7/debian/changelog   2014-06-09 14:22:26.0 
+0200
@@ -1,3 +1,10 @@
+yui-compressor (2.4.7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark yui-compressor as Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 09 Jun 2014 14:22:09 +0200
+
 yui-compressor (2.4.7-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru yui-compressor-2.4.7/debian/control 
yui-compressor-2.4.7/debian/control
--- yui-compressor-2.4.7/debian/control 2012-05-12 23:05:44.0 +0200
+++ yui-compressor-2.4.7/debian/control 2014-06-09 14:22:37.0 +0200
@@ -18,6 +18,7 @@
  java-wrappers,
  libjargs-java,
  ${misc:Depends}
+Multi-Arch: foreign
 Description: JavaScript/CSS minifier
  The YUI Compressor is a JavaScript compressor which, in addition to removing
  comments and white-spaces, obfuscates local variables using the smallest
__
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#839567: rake does not work with jruby

[Helmut Grohne]

Package: rake,jruby
Severity: serious
Justification: policy 3.5
User: helm...@debian.org
Usertags: rebootstrap

Hi,

Please consider the following interaction with a fresh sid chroot:

# apt-get install -y --no-install-recommends jruby
...
# apt-get install --no-install-recommends rake
# rake
-bash: /usr/bin/rake: /usr/bin/ruby: bad interpreter: No such file or directory
#

rake declares a dependency on ruby | ruby-interpreter. jruby declares
that it provides ruby-interpreter. It seems that rake expects
/usr/bin/ruby to be available, but jruby does not contain such a file
nor has a maintainer script that would create one (via alternatives or
other means).

Thus this looks like a broken contract on the meaning of
ruby-interpreter. I believe we have the following options to move
forward:

1. rake removes the ruby-interpreter alternative acknowledging that
   ruby-interpreter does not mean to include /usr/bin/ruby.
2. jruby removes the provides on ruby-interpreter acknowledging that
   ruby-interpreter should provide /usr/bin/ruby.
3. jruby instantiates /usr/bin/ruby as it is required for providing
   ruby-interpreter.

This bug was found by inspecting a valid installation set for ruby:i386
on an amd64 system generated by dose3. Choosing option 1 or 2 will mean
that ruby stops being installable for foreign architectures unless rake
annotates its ruby dependency with :any (ruby is m-a:allowed already).

Helmut

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#839567: rake does not work with jruby

[Helmut Grohne]

On Mon, Oct 03, 2016 at 11:13:13AM +0200, Emmanuel Bourg wrote:
> What is the expected contract for a package providing ruby-interpreter?

I wish I could tell. Judging from
https://wiki.debian.org/Teams/Ruby/Packaging, it seems that
ruby-interpreter requires /usr/bin/ruby. Not sure how official that is.

> Do it just have to offer a /usr/bin/ruby alternative?

As soon as /usr/bin/ruby becomes managed by update-alternatives or
dpkg-divert, ruby itself must drop Multi-Arch: allowed, because it no
longer is in exclusive control of /usr/bin/ruby. So this sounds wrong.

I'm not sure we currently support non-default ruby implementations.
Which indicates that jruby should simply drop the provides.

Not speaking with any ruby hats. Maybe Christian can weigh in with more
details.

Helmut

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#839567: rake does not work with jruby

[Helmut Grohne]

On Mon, Oct 03, 2016 at 04:46:11PM -0700, tony mancill wrote:
> I agree with Helmut's suggestion that jruby should drop the Provides.
> Even if there are contexts in which jruby could act as a ruby
> interpreter, I don't think we should encourage our users to use it
> when we have ruby available.  Or put another way, if you're using
> jruby, it typically to solve a specific problem or because you have
> special considerations about your runtime environment, not because
> you're looking for a general purpose Ruby interpreter.

I think the implications of having jruby drop ruby-interpreter deserve
more thought from the ruby team.

It appears to me that jruby would just work with a fair amount of ruby
modules[1]. Yet, after dropping that provides, trying to install e.g.
jruby and ruby-text will also pull in another ruby implementation. So it
seems to me that the virtual package ruby-interpreter has actually been
used with two very different meanings which is now causing the problem:
One meaning is to provide /usr/bin/ruby and the other is a means to
execute ruby code. At the moment, jruby clearly doesn't do the former,
but still does the latter.

The Perl world has evaded this issue by not having a secondary
implementation (that is considered ready to use with existing modules).

The Python world has "solved" this issue by packaging each and every
module (in addition to extensions) for all of the interpreters. For a
module foo, we now have python-foo, python3-foo and pypy-foo (in the
worst case, e.g. -six, -wand, -pkg-resources, ...).

Please consider learning from them and - if possible - choosing a
different approach here. Consider employing a different policy that
makes the aforementioned combination feasible:

1. Every package that actually invokes ruby (as opposed to using ruby
   libraries through its own library interface) must depend on a ruby
   implementation (e.g. ruby | ruby-interpreter, or possibly an
   embedded interpreter if applicable).

2. Given that all invocation points must depend on an interpreter, ruby
   modules should not depend on a ruby-interpreter unless they require a
   particular implementation.

It seems like 1. is mostly in place already. I just note it here,
because 2. breaks badly if 1. is violated. Let me also clarify that a
module can require a particular implementation by using a ruby
extension, so the beauty mostly vanishes on the first extension in the
dependency tree. It also seems that 2. is partially in place (e.g.
ruby-power-assert, ruby-test-unit, but not ruby-text, ruby-wirble,
ruby-formatador, ...). So what I am requesting might already be policy,
but isn't fully implemented yet.

The Multi-Arch nerd over here also notes that this way allows annotating
a significant chunk of ruby modules with Multi-Arch: foreign and that
tracker.d.o will tell you where (e.g. ruby-rd).

The node people have recently started looking into Multi-Arch and
noticed that maybe having every node module depend on nodejs was not the
best approach.

Helmut

[1] Let me use the typical Perl and Python terminology here: We call
libraries "modules" if they are source-only and we call them
"extensions" if they produce architecture-specific artifacts such as
shared libraries loaded into an interpreter.

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.