Bug#898935: migrate fix to stretch security

[Markus Koschany]

Am 24.08.2018 um 09:30 schrieb Bogdan Veringioiu:
> Hello all,
> 
> is there any plan to migrate the fix to stretch security ?
> 
> I would be interested in the fixes for CVE-2018-1304, CVE-2018-1305
> (resolved in 7.0.88, and in 8.5.32-1 testing) which are important for a
> security certification (PCI) on our stretch machines.

I am currently working on a security update for Tomcat 8 that will also
resolve CVE-2018-1304 and CVE-2018-1305.

Regards,

Markus



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

Bug#902861: axis: FTBFS with Java 10 due to com.sun.net.ssl removal

[Markus Koschany]

Am 24.08.2018 um 01:00 schrieb Emmanuel Bourg:
>> This issue was apparently fixed in version 1.10.4-2. Axis can be rebuilt
>> from source again.
> 
> Actually the issue was triggered by the automatic use of the --release
> javac option in ant/1.10.3-2, the flag removed the internal com.sun.net
> classes from the compilation classpath. The issue vanished once that was
> reverted in ant/1.10.4-2.

Yes, that's the same thing. The --release flag only works with Java9+
bytecode.

Markus




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

Bug#888547: CVE-2017-1000190

[Markus Koschany]

Am 23.08.2018 um 15:55 schrieb Emmanuel Bourg:
> On 23/08/2018 13:14, Markus Koschany wrote:
>> Apparently upstream doesn't consider this "to be their problem". Since
>> simple-xml has no reverse-dependencies and the current uploader is MIA,
>> I think we should consider requesting the removal of simple-xml.
> 
> simple-xml is a dependency of carrotsearch-randomizedtesting.
> 
> The fix should be trivial, it's just a matter of disabling external
> entities parsing on the underlying XML parser. And maybe we've already
> fixed the XML parser used by default.

My concern is that we have an upstream project that does not even
consider such a trivial fix. Then we have another example of a
fire-and-forget one time upload (simple-xml) and now the package is
carried "by the team". carrotsearch-randomizedtesting is a
test-dependency for lucence4.10 and spatial4j, same pattern, one time
upload, now carried by the team. And when I see that we ship at least
three versions of lucene in Debian, then I suppose we still have some
room for improvements.

The gist is: Better maintain few packages and do it well, instead of
maintaining many packages that just exist for collecting RC bugs.

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#888547: CVE-2017-1000190

[Markus Koschany]

Apparently upstream doesn't consider this "to be their problem". Since
simple-xml has no reverse-dependencies and the current uploader is MIA,
I think we should consider requesting the removal of simple-xml.

Markus



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

Bug#906785: version warping patch is overly aggressive

[Markus Koschany]

Am 21.08.2018 um 19:47 schrieb Keith Packard:
[...]
> We only discovered that ant was the source of trouble by comparing the
> output of a project built using that and another project build using a
> simple Makefile.
> 
> If you're going to stop supporting older API versions, I'd suggest that
> the tool should exit with an error status rather than silently
> corrupting the build process. We spent a couple of days tracking down
> this issue, which would have been obvious had the package build simply
> failed when it used -target 1.4.

But wasn't that the issue we wanted to solve in the first place? We
still have packages in Debian that use -target 1.5 or less but we don't
want that they fail to build from source now when someone is rebuilding
them. The patch [1] also prints a warning that older API versions are
not supported anymore and thus the build system switches to the oldest
supported version now.

As I wrote we had assumed OpenJDK 11 would drop support for -target 1.6.
Maybe we can improve the warning but we surely don't want more build
failures aka RC bugs.

Markus

[1]
https://sources.debian.org/src/ant/1.10.5-1/debian/patches/0013-auto-adjust-target.patch/



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

Bug#906785: version warping patch is overly aggressive

[Markus Koschany]

Am 21.08.2018 um 18:49 schrieb Bdale Garbee:
> Markus Koschany  writes:
[...]
>> I think the patch could be removed for OpenJDK 11 but should be applied
>> for OpenJDK 12 again. All build tools already emit a deprecation warning
>> for source/target 1.6, so developers and users should be aware of it,
>> and it is certain now that OpenJDK 11 will be the last JDK that supports
>> 1.6.
> 
> Ok.  While I personally continue to be concerned that the version
> warping in ant isn't a great idea generally, I understand the
> motivation behind it.
> 
> I'll personally be happy if ant doesn't enforce version warping more
> restrictive than the underlying javac requires.  In particular, if it
> allows us to continue to target Java 6 compatibility for the life of
> OpenJDK 11 in Debian, which I think would give us through the life of
> the Buster release cycle since as I think the plan is to ship 11 as the
> default-jdk for Buster? 

Yes, we will ship OpenJDK 11 as the default-jdk for Buster. I agree that
we shouldn't enforce stricter rules in Ant than necessary. We have
always taken care of to compile to bytecode that can be used with the
oldest supported version in Debian and at the moment this is OpenJDK 7.
I believe nobody has any objections against supporting even older
versions, as long as it is maintainable.

I'm waiting for Emmanuel to chime in now. Maybe I missed something
important. Otherwise I think we can resolve this issue rather quickly.
Since Ant isn't the only build system for Java, we probably should
change this for Maven too. We haven't implemented the same for Gradle
yet. [1]

Markus

[1] https://bugs.debian.org/894290



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#906785: version warping patch is overly aggressive

[Markus Koschany]

Hi Bdale,

we all assumed that OpenJDK 11 will remove support for source/target
1.6. After a discussion on the OpenJDK mailing list they decided to
postpone this change for OpenJDK 12. [1]

The current patch simplifies our packaging work because we don't have to
manually fix packages that still target older Java releases. Since we
don't support and ship Java 6 in Debian anymore, there is no downside
for our users because all packages work for them with OpenJDK8 or
OpenJDK 11. Frankly we have never supported your MacOS use case.
Security support for OpenJDK 6 has ended a long time ago.

> Frankly, I'm not sure having this patch in the Debian package at all is a 
> good idea.  Isn't it better to let javac itself emit an error message if/when
> a version actually becomes supported, and let the developer learn about
> versions and how to update their ancient assertions when needed rather than
> hide this problem?

I think the patch could be removed for OpenJDK 11 but should be applied
for OpenJDK 12 again. All build tools already emit a deprecation warning
for source/target 1.6, so developers and users should be aware of it,
and it is certain now that OpenJDK 11 will be the last JDK that supports
1.6.

Regards,

Markus

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001190.html



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

Bug#903428: javadocs generated by javahelper include jquery

[Markus Koschany]

Hi tony,

Am 11.08.2018 um 20:12 schrieb tony mancill:
[...]
> Hi Markus,
> 
> I'm glad that you were able to discuss this directly with Matthias, and
> thank you for sharing the gist of that conversation.  For our sanity, I
> will take a look to see if we can get the severity of the lintian
> warning [1] reduced to some lower level (pedantic?) or completely
> ignored for javadoc packages.
> 
> Cheers,
> tony
> 
> [1] https://lintian.debian.org/tags/embedded-javascript-library.html

A severity of pedantic or informational would be appreciated but I guess
they won't change it. I just remembered that I build the documentation
in src:renpy from source with Sphinx and this tool also embeds jquery
and bootstrap. However Lintian still emits the warning about embedded
javascript libraries. We probably have to get used to the fact that we
will never be able to fix all Lintian warnings again (at least for some
packages).

Cheers,

Markus



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

Bug#903428: javadocs generated by javahelper include jquery

[Markus Koschany]

FTR: I have talked to Matthias Klose (doko) at DebConf18 about the
embedding of jquery into javadoc packages. He pointed me to a similar
discussion in doxygen which also embeds jquery while building doc packages.

In short he doesn't consider it to be a worthwhile task because there is
a risk of breaking the documentation when Debian's system jquery version
is either too old or too new. The security risk of embedding jquery is
also rather low in this case because the documentation is static in
contrast to web applications and it is unlikely that users would be
affected by jquery vulnerabilities.

README.jquery in doxygen explains the problem in more detail.

https://sources.debian.org/src/doxygen/1.8.13-10/debian/README.jquery/

All in all there is no chance that a patch to change the current
situation would be accepted, hence I no longer intend to spend time on it.

Markus



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

Re: libjide-oss-java_3.7.4+dfsg-1_source.changes REJECTED

[Markus Koschany]

Hi,

Am 29.07.2018 um 09:18 schrieb Chris Lamb:
> apo,
> 
>>> binary:libjide-oss-java-doc is NEW.
> […]
>> this error message is very strange. I have never removed the
>> libjide-oss-java-doc binary package from src:libjide-oss-java. It does
>> no longer exist in Debian. Any ideas why?
> 
> Could be https://bugs.debian.org/865304 ?  (Taken from the /topic of
> #debian-ftp)

It appears to be related, although the build time is negligible in case
of libjide-oss-java. The last upload was in May 2018 and the package got
removed from testing in July. Maybe this somehow triggered the removal
of the -doc package? Looks all very fishy to me but I'm just going to
upload the binary package now.

Thanks

Markus



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

Re: libjide-oss-java_3.7.4+dfsg-1_source.changes REJECTED

[Markus Koschany]

Am 29.07.2018 um 08:19 schrieb Debian FTP Masters:
> 
> 
> Source-only uploads to NEW are not allowed.
> 
> binary:libjide-oss-java-doc is NEW.

Hello,

this error message is very strange. I have never removed the
libjide-oss-java-doc binary package from src:libjide-oss-java. It does
no longer exist in Debian. Any ideas why?

Regards,

Markus



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

Bug#899183:

[Markus Koschany]

Am 27.07.2018 um 18:21 schrieb Andrea Vacondio:
> Ok, I see that 2.0.11-1 works correctly but I'm a bit lost. I compiled
> PDFBox using openjdk 10.0.2 with target/source 1.7 but I still get the
> issue with my generated fontbox jar... see mine on the left has the
> ByteBuffer return type causing the issue while on the right is the one
> from 2.0.11-1 correctly using Buffer as return type. Could you point me
> where I can find how the package is compiled? I'm looking here
> https://salsa.debian.org/java-team/libpdfbox2-java but I assume you
> don't just use the pom settings given the compile plugin is set with
> source/target 1.6
> I'm just trying to understand and I can't figure what settings are
> needed to get the same result
> Thanks

You could try the following: I assume you compile libpdfbox2-java on an
up-to-date Debian unstable system.

apt source libpdfbox2-java
cd libpdfbox2-java
debuild -us -uc

The debuild command is in devscripts.

We force source/target 1.7 with our maven-debian-helper tool since this
is the minimum version supported by OpenJDK 10. These steps should
ensure that you get the same result. It is important that you use
Debian's toolchain and packages, don't call Maven manually. Let me know
if this was helpful to you.

Regards,

Markus



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

Bug#899183:

[Markus Koschany]

Am 27.07.2018 um 15:12 schrieb Andrea Vacondio:
> Why not compile with --release 7 ? This way the generated bundle should
> work with java 7 and above, or am I missing something?
> My app is hit by this
> https://bugs.launchpad.net/ubuntu/+source/pdfsam/+bug/1781130 and users
> are currently forced to run it with openjdk 8 given it requires openjfx
> like we discussed here
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886394
> Andrea

If I recall correctly this was a bug in OpenJDK 9 and changing the
compile target wouldn't change the outcome. I can recompile the package
with OpenJDK 10 now which should address this issue. However Ubuntu
users have to wait until the release of 18.10 or install the latest
version of libpdfbox2-java manually.

Markus



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

Bug#886394:

[Markus Koschany]

Hello Andrea,

Am 20.07.2018 um 15:52 schrieb Andrea Vacondio:
> PDFsam is developed using Java 8 and JavaFX. It should work on higher
> versions provided they come with their JavaFX, as far as I know Oracle
> JDK still bundles JavaFX, with a plan to separate the two soon. OpenJDK
> already separated JavaFX available through the package OpenJFX but from
> what I can see, the package in the repo
> https://packages.debian.org/sid/openjfx is for OpenJDK 8. What happens
> is that PDFsam starts with a higher version of OpenJDK (on my brand new
> box is OpenJDK 11) for which there is no OpenJFX.
> A quick fix would be to force the dependencies to openjdk-8-jre + openjfx

we intend to release with OpenJDK 11 for Debian 10, "Buster". OpenJFX 11
is on our todo list. I'm aware of the current situation with PDFsam and
I agree a dependency on openjdk-8-jre + openjfx would make it more
obvious for users at the moment. However we won't release PDFsam with a
dependency on OpenJDK 8 anyway because security support will end way
before Buster is EOL and I don't want to give a false impression of the
current state of our PDFsam package. Unstable users should be able to
handle the situation.

Regards,

Markus



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

Bug#857939: [libtcnative-1] Does not work without symlink

[Markus Koschany]

Am 18.07.2018 um 13:41 schrieb Harald Dunkel:
> Asking all Java Standard Edition users to perform some manual
> configuration steps is not helpful. They will just dislike both
> your package and openjdk for being different to the "real"
> Java version they are used to.
> 
> Just my $0.02. Regards
> Harri

I wonder why users of free software like OpenJDK would dislike our
package which perfectly works for them. Also not everything works
automagically in Debian, some services require manual intervention and
administration. If you don't want to configure non-free software, just
use OpenJDK.

Markus





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

Bug#903428: Got hit by #903428 too

[Markus Koschany]

Am 17.07.2018 um 01:15 schrieb Martin Quinson:
> Hello,
> 
> I'm building a package that provide some javadoc, so I got hit by that
> bug myself too. The solution you propose (dropping javadoc packages)
> does not exactly fit my needs, I must say ;)
[...]

A quick solution is to depend on libjs-jquery and probably
libjs-jquery-ui and then use dh_link or debian/links and symlink the
offending Javascript files to the ones on the system.

Thus said I believe this should be fixed at the root. A good solution
would be to replace the embedded jquery library in OpenJDK-11 with a
symlink to the system library and maybe change some build-helper tools
like javahelper, maven-debian-helper etc. to automatically insert a
dependency on libjs-jquery and libjs-jquery-ui into already existing
substvars.

Regards,

Markus



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

Bug#903428: javadocs generated by javahelper include jquery

[Markus Koschany]

Hi tony,

Am 17.07.2018 um 07:00 schrieb tony mancill:
[...]
>  
> Hi Markus,
> 
> Fair enough.  I can see the value in providing javadoc (or at least a
> way to build the javadoc) for older versions of libraries. 
> 
> I think Martin Quinson's suggestion of "shim" jquery package has some
> merit.  It means that we would have to touch every -java-doc package -
> 475 of them, by my current count - but I'm not sure that can be avoided
> unless we take the path of patching openjdk-11 to use the Debian system
> library.

I believe that every solution that involves patching all of our javadoc
packages is not a good one. :) Of course Martin can depend on Debian's
system jquery and use dh_link to replace the embedded copy with the one
installed on the system but I'm far too lazy too consider this a
worthwhile task for myself. It's not efficient, so to speak ;)

I'm in favor of tackling the issue at the root, openjdk-11. I will take
a closer look at DebConf18 and prepare a patch and resubmit my bug
report. Everything else is up to doko.

> And finally, although I'm still biased towards working on better runtime
> support (to wit, libjide-oss-java is currently FTBFS, so the lintian
> jquery warning seems less important than that), I don't think we should
> ignore the problem and don't want anyone to feel unnecessarily "meh"
> about it either... :)
> 
> Other ideas?

I agree there are a lot more interesting problems to work on but it's
far easier to solve than many of the other ones. As for
libjide-oss-java: I have reported the FTBFS months ago but it doesn't
look like that we will see a real solution soon. They depend on
functionality which was simply removed with OpenJDK 10. Fortunately only
some windows-specific classes are affected, so I could ultimately patch
them out and work around it. However we should strongly consider to ship
OpenJDK 8 with Buster. Then I could just build-depend on it and be done
for now and maybe in two years time there is a better solution. Actually
I don't see a reason why we couldn't do it, provided we mark OpenJDK 8
EOL security-wise and just use it for building/developing packages.

The most important problem is JavaFX at the moment because without that
libjide-oss-java is just another library. The reason why it was packaged
is mediathekview but without JavaFX is won't be part of Buster anyway
(and PDFsam, and Netbeans, and...)

Cheers,

Markus




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

Bug#903916: undertow: Keep it out of Buster

[Markus Koschany]

Source: undertow
Version: 1.4.25-1
Severity: serious

I am filing this bug report to prevent the migration of undertow to
testing and subsequently being part of the next stable release Debian
10, "Buster". This was also briefly discussed with the Security Team.

Reasons:

 - Undertow is regularly affected by security vulnerabilities but
   upstream often does not provide enough information to fix the issue
   with a targeted patch. Sometimes additional information are not
   public or are only disclosed weeks and months later. I have filed a bug
   report and suggested to improve the communication policy but so far
   nothing has happened.

 - Undertow has no reverse-dependencies besides syncany in
   experimental.

Once Buster is released this bug report can be closed again and
hopefully the situation has improved by then.

Markus

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

Bug#903428: javadocs generated by javahelper include jquery

[Markus Koschany]

Hi tony,

Am 10.07.2018 um 05:22 schrieb tony mancill:
[...]
> I'm in favor of dropping the -java-doc packages completely and instead
> using our time and effort to improve the state of our runtime libraries,
> toolchain and application packages.  (It would be a different story if
> we were developing a distribution for Java developers who don't have
> ready access to other sources of documentation, but I have a hard time
> imagining that our users would prefer javadocs over functioning and
> secure libraries.)
> 
>> Well, now we have to convince doku to implement this solution, or at
>> least to accept it, without closing the bug report again. Volunteers?
> 
> Hmm... I choose to believe that the bug (we're talking about [1],
> right?) was mass-closed along with everything else that was open against
> src:openjdk-9.  It seems like a reasonable and very "Debian" approach to
> avoid embedding an available system library.  If we really want javadoc,
> we could resubmit (preferably with a patch).

Yes, I was talking about #883981. There are two main issues with javadoc
at the moment. Firstly the syntax checker has been much more strict
since OpenJDK 8 and we currently work around a couple of problems by
simply ignoring javadoc errors, otherwise a lot more packages would be
RC buggy (FTBFS). Maybe this option will even go away in the future and
this would leave us with the following choice; either fix the underlying
error or drop the -doc package. Since we ship a lot of older or even
unmaintained software, which is still somehow useful to us though, I can
imagine that for some people our corresponding -doc packages are still a
good read because there is no equivalent source on the Internet (anymore).

Sure, that's not the sole reason why we should keep javadoc. My main
argument is that we would risk to overlook javadoc related issues in our
tool chain, if we dropped it completely. There should be at least a way
for people to create their own javadoc packages, preferably without too
much hassle. As long as that works, we could get over the rest. But
everything else is a regression.

And secondly then there is this jquery issue. I don't even know why they
need Javascript while HTML5 could do probably the same or even a better
job. Anyway we could fix this at the packaging level by replacing the
embedded copy with symlinks. There is one issue that remains: Should
-doc packages depend on jquery as well? There is a chance that the JRE
(which pulls in the jquery dependency) is not installed on the system.

So in my opinion it's not a choice between two options, javadoc yes or
no because at least for the jquery part this should be manageable.
However the first step is to acknowledge a problem but if bugs get
closed and everyone is more in favor of dropping javadoc completely,
then I also become rather "Meh".

Regards,

Markus



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

Bug#903428: javadocs generated by javahelper include jquery

[Markus Koschany]

Am 09.07.2018 um 23:35 schrieb Emmanuel Bourg:
> Le 09/07/2018 à 23:29, Markus Koschany a écrit :
> 
>> We should really aim for the simplest solution. Actually I don't see any
>> need to patch the javadoc tool because we could easily solve this at the
>> packaging level. Just replace the embedded jquery library with symlinks
>> to Debian's system library and let openjdk depend on jquery. Problem solved.
> 
> Sounds fine.
> 
> Or remove these mostly unused documentation packages we spend too much
> time fixing or discussing after each new JDK hiccup ;)

Yeah, brutal but there is truth in it. I would really like to keep the
current level of support for Java documentation but I agree when it
becomes too painful and we waste too much time to fix such issues, we
should simply drop it.

Well, now we have to convince doku to implement this solution, or at
least to accept it, without closing the bug report again. Volunteers?

:E






signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#903428: javadocs generated by javahelper include jquery

[Markus Koschany]

Am 09.07.2018 um 23:26 schrieb Emmanuel Bourg:
> Le 09/07/2018 à 23:14, Markus Koschany a écrit :
> 
>> I believe the use case of viewing javadoc outside of a Debian
>> system is negligible and we should just symlink jquery.
> 
> Viewing an API documentation from a lib*-java-doc package outside of a
> Debian system is indeed a negligible use case. But if the javadoc tool
> was to be patched to link any javadoc generated with the system jquery,
> this would render our openjdk package unfit for many development scenarios.
> 
> If the jquery substitution is implemented directly in the javadoc tool
> it must be limited to documentation aimed at lib*-java-doc packages
> (either with an extra parameter passed by the helpers, or by detecting a
> debian specific environment variable, like DEB_BUILD_ARCH).

We should really aim for the simplest solution. Actually I don't see any
need to patch the javadoc tool because we could easily solve this at the
packaging level. Just replace the embedded jquery library with symlinks
to Debian's system library and let openjdk depend on jquery. Problem solved.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#903428: javadocs generated by javahelper include jquery

[Markus Koschany]

Am 09.07.2018 um 23:01 schrieb Emmanuel Bourg:
> Le 09/07/2018 à 22:41, Christoph Berg a écrit :
> 
>> Or even better, have javadoc put in the symlink.
> 
> Not a good idea. The javadoc generated would no longer be usable outside
> Debian. Developers would no longer be able to generate the javadoc of
> their libraries a upload it to a web server.

I think this should work in the context of Debian. It's kind of funny
that we always argue about the usage of Debian packages (e.g. the Spring
framework clearly intended to be for web development, affected by
numerous security vulnerabilities but it is assumed nobody uses it in
production environments but only for building unrelated packages), still
we care about the use case of shipping javadoc outside of a Debian
environment.

In my opinion this issue should be fixed at the OpenJDK level. I am the
one who filed bug #883981 and I'm a bit disappointed that it was closed
automatically, not even reassigned to openjdk-10. IMO it would be
possible to create a javahelper/maven-debian-helper/etc option to choose
between embedding jquery into javadoc or symlinking to the system
libraries. I believe the use case of viewing javadoc outside of a Debian
system is negligible and we should just symlink jquery.

Markus



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

Bug#902991: tomcat 7.0.56-3+really7.0.88-* regression

[Markus Koschany]

Control: retitle -1 jetty8: missing symlink to tomcat-coyote.jar
Control: reassign -1 libjetty8-extra-java
Control: found -1 8.1.16-4

Am 05.07.2018 um 09:35 schrieb Sébastien QUESSON:
[...]
> With tomcat-coyote-7.0.56-3+really7.0.88-2, UriUtil class is found:
> jar tvf /usr/share/java/tomcat-coyote-7.0.56-3+really7.0.88.jar | grep Uri
> 2899 Sun Jul 01 14:38:20 CEST 2018 org/apache/tomcat/util/buf/UriUtil.class
> 
> A symlink solves the issue
> But I could not find the jar where UriUtil class was previously installed 
> with libtomcat7-java 7.0.56-3+deb8u11

Thanks for the confirmation. There is a Jetty update in progress anyway.
We will add the symlink to solve this issue.

Regards,

Markus



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

Bug#902991: tomcat 7.0.56-3+really7.0.88-* regression

[Markus Koschany]

Hello,

Am 04.07.2018 um 17:54 schrieb Sébastien QUESSON:
[...]
> Caused by:
> javax.servlet.ServletException: java.lang.NoClassDefFoundError: 
> org/apache/tomcat/util/buf/UriUtil
> ...
> Caused by:
> java.lang.NoClassDefFoundError: org/apache/tomcat/util/buf/UriUtil
> at 
> org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:316)

UriUtil is a new class and can be found in
/usr/share/tomcat7/lib/tomcat-coyote.jar. I assume this jar file is not
on your classpath. Looking at the source package of jetty8, I only see
that we symlink some tomcat jars into /usr/share/jetty8/lib/jsp/.

Provided you have libjetty8-extra-java already installed, what happens
when you symlink tomcat-coyote.jar into /usr/share/jetty8/lib/jsp/ ?

Regards,

Markus



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

Bug#902776: libpdfbox-java: CVE-2018-8036

[Markus Koschany]

Control: owner -1 !



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

Bug#902776: libpdfbox-java: CVE-2018-8036

[Markus Koschany]

Package: libpdfbox-java
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libpdfbox-java.

CVE-2018-8036[0]:
Vendor:
The Apache Software Foundation

Versions Affected:
Apache PDFBox 1.8.0 to 1.8.14
Apache PDFBox 2.0.0 to 2.0.10
Earlier, unsupported Apache PDFBox versions may be affected as well

Description:
A carefully crafted (or fuzzed) file can trigger an infinite loop which
leads to
an out of memory exception in Apache PDFBox's AFMParser.

Mitigation:
Upgrade to Apache PDFBox 1.8.15 respectively 2.0.11

Credit:
This issue was discovered by Tobias Ospelt


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-8036
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8036

Please adjust the affected versions in the BTS as needed.

Markus



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

Bug#902670: tomcat7: version number causes exception in osgi startup

[Markus Koschany]

Am 30.06.2018 um 02:04 schrieb EmTeedee:
> Hi,
> 
> On 29/06/2018 18:05, Markus Koschany wrote:
>> Ok, that makes sense. If this is the only MANIFEST file that needs an update,
>> we can patch it with the next update. 
> 
> I changed the version number in just the one MANIFEST file and the application
> started without an issue.
> Is this bug enough to release a new update or should I prepare to patch our
> other servers manually?

Hi,

I will upload a fixed version shortly. Thanks for testing and bringing
the issue to our attention.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Re: lucene-solr in Debian : why not version 7.3.1?

[Markus Koschany]

Hi,

Am 18.06.2018 um 13:07 schrieb Alastair McKinstry:
> Hi,
> 
> I'm wondering why lucene-solr in Debian is stuck at version 3.6.2
> (|+dfsg-13) rather than moving to 7.3.1.|
> 
> |The package appears to be actively maintained (last upload last month)
> - are there dependency issues,etc?|
> 
> |Best regards|
> 
> |Alastair|

The package is basically unmaintained and the original uploaders are all
MIA. The remaining people just try to fix the most important bugs
because it seems there are users who still use our package. I had a look
at the latest version but it appears they don't support Solr as a war
file anymore. [1] That means they embed the webserver now. So intrusive
changes incoming. Probably we also need to package a couple of new
dependencies as usual.

In short: We have not enough contributors to upgrade every application
and library to the latest upstream release immediately, because we spend
80% and more of our time to fix security issues, build failures and
build systems, e.g. Java 9 [2] or Java 10 [3] bugs.

Regards,

Markus


[1] https://wiki.apache.org/solr/WhyNoWar
[2]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-j...@lists.debian.org;tag=default-java9
[3]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-j...@lists.debian.org;tag=default-java10



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

Bug#891957: netbeans "loading module" modules.netbinox NullPointerException

[Markus Koschany]

Control: reopen -1

It seems there is another issue with libequinox-osgi-java. Building
Netbeans from source works again but I still get the NullPointerException.



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

Bug#882525: jaxb 2.3.0.1-2 FTBFS

[Markus Koschany]

Control: reopen -1

jaxb 2.3.0.1-2 fails to build from source. Reopening.



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

Bug#882525: netbeans FTBFS with jaxb 2.3.0

[Markus Koschany]

Am 29.05.2018 um 14:53 schrieb Emmanuel Bourg:
[...]
> Well, I disagree with your analysis but since it seems you are having a
> bad day I'm not going to argue and annoy you further with this issue.
> I'm just asking for the severity to remain below RC until the Java 9 fix
> migrates to testing.

Nope, I have a perfectly normal day and I'm 100 % sure that the
reasoning is rational. I don't mind if you want to let the Java 9 fix
migrate to testing but this is IMO unnecessary because people are
supposed to develop with Sid anyway and an RC buggy package is RC buggy
and I don't understand why you even defend that. I mean Netbeans has
been unusable for months now and that's all because of upgrading jaxb to
2.3.0. There is certainly nothing wrong with an update but when it
breaks reverse-dependencies we should do better than to ignore it and
argue about severities. I have reassigned this bug six months ago! We
worry about too many leaf packages but ignore a full blown IDE that
people actually use. Marvelous.



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

Bug#882525: netbeans FTBFS with jaxb 2.3.0

[Markus Koschany]

Am 29.05.2018 um 14:00 schrieb Emmanuel Bourg:
> Le 29/05/2018 à 13:51, Markus Koschany a écrit :
> 
>> I can't remember. Feel free to try and implement your workaround but
>> don't lower the severity of an 100 % RC bug until then.
> 
> This issue matches the definition of an important bug to me, i.e. "a bug
> which has a major effect on the usability of a package, without
> rendering it completely unusable to everyone". The package works and
> achieves its main function, it's just one of its features (the xjc Ant
> task) that is broken and affects netbeans.

This issue makes Netbeans fail to build from source which is by Debian's
standards always an release critical bug. Netbeans will not be part of
Buster as long as the FTBFS has not been rectified. However the bug is
not in src:netbeans but in jaxb 2.3.0. The previous version worked
perfectly fine with Netbeans hence we can deduce your update introduced
the regression which made Netbeans FTBFS. The correct severity is
serious because this is a Policy violation.

For me it goes without saying now that I would take responsibility for
breaking another package and concentrate on fixing it. At least I would
not downplay the bug. We are not talking about some random test failure
here. Jaxb 2.3.0 did introduce a severe regression and it does not
matter if only its xjc Ant task is affected as long as the result is
that another package fails to build from source which was prior in
perfect shape. It should not be part of testing because of that reason.



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#882525: netbeans FTBFS with jaxb 2.3.0

[Markus Koschany]

Am 29.05.2018 um 13:46 schrieb Emmanuel Bourg:
> Le 29/05/2018 à 13:07, Markus Koschany a écrit :
> 
>> I have already tried that weeks ago but to no avail.
> 
> Did you try replacing the  Ant task with an  task invoking
> the xjc command?

I can't remember. Feel free to try and implement your workaround but
don't lower the severity of an 100 % RC bug until then.



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#882525: netbeans FTBFS with jaxb 2.3.0

[Markus Koschany]

Am 29.05.2018 um 13:28 schrieb Emmanuel Bourg:
> Le 29/05/2018 à 13:07, Markus Koschany a écrit :
> 
>> I have already tried that weeks ago but to no avail. I think the
>> severity should remain RC until jaxb is updated to fix this issue. It
>> blocks any way to fix other RC bugs in Netbeans at the moment.
> 
> jaxb/2.3.0-3 is already in testing, so raising the severity won't make a
> big difference. I'm about to upload the version 2.3.0.1 which fixes the
> Java 9 compatibility, it would be nice to let it migrate.

It's about tracking an RC bug. Netbeans FTBFS and has been removed from
testing because of jaxb and if you lower the severity one reason for
reentering testing is gone. It can be downgraded to important but only
if a) the workaround is implemented in Netbeans or b) the bug is
properly fixed in jaxb.

Markus




signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#681726: Eclipse is 6 Years Behind in Debian

[Markus Koschany]

Hello,

Am 25.05.2018 um 21:50 schrieb Josh Blagden:
> Hi folks,
> 
>     I just wanted to make the observation that Debian has had the same
> version of Eclipse for the last six years. When can we expect to see a
> new version to the Debian repository?

Maybe when a solar and lunar eclipse happen at the same time.

On a more serious note, we do not intend to ship the current version
with Debian 10 "Buster" again because, as you have rightly observed, it
is obsolete and also broken. I recommend Debian bug #681726 for further
reading. [1]

I still intend to save parts of Eclipse (eclipse-platform) but will also
look into other alternatives to save aspectj and its
reverse-dependencies, whatever is easier to achieve. Though I have made
up my mind and I don't intend to maintain Eclipse and all plugin
packages alone for Buster. I will focus on Netbeans 9 as an alternative
IDE instead which hopefully requires less maintenance but this also
depends on whether it will be released in time before the next freeze.

So in short, we are aware of the situation but we could need more help
from people who really want to _maintain_ Eclipse.

I also thought about something that was discussed at DebConf17 in
Montreal, just packaging the upstream tarball as is. Obviously we can't
ship that in Debian main but we could provide a eclipse-downloader
package in contrib instead. I'm not sure if this is really needed or
desired because it shouldn't be too difficult to run the Eclipse
installer manually. Just a thought, not a promise.

Hope that helps clarifying the situation a little

Regards,

Markus

[1] https://bugs.debian.org/681726



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

Bug#899374: batik: CVE-2018-8013

[Markus Koschany]

This is apparently upstream bug BATIK-1222

https://issues.apache.org/jira/browse/BATIK-1222

Patch:

https://svn.apache.org/viewvc?view=revision=1831241



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

Bug#899332: CVE-2018-8012: Apache ZooKeeper Quorum Peer mutual authentication

[Markus Koschany]

Package: zookeeper
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security
Fixed: 3.4.10-1

Hi,

The following vulnerability was published for zookeeper.

CVE-2018-8012[0]:
| No authentication/authorization is enforced when a server attempts to
| join a quorum in Apache ZooKeeper before 3.4.10, and 3.5.0-alpha
| through 3.5.3-beta. As a result an arbitrary end point could join the
| cluster and begin propagating counterfeit changes to the leader.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-8012
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8012

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



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

Bug#899183: sub...@bugs.debian.org

[Markus Koschany]

Control: retitle -1 libpdfbox2-java:


Hello,

Am 20.05.2018 um 14:23 schrieb Martin Kittel:
> Package: libpdfbox2-java
> Version: 2.0.9-1
> Severity: important
> 
> Dear Maintainer,
> 
> I get the exception below when running my Java program using
> libpdfbox2-java. I tried running the program with different
> JREs (down to 1.7) but the error persists. I guess the problem is
> that libpdfbox2-java is compiled using Java 9. Java 9 seems to
> introduce a change that breaks things even when running with
> older JREs:
> 
> 'because in JDK9 ByteBuffer.flip() returns a ByteBuffer... It
>  used to return a Buffer in JDK8.'
> (see https://github.com/plasma-umass/doppio/issues/497 also
> for suggestions on how to fix this at build time)

thanks for the report. Unfortunately there is not much what we can do
here. I think it would be impractical to fix all packages by casting
ByteBuffer.flip to Buffer. By default we compile to source/target 1.7
but I can force -release 9 for libpdfbox2-java to make it clear that we
don't support older JREs in Buster. In fact we will release with OpenJDK
11 as the default JRE. If it works with an older runtime it is always a
bonus but isn't really supported by us.

Regards,

Markus



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

Bug#891956: Your mail

[Markus Koschany]

Am 14.05.2018 um 22:21 schrieb Rafi Rubin:
> The dependencies for 3.8.1-11 end up requiring libequinox-osgi-java >=
> 3.9.1 (through eclipse-rcp), which doesn't have
> /usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar
> 
> 
> Going back to stable, 3.8.1-10 for the eclipse packages at least catches
> that jar, but fails after an illegal reflection error.  Maybe it will
> work with an older jdk that's less picky, I haven't tried.
> 
> 
> 
> Is there any intent to package the newer versions of eclipse?  It looks
> like 3.8 is eol at this point.

We won't ship Elicpse 3.8 in Buster. The libequinox-osgi-java issue is
only one of the most obvious bugs in Eclipse and could be easily fixed
but the illegal reflection errors are all caused by Java 10. This
version is simply not ready for everything that is newer than OpenJDK 8.
The plan is to salvage the eclipse-platform package somehow which is a
build-dependency for some important packages but maintaining Eclipse and
its plugins requires more regular help from people who are interested in
keeping it in a good shape. At the moment those volunteers don't exist.

See also https://bugs.debian.org/681726

Markus



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

Bug#896929: java.ext.dirs is gone

[Markus Koschany]

Hi,

Am 09.05.2018 um 13:42 schrieb PaulLiu:
> Hi Markus,
> 
> 
> Any suggest lib for replacements of rxtx?? 

There is an open issue about the current (non-)activity of rxtx development.

https://github.com/rxtx/rxtx/issues/13

Someone suggested to use

https://github.com/scream3r/java-simple-serial-connector

instead but the last release was also four years ago and it appears to
be incompatible with Java 9 too

https://github.com/scream3r/java-simple-serial-connector/issues/124

Sorry, I can't give you any advice in this case.

Regards,

Markus



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

Bug#896929: java.ext.dirs is gone

[Markus Koschany]

Am 01.05.2018 um 15:48 schrieb deb...@fau.xxx:
> I traced this problem to RXTXCommDriver.java:415:
> System.getProperty("java.ext.dirs") comes back null. It's illegal to
> -Djava.ext.dirs on Java 10/11. The easiest fix appears to be to add a
> second argument (default value) of the empty string, which makes the
> code/loop a noop. That, or try and switch it over to classpath? It's
> unclear to me where it's expecting to find a property file file, but
> maybe it does in some setups.
> 
> Debugging is a lot easier if you add e.printStackTrace(); to all three
> /thrown while loading/ catch and discard blocks.
> 
> Also, the package fails to build for me on Ubuntu's Java "11" (i.e. Java
> 10 in a weird package name), due to javah removal.
> 
> Chris.

Thanks Chris for the analysis. I don't believe there will be any
upstream support for Java 11 though. According to
https://github.com/rxtx/rxtx the last activity was three years ago but
significant changes date even back five years. Arduino should be ported
away from rxtx instead.

This package has four reverse-dependencies at the moment:

arduino
jtharness
ucrpf1host
mina2

Regards,

Markus



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

Bug#896604: lucene-solr: CVE-2018-1308 XXE in DataImportHandler

[Markus Koschany]

Package: lucene-solr
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for lucene-solr.

CVE-2018-1308[0]:
| This vulnerability in Apache Solr 1.2 to 6.6.2 and 7.0.0 to 7.2.1
| relates to an XML external entity expansion (XXE) in the
| `dataConfig=inlinexml` parameter of Solr's
DataImportHandler. It
| can be used as XXE using file/ftp/http protocols in order to read
| arbitrary local files from the Solr server or the internal network.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1308
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1308

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



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

Bug#896439: gradle-debian-helper points to an invalid java api directory

[Markus Koschany]

Am 21.04.2018 um 19:57 schrieb Emmanuel Bourg:
> Hi Tiago,
> 
> I don't think gradle-debian-helper should depend on default-jdk-doc by
> default, this is a rather big dependency and it's preferable to keep it
> optional to speed up the builds a bit. I think the packages using
> gradle-debian-helper should instead depend on default-jdk-doc if they
> build a javadoc package. That's what most packages building a javadoc
> already do.
> 
> As for changing the path to the JDK doc why not, but I don't really
> understand the benefit. It seems both URLs are currently in use, with
> /usr/share/doc/default-jdk-doc/api being more popular than
> /usr/share/doc/default-jdk/api despite the longer path.

By the way since Debian Policy 3.9.7 it is recommended to install
additional documentation via -doc packages into /usr/share/doc/pkg and
no longer /usr/share/doc/pkg-doc. This is also enforced with
debhelper/compat >= 11. If we were consequent then we should use
/usr/share/doc/default-jdk/api everywhere.

Markus




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

Bug#893312: lombok FTBFS with openjdk-9

[Markus Koschany]

I've fixed the original errors in Javac.java but there are more later on
due to our friend OpenPain 9. I had no choice but to upgrade to a newer
lombok version. Now I'm stuck because ecj can't be found.

Markus



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

Bug#895920: ecj: only a virtual package and not installable

[Markus Koschany]

Source: ecj
Version: 3.13.2-2
Severity: serious

while I was having some fun with lombok, I discovered that ecj is just
a virtual package and not installable. I don't think that's intended.

Markus

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

Bug#895778: jruby: Several security vulnerabilities

[Markus Koschany]

Package: jruby
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for jruby. Apparently
rubygems is embedded into jruby which makes it vulnerable to.

CVE-2018-179[0]:
| RubyGems version Ruby 2.2 series: 2.2.9 and earlier, Ruby 2.3 series:
| 2.3.6 and earlier, Ruby 2.4 series: 2.4.3 and earlier, Ruby 2.5
| series: 2.5.0 and earlier, prior to trunk revision 62422 contains a
| Directory Traversal vulnerability in gem installation that can result
| in the gem could write to arbitrary filesystem locations during
| installation. This attack appear to be exploitable via the victim must
| install a malicious gem. This vulnerability appears to have been fixed
| in 2.7.6.

CVE-2018-178[1]:
| RubyGems version Ruby 2.2 series: 2.2.9 and earlier, Ruby 2.3 series:
| 2.3.6 and earlier, Ruby 2.4 series: 2.4.3 and earlier, Ruby 2.5
| series: 2.5.0 and earlier, prior to trunk revision 62422 contains a
| Cross Site Scripting (XSS) vulnerability in gem server display of
| homepage attribute that can result in XSS. This attack appear to be
| exploitable via the victim must browse to a malicious gem on a
| vulnerable gem server. This vulnerability appears to have been fixed
| in 2.7.6.

CVE-2018-177[2]:
| RubyGems version Ruby 2.2 series: 2.2.9 and earlier, Ruby 2.3 series:
| 2.3.6 and earlier, Ruby 2.4 series: 2.4.3 and earlier, Ruby 2.5
| series: 2.5.0 and earlier, prior to trunk revision 62422 contains a
| Improper Input Validation vulnerability in ruby gems specification
| homepage attribute that can result in a malicious gem could set an
| invalid homepage URL. This vulnerability appears to have been fixed in
| 2.7.6.

CVE-2018-176[3]:
| RubyGems version Ruby 2.2 series: 2.2.9 and earlier, Ruby 2.3 series:
| 2.3.6 and earlier, Ruby 2.4 series: 2.4.3 and earlier, Ruby 2.5
| series: 2.5.0 and earlier, prior to trunk revision 62422 contains a
| Improper Verification of Cryptographic Signature vulnerability in
| package.rb that can result in a mis-signed gem could be installed, as
| the tarball would contain multiple gem signatures.. This vulnerability
| appears to have been fixed in 2.7.6.

CVE-2018-175[4]:
| RubyGems version Ruby 2.2 series: 2.2.9 and earlier, Ruby 2.3 series:
| 2.3.6 and earlier, Ruby 2.4 series: 2.4.3 and earlier, Ruby 2.5
| series: 2.5.0 and earlier, prior to trunk revision 62422 contains a
| infinite loop caused by negative size vulnerability in ruby gem
| package tar header that can result in a negative size could cause an
| infinite loop.. This vulnerability appears to have been fixed in
| 2.7.6.

CVE-2018-174[5]:
| RubyGems version Ruby 2.2 series: 2.2.9 and earlier, Ruby 2.3 series:
| 2.3.6 and earlier, Ruby 2.4 series: 2.4.3 and earlier, Ruby 2.5
| series: 2.5.0 and earlier, prior to trunk revision 62422 contains a
| Deserialization of Untrusted Data vulnerability in owner command that
| can result in code execution. This attack appear to be exploitable via
| victim must run the `gem owner` command on a gem with a specially
| crafted YAML file. This vulnerability appears to have been fixed in
| 2.7.6.

CVE-2018-173[6]:
| RubyGems version Ruby 2.2 series: 2.2.9 and earlier, Ruby 2.3 series:
| 2.3.6 and earlier, Ruby 2.4 series: 2.4.3 and earlier, Ruby 2.5
| series: 2.5.0 and earlier, prior to trunk revision 62422 contains a
| Directory Traversal vulnerability in install_location function of
| package.rb that can result in path traversal when writing to a
| symlinked basedir outside of the root. This vulnerability appears to
| have been fixed in 2.7.6.

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-179
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-179
[1] https://security-tracker.debian.org/tracker/CVE-2018-178
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-178
[2] https://security-tracker.debian.org/tracker/CVE-2018-177
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-177
[3] https://security-tracker.debian.org/tracker/CVE-2018-176
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-176
[4] https://security-tracker.debian.org/tracker/CVE-2018-175
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-175
[5] https://security-tracker.debian.org/tracker/CVE-2018-174
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-174
[6] https://security-tracker.debian.org/tracker/CVE-2018-173
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-173

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
.