Package: udev
Version: 239-5
Severity: serious
Hi,
When upgrading udev, it failed to upgrade, because udev didn't
want to start. I think there might be some ordering problem.
This is the apt history log:
Start-Date: 2018-07-07 23:51:34
Commandline: apt-get upgrade
Upgrade: libsystemd0:amd64 (23
On Sun, Jul 08, 2018 at 03:05:34AM +0200, Michael Biebl wrote:
> Control: tags -1 moreinfo unreproducible
>
> Am 08.07.2018 um 00:26 schrieb Kurt Roeckx:
> > Package: udev
> > Version: 239-5
> > Severity: serious
> >
> > Hi,
> >
> > When upgrad
On Wed, Sep 05, 2018 at 10:58:27PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-08-23 09:07:31 [+0200], Paul Gevers wrote:
> > 2) enable the openssl package to collect information which packages it
> > breaks and which version of those package fix the issue. With that
> > information the opens
Now that bug #907278 is fixed, I think this is fixed too.
Now that bug #907278 is fixed, I think this is fixed too.
On Tue, Sep 11, 2018 at 04:11:02PM +0300, Adrian Bunk wrote:
>
> Dmitry already implemented my short-term workaround:
> https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/
If this is for a call to SSL_CTX_set_max_proto_version(), you can
use 0 in
On Tue, Sep 11, 2018 at 02:28:02PM +0200, Jonas Smedegaard wrote:
> Jan-Marek Glogowski wrote:
> > Qt5 is just the first breaking package - I have no idea, how many
> > packages use TLS_MAX_VERSION in their code.
>
> According to https://codesearch.debian.net/search?q=TLS_MAX_VERSION the
> follo
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 point,
On Mon, Nov 13, 2017 at 12:09:05AM +0800, Daniel Kahn Gillmor wrote:
> On Sun 2017-11-12 15:45:26 +0100, Ondřej Surý wrote:
> > Control: forwarded -1
> > https://gitlab.labs.nic.cz/knot/knot-resolver/issues/272
> >
> > dkg, I told you :)
>
> I don't think this is the same problem. knot-resolver 1
On Mon, Nov 14, 2016 at 03:06:44PM -0800, Russ Allbery wrote:
> Stefan Fritsch writes:
>
> > I must admit that I did not think of php when doing that change, sorry.
>
> > On the other hand, shibboleth-sp2 also build-depends on apache2-dev and
> > there
> > have been some indications that shib
On Wed, Nov 16, 2016 at 10:26:48PM +0200, Adrian Bunk wrote:
> On Wed, Nov 16, 2016 at 08:36:49PM +0100, Kurt Roeckx wrote:
> > On Mon, Nov 14, 2016 at 03:06:44PM -0800, Russ Allbery wrote:
> > > Stefan Fritsch writes:
> > >
> > > > I must admit that I did
On Wed, Nov 16, 2016 at 11:05:13PM +0100, Stefan Fritsch wrote:
> Hi,
>
> [I have trimmed the cc list a bit]
>
> On Wednesday, 16 November 2016 20:36:49 CET Kurt Roeckx wrote:
> > On Mon, Nov 14, 2016 at 03:06:44PM -0800, Russ Allbery wrote:
> > > Stefan Fritsch
On Sun, Nov 20, 2016 at 07:10:43PM -0800, Tianon Gravi wrote:
> On 2 November 2016 at 00:25, Kurt Roeckx wrote:
> > I'm guessing this is something systemd sets up, but that I might
> > need to manually set up if not using it?
>
> Ah yeah, sounds like it -- did y
On Fri, Nov 25, 2016 at 10:56:39AM +0100, Philipp Kern wrote:
> On Sun, Oct 30, 2016 at 10:40:42PM +0100, Kurt Roeckx wrote:
> > On Sun, Oct 30, 2016 at 11:35:23PM +0200, Adrian Bunk wrote:
> > > I am raising this to RC severity since 1.0.2 will likely still be
> > &
On Tue, Nov 29, 2016 at 12:47:13AM +0200, Adrian Bunk wrote:
> On Mon, Nov 28, 2016 at 11:05:07PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2016-11-28 23:31:38 [+0200], Adrian Bunk wrote:
> > > Control: retitle -1 gnubiff: FTBFS due to missing #include
> > > Control: tags -1 patch fixed-upstr
Package: wml
Version: 2.12.2~ds1-1
Severity: serious
Hi,
I'm getting the following error:
Can't locate GD.pm in @INC (you may need to install the GD module) (@INC
contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1
/usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28
/
Package: purple-matrix
Version: 0.0.0+git20170105-1
Severity: serious
Hi,
I think this version shouldn't be shipped with the next
release. Like the description says, it's "somewhat alpha".
It works some times, but then stops working, it crashes,
and so on.
Kurt
On Mon, Feb 20, 2017 at 08:57:55AM +0100, Alberto Garcia wrote:
> On Mon, Feb 20, 2017 at 12:12:35AM +0100, Kurt Roeckx wrote:
>
> > I think this version shouldn't be shipped with the next
> > release. Like the description says, it's "somewhat alpha".
> &
On Mon, Feb 20, 2017 at 11:21:50AM +0100, Alberto Garcia wrote:
> On Mon, Feb 20, 2017 at 09:33:55AM +0100, Kurt Roeckx wrote:
>
> > > Could you be a bit more specific about the problems? In my
> > > experience it disconnects (infrequently) and it lacks some
> > &
On Wed, Feb 22, 2017 at 01:56:31PM +0100, Alberto Garcia wrote:
> On Mon, Feb 20, 2017 at 06:52:58PM +0100, Kurt Roeckx wrote:
>
> > It's just that each time I mention I'm using this, people tell me
> > taht it's experimental, and probably a bug in purple-matrix.
On Wed, Feb 22, 2017 at 11:21:57PM +0100, Alberto Garcia wrote:
> On Wed, Feb 22, 2017 at 10:59:08PM +0100, Kurt Roeckx wrote:
>
> > > I don't know, I think I would understand you better if I had a
> > > list of specific problems that make this software unsuitable
Hi,
Any update on this?
There are very few packages in testing that still use OpenSSL
1.0.2, and it looks like openssh is the only reason to keep it
around.
Kurt
On Fri, Aug 03, 2018 at 08:50:37PM +0200, Paul Gevers wrote:
> Dear madplay maintainers,
>
> It is my intent to upload madplay to the achieve in about 10 days
> containing the changes in the attached debdiff.
Just upload it
Kurt
clone 907049 -1
reassign -1 offlineimap
severity -1 serious
retitle -1 offlineimap: Not using SNI
thanks
On Thu, Aug 23, 2018 at 02:54:36PM +0200, Antonin Kral wrote:
> Package: openssl
> Version: 1.1.1~~pre9-1
> Severity: critical
> Justification: renders other packages unusable
>
> Hi,
>
> I h
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.
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
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 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 run
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
reassign 907049 openvpn
severity 907049 serious
retitle 907049 openvpn: ssl_choose_client_version:version too low
block 907015 by 907049
thanks
On Sat, Aug 25, 2018 at 02:49:12PM +0200, Samuel Hym wrote:
> > Can you try with:
> > MinProtocol = TLSv1
> >
> > And with:
> > #MinProtocol = TLSv1.2
>
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
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
The log shows:
> ERROR: SSL or crypto error: loading certificates from
> testfiles/clientCerts.pem: error:140AB18F:SSL
> routines:SSL_CTX_use_certificate:ee key too small
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
This is google enforcing SNI when you use TLS 1.3, see
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication
Kurt
For more information about this, see:
https://wiki.openssl.org/index.php/TLS1.3#Server_Name_Indication
The most likely reason for a timeout is this:
*) SSL_MODE_AUTO_RETRY is enabled by default. Applications that use blocking
I/O in combination with something like select() or poll() will hang. This
can be turned off again using SSL_CTX_clear_mode().
Many applications do not properly
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
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 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
Source: gnucash
Version: 1:3.3-2
Severity: serious
Gnucash has a test suite problem. There is a log here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gnucash.html
showing:
[pass] line:641, test: dual amount column, grand totals available
[fail] line:644, test: dual amount c
I've enabled guile-2.0 and 2.2 again on armel yesterday, and it
seems to build without issues now.
Package: matrix-synapse
Version: 0.34.1.1-2
Severity: serious
Hi,
When installing the version in stretch-backports, I get:
-- Unit matrix-synapse.service has begun starting up.
Jan 18 19:07:18 mirror python3[25438]: ERROR:root:Needed pymacaroons>=0.9.3,
got pymacaroons==0.9.2
Jan 18 19:07:18 mir
On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> found 919707 0.34.1.1-2~bpo9+1
> notfound 919707 0.34.1.1-2
I believe the version I've set it to was the correct version, even
when I did find the problem in backports, the problem really exist
is both testing and stretch-backports.
On Fri, Jan 18, 2019 at 10:34:36PM +0100, Andrej Shadura wrote:
> Hi,
>
> On Fri, 18 Jan 2019 at 22:15, Kurt Roeckx wrote:
> > On Fri, Jan 18, 2019 at 08:49:01PM +0100, Andrej Shadura wrote:
> > > found 919707 0.34.1.1-2~bpo9+1
> > > notfound 919707 0.34.1.1-2
&
On Sat, Jan 19, 2019 at 12:24:45PM +0300, sergio wrote:
> On Fri, 18 Jan 2019 23:02:28 +0100 Kurt Roeckx wrote:
>
> > You have python3-msgpack (>= 0.3.0), while it should be be >= 0.4.2.
>
>
> The python3-msgpack dependency is absent.
>
> % apt show matrix-sy
Package: python3-twisted
Version: 17.4.0-2
Severity: serious
Hi,
When using python3-twisted from backports (18.7.0-2~bpo9+1), I get
the following error:
Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr
On Fri, Aug 14, 2015 at 11:36:25AM +0200, intrigeri wrote:
> Hi,
>
> intrigeri wrote (26 May 2015 09:06:57 GMT) :
> > Dererk wrote (23 May 2015 12:45:16 GMT) :
> >> What would you say about importing ntp apparmor's hardening profile into
> >> ntp package?
> >> This carries a little bit of work, tr
On Fri, Jan 13, 2017 at 07:31:03PM +0100, Bernhard Schmidt wrote:
> Hi,
>
> > Your package is failing to build with openss 1.1:
> > checking for OpenSSL library... no
> > yes
> > checking for using OpenSSL for hash functions... no
> > [...]
> > checking for OpenSSL library... using OpenSSL from /u
Hi,
It seems a fix for this is sitting git, but hasn't been uploaded. Is
there a reason it's not been uploaded yet?
Kurt
Hi,
Are you waiting for something before uploading this fix?
Kurt
Hi,
Is the issue that with older glibc versions, it was silently casted
to a 32 bit value, but now that glibc supports 64 bit, it knows
it can't represent it, and gives an error?
Maybe for bookworm, we should just ignore the test error?
Kurt
Source: aflplusplus
Version: 4.04c-2
Severity: serious
Hi,
Your package is failing to build on s390x:
[*] Compiling afl++ for OS Linux on ARCH s390x
./test/unittests/unit_maybe_alloc
[==] Running 6 test(s).
[ RUN ] test_pow2
[ OK ] test_pow2
[ RUN ] test_null_allocs
[
On Wed, Jun 23, 2021 at 09:05:03PM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-06-23 14:46:37 [+0200], Andreas Beckmann wrote:
> > Writing new private key to '/etc/ssl/private/ssl-cert-snakeoil.key'
> > -
> > Warning: No -copy_extensions given; ignoring any extensions in the request
On Thu, Jun 24, 2021 at 12:20:45AM +0200, Kurt Roeckx wrote:
>
> From the manpage:
>Random State Options
>
>Prior to OpenSSL 1.1.1, it was common for applications to store
>information about the state of the random-number generator in a
>file that was
reassign 990228 ssl-cert
severity 990228 normal
thanks
So I think there is no bug in OpenSSL and the additional check
being done in 3.0 makes sense. So I'm reassigning this to
ssl-cert.
Kurt
reopen 977657
thanks
Hi,
The CI test still fails with 1.1.1i:
Testing package ssl:ssl
Script test_ssl.pl failed: Unknown message: exit(1)
% PL-Unit: ssl_options ... done
% PL-Unit: ssl_server . done
% PL-Unit: ssl_keys . done
% PL-Unit: ssl_certificates .
ERRO
forwarded 983013 https://gitlab.com/m2crypto/m2crypto/-/issues/293
thanks
I've created an upstream issue for it.
Package: swi-prolog
Version: 8.2.1+dfsg-2
Severity: serious
Hi,
swi-prolog fails to build using OpenSSL 1.1.1h. See
https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/7715788/log.gz
for a log.
I've filed an upstream bug about this at:
https://github.com/SWI-Prolog/packages-ssl/iss
On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote:
> On Fri, Nov 6, 2020 at 9:09 AM Michal Palenik wrote:
> > for those stumbling on this via searching, the workaround mentioned
> > above is:
> [...]
> > apt -t unstable install libssl1.1:amd64
> Thanks for possibly the best
On Sat, Dec 05, 2020 at 02:13:32PM +0100, Matthias Klose wrote:
> Package: src:openssl
> Version: 1.1.1h-1
> Severity: serious
> Tags: sid bullseye patch
>
> Please backport https://github.com/openssl/openssl/pull/13585
>
> Without this patch, this causes python-asyncssh's tests to fail (and fail
Package: m2crypto
Version: 0.36.0-1
Severity: serious
Forwarded: https://gitlab.com/m2crypto/m2crypto/-/issues/289
Hi,
m2crypto is failing to build since the 1.1.1i version of OpenSSL,
see the upstream bug report for more details.
Kurt
Package: swi-prolog
Version: 8.2.3+dfsg-1
Severity: serious
Forwarded: https://github.com/SWI-Prolog/packages-ssl/issues/159
Tag: patch
Hi,
Swi-prolog is failing to build using OpenSSL 1.1.1i. I've attached
a patch that fixes it.
Kurt
--- packages/ssl/test_ssl.pl.orig 2020-12-18 11:04:37.48104
Package: python-cryptography
Version: 1.7.1-2
Severity: serious
Hi,
OpenSSL made ASN1_TIME_to_generalizedtime() take a const. But it
seems that python-cryptography has a local copy of the header
files, which now conflict with the one from OpenSSL.
It was discussed with python-cryptography and th
On Sat, May 27, 2017 at 04:00:58PM +0200, David Kalnischkies wrote:
> Control: reassign -1 libssl-dev 1.1.0e-2
> Control: retitle -1 libssl-dev: declare conflict with libssl1.0-dev to help
> apt find solutions
[...]
> Not being installable is the problem of the package which isn't
> installable –
On Mon, Jun 05, 2017 at 12:45:33AM +0300, Adrian Bunk wrote:
> Control: reassign -1 libssl1.1 1.1.0f-1
> Control: affects -1 src:simple-tpm-pk11
>
> Looking at the reproducible builds results, I noticed that
> simple-tpm-pk11 always FTBFS in unstable but never FTBFS in stretch.
>
> I confirmed t
On Mon, Jun 05, 2017 at 10:30:11AM +0100, Thomas Habets wrote:
> https://github.com/openssl/openssl/issues/3615 says this has been
> fixed in
> https://github.com/openssl/openssl/commit/7dca72af91936d246700b78e06def16561a36028
> and was an OpenSSL bug.
>
> So should this issue be closed?
This is
On Mon, Dec 19, 2016 at 09:57:42PM +0100, Daniel Pocock wrote:
>
>
> On 19/12/16 21:26, Sebastian Andrzej Siewior wrote:
> > On 2016-12-19 09:40:38 [+0100], Daniel Pocock wrote:
> >> Could this be a known issue on ppc64el or with libssl?
> >
> > Nothing comes to mind. But it explodes the same wa
On Tue, Dec 20, 2016 at 05:33:12PM +0100, Daniel Pocock wrote:
>
>
> On 19/12/16 23:05, Kurt Roeckx wrote:
>
> >
> > You should use SSL_COMP_free_compression_methods() so that we can
> > put the internal pointer to NULL.
> >
>
> Thanks for sug
On Fri, Jul 21, 2017 at 04:47:23PM -0400, Antoine Beaupré wrote:
> On 2017-07-21 22:19:20, Philipp Kern wrote:
> > My point was that you state what your delta is and essentially boils
> > down to attach the diff of what will actually happen to the .deb. I
> > think it's generally fine to add new
On Wed, Jul 26, 2017 at 11:18:32PM -0700, Daniel Schepler wrote:
> Source: openssl
> Version: 1.1.0f-3
> Severity: serious
>
> From my pbuilder build log (on amd64):
>
> ...
> Test Summary Report
> ---
> ../../test/recipes/70-test_sslrecords.t (Wstat: 0 Tests: 10 Failed: 0)
>
On Thu, Jul 27, 2017 at 08:14:45AM -0700, Daniel Schepler wrote:
> On Thu, Jul 27, 2017 at 12:02 AM, Kurt Roeckx wrote:
> > Is that reproducible?
>
> Yes, it's definitely reproducible on my machine.
Does the attached patch fix it?
Kurt
>From b72668a0d3586ee2560f0536c
On Sat, Jan 28, 2017 at 12:59:43PM +, Daniel Silverstone wrote:
> Control: tag -1 pending
>
> Hi,
>
> I've uploaded the patch previously sent into DELAYED/5
>
> Let me know if this should be expedited.
Just upload it to unstable.
Kurt
On Sat, Jan 28, 2017 at 04:02:02PM +0100, gregor herrmann wrote:
> Control: tag -1 + confirmed
> Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=120006
I've just filed:
https://rt.cpan.org/Public/Bug/Display.html?id=120006
Kurt
On Sat, Jan 28, 2017 at 06:07:02PM +0100, gregor herrmann wrote:
> On Sat, 28 Jan 2017 16:35:44 +0100, Kurt Roeckx wrote:
>
> > On Sat, Jan 28, 2017 at 04:02:02PM +0100, gregor herrmann wrote:
> > > Control: forwarded -1
> > > https://rt.cpan.org/Public/Bug/Displa
On Tue, Nov 01, 2016 at 08:42:00PM -0700, Tianon Gravi wrote:
> On 1 November 2016 at 05:35, Kurt Roeckx wrote:
> > The file /var/run/docker.sock seems to exist, is created when it starts,
> > but it really seems to be listening to an other socket.
> >
> > The p
On Wed, Nov 02, 2016 at 10:39:29AM +0100, Moritz Muehlenhoff wrote:
>
> The issue hasn't been diagnosed upstream, but this will likely also affect
> nginx
> once rebuilt against openssl 1.1.
It seems it was fixed in OpenSSL in the mean time.
Kurt
On Thu, Nov 03, 2016 at 07:45:16AM +0100, Andreas Henriksson wrote:
> Hello Kurt Roeckx.
>
> On Sun, Jun 26, 2016 at 12:21:39PM +0200, Kurt Roeckx wrote:
> > Source: fetchmail
> > Version: 6.3.26-2
> > Severity: important
> > Control: block 827061 by -1
>
On Thu, Nov 03, 2016 at 10:42:50AM -0400, Sandro Tosi wrote:
> On Sun, 11 Sep 2016 20:10:53 +0200 =?UTF-8?B?SsOpcsOpbXkgTGFs?=
> wrote:
> > 2016-09-11 14:25 GMT+02:00 Kurt Roeckx :
> >
> > > tags 828457 + patch
> > >
> > > A patch for it is available
On Fri, Nov 04, 2016 at 10:03:02AM +0200, Christos Trochalakis wrote:
> On Wed, Nov 02, 2016 at 05:22:21PM +0100, Kurt Roeckx wrote:
> > On Wed, Nov 02, 2016 at 10:39:29AM +0100, Moritz Muehlenhoff wrote:
> > >
> > > The issue hasn't been diagnosed ups
Package: opendmarc
Version: 1.3.2~Beta0+dfsg-2
Severity: serious
Hi,
I just ran into this when upgrading:
Setting up opendmarc (1.3.2~Beta0+dfsg-2) ...
Installing new version of config file /etc/default/opendmarc ...
/lib/opendmarc/opendmarc.service.generate: 83:
/lib/opendmarc/opendmarc.service
On Tue, Nov 08, 2016 at 07:36:42PM +0100, Andreas Beckmann wrote:
> Package: openssl
> Version: 1.1.0b-2
> Severity: serious
>
> Hi,
>
> I just noticed that the sendmail postinst hangs on
>
> openssl dsaparam 2048 -out file
The 2048 should be the last parameter, like it has always been
docum
On Wed, Nov 09, 2016 at 04:34:32PM +0100, Ferenc Wágner wrote:
> Hi,
>
> I switched xmltooling to libssl1.0-dev just like I switched
> xml-security-c beforehand. I got the following warnings:
>
> libtool: link: g++ -Wall -g -O2 -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werro
On Wed, Nov 09, 2016 at 07:13:58PM +0100, Ferenc Wágner wrote:
> wf...@niif.hu (Ferenc Wágner) writes:
>
> > Can you recommend a reliable way to decide whether there really are any
> > conflicts between the different OpenSSL libraries used by libcurl and
> > xmltooling?
>
> I've found two code fr
On Wed, Nov 09, 2016 at 07:13:58PM +0100, Ferenc Wágner wrote:
> struct curl_tlssessioninfo* tlsinfo = nullptr;
> CURLcode infocode = curl_easy_getinfo(ctx->m_handle,
> CURLINFO_TLS_SSL_PTR, &tlsinfo);
> if (infocode == CURLE_OK && tlsinfo && tlsinfo->backend ==
On Wed, Nov 09, 2016 at 09:26:00PM +, Cantor, Scott wrote:
> On 11/9/16, 3:55 PM, "Pkg-shibboleth-devel on behalf of Kurt Roeckx"
> behalf of k...@roeckx.be> wrote:
>
> > Can I just say this is really ugly code? It's called "internal",
> >
This seems to have been fixed upstream.
It also seems like for some reason ssl support is disabled on
other arches than amd64 and i386.
Kurt
On Sun, Nov 13, 2016 at 06:08:00PM +0300, Sergey B Kirpichev wrote:
> On Sun, Nov 13, 2016 at 03:43:29PM +0100, Kurt Roeckx wrote:
> > This seems to have been fixed upstream.
>
> Yes, this bug was closed by upstream. Thank you for tagging.
>
> BTW, it still FTBFS on i386
On Sun, Nov 13, 2016 at 08:26:48PM +0300, Sergey B Kirpichev wrote:
> On Sun, Nov 13, 2016 at 05:29:10PM +0100, Kurt Roeckx wrote:
> > That's because the configure script tries to look for a function
> > that's been turned into a define. For some reason it'
On Mon, Nov 14, 2016 at 11:34:52AM +0100, Sascha Steinbiss wrote:
> Hi Hilko and Kurt,
>
> some progress on this: I have modified Hilko's patch to use new API
> functions to access the OCSP response info, see attachment. This seems
> to have been the last issue, Bro builds fine with this patch for
On Mon, Nov 14, 2016 at 05:03:45AM +0100, Ondřej Surý wrote:
> > Looking at mod_ssl_openssl.h and the comment in #828330,
> > I'd suggest the change below to add a dependency on libssl1.0-dev
> > to apache2-dev.
>
> And that exactly happens meaning that PHP 7.0 can no longer be built
> unless all
On Sat, Aug 05, 2017 at 09:03:41PM +0200, Sebastian Andrzej Siewior wrote:
> control: tags -1 patch fixed-upstream pending
> control: forwaded -1 https://github.com/openssl/openssl/issues/3562
>
> On 2017-07-27 19:06:19 [-0700], Daniel Schepler wrote:
> > It appears so. (Though I did have to appl
On Sun, Aug 06, 2017 at 06:03:30PM +0200, Sebastian Andrzej Siewior wrote:
> On 5 August 2017 23:31:33 CEST, Kurt Roeckx wrote:
>
> >I planned to break things by disabling TLS 1.0 and 1.1, which I
> >might upload soon. I guess I can fix that at the same time.
>
> Do you
On Mon, Oct 17, 2016 at 11:20:07PM +0100, James Clarke wrote:
> This was fixed upstream by [1]. I intend to perform another NMU to fix
> this; please let me know if you disagree.
Go ahead. There is no need to upload this via delayed, I was
suprised your previous upload was.
Kurt
On Wed, Oct 26, 2016 at 11:29:46AM -0700, Stefano Rivera wrote:
> Hi Kurt (2016.10.26_10:50:40_-0700)
> > severity 828517 serious
>
> FYI, I chatted about this with the upstream core developers, last month.
> They're estimating that it's 3 months' work, and haven't started on it,
> yet. (The OpenS
On Thu, Oct 27, 2016 at 08:58:17AM +0300, Otto Kekäläinen wrote:
> You increased the seriousness of this issue, with the result of
> upcoming autoremoval of galera-3 from Debian testing despite OpenSSL
> 1.1 not being available in testing yet, and not even in unstable yet.
> Galera-3 currently buil
On Thu, Oct 27, 2016 at 09:18:31AM +0200, Bernhard Schmidt wrote:
>
> I changed that to check for OPENSSL_init_ssl instead of
> SSL_library_init, which makes configure enable SSL and ultimately leads
> to the following build error
Those are all very easy to fix. Maybe other files also have such
p
On Fri, Oct 28, 2016 at 12:53:51PM +0800, Keng-Yu Lin wrote:
> Built on my local machine with the latest sid, the failure is not
> reproducible any more.
Please note that it's still in experimental.
Kurt
On Sat, Oct 29, 2016 at 11:04:33AM +0300, Christos Trochalakis wrote:
> On Tue, Oct 11, 2016 at 10:41:01AM +0300, Christos Trochalakis wrote:
> > On Fri, Sep 02, 2016 at 10:52:15PM +0200, Kurt Roeckx wrote:
> > > Hi,
> > >
> > > It seems the version in ex
On Sat, Oct 29, 2016 at 11:04:33AM +0300, Christos Trochalakis wrote:
>
> I am not sure if the first lua patch is safe (regarding the
> "ssl_conn->tlsext_status_expected = 1;" removal).
I'm not sure which patch you're talking about. I remember
something about something doing weird things with the
On Sat, Oct 29, 2016 at 12:34:51PM +0300, Christos Trochalakis wrote:
> On Sat, Oct 29, 2016 at 11:29:12AM +0200, Kurt Roeckx wrote:
> > On Sat, Oct 29, 2016 at 11:04:33AM +0300, Christos Trochalakis wrote:
> > >
> > > I am not sure if the first lua patch is safe (re
1 - 100 of 2617 matches
Mail list logo
