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 -1 3.5.18-1
>
> On 2
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
>
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 Gi
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].
http://pkgs.fedoraproject.org/cgit/rpms
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
wrote:
> Ok, this
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 only currently see
>
On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
> Control: reopen 813598
>
> On 2016-02-15 Nikos Mavrogiannopoulos wrote:
> > On Sun, Feb 14, 2016 at 3:14 PM, Andreas Metzler
> > wrote:
> > > this is http://bugs.debian.org/813598 reporte
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
> segfault and exits,
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 client
>library get det
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?
>
> (This would need li
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 1100.10101000.0
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 unb
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
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
> s
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,
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
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)
Definitio
quot;Usage: ocpasswd -c [passwd] [options] username\nocpasswd
--help for usage instructions.\n";
explain = "";
reorder-args;
argument = "[username]";
detail = "This program is openconnect password (ocpasswd) utility. It allows
the generation
an
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 validatin
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
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 (libdan
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 compatible.
> 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 s
t 2014 19:11:28 +0100 Andreas Metzler wrote:
>> On 2014-10-28 Nikos Mavrogiannopoulos 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 descri
On Wed, Oct 29, 2014 at 1:02 PM, Didier 'OdyX' Raboud wrote:
> Hi Nikos, hi Andreas,
>
> On Tue, 28 Oct 2014 19:11:28 +0100 Andreas Metzler wrote:
>> On 2014-10-28 Nikos Mavrogiannopoulos wrote:
>> > I think that the issue should be reassigned to cups and it sh
On Wed, Oct 22, 2014 at 10:39 AM, Nikos Mavrogiannopoulos
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 of is having a fun
>
>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, "gnut
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
On Sat, 11 Oct 2014 15:20:45 + Andreas Metzler 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 while the change
On Sun, 21 Sep 2014 13:50:36 +0200 Andreas Metzler wrote:
> On 2014-09-16 Didier 'OdyX' Raboud 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 generation of core f
On Wed, Jun 4, 2014 at 5:50 PM, Daniel Kahn Gillmor
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 o
On Tue, Jun 3, 2014 at 12:33 AM, Daniel Kahn Gillmor
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 make it clear t
On Fri, Apr 18, 2014 at 9:46 AM, NIIBE Yutaka 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 temporar
On Fri, Apr 18, 2014 at 1:14 AM, NIIBE Yutaka 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 gnom
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 usin
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, [37440
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
[0x7f47f4217
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]. https://bitbucket.org/shlomif/website-meta-l
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 http://au
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
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.*
T
> 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 AES-
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=2765&user=guest&pass=guest
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debia
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 difference.
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 -
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]: D
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 (c.c
s the attached patch
fix the issue?
regards,
Nikos
>From c4a8f333fc118ac454906e6ef056789b4069e4d2 Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Sat, 27 Aug 2011 20:20:43 +0200
Subject: [PATCH] gnutls_certificate_set_x509_key() and
gnutls_certificate_set_openpgp_key() operate as i
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
>>
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 l
On Wed, Mar 30, 2011 at 2:01 PM, Luca Capello 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 pas
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 a
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 l
2011/3/8 Vedran Furač :
>>> - 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 expired?
>
> T
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
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 listmas...@lists.debia
On Thu, Feb 3, 2011 at 11:15 PM, brian m. carlson
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
> MD5 (according to my tes
On Fri, Feb 4, 2011 at 9:09 AM, Simon Josefsson 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 other choice
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 rep
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 sequen
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 wit
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
Daniel Kahn Gillmor wrote:
> Thanks for the feedback, Simon.
>
> On 02/19/2009 05:02 PM, Simon Josefsson wrote:
>> Daniel Kahn Gillmor writes:
>>> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
>> This is essentially the (untested) patch I proposed earlier.
>>
>>> (this may mean t
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:
Hel
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:
Tha
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 h
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 'https://foo.example.org/svn/monkey/tr
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 send
wrote:
> 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
> whene
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:
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
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 cau
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:
> http://bugs.debian.org/cgi
> 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 tcp
> 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
> 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
> $ 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 fallbac
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 = /etc/exim4/certificates/newserver_co_u
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 b
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
> > 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)ran
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 d
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
> >
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 [E
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
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
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 wo
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 wo
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 exchan
> 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 o
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 gnutls-param
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, 'unstable')
92 matches
Mail list logo
