Bug#888426: certtool has year 2k38 problem, giving problems for scripts that generate 20 year certs today

No good solution to that, but given that we depend on glibc's time_t, we are tied to it solving the issue. The issue is tracked at: https://gitlab.com/gnutls/gnutls/issues/370 On Sun, Feb 18, 2018 at 2:12 PM Andreas Metzler wrote: > Control: found -1 3.6.2-1 > Control: found

Bug#857675: libidn2-0 FTCBFS: runs host arch code during build (gentr46map, help2man)

On Tue, 2017-03-14 at 20:12 +0100, Helmut Grohne wrote: > > > > Also, using -lunistring directly doesn't work out on systems > > > > without > > > > libunistring. I guess it needs libtool and $(LTLIBUNISTRING) + > > > > ../gl/libgnu.la to do it portable. I can't test that for the > > > > Debian >

Bug#844658: stretch GIT broken

I think few months ago a similar issue was reported. The culprit was librtmp or some other lib linking to a version of nettle with unversioned symbols. That resulted to a symbol clash which caused that issue. The solution was to update that lib. On 18 November 2016 02:50:14 CET, Daniel Kahn

Bug#839937: GnuTLS error (at worker-vpn.c:585): Error in the system's randomness device.

Hi, You can work-around the issue by setting isolate-workers=false. The problem is that the getrandom() system call is not included in the whitelisted seccomp filter. The "right" solution is to either apply patch [0] or move to 0.11.5. regards, Nikos [0].

Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets

Thanks for the update, your case was really challenging my computing knowledge :) However, out of curiosity how does librtmp comes into play here? It doesn't seem to be a dependency (direct at least) or either curl or git. On Fri, Sep 23, 2016 at 3:01 PM, marcelomen...@gmail.com

Bug#813598: [gnutls-devel] FTBFS[kfreebsd]: tests/mini-loss-time race

On Sat, Mar 5, 2016 at 7:57 PM, Steven Chamberlain wrote: > Hi Andreas, > > In a future upload please could you try the attached diff, which is a > much simpler way I found to get the testsuite output into the build log. > Since more than one set of tests runs in parallel, we

Bug#813598: [gnutls-devel] FTBFS[kfreebsd]: tests/mini-loss-time race

On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote: > Control: reopen 813598 > > On 2016-02-15 Nikos Mavrogiannopoulos <n...@gnutls.org> wrote: > > On Sun, Feb 14, 2016 at 3:14 PM, Andreas Metzler <ametz...@bebt.de> > > wrote: > > > this is http:/

Bug#815843: ocserv: Segfault when loading ocserv

On Thu, Feb 25, 2016 at 1:52 AM, Tony Zhou wrote: > Package: ocserv > Version: 0.10.11-2 > Severity: important > > Dear Maintainer, > I have just upgraded my ocserv from 0.10.11-1 to 0.10.11-2 in order to > gain RADIUS support. However, when I try to start ocserv it throws a

Bug#813690: ocserv: missing RADIUS support

Freeradius client 1.1.6 is not supported by ocserv. You'll need at least version 1.1.7. On 5 February 2016 22:11:07 CET, Aron Xu wrote: >radcli in Debian does not have pkgconfig file included, I've filed a >bug (#813842), and added a patch to ocserv to make freeradius

Bug#813690: ocserv: missing RADIUS support

Note that libradcli can also be used. It is available in debian testing. On Thu, Feb 4, 2016 at 12:55 PM, Mantas Mikulėnas wrote: > Package: ocserv > Version: 0.10.10-1 > Severity: wishlist > > Dear Maintainer, > > Could you include RADIUS authentication support in ocserv? > >

Bug#809847: ipcalc doesn't support IPv6

Package: ipcalc Version: 0.41-4 Severity: normal Tags: ipv6 Dear Maintainer, The ipcalc tool included in Debian works fine for IPv4 addresses but has no support whatsoever for IPv6 addresses. The output of: $ ipcalc ::1 INVALID ADDRESS: ::1 Address: 192.168.1.1

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

On Tue, 2015-11-17 at 14:40 +0100, Luca Bruno wrote: > > I really don't know. You can pretend somebody jumped on me asking > > whether I was part of Debian and mentioned this issue that has been > > tagged wontfix. That wouldn't be very far from what happened. ;) > > > > I can add nettlifying

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

On Sun, 2015-06-28 at 17:18 -0700, Bruce Korb wrote: On 06/28/15 04:26, Nikos Mavrogiannopoulos wrote: http://autogen.sourceforge.net/data/autogen-5.18.5pre20.tar.xz That version works for me. OK, then, I've now unwound all the Guile wrapper macro removals from top of tree. http

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

On Sat, 2015-06-27 at 12:05 -0700, Bruce Korb wrote: On 06/06/15 10:10, Andreas Metzler wrote: FWIW, it also works for me on sid (both amd64 and i386). FWIW, it appears to be related to the disablement of Guile 1.6. I may have to unwind that until I can figure out how Guile 1.6 support

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

On Sat, 2015-06-06 at 16:18 -0700, Bruce Korb wrote: In that log, I find: Compiling '[ -~]' with bits 0x1 === compiled as extended RE CASE no match: `c' MATCH_FULL vs. `[ -~]' I think there is a RE library problem. The code is as follows: /* * On the first call for this

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

On Sun, 2015-06-07 at 14:09 -0700, Bruce Korb wrote: Nikos, I am stumped here. Oh, wait -- what version of Guile? 2.0.[0123] are broken. I've stopped choking on newer versions of 2.0.x that I've not seen, but history says that problems do sneak in in micro releases. (Way back whenever, I

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

On Fri, 2015-06-05 at 18:19 -0700, Bruce Korb wrote: export AUTOGEN_TRACE=everything AUTOGEN_TRACE_OUT='/tmp/ag-log.txt' Log is attached. ===AutoGen starts - 13485: autogen 'ocpasswd-args.def' Guile Library Version 2.0.11 eval from file agInit.c line 80: (debug-enable 'backtrace) Definition

Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works

= [username]; detail = This program is openconnect password (ocpasswd) utility. It allows the generation and handling of a 'plain' password file used by ocserv.; copyright = { date = 2013, 2014; owner = Nikos Mavrogiannopoulos; author = Nikos Mavrogiannopoulos; eaddr

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

On Tue, 2015-03-24 at 18:52 -0400, Robert Edmonds wrote: 4. Design and implement a D-Bus interface for securely retrieving DNSSEC-validated records that have been validated *on the system*. Patch daemons (Unbound, BIND, et al) to answer to this interface. Patch clients (libdane,

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

On Wed, 2015-03-25 at 14:00 -0400, Robert Edmonds wrote: The D-BUS interface is not really necessary because DNS provides already this functionality. What we need is a convention for applications in the system to discover the local trusted (for dnssec) nameservers. What do you mean by

Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

On Wed, 2015-03-25 at 18:19 -0400, Robert Edmonds wrote: How does a server on a different VM count as local, even if running on the same chassis? (Also, you do exclude across a physical LAN/WLAN/etc. from your definition of local, right? Just making sure.) You could run multiple validating

Bug#778965: libfreeradius-client2: freeradius-client 1.1.7 is available

Package: libfreeradius-client2 Version: 1.1.6-7 Severity: wishlist Dear Maintainer, The upstream version 1.1.7 solves many issues of this package seen in http://freeradius.org/freeradius-client/ That includes several crash fixes, memory leaks as well as the library is now GPL-license

Bug#732052: libfreeradius-client2: rc_read_config crashes if radius_deadtime is not set

Package: libfreeradius-client2 Version: 1.1.6-6 Severity: important libfreeradius-client introduced a radius_deadtime configuration option which was not present in libradiusclient-ng. If this option is not set, the rc_read_config method crashes with a SEGFAULT. This should be solved in

Bug#760476: concerning 760476

Andreas Metzler wrote: On 2014-10-28 Nikos Mavrogiannopoulos n...@gnutls.org wrote: I think that the issue should be reassigned to cups and it should be modified to close the known file descriptors (stdin/stdout/stderr) instead of all open descriptors. Thanks for the explanation. re

Bug#760476: concerning 760476

On Wed, Oct 29, 2014 at 1:02 PM, Didier 'OdyX' Raboud o...@debian.org wrote: Hi Nikos, hi Andreas, On Tue, 28 Oct 2014 19:11:28 +0100 Andreas Metzler wrote: On 2014-10-28 Nikos Mavrogiannopoulos n...@gnutls.org wrote: I think that the issue should be reassigned to cups and it should

Bug#760476: gnutls28 3.3.8-3

in start phase. Bests Christophe On 21/10/2014 22:50, Nikos Mavrogiannopoulos wrote: On Tue, 21 Oct 2014 11:58:21 +0200 =?UTF-8?B?Q2hyaXN0b3BoZSBTw6lndWk=?= read(3, 0x7fff63334f20, 16) = -1 EINVAL (Invalid argument) write(2, gnutls[2]: Failed to read /dev/u..., 57) = 57 write(2, gnutls

Bug#760476: gnutls28 3.3.8-3

On Wed, Oct 22, 2014 at 10:39 AM, Nikos Mavrogiannopoulos n.mavrogiannopou...@gmail.com wrote: Thanks, it seems I am correct. Cups closes all open descriptors. I don't know what I can do in gnutls to fix that. That looks like that should be addressed in cups. The best that I can think

Bug#760476: gnutls28 3.3.8-3

On Tue, 21 Oct 2014 11:58:21 +0200 =?UTF-8?B?Q2hyaXN0b3BoZSBTw6lndWk=?= read(3, 0x7fff63334f20, 16) = -1 EINVAL (Invalid argument) write(2, gnutls[2]: Failed to read /dev/u..., 57) = 57 write(2, gnutls[3]: ASSERT: rnd.c:142\n, 29) = 29 write(2, gnutls[3]: ASSERT: rnd.c:329\n, 29)

Bug#760476: fixed in gnutls28 3.3.8-3

On Sat, 11 Oct 2014 15:20:45 + Andreas Metzler ametz...@debian.org wrote: Source: gnutls28 Source-Version: 3.3.8-3 We believe that the bug you reported is fixed in the latest version of gnutls28, which is due to be installed in the Debian FTP archive. Sorry, I misread the strace, and

Bug#760476: cups - crashes after reading tls stuff

On Sun, 21 Sep 2014 13:50:36 +0200 Andreas Metzler ametz...@bebt.de wrote: On 2014-09-16 Didier 'OdyX' Raboud o...@debian.org wrote: [...] Le jeudi, 4 septembre 2014, 13.30:19 Bastian Blank a écrit : cups aborts at random times after reading certificates and keys: (…) As cups disables

Bug#750094: Misleading warning

On Wed, Jun 4, 2014 at 5:50 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 06/04/2014 03:30 AM, Nikos Mavrogiannopoulos wrote: I agree with your points. In fact the current warning was setup to cover (0). There could be another warning for (1), but gnutls-cli prints the size

Bug#750094: Misleading warning

On Tue, Jun 3, 2014 at 12:33 AM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: over on https://bugs.debian.org/750094, This warning is printed before any TLS negotiation happens, so it does not reflect the parameters that were actually negotiated. The wording should be changed in order to

Bug#745055: scute cannot work properly on a Desktop

On Fri, Apr 18, 2014 at 1:14 AM, NIIBE Yutaka gni...@fsij.org wrote: Hello, Thank you for your report. On 2014-04-17 at 17:56 +0200, Nikos Mavrogiannopoulos wrote: scute needs gpg-agent, but in a debian desktop system this is typically overriden by gnome keyring. Since the gnome keyring

Bug#745055: scute cannot work properly on a Desktop

On Fri, Apr 18, 2014 at 9:46 AM, NIIBE Yutaka gni...@fsij.org wrote: On 2014-04-18 at 09:09 +0200, Nikos Mavrogiannopoulos wrote: No matter who's bug it is, it is a usability (or unusability) issue of scute. [...] That's a nice hack to make things work temporarily, but in the end

Bug#745051: nuttcp crashes if /proc/sys/net/ipv4/tcp_adv_win_scale does not exist

Package: nuttcp Version: 6.1.2-4 Severity: important Tags: upstream Dear Maintainer, If nuttcp (server) is run under the docker debian image where /proc/sys/net/ipv4/tcp_adv_win_scale does not exist, it crashes. The last lines of strace are shown below: getsockopt(6, SOL_SOCKET, SO_RCVBUF,

Bug#745055: scute cannot work properly on a Desktop

Package: scute Version: 1.4.0-4 Severity: important Tags: upstream Dear Maintainer, scute needs gpg-agent, but in a debian desktop system this is typically overriden by gnome keyring. Since the gnome keyring replacement doesn't have the same features, it renders scute unusable. How to debug

Bug#741970: vlc-nox: vlsub plugin fails to run

Package: vlc-nox Version: 2.1.2-2+b2 Severity: normal Dear Maintainer, The vlsub functionality is not working. Trying to click on the View-Vlsub menu brings: [0x7f47f4217e88] lua generic debug: Activating extension 'VLsub 0.9.10' [0x7f47f4217e88] lua generic debug: [VLsub] Welcome

Bug#729596: wml: there is a new maintainer of wml

Package: wml Version: 2.0.12ds1-6+b1 Severity: wishlist Tags: upstream Dear Maintainer, There is an updated version of the package at: http://www.shlomifish.org/open-source/projects/website-meta-language/ His newest release is at 2013-05-29 [0]. [0].

Bug#728817: autogen: libopts-xx.x.x.tar.gz is not included

Package: autogen Version: 1:5.18-2 Severity: important Hello, Autogen gives the option to include a self-contained version of it into programs. This is done by retrieving the file shown with the following command: $ autoopts-config libsrc /usr/share/autogen/libopts-40.0.15.tar.gz (see

Bug#695798: webalizer: Matching referrers and sites for grouping is very primitive

On 12/12/2012 09:23 PM, Julien Viard de Galbert wrote: On Wed, Dec 12, 2012 at 08:38:01PM +0100, Nikos Mavrogiannopoulos wrote: Package: webalizer Version: 2.23.05-1 Severity: wishlist Tags: upstream Hello, Hello, Trying to group the google sites with webalizer is hell as its

Bug#695798: webalizer: Matching referrers and sites for grouping is very primitive

Package: webalizer Version: 2.23.05-1 Severity: wishlist Tags: upstream Hello, Trying to group the google sites with webalizer is hell as its matching algorithm is primitive. For example: www.google.co.uk, www.google.com and www.google.ie cannot be catched by using something like www.google.*

Bug#665766: libgnutls26: should prefer TLS 1.2/ECC cipher suites

Now that OpenSSL 1.0.1 is in sid, mutt can now talk to my dovecot IMAP server using TLS 1.2 [0]. However, I was disappointed to discover that mutt (which does not have knobs for cipher suites) still uses DHE-RSA/AES-128-CBC/SHA1. Hello, libgnutls26 doesn't support elliptic curves or

Bug#664454: [openssl] debian openssl's behavior is different than original

Package: openssl Version: 1.0.0h-1 Severity: important --- Please enter the report below this line. --- The debian distributed openssl negotiated SSL 3.0 if TLS 1.2 is offered while the original openssl 1.0.0h negotiates TLS 1.0 if offered the same client hello. This is a really weird

Bug#664454: why it is important

And why I think this bug is important, is because the debian behavior causes incompatibility problems with gnutls (and possibly others). More information at: http://rt.openssl.org/Ticket/Display.html?id=2765user=guestpass=guest -- To UNSUBSCRIBE, email to

Bug#642524: libssl1.0.0: crash when using DTLS1

Package: libssl1.0.0 Version: 1.0.0e-2 Severity: important Tags: upstream Dear Maintainer, * What led up to the situation? Trying to establish a DTLS server and connecting with a client makes the server crash. I used the openssl utility for that. $ openssl s_server -accept -keyform pem

Bug#640812: libopencryptoki0: libopencryptoki paths for modules are incorrect

Package: libopencryptoki0 Version: 2.3.1+dfsg-2 Severity: important If I try to open libopencryptoki0 pkcs11 module with a pkcs11 application (e.g. p11tool of gnutls) I get: Sep 7 17:09:30 nomad openCryptokiModule[5547]: Logging enabled 1 enabled Sep 7 17:09:30 nomad openCryptokiModule[5547]:

Bug#639818: gcc-4.6: valgrind reports Invalid read of size 4 in legal code

Package: gcc-4.6 Version: 4.6.1-4 Severity: important Tags: upstream The attached code is being miscompiled with gcc-4.6 (works perfectly with 4.4 or 4.5). The error can be seen if valgrind is run on the resulting executable as: ==21804== Invalid read of size 4 ==21804==at 0x400437: main

Bug#638595: WWWOFFLE HTTPS now unusable

the issue? regards, Nikos From c4a8f333fc118ac454906e6ef056789b4069e4d2 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos n...@gnutls.org Date: Sat, 27 Aug 2011 20:20:43 +0200 Subject: [PATCH] gnutls_certificate_set_x509_key() and gnutls_certificate_set_openpgp_key() operate as in gnutls

Bug#623001: libgnutls26: fails to handshake on a number of sites (firefox works)

On 04/17/2011 09:45 AM, Simon Josefsson wrote: thank you for taking the time to test the packages in experimental. I can reproduce the bug. For clarification it is not caused by libgcrypt11 from experimental, libgnutls26 2.12.2-1 with stable libgcrypt11 also fails. Attached verbose log is

Bug#623001: libgnutls26: fails to handshake on a number of sites (firefox works)

On 04/16/2011 05:54 PM, Andreas Metzler wrote: thank you for taking the time to test the packages in experimental. I can reproduce the bug. For clarification it is not caused by libgcrypt11 from experimental, libgnutls26 2.12.2-1 with stable libgcrypt11 also fails. Attached verbose log is

Bug#619746: gnutls-bin: [certtool] include useless data when creating a CSR

On Wed, Mar 30, 2011 at 2:01 PM, Luca Capello l...@pca.it wrote:  I don't quite understand what is the issue here. What is the information contained in the CRQ that you consider useless? As I wrote, the new CSR (BTW, what does CRQ mean?) contains data other than the request itself, e.g. the

Bug#619746: gnutls-bin: [certtool] include useless data when creating a CSR

On 03/26/2011 06:57 PM, Luca Capello wrote: Package: gnutls-bin Version: 2.10.5-1 Severity: important Hi there! I was creating a Certificate Signing Request with certtool and then I discovered that the output file contains more than the CSR, even worse it contains the password asked

Bug#616035: [libgnutls26] Breaks OpenLDAP with message: TLS: peer cert untrusted or revoked (0x402)

2011/3/8 Vedran Furač vedran.fu...@gmail.com:   - subject `blahblah', issuer `blahblah', RSA key 1024 bits, signed using RSA-SHA, activated `2006-07-22 12:59:58 UTC', expires `2009-07-21 12:59:58 UTC', SHA-1 fingerprint `ec5248b3194be9fda5639b59458962bc9bee32cc' Looks like one of certs had

Bug#616035: [libgnutls26] Breaks OpenLDAP with message: TLS: peer cert untrusted or revoked (0x402)

On 03/10/2011 04:14 AM, Vedran Furač wrote: - subject `blahblah', issuer `blahblah', RSA key 1024 bits, signed using RSA-SHA, activated `2006-07-22 12:59:58 UTC', expires `2009-07-21 12:59:58 UTC', SHA-1 fingerprint `ec5248b3194be9fda5639b59458962bc9bee32cc' Looks like one of certs had

Bug#616035: [libgnutls26] Breaks OpenLDAP with message: TLS: peer cert untrusted

Hello, Could you send the certificate in question (not the private key, just the certificate), or if not possible provide a -d2 output? regards, Nikos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#616035: [libgnutls26] Breaks OpenLDAP with message: TLS: peer cert untrusted or revoked (0x402)

btw. the 0x402 error code indicates an expired certificate. regards, Nikos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#464625: please support OpenSSL-compatible ciphher nammes

On Fri, Feb 4, 2011 at 9:09 AM, Simon Josefsson si...@josefsson.org wrote: gnutls-cli(1).  Looking at the source, RC4 is defined in SECURE256, and due to major weaknesses in its key scheduling (which can be used very effectively against e.g. WEP), I would absolutely not want to use it if any

Bug#464625: please support OpenSSL-compatible ciphher nammes

On Thu, Feb 3, 2011 at 11:15 PM, brian m. carlson sand...@crustytoothpaste.net wrote: I am a system administrator and programmer and I do know what each ciphersuite does, offers, and costs.  I've implemented cryptographic algorithms, including the second-fastest non-assembly implementation of

Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)

On 01/20/2011 05:58 PM, Václav Ovsík wrote: On Thu, Jan 20, 2011 at 05:22:12PM +0100, Nikos Mavrogiannopoulos wrote: Hello, Indeed I'm mistaken. The reported problem is about order of certificates with the same subject DN in the repository during verifying certificate. I have server

Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)

On 01/20/2011 05:01 PM, Václav Ovsík wrote: Hi Nikos, On Mon, Dec 20, 2010 at 05:03:28PM +0100, Nikos Mavrogiannopoulos wrote: You cannot reorder certificates on will. For TLS/SSL the certificates have to be ordered (from RFC5246): This is a sequence (chain) of certificates. The sender's

Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)

You cannot reorder certificates on will. For TLS/SSL the certificates have to be ordered (from RFC5246): This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Gnutls is strict with

Bug#579631: cr-lf causes same problem

On 09/10/2010 01:16 AM, Scott Wheeler wrote: I see the same error message. In my case it turned out to be CR-LF line endings introduced by cut and paste of a certificate in an email client on a Mac into vi on an Ubuntu box, so arguably it's my fault. However OpenSSL does handle this, and if

Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)

Daniel Kahn Gillmor wrote: Thanks for the feedback, Simon. On 02/19/2009 05:02 PM, Simon Josefsson wrote: Daniel Kahn Gillmor d...@fifthhorseman.net writes: 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set This is essentially the (untested) patch I proposed earlier. (this

Bug#511573: [Modules] mod_gnutls: Failed to load Client CA File ... The given memory buffer is too short to hold parameters.

Jack Bates wrote: Sander Marechal reports that he cannot use the CA certificates distributed in the Debian ca-certificates package with mod_gnutls: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511573 I confirmed that this behaviour is the same in mod_gnutls trunk revision 403: Hello,

Bug#511573: [Modules] mod_gnutls: Failed to load Client CA File ... The given memory buffer is too short to hold parameters.

Jack Bates wrote: Sander Marechal reports that he cannot use the CA certificates distributed in the Debian ca-certificates package with mod_gnutls: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511573 I confirmed that this behaviour is the same in mod_gnutls trunk revision 403: Thanks

Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Joe Orton wrote: I've tried this using a git build of GnuTLS, gnutls-cli and a test httpd/mod_ssl server configured for per-location client cert auth (i.e. it requests a second handshake after the GET request is recevied), and it does fail, so I think this is indeed a GnuTLS bug in the

Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Joe Orton wrote: On Sat, Nov 22, 2008 at 01:54:43PM -0500, Daniel Kahn Gillmor wrote: On Sat 2008-11-22 03:05:03 -0500, Joe Orton wrote: [0 [EMAIL PROTECTED] cdtemp.oNUHIC]$ svn co https://foo.example.org/svn/monkey/trunk/gorilla svn: OPTIONS of

Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

: On Fri, Nov 21, 2008 at 09:24:02AM +0200, Nikos Mavrogiannopoulos wrote: For neon to solve this, it has to perform a handshake after the rehandshake request has been required. Ah, I didn't realise that - OpenSSL will automatically rehandshake whenever requested by the server. So to provide

Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Daniel Kahn Gillmor wrote: On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote: Hello, this does not seem to be a gnutls error. The server merely asks for renegotiation, gnutls-cli ignores it (legal behavior) and server does not like it thus sends a fatal alert. Do you think

Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Daniel Kahn Gillmor wrote: OK, i'm now sure that debian #480041 is a gnutls problem, and not just due to something wacky in libneon (though there may be libneon bits as well). Here's a way to duplicate the problem without using libneon. [...] - Simple Client Mode: *** Non fatal error:

Bug#505279: libgnutls26: segfault in _gnutls_x509_crt_get_raw_dn2

On Wed, Nov 12, 2008 at 12:15 PM, Simon Josefsson [EMAIL PROTECTED] wrote: You mean just removing this code snippet instead of moving it? /* Check if the last certificate in the path is self signed. * In that case ignore it (a certificate is trusted only if it * leads to a trusted

Bug#503833: Unparseable PKCS cert

On Fri, Nov 7, 2008 at 10:16 AM, Simon Josefsson [EMAIL PROTECTED] wrote: I just realized: doesn't Nikos' patch actually do two separate things? 1) Add the BER stuff needed to support the PKCS#12 blob 2) Optimize tree generation by using the small_value field. It is the 2) that causes the

Bug#503833: Unparseable PKCS cert

dann frazier wrote: Thanks Nikos. Our Debian maintainer has applied your fix and uploaded a package to our experimental repository. However, he does have some concerns about ABI compatibility that may make it harder for us to get it into the upcoming release:

Bug#466477: SSLv2 ldap servers

$ gnutls-cli-debug -p 636 bluepages.ibm.com Resolving 'bluepages.ibm.com'... Connecting to '9.17.186.253:636'... Checking for TLS 1.1 support... no (1) Checking fallback from TLS 1.1 to... failed (2) By the output of 1,2 I'd say that this server does not support 1.1 and fails to fallback to

Bug#464625: please support OpenSSL-compatible ciphher nammes

I think that both the openssl and the gnutls cipher name constructs are unnecessarily complex: there are maybe max 100 registered TLS ciphersuites. A tiny portion of those are useful in normal situations. I think it would be simpler if the administrator simply specified exactly which TLS

Bug#396867: gnutls-bin: does not seem to properly handle rehandshake request

I have one internal https server (running IIS on Windows Server 2003) which seems to request a rehandshake after the http request was transmitted. This seems to badly confuse gnutls-cli: It is quite late for a reply but anyway. It could be a server issue. A debug input from wireshark or

Bug#481132: [Pkg-gnutls-maint] Bug#481132: libgnutls26: flags key usage error where OpenSSL does not

I've figured out what the problem is. If I don't disable kEDH in sendmail's config, it fails, but if I do disable it, it works. My IMAP server also has kEDH disabled, and so it also works. Apparently OpenSSL doesn't try to use kEDH, and so it doesn't fail. GnuTLS should implement the same

Bug#426013: Problems with specific certificate/key (Debian Bug #426013)

All, This is now working as desired. I am using exactly the same configuration as I detailed in my first post (it was commented, I uncommented it.) MAIN_TLS_ENABLE = yes MAIN_TLS_PRIVATEKEY = /etc/exim4/certificates/newserver_co_uk.pem MAIN_TLS_CERTIFICATE =

Bug#426013: Problems with specific certificate/key (Debian Bug #426013)

Mark Adams wrote: On Jan 3, 2008 2:36 AM, Marc Haber [EMAIL PROTECTED] wrote: I'm using gnutls 2.0.4 at present (this is the current debian testing version). Is it possibly a known issue with this version? I can not install the new version at present, as this is a production server. I will be

Bug#316522: Interoperability issue with The Bat (Debian Bug #316522)

On Friday 04 January 2008, Simon Josefsson wrote: Simon Josefsson [EMAIL PROTECTED] writes: It might be possible (judging from https://www.ritlabs.com/bt/view.php?id=5785) that The Bat by default refuses to talk TLS to a server presenting a self-signed certificate. I also note that it

Bug#426013: Problems with specific certificate/key (Debian Bug #426013)

On Jan 3, 2008 2:36 AM, Marc Haber [EMAIL PROTECTED] wrote: Hi, Simon writes: Appears to be an unreprodicible problem with a specific certificate/key which the user cannot reveal. Another certificate/key from the same CA works fine. Theory: could it be CRLF problems? Other non-ASCII

Bug#448775: Uses too much entropy (Debian Bug #343085)

On Jan 3, 2008 2:32 AM, Marc Haber [EMAIL PROTECTED] wrote: Hi, Debian Bug #343085, http://bugs.debian.org/343085 This is an example bug for the entropy issue which seems to be the most pressing issue with Exim4 and GnuTLS at the moment. Let me give you a little background: Exim4's

Bug#448775: Uses too much entropy (Debian Bug #343085)

A workaround might be to use the libgcrypt's random number process feature which uses a single server process to feed other processes with entropy (I've never worked with it so I don't know if it can be used in that case). This might solve this issue. Disagree. * /dev/(u)random is more

Bug#327845: compression issue?

This must be related with the TLS compression issue fixed in gnutls 2.0.4. When the data were expanded (e.g when compressing pictures) there were some cases were gnutls rejected legitimate packets. This is now fixed in 2.0.4 and later versions. regards, Nikos -- To UNSUBSCRIBE, email to

Bug#390712: gnutls

OpenSSL does not support random padding. They handle TLS 1.0 padding exactly as SSL 3.0, thus this issue does not occur there. I believe that random padding is important feature that avoids statistical attacks on the data, so it's enabled by default in gnutls. On 11/5/07, Simon Josefsson [EMAIL

Bug#338319: proposed solutions

On Friday 26 October 2007, Florian Weimer wrote: * Nikos Mavrogiannopoulos: 2. Generate the parameters in a non-blocking way using /dev/urandom. (sol2.patch) Huh? At least at one point in the past, GNUTLS used /dev/urandom for DH parameters. Has this changed? Indeed. When I added

Bug#402861: gnutls

On Monday 22 October 2007, Nikos Mavrogiannopoulos wrote: On Sun, Aug 19, 2007 at 08:38:42AM +0200, Andreas Metzler wrote: Something that might help in debugging without much fuss, would be to test handshake by enabling other ciphersuites. That would be for gnutls-serv to only enable

Bug#327625: gnutls

gnutls_record_recv: A TLS packet with unexpected length was received. --- ABOR Closing aborted data socket Closing control socket Fatal error: gnutls_record_recv: A TLS packet with unexpected length was received. I doesn't say when this happens. If this is at the point of the

Bug#438137: gnutls

On Sun, Aug 19, 2007 at 08:38:42AM +0200, Andreas Metzler wrote: Something that might help in debugging without much fuss, would be to test handshake by enabling other ciphersuites. That would be for gnutls-serv to only enable: a. key exchage: DHE-RSA cipher: 3DES b. key exchange:

Bug#438137: gnutls

On Monday 22 October 2007, Nikos Mavrogiannopoulos wrote: On Sun, Aug 19, 2007 at 08:38:42AM +0200, Andreas Metzler wrote: Something that might help in debugging without much fuss, would be to test handshake by enabling other ciphersuites. That would be for gnutls-serv to only enable

Bug#338319: proposed solutions

I've seen this problem to be open quite long time, and I believe it occurs because exim tries to generate Diffie Hellman parameters on the fly when they don't exist. This situation may occur when the gnutls-params file is missing. I propose some solutions. 1. Return an error if the

Bug#286610: libgnutls11: this is libgcrypt related

Package: libgnutls11 Version: 1.0.16-13 Followup-For: Bug #286610 This bug report should be moved to libgcrypt, since the blocking calls for /dev/random are there and cannot be handled by libgnutls. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500,