Bug#873055: libgnutls30: Safe renegotiation breaks on session resumption with OpenSSL client
Package: libgnutls30 Version: 3.5.14-3 Severity: normal If the %SAFE_RENEGOTIATION flag is enabled in the priorities string of a GnuTLS server, Client Hellos from OpenSSL clients attempting session resumption are rejected with a "safe renegotiation failed" error, even though the client does support safe renegotiation. Note that the handshake works as expected if the session cache entry or ticket has expired (without resumption, of course), so the bug only affects otherwise successful resumption. I have initially observed this bug using mod_gnutls (package libapache2-mod-gnutls), but it is fully reproducible using only the GnuTLS and OpenSSL command line tools. The logs below have been produced by running a gnutls-serv server and connecting using openssl s_client and gnutls-cli (separated by three pings for clarity in client logs and packet capture), both set to immediately disconnect and resume after the initial handshake. The GnuTLS client can resume the TLS session as expected, while the OpenSSL client is rejected. Commands to reproduce: (server)$ gnutls-serv --priority="NORMAL:%SAFE_RENEGOTIATION" --x509keyfile=server/secret.key --x509certfile=server/x509-chain.pem -p 4433 (OpenSSL client)$ openssl s_client -connect localhost:4433 -reconnect (GnuTLS client)$ gnutls-cli -p 4433 --x509cafile=authority/x509.pem --resume localhost A packet capture taken during this process shows a difference in how GnuTLS and OpenSSL signal safe renegotiation support in the Client Hello: GnuTLS sends the renegotiation_info extension, OpenSSL includes the TLS_EMPTY_RENEGOTIATION_INFO_SCSV in the list of cipher suites. According to RFC 5746 both are equally valid for both full and session-resumption handshakes, but the GnuTLS server appears to ignore the SCSV during session resumption. *** safe_renegotiation_resume.server $ gnutls-serv --priority="NORMAL:%SAFE_RENEGOTIATION" --x509keyfile=server/secret.key --x509certfile=server/x509-chain.pem -p 4433 HTTP Server listening on IPv4 0.0.0.0 port 4433...done HTTP Server listening on IPv6 :: port 4433...done * Accepted connection from IPv6 ::1 port 58956 on Wed Aug 23 13:59:33 2017 - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM) - Session ID: 78:EE:E1:54:AD:C3:EF:35:52:6D:B3:1A:51:8B:45:96:72:8D:50:A0:42:06:22:45:8E:F9:46:6A:23:B3:B7:A3 No certificates found! - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA512 - Cipher: AES-256-GCM - MAC: AEAD - Compression: NULL - Options: extended master secret, safe renegotiation, - Channel binding 'tls-unique': 3019c6c0c2a491101e3a4a1e * Accepted connection from IPv6 ::1 port 58958 on Wed Aug 23 13:59:33 2017 Error in handshake Error: Safe renegotiation failed. * Accepted connection from IPv6 ::1 port 58960 on Wed Aug 23 13:59:35 2017 - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM) - Session ID: 0B:B5:29:05:D5:E0:56:DD:76:95:F3:D1:2B:C0:83:05:85:CD:D0:1E:48:CA:FB:63:7F:06:8B:BC:8E:0C:95:C7 - Given server name[1]: localhost No certificates found! - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA256 - Cipher: AES-256-GCM - MAC: AEAD - Compression: NULL - Options: extended master secret, safe renegotiation, - Channel binding 'tls-unique': 0be4e24d6efda699b2af69df * Accepted connection from IPv6 ::1 port 58962 on Wed Aug 23 13:59:35 2017 *** This is a resumed session - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM) - Session ID: AD:2C:A9:E9:5C:C3:9A:4A:FC:F6:F6:01:A4:2A:42:FD:52:51:FF:94:60:70:2A:93:62:C9:3E:A2:6C:DD:DD:B4 - Given server name[1]: localhost No certificates found! - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Cipher: AES-256-GCM - MAC: AEAD - Compression: NULL - Options: extended master secret, safe renegotiation, - Channel binding 'tls-unique': 62489fad3554606b907fd7dc *** safe_renegotiation_resume.client $ openssl s_client -connect localhost:4433 -reconnect; ping -c 3 localhost; gnutls-cli -p 4433 --x509cafile=authority/x509.pem --resume localhost CONNECTED(0003) depth=1 CN = Testing Authority verify error:num=19:self signed certificate in certificate chain --- Certificate chain 0 s:/CN=localhost i:/CN=Testing Authority 1 s:/CN=Testing Authority i:/CN=Testing Authority --- Server certificate -BEGIN CERTIFICATE- MIIEozCCAwugAwIBAgIEIv/w2TANBgkqhkiG9w0BAQsFADAcMRowGAYDVQQDExFU ZXN0aW5nIEF1dGhvcml0eTAeFw0xNzA4MjMxMTA5MjBaFw0xODA4MjMxMTA5MjBa MBQxEjAQBgNVBAMTCWxvY2FsaG9zdDCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCC AYoCggGBALt5LnvO+Y1b024IRaIlX8gQqRlDTTl42SBb1XyRvRLfqZbxsyVXL+k2 4PSG2PltF/6QLxpGDhNUk4Qh//B3i/Q0q1F1QH62Png6T18U/vtD+5lQOhwH+2RT x8Nm3X4JPZaDrm29oKmt7OSk+Kv4rQIyfI6X1DJ1+pHRUjZAmBgOeSQCSaOUDCny
Bug#855933: mod-gnutls: FTBFS: Test failures
Hi Daniel, hi Lucas, I have pushed a suggested version 0.8.2-3 to the "for-debian" branch at commit 266c7750aa4c1a25089d3ad79e4b5359b9342214 in my Github repository [1]. I tried to keep the differences reasonably small, I hope the result is acceptable during the freeze. The set of changes assumes that (patch numbers refer to the numbered file names in debian/patches, 0001 is already in 0.8.2-2): * Verbose logging around the fixed bugs is desirable. That's why it includes patches 0002 to 0004, just increasing the timeouts could be one smaller patch. * Not breaking compatibility for jessie-backports is desirable (patch 0005). Ironically, this could be dropped without the verbose logging part above. * Fixing the tests for hurd-i386 is desirable, even though it's not a release architecture (patch 0006). * The update will go through unstable (patch 0007 for compatibility with GnuTLS 3.5.9). Regards, Thomas [1] https://github.com/airtower-luna/mod_gnutls/commits/for-debian
Bug#855933: GnuTLS 3.5.9 compatibility
If a patched upload goes through unstable, I suggest also including commit 61353933986460ea2d7bcbc57531ecd066795f0d (patch attached). It's just one line, but without it we'll be back to FTBFS when GnuTLS 3.5.9 hits unstable. From 61353933986460ea2d7bcbc57531ecd066795f0d Mon Sep 17 00:00:00 2001 From: Thomas Klute <thomas2.kl...@uni-dortmund.de> Date: Sun, 19 Feb 2017 18:57:56 +0100 Subject: [PATCH] Do not treat warnings about deprecated declarations as errors GnuTLS has declared OpenPGP support as deprecated in version 3.5.9. Treating deprecation warnings as errors causes the build to fail with this version, so exempt them from "-Werror" until OpenPGP support is removed from mod_gnutls. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index cc3e8ae..3335773 100644 --- a/configure.ac +++ b/configure.ac @@ -64,7 +64,7 @@ AC_ARG_ENABLE(strict, STRICT_CFLAGS="" if test "$use_strict" != "no"; then -STRICT_CFLAGS="-Wall -Werror -Wextra" + STRICT_CFLAGS="-Wall -Werror -Wextra -Wno-error=deprecated-declarations" fi AC_MSG_CHECKING([whether to enable SRP functionality]) -- 2.9.3
Bug#855933: mod-gnutls: FTBFS: Test failures
These look like the timeout issues I discovered in the build logs for 0.8.2-2, see [1] for Daniel's report and [2] for my analysis, plus my two follow up mails if jessie-backports and hurd-i386 matter. I'm going to quote that mail below. Just a little clarification ahead: I've since confirmed that the issue was definitely the combination of parallel=32 and a pretty short timeout for the flock calls. All test cases got started simultaneously but had to wait their turn for the port(s) used in the tests (that's what the flock calls around Apache are for), effectively making the flock timeout (30 seconds by default) a timeout for the whole test suite except the last test case to complete. [1] https://lists.gnupg.org/pipermail/mod_gnutls-devel/2017-February/000185.html [2] https://lists.gnupg.org/pipermail/mod_gnutls-devel/2017-February/000186.html Looking at both build logs my best guess is that the tests are hitting timeouts, both when getting the server instance locks (used to prevent port conflicts) and running HTTPS requests against them. The log for test-15_basic_msva.bash on sparc64 even looks like the timeout hit in the middle of request handling. I've pushed three related commits to master (the attached patch combines all three), in order: 8184ad0eda43102d24d7cf158710e0109c7e293b Test suite: Run flock with "--verbose" to log timeouts bbfcbb57c2cb89790316b66bdd475c3a64ca4080 Test suite: Log if a process to be stopped by PID file is not running 6c030c14da928da3e05f232e3fb8dd5aa98c659a Test suite: Make timeouts for server locks and HTTPS requests configurable Commits 8184ad0eda43102d24d7cf158710e0109c7e293b and bbfcbb57c2cb89790316b66bdd475c3a64ca4080 just make the logging more detailed to show if the tests are really hitting timeouts. To change the timeouts, you can either cherry-pick 6c030c14da928da3e05f232e3fb8dd5aa98c659a and pass TEST_LOCK_WAIT and TEST_QUERY_TIMEOUT with large values (e.g. 300 or even 600, default is 30 [seconds]) to ./configure, or patch the values of lock_wait and TEST_QUERY_DELAY in test/Makefile.am (I've replaced/renamed the variables in the patch). > I can make force the entire build to not be parallel if you think it > would be useful to test. While i see "parallel=32" in the sparc64 > transcript, i don't see a "parallel=" note at all in ppc64. Running in parallel definitely makes hitting the timeouts more likely, but shouldn't cause any additional problems. You can force just the test part of the build to run serially by passing --disable-flock to ./configure, which will add the special target .NOTPARALLEL to test/Makefile. I'd prefer if you try the patches first, though.
Bug#851384: Fixed upstream
This is a bug in the program which generates the OCSP database used in the failed test. I believe I have fixed this issue upstream in version 0.8.2. A build in a qemubuilder mips environment produced a correct test database.
Bug#848743: Build problem fixed in mod_gnutls 0.8.1
I have confirmed that the patch in my previous mail works on i386, and released mod_gnutls 0.8.1 to fix the build failures on 32 bit architectures.
Bug#848743: mod_gnutls 0.8.0-1 build failures
It looks like the test failures were cause by bug #848339, which was fixed in libunbound2 1.6.0-2. Relevant log excerpts: Setting up the build environment (libunbound2 version): > Selecting previously unselected package libunbound2:amd64. > Preparing to unpack .../088-libunbound2_1.6.0-1_amd64.deb ... > Unpacking libunbound2:amd64 (1.6.0-1) ... Test log (look at any of the failed tests): > gnutls-cli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libunbound.so.2: > undefined symbol: fake_dsa I believe a rebuild with libunbound2 1.6.0-2 will fix the test failures. However, there were also build failures on the 32 bit architectures, which are my fault for not using the right (portable) format modifier with apr_size_t in a few calls to ap_log_error() or apr_psprintf(). I didn't get to test a 32 bit build yet, but I believe the attached patch will fix the problem. diff --git a/src/gnutls_cache.c b/src/gnutls_cache.c index 3ebbd08..2b615f9 100644 --- a/src/gnutls_cache.c +++ b/src/gnutls_cache.c @@ -494,7 +494,7 @@ static gnutls_datum_t dbm_cache_fetch(mgs_handle_t *ctxt, gnutls_datum_t key) } ap_log_cerror(APLOG_MARK, APLOG_TRACE1, rv, ctxt->c, - "fetched %ld bytes from cache", + "fetched %" APR_SIZE_T_FMT " bytes from cache", dbmval.dsize); memcpy(data.data, dbmval.dptr + sizeof (apr_time_t), data.size); @@ -587,7 +587,8 @@ static int dbm_cache_store(server_rec *s, gnutls_datum_t key, apr_global_mutex_unlock(sc->cache->mutex); ap_log_error(APLOG_MARK, APLOG_TRACE1, rv, s, - "stored %ld bytes of data (%ld byte key) in cache '%s'", + "stored %" APR_SIZE_T_FMT " bytes of data (%" + APR_SIZE_T_FMT " byte key) in cache '%s'", dbmval.dsize, dbmkey.dsize, sc->cache_config); apr_pool_destroy(spool); diff --git a/src/gnutls_util.c b/src/gnutls_util.c index 9905bad..5e98bd4 100644 --- a/src/gnutls_util.c +++ b/src/gnutls_util.c @@ -28,7 +28,7 @@ const char* http_post_header(apr_pool_t *p, apr_uri_t *uri, "Host: %s\r\n" "Content-Type: %s\r\n" "Accept: %s\r\n" -"Content-Length: %ld\r\n\r\n", +"Content-Length: %" APR_SIZE_T_FMT "\r\n\r\n", apr_uri_unparse(p, uri, APR_URI_UNP_OMITSITEPART), uri->hostname, content_type, accept != NULL ? accept : "*/*",
Bug#798396: Still present in 2.1.0-2
Control: found -1 2.1.0-2 This bug is still present in 2.1.0-2 according to the logs from buildd (https://buildd.debian.org/status/fetch.php?pkg=softhsm2=arm64=2.1.0-2=1459985395): > configure:4560: checking if we can compile in 64-bit mode > configure:4583: gcc -o conftest -m64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE > -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed conftest.c >&5 > gcc: error: unrecognized command line option '-m64' SoftHSM v1 is getting removed (see #820235), so having softhsm2 available is important (e.g. see #820248).
Bug#820235: SoftHSM2 support
Am 12.04.2016 um 18:38 schrieb Daniel Kahn Gillmor: > i'm aiming to get 0.7.3 into debian in the next couple days, sorry for > the delay! if you get 0.7.4 out the door before i get 0.7.3 into > debian, i'll just roll those changes together. I've just released version 0.7.4. If possible under Debian policy please keep SoftHSM 1 as an alternative dependency. That way the package can be backported to stable without any modification. Best regards, Thomas
Bug#820235: SoftHSM2 support
Hi, this is the upstream mod_gnutls maintainer. The patch is not going to be enough to use SoftHSM 2, that would need a bunch of changes to the test environment setup as well. If the build doesn't fail with the patch, that's because the PKCS #11 test is skipped when "make check" cannot find a supported SoftHSM version (same effect as just removing the dependency on softhsm). However, I have SoftHSM 2 support in my development repository (https://github.com/airtower-luna/mod_gnutls.git master) since March. I didn't consider releasing it high priority because SoftHSM 1 works well enough for tests, but I could make a 0.7.4 release with SoftHSM 2 support instead of waiting for 0.8 with new features if that helps. Daniel, what do you think? Regards, Thomas
Bug#514005: Patch available
I have a patch for this problem in my development repository [1], the fix will be included in mod_gnutls 0.7.3 (to be released soon). [1] https://github.com/airtower-luna/mod_gnutls/commit/8ac7c0dbd1357a8acadafc2aab8568bdebe7ae8f
Bug#642357: Fixed upstream & in unstable/testing
The test suite included in mod_gnutls since version 0.6 uses only connections from and to localhost, so it is safe to say that this bug is fixed.
Bug#813243: gnutls-bin: Broken Key Usage flags in certificates created with certtool
Package: gnutls-bin Version: 3.4.8-2 Severity: normal Tags: upstream patch I found that certtool writes broken Key Usage extensions to generated certificates. For example, when using the follwing template (from the mod_gnutls test suite) to create a CA, neither of the requested flags (certificate signing and CRL signing) is set. cn="Testing Authority" ca cert_signing_key crl_signing_key The key usage extension ends up present but empty. This leads to all certificates issued by the CA getting rejected because signing certificates violates the certificate's constraints. I've reported the bug upstream [1] and there is a simple patch [2]. Please apply it to the version in Sid. [1] http://lists.gnutls.org/pipermail/gnutls-devel/2016-January/007861.html [2] https://gitlab.com/gnutls/gnutls/commit/7d3caedb8df9d04eee9513cb5b3b417ae29927f5 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnutls-bin depends on: ii libc62.21-7 ii libgmp10 2:6.1.0+dfsg-2 ii libgnutls30 3.4.8-2 ii libhogweed4 3.1.1-4 ii libidn11 1.32-3 ii libnettle6 3.1.1-4 ii libopts251:5.18.7-3 ii libp11-kit0 0.23.2-3 ii libtasn1-6 4.7-3 ii zlib1g 1:1.2.8.dfsg-2+b1 gnutls-bin recommends no packages. gnutls-bin suggests no packages. -- no debconf information
Bug#785683: RFS: mod-gnutls/0.6-1.4 [NMU]
Package: sponsorship-requests Severity: normal Dear mentors, I'm looking for a sponsor for a bugfix update of mod-gnutls that would close bug #775909 (segfaults with reverse proxy configuration). I've uploaded the package to Debian Mentors a few weeks ago. The maintainer has not responded (like for the security updates to 0.5.10-1.1+deb7u1 and 0.6-1.3, which went through the security team, see DSA-3177 [1]), so now I'm looking for a sponsor for an NMU. * Package name: mod-gnutls Version : 0.6-1.4 Upstream Author : Daniel Kahn Gillmor d...@fifthhorseman.net * URL : https://mod.gnutls.org/ * License : Apache-2.0 Section : httpd It builds those binary packages: libapache2-mod-gnutls - Apache module for SSL and TLS encryption with GnuTLS To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mod-gnutls Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mod-gnutls/mod-gnutls_0.6-1.4.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * Fix segfaults with reverse proxy configuration (Closes: #775909) * Upgrade Standards-Version to 3.9.6, change DocumentRoot in default-tls.conf to /var/www/html accordingly. Regards, Thomas Klute [1] https://www.debian.org/security/2015/dsa-3177 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784961: JamVM: Relocation error on startup, JVM_GetResourceLookupCacheURLs undefined
Package: openjdk-8-jre-jamvm Version: 8u45-b14-2 Severity: important When trying to run a Java program with JamVM, the JVM fails to start with the following error message: java: relocation error: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libjava.so: symbol JVM_GetResourceLookupCacheURLs, version SUNWprivate_1.1 not defined in file libjvm.so with link time reference The bug occurs even with a simple Hello World program, or when java -jamvm is called without any further parameters (should print a help message and exit). Output with -verbose below. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/32 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openjdk-8-jre-jamvm depends on: ii libc6 2.19-18 ii openjdk-8-jre-headless 8u45-b14-2 ii zlib1g 1:1.2.8.dfsg-2+b1 openjdk-8-jre-jamvm recommends no packages. openjdk-8-jre-jamvm suggests no packages. -- no debconf information *** Verbose output: $ java -verbose -jamvm HelloWorld [Loaded java/lang/Object from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/Object] [Loaded java/io/Serializable from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/io/Serializable] [Loaded java/lang/reflect/AnnotatedElement from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/reflect/AnnotatedElement] [Loaded java/lang/reflect/GenericDeclaration from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/reflect/GenericDeclaration] [Loaded java/lang/reflect/Type from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/reflect/Type] [Loaded java/lang/Class from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/Class] [Loaded java/lang/ClassLoader from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/ClassLoader] [Loaded java/lang/Comparable from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/Comparable] [Loaded java/lang/CharSequence from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/CharSequence] [Loaded java/lang/String from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/String] [Loaded java/lang/Cloneable from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/Cloneable] [Loaded java/lang/StackTraceElement from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/StackTraceElement] [Created array class [Ljava/lang/StackTraceElement;] [Loaded java/lang/Throwable from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/Throwable] [Loaded java/lang/Error from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/Error] [Loaded java/lang/LinkageError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/LinkageError] [Loaded java/lang/BootstrapMethodError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/BootstrapMethodError] [Loaded java/lang/VirtualMachineError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/VirtualMachineError] [Loaded java/lang/InternalError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/InternalError] [Loaded java/lang/ClassFormatError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/ClassFormatError] [Loaded java/lang/IncompatibleClassChangeError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/IncompatibleClassChangeError] [Loaded java/lang/NoSuchFieldError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/NoSuchFieldError] [Loaded java/lang/OutOfMemoryError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/OutOfMemoryError] [Loaded java/lang/NoSuchMethodError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/NoSuchMethodError] [Loaded java/lang/InstantiationError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/InstantiationError] [Loaded java/lang/IllegalAccessError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/IllegalAccessError] [Loaded java/lang/Exception from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/Exception] [Loaded java/lang/RuntimeException from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/RuntimeException] [Loaded java/lang/ClassCastException from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] [Linking class java/lang/ClassCastException] [Loaded java/lang/StackOverflowError from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar]
Bug#766284: Still broken in version 8u45-b14-1
Control: found -1 8u45-b14-1 I still encountered this bug when testing the current version of openjdk-8-jre-jamvm in unstable on amd64 (8u45-b14-1). $ java -jamvm -version Error initialising VM (initialiseClassStage2) ClassBlock padding is less than java.lang.Class fields! Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. $ java -version openjdk version 1.8.0_45-internal OpenJDK Runtime Environment (build 1.8.0_45-internal-b14) OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775909: Seeking sponsor for patched package
For the record: I have uploaded a source package containing my patches to mentors.debian.net [1] as version 0.6-1.4 and am looking for a sponsor for it (or comments if improvements are necessary). [1] https://mentors.debian.net/package/mod-gnutls -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635711: Still broken in monkeysphere 0.37-2 on sid
I still see this bug in monkeysphere 0.37-2 on sid (fresh stable install, upgrade through testing to unstable). Aptitude installation: Setting up monkeysphere (0.37-2) ... adding monkeysphere user... ms: setting up Monkeysphere authentication trust core... Failed running transition script /usr/share/monkeysphere/transitions/0.23 dpkg: error processing package monkeysphere (--configure): subprocess installed post-installation script returned error exit status 141 [... other packages ...] Errors were encountered while processing: monkeysphere E: Sub-process /usr/bin/dpkg returned an error code (1) Failed to perform requested operation on package. Trying to recover: Setting up monkeysphere (0.37-2) ... ms: setting up Monkeysphere authentication trust core... /usr/share/monkeysphere/ma/setup: line 73: printf: write error: Broken pipe Failed running transition script /usr/share/monkeysphere/transitions/0.23 dpkg: error processing package monkeysphere (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: monkeysphere Running the transition script manually doesn't produce any output that tells me what is wrong, but the return value is the same: # /usr/share/monkeysphere/transitions/0.23; echo $? ms: setting up Monkeysphere authentication trust core... 141 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578663: libapache2-mod-gnutls: GnuTLSClientVerify require is ignored.
Package: libapache2-mod-gnutls
Version: 0.5.10-1.1
Followup-For: Bug #578663
This bug still exists in current stable and unstable packages. I have
analyzed the problem and found that the authentication hook
(mgs_hook_authz) failed to consider the server's client verify mode,
even if the verify mode was unset in the directory configuration. As a
result, invalid certificates were ignored and clients could connect and
receive data as long as they presented any certificate whatsoever. The
logs show that the certificate was recognized as invalid, but the
request is still served.
[debug] gnutls_hooks.c(1181): [client 127.0.0.1] GnuTLS: A Chain of 1
certificate(s) was provided for validation
[debug] gnutls_hooks.c(1236): [client 127.0.0.1] GnuTLS: Verifying list
of 1 certificate(s)
[info] [client 127.0.0.1] GnuTLS: Could not find Signer for Peer Certificate
[info] [client 127.0.0.1] GnuTLS: Peer Certificate is invalid.
The attached patch applies to the version in stable, commit
5a8a32bbfb8a83fe6358c5c31c443325a7775fc2 in my git repository [1] should
work for the unstable version. Functionally, they are identical, but
apparently indentation changed between the two versions.
Since this bug makes required TLS client auth effectively worthless, I
consider it a security issue.
[1]
https://github.com/airtower-luna/mod_gnutls/commit/5a8a32bbfb8a83fe6358c5c31c443325a7775fc2
-- System Information:
Debian Release: 7.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libapache2-mod-gnutls depends on:
ii libapr-memcache0 0.7.0-1
ii libc6 2.13-38+deb7u7
ii libgnutls26 2.12.20-8+deb7u2
libapache2-mod-gnutls recommends no packages.
libapache2-mod-gnutls suggests no packages.
-- Configuration Files:
/etc/apache2/sites-available/default-tls changed [not included]
-- no debconf information
From 5a8a32bbfb8a83fe6358c5c31c443325a7775fc2 Mon Sep 17 00:00:00 2001
From: Thomas Klute thomas2.kl...@uni-dortmund.de
Date: Thu, 5 Feb 2015 14:48:45 +0100
Subject: [PATCH] TLS Client auth: Check server verify mode if unset for dir
The authentication hook (mgs_hook_authz) failed to consider the server's
client verify mode, even if the verify mode was unset in the directory
configuration. As a result, invalid certificates were ignored and
clients could connect and receive data as long as they presented any
certificate whatsoever. Logs showed that authorization was granted
despite the certificate being invalid (timestamps removed for
readability):
[:debug] [pid 10806:tid 140242057148160] gnutls_hooks.c(1198): [client ::1:40992] GnuTLS: Verifying list of 1 certificate(s) via method 'cartel'
[:info] [pid 10806:tid 140242057148160] [client ::1:40992] GnuTLS: Could not find Signer for Peer Certificate
[:info] [pid 10806:tid 140242057148160] [client ::1:40992] GnuTLS: Peer Certificate is invalid.
[authz_core:debug] [pid 10806:tid 140242057148160] mod_authz_core.c(835): [client ::1:40992] AH01628: authorization result: granted (no directives)
This commit adds a check for undefined verify mode in the directory
configuration and applies the server wide configuration in that case.
---
src/gnutls_hooks.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: mod-gnutls-0.5.10/src/gnutls_hooks.c
===
--- mod-gnutls-0.5.10.orig/src/gnutls_hooks.c 2011-07-08 23:29:46.0 +0200
+++ mod-gnutls-0.5.10/src/gnutls_hooks.c 2015-02-17 15:37:15.173845398 +0100
@@ -909,9 +909,12 @@
return DECLINED;
}
rv = mgs_cert_verify(r, ctxt);
- if (rv != DECLINED
- (rv != HTTP_FORBIDDEN ||
- dc-client_verify_mode == GNUTLS_CERT_REQUIRE)) {
+ if (rv != DECLINED
+ (rv != HTTP_FORBIDDEN
+ || dc-client_verify_mode == GNUTLS_CERT_REQUIRE
+ || (dc-client_verify_mode == -1
+ ctxt-sc-client_verify_mode == GNUTLS_CERT_REQUIRE)))
+ {
return rv;
}
}
Bug#775909: libapache2-mod-gnutls: segfaults with reverse proxy configuration
Package: libapache2-mod-gnutls
Version: 0.6-1.2
Severity: normal
I've configured mod_gnutls to handle client TLS connections for a
reverse proxy with HTTP back end connections. However, requests
handled by the proxy led to segfaults in the handler process and, after
I fixed the first issue, the TLS stack shutting down completely.
I found and fixed three bug in mod_gnutls related to the reverse proxy
configuration:
* NULL pointer dereference in ssl_engine_disable (removing nonexistent
filters) [1]
* ssl_engine_disable disabled TLS globally instead of per connection [2]
* ssl_engine_disable called a global deinit function, leading to
use-after-free segfaults [3]
The bugs exist in the upstream source as well, I have submitted a pull
request [4] on the mod_gnutls-devel mailing list. Until there is an
updated upstream version, I suggest adding the patches in Debian. The
attached patches fit on top of the existing quilt patch in
mod-gnutls_0.6-1.2, in the following order:
proxy-segfault-fix.patch
enable-tls-per-connection.patch
no-deinit-on-proxy-disable.patch
[1]
https://github.com/airtower-luna/mod_gnutls/commit/3d361b8e5d7c4c971d344658728979fe978dc759
[2]
https://github.com/airtower-luna/mod_gnutls/commit/e8acf058857eae21cde2fca0f4e97338075f5f60
[3]
https://github.com/airtower-luna/mod_gnutls/commit/c782c1f12c0ed4d5048eb52fd3ef51037c53f426
[4]
http://lists.gnupg.org/pipermail/mod_gnutls-devel/2015-January/000114.html
(Note: the debsums: changed file error below is a result of my
manually patched version being installed on top of the Debian package
on my development system. I've tested a package built with the patches
on a separate host.)
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libapache2-mod-gnutls depends on:
ii apache2-bin [apache2-api-20120211] 2.4.10-9
ii libapr-memcache00.7.0-3
ii libc6 2.19-13
ii libgnutls-deb0-28 3.3.8-5
ii libmsv1 1.1-1
libapache2-mod-gnutls recommends no packages.
libapache2-mod-gnutls suggests no packages.
-- Configuration Files:
/etc/apache2/mods-available/gnutls.conf changed [not included]
/etc/apache2/sites-available/default-tls.conf changed [not included]
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/lib/apache2/modules/mod_gnutls.so (from
libapache2-mod-gnutls package)
From 3d361b8e5d7c4c971d344658728979fe978dc759 Mon Sep 17 00:00:00 2001
From: Thomas Klute thomas2.kl...@uni-dortmund.de
Date: Tue, 13 Jan 2015 17:04:38 +0100
Subject: [PATCH] Check if filters exist before removing them in
ssl_engine_disable
Trying to remove filters that are NULL leads to a segfault in the worker
thread. Check if c-input_filters and c-output_filters are defined
before removing and remove only if set.
Also, output filters should be removed with the dedicated function.
---
src/mod_gnutls.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/src/mod_gnutls.c
+++ b/src/mod_gnutls.c
@@ -80,8 +80,10 @@
if(sc-enabled == GNUTLS_ENABLED_FALSE) {
return 1;
}
-ap_remove_input_filter(c-input_filters);
-ap_remove_input_filter(c-output_filters);
+if (c-input_filters)
+ap_remove_input_filter(c-input_filters);
+if (c-output_filters)
+ap_remove_output_filter(c-output_filters);
mgs_cleanup_pre_config(c-pool);
sc-enabled = 0;
return 1;
From e8acf058857eae21cde2fca0f4e97338075f5f60 Mon Sep 17 00:00:00 2001
From: Thomas Klute thomas2.kl...@uni-dortmund.de
Date: Tue, 20 Jan 2015 16:30:36 +0100
Subject: [PATCH] Enable/disable TLS per connection in ssl_engine_disable
Previously, ssl_engine_disable set the server wide variable sc-enabled
to GNUTLS_ENABLED_FALSE, leading to mod_gnutls refusing to serve any
connection, including incoming client connections. The general HTTP
handler cannot process raw TLS traffic, so all further requests using
TLS failed.
This commit adds a new element enabled to struct mgs_handle_t, which
is used to disable TLS per connection, making it possible to disable TLS
for proxy back end connections while continuing to serve TLS clients.
---
include/mod_gnutls.h.in | 2 ++
src/gnutls_hooks.c | 50 +++--
src/mod_gnutls.c| 23 +++
3 files changed, 53 insertions(+), 22 deletions(-)
Index: mod-gnutls-0.6/include/mod_gnutls.h.in
===
--- mod-gnutls-0.6.orig/include/mod_gnutls.h.in
+++ mod-gnutls-0.6/include/mod_gnutls.h.in
@@ -170,6 +170,8 @@ typedef struct {
mgs_srvconf_rec *sc;
/* Connection record */
conn_rec* c
Bug#766284: openjdk-8-jre-jamvm: JamVM fails with incorrect ClassBlock padding
Package: openjdk-8-jre-jamvm Version: 8u40~b09-1 Severity: important Any attempt to use JamVM, even just checking the version, results in failure with the following error message: $ java -jamvm -version Error initialising VM (initialiseClassStage2) ClassBlock padding is less than java.lang.Class fields! Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. The previous version 8u40~b04-2 worked without problems. The problem occurs equally with the Sid package (chroot environment) and a locally built backport from the Sid sources to Wheezy, all on amd64. Using the default VM from openjdk-8-jre-headless, Java works as expected. Please let me know if I can help with debugging this further. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/32 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openjdk-8-jre-jamvm depends on: ii libc6 2.19-11 ii openjdk-8-jre-headless 8u40~b09-1 ii zlib1g 1:1.2.8.dfsg-2 openjdk-8-jre-jamvm recommends no packages. openjdk-8-jre-jamvm suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754942: jtreg uses /usr/lib/jvm/default-java/ but does not depend on default-jre-headless
Package: jtreg Version: 4.1-2 Severity: important While trying to compile the experimental openjdk-8 package from source, the jtreg test suite completely failed to run with the error message Cannot determine version of java to run jtreg. I found that the reason was that jtreg expects to find a usable JVM in /usr/lib/jvm/default-java/, unless $JAVA_HOME provides a different path. However, this default value will fail if default-jre-headless is not installed, as may well be the case (e.g., I had manually installed openjdk-7-jdk without any of the default-(jre|jdk)* packages). Without default-jre-headless: $ jtreg -version Cannot determine version of java to run jtreg With default-jre-headless: $ jtreg -version jtreg, version 4.1 src b02 Installed in /usr/share/java/jtreg.jar Running on platform version 1.6.0_31 from /usr/lib/jvm/java-6-openjdk-amd64/jre. Built with 1.6.0_18 on 07/07/2011 03:57 AM. Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Since jtreg can still be used without default-jre-headless by setting JAVA_HOME as appropriate, a Depends relationship is not warranted, but Recommends or Suggests seems reasonable. An alternative approach would be to simply use the first java binary found in $PATH by default, which will usually be whatever the administrator has selected using update-java-alternatives, which also seems reasonable. The problem also exists in sid (jtreg_4.1-b09-1), although the error message is more useful because it directly points at the missing java binary: $ jtreg -version /usr/bin/jtreg: 86: /usr/bin/jtreg: /usr/lib/jvm/default-java/bin/java: not found -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/32 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages jtreg depends on: ii javahelp2 2.0.05.ds1-6 ii libjtharness-java 4.4.0-MR1-Rel-b19-1 ii libxalan2-java 2.7.1-7+deb7u1 jtreg recommends no packages. jtreg suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754942: jtreg uses /usr/lib/jvm/default-java/ but does not depend on default-jre-headless
Hi Emmanuel! Am 16.07.2014 11:15, schrieb Emmanuel Bourg: jtreg doesn't depend on a Java runtime because it can use the JDK being tested to run. This is done by setting the JT_JAVA environment variable (or JAVA_HOME with jtreg 4.1-2 in Wheezy). I know, but the openjdk-8 build doesn't do that (which admittedly is not a failure of jtreg), even on Sid. Remove default-jre-headless and give it a try. ;-) The best we could do would be to add a suggested dependency, but this can't be a hard dependency. As I've written in the report, I know that a hard dependency would not be appropriate. I'm not sure if suggested or recommended is more suitable, but I'm not going to complain either way. :-) Also note that you'll have to backport jtreg 4.1-b09-1 from unstable if you want to run the openjdk-8 tests in Wheezy, jtreg 4.1-2 doesn't work. Actually, it does. I haven't checked if some of the reported failures and errors are due to the older version, but the test suite runs on my wheezy system – as long as default-jre-headless is installed. Kind regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742864: Build without nostrip fails on weezy, another try for debian/control generation
Am 08.07.2014 14:13, schrieb Emmanuel Bourg: Le 08/07/2014 11:47, Thomas Klute a écrit : Compiling with the same build system (plus freshly generated debian/control) in a sid chroot works just fine. I'm not sure if this should be considered important for OpenJDK 8 packaging (looks more like a binutils bug to me). Any suggestions on how to handle this? Could this be related to Lintian emitting a debug-file-with-no-debug-symbols warning about these files? Possibly. Since the wheezy build fails in the dh_strip stage it doesn't get to lintian, but in the sid build log I see the linitan warnings, and during dh_strip there are many debuglink section already exists from objcopy. My current guess is that the OpenJDK build system already does something about the debug symbols, but I haven't looked into it yet. I'm not sure if it makes sense to with the alternative packaging going on. I've also taken another look at the debian/control situation. My previous suggestion to remove it from the repository could create the problem that it could not easily be generated from a fresh repository clone, because the code in debian/rules expected the file to be present (though it could be empty). A patch available on my Github repository [1] fixes that. Good idea, I merged it. I also got caught by this issue once. Thanks! I guess I'll have to see how that Launchpad repository develops. Will this bug continue to be updated? Kind regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742864: Build without nostrip fails on weezy, another try for debian/control generation
Compiling on wheezy fails unless nostrip is set in DEB_BUILD_OPTIONS: dh_strip -s -Nopenjdk-8-8-jre-cacao -Nopenjdk-8-8-jre-jamvm \ -Xlibjvm.so --dbg-package=openjdk-8-dbg objcopy:debian/openjdk-8-jdk/usr/lib/jvm/java-8-openjdk-amd64/bin/stEZfrnA: cannot create debug link section `debian/openjdk-8-dbg/usr/lib/debug/.build-id/27/b090842e021ced5bdfd3a9aba73af6b5afc44e.debug': Invalid operation dh_strip: objcopy --add-gnu-debuglink debian/openjdk-8-dbg/usr/lib/debug/.build-id/27/b090842e021ced5bdfd3a9aba73af6b5afc44e.debug debian/openjdk-8-jdk/usr/lib/jvm/java-8-openjdk-amd64/bin/javac returned exit code 1 make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Compiling with the same build system (plus freshly generated debian/control) in a sid chroot works just fine. I'm not sure if this should be considered important for OpenJDK 8 packaging (looks more like a binutils bug to me). Any suggestions on how to handle this? By the way, is the double -8 in the cacao and jamvm package names intentional? It seems strange to me. I've also taken another look at the debian/control situation. My previous suggestion to remove it from the repository could create the problem that it could not easily be generated from a fresh repository clone, because the code in debian/rules expected the file to be present (though it could be empty). A patch available on my Github repository [1] fixes that. Kind regards, Thomas [1] https://github.com/airtower-luna/openjdk-8-debpkg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742864: Update to jdk8u20-b18
Am 18.06.2014 14:55, schrieb Emmanuel Bourg: Even if removing the generated files could avoid mistakes like updating the control file but not its template, I lean toward keeping them for the convenience. Checking out the package and not seeing debian/control could also be confusing. I disagree. Having a generated file in the source repository is surprising and thereby confusing. I assumed I had to change the g++ dependency precisely for that reason. Sure, I would have been surprised if the checkout had not contained a debian/control file, but then I would have checked what's going on and subsequently understood. Equally, convenience is actually a point against keeping a generated control file in the repository: People will need to regenerate the file for their build systems and then will have local changes that cannot be merged upstream. This is generally annoying, and especially with Git operations that require a clean tree. Of course, the debian/control file would belong in a source package for a specific version. In my opinion the clean solution is to ignore generated files for the VCS tree, and if that requires many preparation steps before build, script them. Kind regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742864: Update to jdk8u20-b18
Am 17.06.2014 22:08, schrieb Emmanuel Bourg: Le 17/06/2014 20:09, Thomas Klute a écrit : * g++-4.9 was a hardcoded build dependency, but is not available on stable. I could build the package with g++-4.7 from Wheezy, so I've changed the dependency to g++ = 4.7. Actually debian/control is generated from a template (debian/templates/control.in) and has to be refreshed for your distribution. You do that by touching the template and running './debian/rules debian/control'. This is a bit tricky, I'll document it in debian/README.source. OK, I didn't know about that. I that case I suggest removing debian/control from the repository after that step is documented. I've rebased my master branch on your repository and added a patch to that effect, including documentation. [1] * I filed bug #751873, which was promptly fixed (many thanks to the QA team!), so we can now use http://qa.debian.org/cgi-bin/fakeupstream.cgi to get the latest upstream sources. I believe there is a new tag every week or so, I don't think we really want to push updates that fast. Currently the package tracks the OpenJDK builds used by Oracle to release the official version of Java. This is done by parsing the documentation download page [1], I wrote a small PHP page [2] that performs this task for Java 7 and 8. Good point. I'll keep the jdk8u20-b18 branch around and might occasionally rebase it to keep track of master changes. ;-) Thomas [1] https://github.com/airtower-luna/openjdk-8-debpkg.git master -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751873: fakeupstream.cgi rejects hg repository URLs containing numbers
Package: qa.debian.org Severity: normal While trying to check for the latest version in the OpenJDK 8 upstream repository, I found that fakeupstream.cgi would not accept hg repository URLs containing numbers before the project name part (after the last slash in the URL). Upstream repository URL: http://hg.openjdk.java.net/jdk8u/jdk8u/ HTTP request: http://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=vcs/hg/http://hg.openjdk.java.net/jdk8u/jdk8u Result: no data found for given parameter value(s) Expected result: jdk8u20-b18 I believe the bug can be fixed by changing the definition of $hg_repository_re from the current my $hg_repository_re = '[a-z\.\-:/]+'; to my $hg_repository_re = '[a-z0-9\.\-:/]+'; It may be useful to allow capital letters as well, to provide for directory names containing them. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742864: Update to jdk8u20-b18
Hi everyone, I've cloned Emmanuel's repository and worked with it on Wheezy (amd64). Results so far: * I've updated the build system to work with the newest upstream version (jdk8u29-b18). Refreshing the patches was fairly straightforward, but I'd be great if someone with more knowledge of OpenJDK internals could review them. * g++-4.9 was a hardcoded build dependency, but is not available on stable. I could build the package with g++-4.7 from Wheezy, so I've changed the dependency to g++ = 4.7. * The package builds successfully if (and only if) nostrip is set in DEB_BUILD_OPTIONS. I haven't done extensive tests yet, but the result looks good so far. I have not tried building or running alternative JVMs. * I filed bug #751873, which was promptly fixed (many thanks to the QA team!), so we can now use http://qa.debian.org/cgi-bin/fakeupstream.cgi to get the latest upstream sources. * I've also changed the top directory in the archive created by debian/orig-tar.sh to match the package name. That avoids some confusion, because for me the sources initially didn't show up where they should have. You can find my patches on GitHub: Webinterface: https://github.com/airtower-luna/openjdk-8-debpkg/tree/jdk8u20-b18 Clone/pull URL: https://github.com/airtower-luna/openjdk-8-debpkg.git Branch: jdk8u20-b18 Kind regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
