Hello Joost,
On 11/27/18 11:29 AM, Joost van Zwieten wrote:
> Hi Kurt, Andreas,
>
> I ran into this issue today. When switching from stretch to buster I
> noticed that gmsh couldn't read STEP files anymore. The following
> error message appears:
>
> Error : Gmsh
racks this problem
> should prevent the migration.
It won't, since it affects also the version in testing, it can
just migrate.
Kurt
or:141A318A:SSL routines:tls_process_ske_dhe:dh key too small
>
> (In the above message, server.com and 1.2.3.4 are place holders.)
>
> Is there any known workaround for isync 1.3.0-2 users?
Please see:
/usr/share/doc/libssl1.1/NEWS.Debian.gz
Kurt
ed bug."
Please see /usr/share/doc/libssl1.1/NEWS.Debian.gz
Kurt
Package: libocct-doc
Version: 7.3.0+dfsg1-4
Severity: minor
Dear Maintainer,
When accessing the HTML documentation, there is a search form in the
top-right of the page. Attempting to use this search form results in a
download prompt for the file "search.php" instead of executing a search
of the
Source: glibc
Version: 2.25-2
Hi,
On kfreebsd-* and hurd I'm getting a linker failure that mremap()
doesn't exist. It exists in sys/mman.h.
Kurt
The difference between a good and bad test seems to be how many
processes are running. Maybe it needs to wait longer before
running the test, or retry with some timeout.
Source: rspamd
Version: 1.8.1-2
Severity: impotant
Hi,
It seems the autopkgtest randomly fails, see:
https://ci.debian.net/packages/r/rspamd/testing/amd64/
Kurt
x32 version.
Kurt
-dev.
There doesn't seem to be any of the binary packages that has a
Depends or Recommends on libssl1.0.2, so either the support for it
actually got disabled or it's loaded at run time and might fail
to load it since nothing will pull in libssl1.0.2.
Kurt
> possible for a developer to make a non-maintainer upload to resolve this?
I'm expecting a new upstream version soon, and will do an upload
of that then.
Kurt
On Mon, Nov 12, 2018 at 07:22:26AM +0100, Sebastiaan Couwenberg wrote:
> fixed 913535 sfcgal/1.3.1-1~exp1
> thanks
>
> On 11/11/18 11:34 PM, Kurt Roeckx wrote:
> > Clearly I don't need all of this just for postgis.
> >
> > Most of this seems to be a dependency
of dependencies can be reduced?
Avoiding the dependency on libopenscenegraph100v5 would be nice.
For instance, it talks about a C API, maybe you can split the
library in one that only provides the C API and part that provides
the C++ API and then have separate packages for it?
Kurt
orts
TLS 1.2 and things like that.
I have no idea why it doesn't work for you, or why it doesn't work
with sendmail, but this does not look like an openssl issue, so
I've reassign it to the sendmail package.
Kurt
On Sat, Nov 10, 2018 at 08:17:19PM +0100, BERTRAND Joël wrote:
> Kurt Roeckx a écrit :
> > On Thu, Nov 08, 2018 at 06:36:52PM +0100, Kurt Roeckx wrote:
> >> On Thu, Nov 08, 2018 at 06:10:29PM +0100, BERTRAND Joël wrote:
> >>> Kurt Roeckx a écrit :
> >>>
On Thu, Nov 08, 2018 at 06:36:52PM +0100, Kurt Roeckx wrote:
> On Thu, Nov 08, 2018 at 06:10:29PM +0100, BERTRAND Joël wrote:
> > Kurt Roeckx a écrit :
> > > On Wed, Nov 07, 2018 at 11:21:44AM +0100, BERTRAND Joël wrote:
> > >> Nov 7 09:17:31 rayleigh sm-mta[10148]:
On Sat, Nov 10, 2018 at 03:48:37PM +0100, Pino Toscano wrote:
> In data sabato 10 novembre 2018 13:30:19 CET, Kurt Roeckx ha scritto:
> > On Sun, Oct 28, 2018 at 11:29:43PM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote:
> >
On Sun, Oct 28, 2018 at 11:29:43PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote:
> > On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> > > &
--- Begin Message ---
Hi, everybody,
there is a new release of M2Crypto, most complete Python bindings
for OpenSSL (from 1.0.1e to 1.1.1), supporting both Python 2 (2.6
and 2.7) and Python 3 (from 3.4 upwards).
This is mostly bugfix release, including:
- support for OpenSSL 1.1.1
- Fixes
On Thu, Nov 08, 2018 at 06:10:29PM +0100, BERTRAND Joël wrote:
> Kurt Roeckx a écrit :
> > On Wed, Nov 07, 2018 at 11:21:44AM +0100, BERTRAND Joël wrote:
> >> Nov 7 09:17:31 rayleigh sm-mta[10148]: ruleset=try_tls,
> >> arg1=smtp-in.orange.fr, relay=smtp-in.
file a bug against sendmail to override the
defaults.
Kurt
g socket when it's
waiting for the server hello.
Or are you seeing it with a blocking socket? I can't think of a
reason why that should have changed.
Kurt
On Sun, Nov 04, 2018 at 12:49:48PM -0800, James Bottomley wrote:
> On Sun, 2018-11-04 at 21:30 +0100, Kurt Roeckx wrote:
> > On Sun, Nov 04, 2018 at 12:13:43PM -0800, James Bottomley wrote:
> > >
> > > No, I'm saying with no client tls-version-min specified at all (the
that's totally what I expected, and have been explaining.
The 2.3.X version only want to do TLS 1.0 unless you specify
"tls-version-min 1.0", in which case they also do TLS 1.2.
So I'm failing to see what this bug report is about.
Kurt
s-version-min 1.0 and everything works for me.
I will try to look at this in a few days.
Kurt
On Sun, Nov 04, 2018 at 11:19:41AM -0800, James Bottomley wrote:
> On Sun, 2018-11-04 at 20:15 +0100, Kurt Roeckx wrote:
> > This is not at all how the version negiotation in TLS 1.2 and
> > below works. The client just indicates the highest version it
> > supports, so for i
On Sun, Nov 04, 2018 at 10:19:00AM -0800, James Bottomley wrote:
> On Sun, 2018-11-04 at 18:43 +0100, Kurt Roeckx wrote:
> > Older versions of openvpn only support TLS 1.0 because they told
> > OpenSSL to only use TLS 1.0. Adding the --tls-version-min 1.0
> > should ma
ciphers it should negotiate the mutually acceptable version.
Older versions of openvpn only support TLS 1.0 because they told
OpenSSL to only use TLS 1.0. Adding the --tls-version-min 1.0
should make it support all TLS versions since openvpn 2.3.4 or
something like that, and I think 2.4 or newer should just work.
But if you changed the openssl.cfg to say all versions are
supported, it should work too, I'm not sure why you say otherwise.
Kurt
. It does not document all
possible error messages.
Kurt
send what they're going to pick anyway. For
instance this works:
openssl s_client -connect voscomptesenligne.labanquepostale.fr:443 -cipher
DEFAULT@SECLEVEL=1
Kurt
com/openssl/openssl/issues/7126
I suggest you try to contact your bank so that they update their
software.
Kurt
2 different TLS implementaitons saying something is
wrong.
Does it work when you add --tls-max 1.2?
I suspect there is some middlebox that breaks things for you.
Kurt
efault, so openvpn from testing doesn't talk to a default openvpn
version from jessie. Could you please change the version in jessie
so that it supports TLS 1.0+ instead of just 1.0 by default?
Kurt
On my desktop (with a chaos key attached)
[3.844484] random: crng init done
[ 5.312406] systemd[1]: systemd 239 running in system mode.
Kurt
ault is used which changed.
As far as I know, the default in stretch should also use sha256,
most likely those certificates are older.
Kurt
te site in case the defaults cause
problems.
Kurt
refreshed and the attacker could have read the file
> before the crash.
So are you saying that the /var/lib/random/seed is untrusted, and
should never be used, and we should always wait for fresh entropy?
Anyway, I think if an attacker somehow has access to that file,
you have much more serious problems.
Kurt
On Mon, Oct 29, 2018 at 09:58:20PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> > So I believe this is not an openssl issue, but something in the
> > order that the kernel's RNG is initialized and openssh is started.
> > Potent
On Mon, Oct 29, 2018 at 07:11:17PM +0100, Michael Biebl wrote:
> On Mon, 29 Oct 2018 18:22:08 +0100 Kurt Roeckx wrote:
> > reassign 912087 openssh-server,systemd
> > thanks
> >
> > On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote:
> > > On Mon, Oct
reassign 912087 openssh-server,systemd
thanks
On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote:
> On Mon, Oct 29, 2018 at 12:28:15AM +, Colin Watson wrote:
> > Reassigning to OpenSSL - could the OpenSSL maintainers please have a
> > look and advise what's be
andom data from
the previous boot. This used to be done by /etc/init.d/urandom,
but I'm not sure if that's still used. This should be done as
early as possible during the boot not to cause such problems. You
should look into when during the boot process the kernel gets this
random data.
Kurt
ase I would recommend that you configure it there.
Kurt
r those who might run into
> the same thing,
Can you please clarify what stopped working, what error did you
get?
Are you asking to restart getmail on upgrade? Does that actually
fix your problem?
The new 1.1.1-1 version might break some things because for
various reasons. So if you get an error, please report it.
Kurt
On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> > > Source: kopete
> > > Source-Version: 4:18.04.1-1
> > >
> &
On Sun, Oct 07, 2018 at 11:00:48AM +0200, Andrej Shadura wrote:
>
> I’m unsure what can be done to help resolve this issue from the wpa side.
The only thing I can think of is that wpa could add a way to
specify the minimum tls version.
I will enable SSLv2, SSLv3, 3DES, RC4, export ciphers, and so on again.
On Thu, Oct 18, 2018 at 04:05:32PM +0200, Mattia Rizzolo wrote:
> On Thu, Oct 18, 2018 at 04:01:59PM +0300, Niko Tyni wrote:
> > On Wed, Oct 17, 2018 at 09:21:29PM +0200, Kurt Roeckx wrote:
> > > On Wed, Oct 17, 2018 at 09:22:35PM +0300, Niko Tyni wrote:
> >
> > &
issues.
> Is it still useful to block openssl 1.1.1 testing migration with this bug?
Things like python are also blocked on it. I have no problem
lowering the severity of this issue, to make it migrate.
Kurt
All the errors in the test suite are problems in the test suite
itself. Some of those have been fixed upstream.
Some of the problems are:
- The test suite used 1024 bit keys, they have been replaced by
2048 bit keys
- The test suite didn't send the Finished message to the server,
the client
On 10/9/18 11:42 AM, W. Martin Borgert wrote:
> Dear Harri Haataja,
>
> Quoting Harri Haataja :
>> It's been over five months since the release and #888712 seems to have
>> markings of being fixed. Is there something still holding this back?
>
> Note, that FreeCAD 0.17 is already uploaded to
On Sat, Oct 06, 2018 at 06:19:32PM +0200, Kurt Roeckx wrote:
> On Sat, Oct 06, 2018 at 12:36:44PM -0300, Antonio Terceiro wrote:
> > Source: openssl
> > Version: 1.1.1-1
> > Severity: normal
> > Tags: patch
> >
> > The autopkgtests for openssl are
On Sat, Oct 06, 2018 at 12:36:44PM -0300, Antonio Terceiro wrote:
> Source: openssl
> Version: 1.1.1-1
> Severity: normal
> Tags: patch
>
> The autopkgtests for openssl are currently broken due to a set of typos:
This should already be fixed in git.
Kurt
Source: opencollada
Severity: wishlist
Dear Maintainer,
A new upstream version, 1.6.63, is available [1], which contains 247
commits' worth of additional development [2] so it would be great if
this package could be updated.
[1] https://github.com/KhronosGroup/OpenCOLLADA/releases/tag/v1.6.63
On Tue, Sep 18, 2018 at 11:44:29PM +0200, Bernhard Schmidt wrote:
> > I have no idea how we can properly avoid that. When do you think
> > would be a good time to reset the clock? After a reboot? I think
> > it's not very obvious that you'd have to start it manually or
> > reboot it after
when used interactively. Both
-quiet and -ign_eof should turn off that behaviour.
Kurt
On Tue, Sep 11, 2018 at 08:14:35PM +0300, Dmitry Shachnev wrote:
> Hi Kurt,
>
> On Tue, Sep 11, 2018 at 07:09:04PM +0200, Kurt Roeckx wrote:
> > If this is for a call to SSL_CTX_set_max_proto_version(), you can
> > use 0 instead of TLS_MAX_VERSION.
>
> Good
* globus-gssapi-gsi
Should still work, only in comment, they don't want TLS 1.3
It really looks like qtbase-opensource-src is the only one that
breaks on it.
Kurt
can
use 0 instead of TLS_MAX_VERSION.
Kurt
Now that bug #907278 is fixed, I think this is fixed too.
On Sat, Sep 08, 2018 at 01:23:41AM +0200, Bernhard Schmidt wrote:
> Package: ntpdate
> Severity: normal
>
> Hi Kurt (and everyone else in the BTS),
>
> I've been going through the open bugs in the BTS again and have come to the
> conclusion that the whole ifupdown triggeri
eases to all
supported branches.
Kurt
Now that bug #907278 is fixed, I think this is fixed too.
The problem here is that the CA you're connecting to has an
insecure certificate. You should talk to your administrator
to generate stronger keys.
The "ca md too weak" is because the certificate is probably using
SHA-1, while it should move to SHA256.
This can be worked around by using this in
was released, so it should not be
> a big problem for most users :-)
It would be best that you could specify this as specific as
needed, so per connection. So having support for that in
NetworkManager could be nice.
Kurt
de
> upgrades their things or the users enabled "lower security" mode.
> Is there anything that skipped my mind?
There are also bugs in packages that actually break because of the
TLS 1.3 changes, for instance not sending the SNI and trying to
connect to google. Having a Breaks might be useful for those.
Kurt
tell your administrator to use 2048 (or more) bit
keys. I assume there are certificates on both sides, so they both
need to get replaced.
You can work around this issue by putting something like this in
your config file:
openssl_ciphers=DEFAULT@SECLEVEL=1
But you really should use a certificate with a stronger key.
Kurt
;
> Hi,
>
> On Fri, 10 Aug 2018 04:59:38 -0500 Kurt Kremitzki
> wrote:
> > Source: med-fichier
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Med-fichier supports CMake builds, and if CMake is used there are
> > several .cmake helper file
Package: gmsh
Version: 3.0.6+dfsg1-3
Severity: wishlist
Dear Maintainer,
A new upstream version 4.0.0 has been released. Please update the
package to provide this version.
Note: I've already almost finished the packaging for this, and wanted to
file this bug just to make sure other people
Package: wnpp
Severity: wishlist
Owner: Kurt Kremitzki
* Package name: salome-smesh
Version : 8.3.0.3
Upstream Author : Trevor Laughlin
* URL : https://github.com/LaughlinResearch/SMESH
* License : LGPL-2.1
Programming Lang: C++
Description
This is most likely caused by google sending invalid certificates
if you talk TLS 1.3 but don't send the SNI extention. See
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication
On Tue, Aug 28, 2018 at 03:33:11PM +0200, Pierre-Elliott Bécue wrote:
> Le samedi 25 août 2018 à 20:34:35+0200, Kurt Roeckx a écrit :
> > This is caused by a Debian change to require a 2048 bit key by
> > default instead of a 1024 bit key. Since this is just for a test,
> >
This is caused by a Debian change to require a 2048 bit key by
default instead of a 1024 bit key. Since this is just for a test,
you can either just replace the certificates with larger keys,
or lower the security level for the test from 2 to 1. I suggest
you just create a new certificates.
Kurt
(), SSL_CTX_set_mode() and
SSL_CTX_set_read_ahead() again.
Kurt
For more information about this, see:
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication
This is google enforcing SNI when you use TLS 1.3, see
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication
Kurt
s is just for a test,
you can either just replace the certificate with a larger key,
or lower the security level for the test from 2 to 1. I suggest
you just create a new certificate.
Kurt
Hi,
The problem is:
> Generating a 1024 bit RSA private key
Which then later results in:
> lua: server.lua:19: error loading certificate (ee key too small)
We've changed the default in Debian to require 2048 bit keys.
Kurt
severity 907049 important
thanks
On Sat, Aug 25, 2018 at 03:06:47PM +0200, Kurt Roeckx wrote:
> Anyway, that seems to mean that openvpn only supports TLS 1.0 for
> some reason. I have no idea how openvpn works, but if it uses
> TLS 1.0, it really should switch to 1.2 or 1.3.
S
e reason. I have no idea how openvpn works, but if it uses
TLS 1.0, it really should switch to 1.2 or 1.3.
Kurt
On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> Source: kopete
> Source-Version: 4:18.04.1-1
>
> We believe that the bug you reported is fixed in the latest version of
> kopete, which is due to be installed in the Debian FTP archive.
Any plans to upload this to unstable?
Kurt
On Mon, May 28, 2018 at 05:59:08PM +0200, Emilio Pozuelo Monfort wrote:
> On Tue, 17 Apr 2018 20:55:00 +0200 Emilio Pozuelo Monfort
> wrote:
> > On Wed, 24 Jan 2018 11:07:19 + deb...@fau.xxx wrote:
> > > Upstream have accepted both patches. netty 4.1.20 has been released,
> > > which will
On Fri, Aug 24, 2018 at 10:27:16AM +, Damyan Ivanov wrote:
> -=| Kurt Roeckx, 23.08.2018 22:32:13 +0200 |=-
> > Note that the SIGPIPE issue is probably a known upstream issue
> > that still needs to be fixed, we're at least still working on a
> > SIGPIPE issue.
> >
On Thu, Aug 23, 2018 at 10:32:13PM +0200, Kurt Roeckx wrote:
> Note that the SIGPIPE issue is probably a known upstream issue
> that still needs to be fixed, we're at least still working on a
> SIGPIPE issue.
OpenSSL might only be able to handle the EPIPE case, and the
applications m
Note that the SIGPIPE issue is probably a known upstream issue
that still needs to be fixed, we're at least still working on a
SIGPIPE issue.
But that does not mean that the other issues in libnet-ssleay-perl
should not get fixed.
Upstream python has been working on OpenSSL 1.1.1 support for a
while, the upstream bug is: https://bugs.python.org/issue32947
I already notified them yesterday about the issues.
Kurt
otocol = TLSv1.2
I assume the first will still fail, and the later one will work.
And I'm currently unsure what to do about that, but there are
multiple options.
Kurt
ow having:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2
Where the SECLEVEL 2 requires a 112 / 2048 bit security level.
Kurt
the atomic qualifier and
clang doesn't support that.
>From what I understand, including gcc's headers was a workaround
for a bug that is now fixed.
I think the most relevant upstream bug for this is:
https://bugs.llvm.org/show_bug.cgi?id=23556
https://bugs.llvm.org/show_bug.cgi?id=22740
Kurt
Hello Andreas,
On 08/14/2018 05:17 AM, Andreas Beckmann wrote:
> Package: freecad-common,freecad-python2,libfreecad-python2-0.17
> Version: 0.17+dfsg1-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package
Hello Debian Science,
The package described below is ready for consideration at
https://salsa.debian.org/science-team/freecad-doc.
Thank you!
On Tue, 14 Aug 2018 03:40:38 -0500 Kurt Kremitzki
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Kurt Kremitzki
>
> * Package nam
Package: wnpp
Severity: wishlist
Owner: Kurt Kremitzki
* Package name: freecad-doc
Version : 0.17.20180719
Upstream Author : FreeCAD Community
* URL : https://github.com/freecad/freecad-doc
* License : CC-BY-3.0
Programming Lang: Python
Description
Source: pyside2
Severity: normal
Dear Maintainer,
The aforementioned packages only support automatic CMake configuration
for Python 2. It would be nice to support both 2 & 3 by including the files
`{PySide2Config,Shiboken2Config}.cpython-36m-x86_64-linux-gnu.cmake` in
the packages.
-- System
On Mon, Aug 13, 2018 at 12:14:16AM -0700, Steve Langasek wrote:
> On Mon, Aug 13, 2018 at 09:06:27AM +0200, Kurt Roeckx wrote:
> > > Yes, because it's patched source and also there is no openssl in the
> > > archive
> > > that's built for a standalone ta
penssl 1.1.0 now, and the changelog says
it's now unpatched.
Kurt
Package: edk2
Hi,
Is there a reason edk2 embeds an openssl version and doesn't use
the system provided openssl?
Kurt
Package: wnpp
I'm orphaning libtool.
It currently has 1 RC bug, and the last NMU at least seems to
cause a regression.
Kurt
Hello Gilles,
On 08/11/2018 04:43 PM, Gilles Filippini wrote:
> Control: tags -1 + moreinfo
>
> Hi,
>
-snip-
>
> Patches welcome :)
>
> I gave a try using the CMake build system, but it failed. Firstly, there
> is no CMakeList.txt to build the doc. Secondly the test suite fails:
-snip-
>
>
Source: med-fichier
Severity: normal
Dear Maintainer,
Med-fichier supports CMake builds, and if CMake is used there are
several .cmake helper files generated which are currently missing from
the package. Downstream projects then expect those .cmake files to be
available, and it causes difficulty
Package: python-fluids-doc
Version: 0.1.72-1
Severity: minor
Dear Maintainer,
The LaTeX in the documentation fails to render. To easily reproduce
this, visit index.html and then scroll down to API Reference, and click
on 'Compressible flow and compressor sizing'. Instead of a rendered
LaTeX
-0500 Kurt Kremitzki
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Kurt Kremitzki
>
> * Package name : openvoronoi
> Version : 2018.08
> Upstream Author : Anders Wallin
> * URL : https://github.com/aewallin/openvoronoi
> * License : LGPL-2.1
> Programmin
301 - 400 of 6713 matches
Mail list logo
