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
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
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 t
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
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.
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.
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
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
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
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
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
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.
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
:
* 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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
29 matches
Mail list logo
