Bug#918717: [Pkg-openssl-devel] Bug#918717: Bug#918717: openssl: wrong signature type on a specific website with openssl.cnf shipped in debian

[Kurt Roeckx]

On Tue, Jan 08, 2019 at 07:30:01PM +0100, Sebastian Andrzej Siewior wrote:
> On 2019-01-08 17:40:04 [+0100], Jérémy Lal wrote:
> > Package: openssl
> > Version: 1.1.1a-1
> > Severity: normal
> > 
> > Hi,
> > 
> > curl https://portal.gexpertise.fr/GexPortal
> > returns an error,
> > 
> > however (you need nodejs 10.15~dfsg-8 for this file to be available - the 
> > file in itself
> > is there to be able to run upstream tests suites)
> > OPENSSL_CONF=/usr/include/nodejs/openssl.cnf curl 
> > https://portal.gexpertise.fr/GexPortal
> > does work
> 
> The server is vurnable to OpenSSL Padding Oracle vulnerability
> (CVE-2016-2107) [0].
> 
> The problem is that the remote server is signing the certificate wit
> SHA1 instead something stronger:
> |No client certificate CA names sent
> |Peer signing digest: SHA1
> |Peer signature type: RSA
> |Server Temp Key: ECDH, P-256, 256 bits
> 
> Kurt did we want to enable SHA1 for DEFAULT@SECLEVEL=2?

No, we do not want to enable it at level 2.

The server in question should support SHA256, but because of a bug
always uses SHA1. The commit that fixed it in the 1.0.1 branch,
which I think is what they are running, is
4e05aedbcab7f7f83a887e952ebdcc5d4f2291e4, which is a commit from
2014.


Kurt

Bug#918717: [Pkg-openssl-devel] Bug#918717: openssl: wrong signature type on a specific website with openssl.cnf shipped in debian

[Kurt Roeckx]

On Tue, Jan 08, 2019 at 05:40:04PM +0100, Jérémy Lal wrote:
> Package: openssl
> Version: 1.1.1a-1
> Severity: normal
> 
> Hi,
> 
> curl https://portal.gexpertise.fr/GexPortal
> returns an error,

They are running an ancient OpenSSL version with known security
vulnerabilities, and an old bug you run into.


Kurt

Re: Appeal procedure for DAM actions

[Kurt Roeckx]

On Mon, Jan 07, 2019 at 11:27:35PM +0100, Joerg Jaspert wrote:
> 
> we waive the time limit defined in §1 for the cases
> from the last 6 months.

Would it make sense to have them 1 week from publishing this
instead?


Kurt

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Sat, Jan 05, 2019 at 08:33:18PM +0100, Steffen Nurpmeso wrote:
> 
> (I am also really interested and will look into OpenSSL to see if
> the abort() that seems to happen if the initial seed fails is in
> a linker-resolved constructor, and if not, why later failures do
> not also abort.

We do not call abort(). A function like RAND_bytes() or
RAND_status() will just return an error.

> Yes, while i am going, the full truth is that
> i do not like it, i do not like that possibly a constructor call
> is made for something that is possibly not needed, if it is done
> like that, that someone simply aborts because of a some internal
> PRNG, especially so if it is not in a constructor call and if
> errors can and are expected to be handled by PRNG users anyway,

RAND_bytes() has always documented that it can fail. Most function
calls can return errors for various reasons. Not checking for such
errors is in my opinion a bad style.

> i do not like that the stuff is instantiated in all threads

It's only created in each thread that tries to the RNG. I'm not
sure what exactly your problem with it is. Either we need a global
lock, or we need an RNG per thread. We went with the per thread
RNG.

We have a master DRBG that you can get with
RAND_DRBG_get0_master(). I recommend that you do not use it. It
requires that you take an external lock to use it. Internally we
lock it, but there is no way for you to use the same lock.

> which
> in addition requires forks handlers to be installed all over the
> place.

OpenSSL adds it's own fork handler now. You should not need to do
anything on fork related to OpenSSL.

> the Linux kernel that drives
> the world from smallest to hugest has one internal entropy pool
> that feeds two public pools, whereas i the lucent little hobby
> server from user space get an armada of these.  Wow.

Linux has a master pool, and a pool per core for the very same
reason as we also have a master DRBG and per thread DRBG.


Kurt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Sat, Jan 05, 2019 at 08:45:37AM +1000, Dr Paul Dale wrote:
> I’m not sure about the quality of Android’s sources, but would expect them to 
> be decent.

Android is just a Linux kernel. It always had /dev/urandom. Oreo
(8.0) requires at least Linux kernel 4.4. There were no
requirements for the kernel version before this. Some devices with
Marshmallow (6.0) will run a Linux kernel with 3.18, but not all
of them.


Kurt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Fri, Jan 04, 2019 at 02:48:48PM +0100, Steffen Nurpmeso wrote:
> Dr. Matthias St. Pierre wrote in <450169f8ca7c43d1841c4c8052e78c72@Ex13.\
> ncp.local>:
>  |> So my concerns are:
>  |> 1. Whether I really can count on getting a high-entropy PRNG across \
>  |> these various platforms, without any explicit initialization.
>  |
>  |Yes, for the mentioned platforms, the default configuration is `--with-r\
>  |and-seed=os`, which means the DRBG automatically seeds
>  |and reseeds using os entropy sources.
>  |
>  |2. If something goes wrong with PRNG initialization, that it will fail \
>  |hard rather than fall back to something less secure. And if so how \
>  |I detect such a failure.
>  |
>  |If the (re-)seeding fails, the DRBG enters an error state. When you \
>  |try to generate random bytes it will detect the error state and try
>  |automatically to heal the error state by reinstantiating. But if reseeding \
>  |fails, it will return and error code and not generate any pseudo random \
>  |bytes.
>  |
>  |Citing from the manual pages:
>  ...
>  | As a normal application developer, you do not have to worry about \
>  | any details, just use RAND_bytes(3)
>  | to obtain random data. Having said that, there is one important rule \
>  | to obey: Always check the error
>  | return value of RAND_bytes(3) and do not take randomness for granted.
>  |
>  | https://www.openssl.org/docs/man1.1.1/man7/RAND.html
> 
> That is new however, _imho_.  The wording of RAND_bytes(3) (still)
> says that "an error occurs [.if.] not [been] seeded with enough
> [data]", and RAND_status(3) returns 1 if the PRNG "has been seeded
> with enough data".  So if it is seeded it is seeded, in my
> understanding anything further on up the road only mixes in noise
> (which likely will undergo further maths and be stirred into the
> pool, i have not looked, actually).  I do not test RAND_bytes(3)
> return (yet), because i have ensured the PRNG is sufficiently
> seeded, and RAND_status(3) returns success, before RAND_bytes(3)
> is used the first time.

For 1.1.0 and older that works, because they do not reseed. Since
1.1.1 it does reseed, and if the reseed fails, it will go to an
error state. So yes, this is new behavior.

The RAND_bytes and RAND_status manpages can clearly be improved.
Since you always have to check RAND_bytes's return value now,
RAND_status is mostly useless.


Kurt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RFC 7919 DH parameters and OpenSSL DH_check()

[Kurt Roeckx]

On Thu, Jan 03, 2019 at 12:18:05PM -0800, Andy Schmidt wrote:
> I am adding the RFC 7919 Diffie-Hellman parameters to our TLS servers, and
> I've found that these parameters won't pass OpenSSL's Diffie Hellman
> parameter check function DH_check(). The return code is
> DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears to fail
> because the remainder of the prime divided by 24 is not 11. That its, p mod
> 24 != 11. I have a couple of questions:
> 
> What relationship between the prime p and the generator g is this checking
> for? I thought that since p was a safe prime, as long as the generator g
> wasn't 1 the only choice is between the full group and the subgroup of the
> squares?
> 
> I would like to use DH_check() to attempt to ensure that Diffie Hellman
> parameters haven't been tampered on operating systems that don't have
> digital signatures for executable binaries.

See:
https://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11


Kurt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Thu, Jan 03, 2019 at 11:03:01AM -0500, Mike Blaguszewski wrote:
> I am using the EVP API (version 1.1.1) for performing public key and 
> symmetric key operations across a variety of platforms (macOS, Windows, 
> Linux, iOS and Android). I am currently not doing anything to explicitly seed 
> OpenSSL’s random number generator. My understanding is that the default 
> behavior  should be 
> cryptographically secure.
> 
> So my concerns are:
> 1. Whether I really can count on getting a high-entropy PRNG across these 
> various platforms, without any explicit initialization.
> 2. If something goes wrong with PRNG initialization, that it will fail hard 
> rather than fall back to something less secure. And if so how I detect such a 
> failure.
> 
> Our current implementation uses libsodium, which relies on the usual system 
> calls to generate entropy, so if I can count on OpenSSL always doing this 
> then I’m happy. 

It will make use of system calls when available. Those are known
to provide system calls:
- Linux since 3.17
- Darwin since 16 (OSX 10.12, IOS 10.0).
- Solaris since 11.3
- OpenBSD since 5.6
- FreeBSD since 12.0 (1200061)

By default it will fall back to use something like /dev/urandom if
the system call is not available or returns an error.

On Windows we are also using the system provided entropy by using
function calls.

You do not need to do anything to initialize RNG. It will
automatically initiailze on first use.

It will hard fail when it's not able to get entropy.

Since it now reseeds from time to time, it can actually start to
fail after having run succesfully for some time. But it's very
unlikely that you would run into that, by default we should make
sure that we can always get entropy.


Kurt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: Yet more undisclosed intermediates

[Kurt Roeckx via dev-security-policy]

On 2019-01-03 16:25, Jakob Bohm wrote:

There is the date fields in the SubCA certificate itself, as well as any
embedded CT data (assuming the parent CA is correctly CT-logged).


Do you expect precertificates for CA certificates?

I currently don't know if there are any requirements for logging CA 
certificates in CT. I assume it was only for subscriber certificates, 
but I didn't check what Google's current policy is. So it's possible 
that a CA certificate is only be logged the first time a subscriber 
certificate is generated.



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Bug#883778: problems building guile-2.0 on armel

[Kurt Roeckx]

I've enabled guile-2.0 and 2.2 again on armel yesterday, and it
seems to build without issues now.

Bug#883778: problems building guile-2.0 on armel

[Kurt Roeckx]

I've enabled guile-2.0 and 2.2 again on armel yesterday, and it
seems to build without issues now.

Bug#918057: gnucash: FTBFS: test suite failure

[Kurt Roeckx]

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 column, first transaction correct
transaction.scm/display options
 -> expected: ("01/03/18" "$103 income" "Root.Asset.Bank" "$103.00" "$103.00")
 -> obtained: ("01/03/20" "$103 income" "Root.Asset.Bank" "$103.00" "$103.00")

This is an other log showing it:
https://buildd.debian.org/status/fetch.php?pkg=gnucash=armel=1%3A3.3-2=1546423068=0


Kurt

Bug#918057: gnucash: FTBFS: test suite failure

[Kurt Roeckx]

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 column, first transaction correct
transaction.scm/display options
 -> expected: ("01/03/18" "$103 income" "Root.Asset.Bank" "$103.00" "$103.00")
 -> obtained: ("01/03/20" "$103 income" "Root.Asset.Bank" "$103.00" "$103.00")

This is an other log showing it:
https://buildd.debian.org/status/fetch.php?pkg=gnucash=armel=1%3A3.3-2=1546423068=0


Kurt

Re: Please give back meep on mipsel

[Kurt Roeckx]

On Tue, Jan 01, 2019 at 08:35:40PM +0100, Kurt Roeckx wrote:
> On Tue, Jan 01, 2019 at 04:59:17PM +0100, Thorsten Alteholz wrote:
> > Hi,
> > 
> > the mipsel buildd marked meep as "unsatisfiable Build-Depends(-Arch) on
> > mipsel: mpb-dev".
> > As mpb-dev is finally available on mipsel, please give meep back:
> > 
> >gb meep_1.7.0-2 . mipsel
> 
> Build-Depends are checked automatically. mpb-dev is still not
> available on mipsel. On mipsel, the meep source pacakge did not

I of course meant the mpb source package

> generate the mpb-dev binary package like it does on some of the
> other arches.
> 
> 
> Kurt
> 

Re: Please give back meep on mipsel

[Kurt Roeckx]

On Tue, Jan 01, 2019 at 04:59:17PM +0100, Thorsten Alteholz wrote:
> Hi,
> 
> the mipsel buildd marked meep as "unsatisfiable Build-Depends(-Arch) on
> mipsel: mpb-dev".
> As mpb-dev is finally available on mipsel, please give meep back:
> 
>gb meep_1.7.0-2 . mipsel

Build-Depends are checked automatically. mpb-dev is still not
available on mipsel. On mipsel, the meep source pacakge did not
generate the mpb-dev binary package like it does on some of the
other arches.


Kurt

Re: [openssl-users] Authentication over ECDHE

[Kurt Roeckx]

On Mon, Dec 31, 2018 at 02:11:56PM +, Matt Caswell wrote:
> 
> Well, you have vocally complained about the state of the documentation. You 
> have
> the benefit of being a new OpenSSL user. You know what things were confusing 
> or
> unclear in the documentation. More experienced OpenSSL coders often don't have
> the perspective - because some things are just "obvious" to them. So help with
> pull requests to improve the documentation.

Or you could just file a bug pointing out the areas that are
unclear.


Kurt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Accepted elfutils 0.175-2 (source) into unstable

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 30 Dec 2018 15:02:01 +0100
Source: elfutils
Binary: elfutils libelf1 libelf-dev libdw-dev libdw1 libasm1 libasm-dev
Architecture: source
Version: 0.175-2
Distribution: unstable
Urgency: medium
Maintainer: Kurt Roeckx 
Changed-By: Kurt Roeckx 
Description:
 elfutils   - collection of utilities to handle ELF objects
 libasm-dev - libasm development libraries and header files
 libasm1- library with a programmable assembler interface
 libdw-dev  - libdw1 development libraries and header files
 libdw1 - library that provides access to the DWARF debug information
 libelf-dev - libelf1 development libraries and header files
 libelf1- library to read and write ELF files
Changes:
 elfutils (0.175-2) unstable; urgency=medium
 .
   * Add support for the mips ABI CFI callback
   * Properly clean up in test suite on skipped tests
Checksums-Sha1:
 f3005c06bc6d1fca972f6478b75e82edbee566fb 2568 elfutils_0.175-2.dsc
 b4a6ac7f6d2577eb6015de140c745d52f7f9826a 38308 elfutils_0.175-2.debian.tar.xz
 f27e3e20bfd6f68e68a81beb89dd060f57ba31cf 8032 elfutils_0.175-2_source.buildinfo
Checksums-Sha256:
 d256b8eaf5a3b8390b0a66d215a7bb11375c01a5fe1eb2b32861432249a9d1af 2568 
elfutils_0.175-2.dsc
 e4c0cfd5381387964fbb1ccee085b3b37564b16100eb36588ba72bba7eff062d 38308 
elfutils_0.175-2.debian.tar.xz
 f742246021eaae301c33d230dac5f2d9ae1535c6e6ec9d5ed803143a95dfcffe 8032 
elfutils_0.175-2_source.buildinfo
Files:
 8ae42c9e2ac565b1964f2724bcc8ee64 2568 libs optional elfutils_0.175-2.dsc
 14cd2ae585b3e058c008549c49723724 38308 libs optional 
elfutils_0.175-2.debian.tar.xz
 31c074f3f65835d713716223d7ce51c7 8032 libs optional 
elfutils_0.175-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEUWHm1ANgDdycoJP748TdzR5MEkQFAlwo0goACgkQ48TdzR5M
EkTpPBAAjUjG1PdqVuct5RFeAPhoiEqLPiuGbO5HCDeCDpm7/KoV4xjA9Xk9DHP0
rXv1qoMZOdI5KmbgsbQoRmeBpyv+Wayiy6FH+pb7wGcvH0WMtAsbRbcCaKpKS4Rh
r3ERp1A/nq/MZiIf4zWPEPpt6xBIJA3we6hMDwvG72QOolM0gmdE0m2riaBq5Ddm
Mjf7sqMmFFahkYUzxzQG5zAhlbW8IxLafWTVLhYQn7QvPJIs0HlkIUaDNaX1eRfn
idMso3GOmujvL8rxKm+ZT1/+IjXKega/2l12DkEuasNHzJB+1vhMxjGy2nGZhNUN
EG2VwwhbWAToU2TIp87UMTwHFQJEKaumnVtbsZ4ot2s2i79eFw+bpqvRZzVtPQoa
palO3+Xsr3CkvhuwdfGaTorxMZAWxDPK8oPp4qwOPTLtARuSj3WP8Pae0GqCz6jE
bX11lt5SNqhkgwwZ6bAPdOA44T9x1/zlwS2t57Ka/+H6eKmr1+GlJkYtXH2yysXP
9KTfih7NUF2K1zYgznf7puWwfO2Rb7G90b4ahwpULstAtCN/hjDDE+0ELmg7gWHz
zkH5fkvgh1pJDSW7Z9L/A7kuxZb/m0lJFNf+gBjqXiUDut1ghKG7vziZ4CbcaceI
GTiDWjDJtB/Jp6UYbJIVSmjVAzKzoUh/9gjvch44c0un9o6tHwU=
=5FjI
-END PGP SIGNATURE-

Bug#917366: RFP: postfix-mta-sts-resolver -- daemon that adds support for MTA-STS to postfix

[Kurt Roeckx]

Package: wnpp
Severity: wishlist

* Package name: postfix-mta-sts-resolver
  Version : 0.2.4
* URL : https://github.com/Snawoot/postfix-mta-sts-resolver
* License : MIT
  Programming Lang: python
  Description : Daemon which provides TLS client policy for
Postfix via socketmap, according to domain MTA-STS
policy.

Bug#917366: RFP: postfix-mta-sts-resolver -- daemon that adds support for MTA-STS to postfix

[Kurt Roeckx]

Package: wnpp
Severity: wishlist

* Package name: postfix-mta-sts-resolver
  Version : 0.2.4
* URL : https://github.com/Snawoot/postfix-mta-sts-resolver
* License : MIT
  Programming Lang: python
  Description : Daemon which provides TLS client policy for
Postfix via socketmap, according to domain MTA-STS
policy.

Bug#917366: RFP: postfix-mta-sts-resolver -- daemon that adds support for MTA-STS to postfix

[Kurt Roeckx]

Package: wnpp
Severity: wishlist

* Package name: postfix-mta-sts-resolver
  Version : 0.2.4
* URL : https://github.com/Snawoot/postfix-mta-sts-resolver
* License : MIT
  Programming Lang: python
  Description : Daemon which provides TLS client policy for
Postfix via socketmap, according to domain MTA-STS
policy.

Re: Online exposed keys database

[Kurt Roeckx via dev-security-policy]

On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy 
wrote:
> On 2018-12-18 11:44, Matt Palmer wrote:
> > It's currently loaded with great piles of Debian weak keys (from multiple
> > architectures, etc), as well as some keys I've picked up at various times.
> > I'm also developing scrapers for various sites where keys routinely get
> > dropped.
> 
> You might for instance also want to look at
> https://github.com/devttys0/littleblackbox, I'm not sure how useful it is.

You might also want to contact the people from
https://factorable.net/


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Bug#916873: python-twisted-core: Incorrect versioned dependency on python-attr

[Kurt Roeckx]

Package: python-twisted-core
Version: 18.7.0-2~bpo9+1
Severity: serious

Hi,

With python-twisted-core and python-attr 16.3.0-1, I get the
following error:
[...]
  File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 100, in 

from twisted.internet import interfaces, protocol, address
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py", line 23, 
in 
class IPv4Address(object):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py", line 37, 
in IPv4Address
type = attr.ib(validator=attr.validators.in_(["TCP", "UDP"]))
AttributeError: 'module' object has no attribute 'in_'

Upgrading python-attr to the version from backports (17.4.0-2~bpo9+1) works.


Kurt

[Python-modules-team] Bug#916873: python-twisted-core: Incorrect versioned dependency on python-attr

[Kurt Roeckx]

Package: python-twisted-core
Version: 18.7.0-2~bpo9+1
Severity: serious

Hi,

With python-twisted-core and python-attr 16.3.0-1, I get the
following error:
[...]
  File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 100, in 

from twisted.internet import interfaces, protocol, address
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py", line 23, 
in 
class IPv4Address(object):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py", line 37, 
in IPv4Address
type = attr.ib(validator=attr.validators.in_(["TCP", "UDP"]))
AttributeError: 'module' object has no attribute 'in_'

Upgrading python-attr to the version from backports (17.4.0-2~bpo9+1) works.


Kurt

___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#916873: python-twisted-core: Incorrect versioned dependency on python-attr

[Kurt Roeckx]

Package: python-twisted-core
Version: 18.7.0-2~bpo9+1
Severity: serious

Hi,

With python-twisted-core and python-attr 16.3.0-1, I get the
following error:
[...]
  File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 100, in 

from twisted.internet import interfaces, protocol, address
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py", line 23, 
in 
class IPv4Address(object):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py", line 37, 
in IPv4Address
type = attr.ib(validator=attr.validators.in_(["TCP", "UDP"]))
AttributeError: 'module' object has no attribute 'in_'

Upgrading python-attr to the version from backports (17.4.0-2~bpo9+1) works.


Kurt

Re: Online exposed keys database

[Kurt Roeckx via dev-security-policy]

On 2018-12-19 10:55, Matt Palmer wrote:

On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy 
wrote:

On 2018-12-18 11:44, Matt Palmer wrote:

It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I've picked up at various times.
I'm also developing scrapers for various sites where keys routinely get
dropped.


You might for instance also want to look at
https://github.com/devttys0/littleblackbox, I'm not sure how useful it is.


Oh my, that's an interesting trove.  I was a bit worried at first that the
private keys weren't included, but it looks like there's at least some in
there.


I'm not sure how you feel about listing keys where you don't have the 
private key for, but are known to be compromised anyway. One potential 
source for such information might be CRLs where the reason for 
revocation was keyCompromise.


If you don't want to publish the private keys, distributing the public 
keys might be an option.



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Online exposed keys database

[Kurt Roeckx via dev-security-policy]

On 2018-12-18 11:44, Matt Palmer wrote:

It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I've picked up at various times.
I'm also developing scrapers for various sites where keys routinely get
dropped.


You might for instance also want to look at 
https://github.com/devttys0/littleblackbox, I'm not sure how useful it is.



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[openssl-commits] [openssl] master update

[Kurt Roeckx]

The branch master has been updated
   via  6e94b5aecd619afd25e3dc25902952b1b3194edf (commit)
  from  04cd70c6899c6b36517b2b07d7a12b2cceba1bef (commit)


- Log -
commit 6e94b5aecd619afd25e3dc25902952b1b3194edf
Author: Kurt Roeckx 
Date:   Fri Nov 2 15:51:19 2018 +0100

Convert tls1_prf_P_hash to use the EVP_MAC interface

Reviewed-by: Richard Levitte 
GH: #7554

---

Summary of changes:
 crypto/kdf/tls1_prf.c | 46 +++---
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/crypto/kdf/tls1_prf.c b/crypto/kdf/tls1_prf.c
index c3be7dd..24ad59b 100644
--- a/crypto/kdf/tls1_prf.c
+++ b/crypto/kdf/tls1_prf.c
@@ -178,8 +178,7 @@ static int tls1_prf_P_hash(const EVP_MD *md,
unsigned char *out, size_t olen)
 {
 int chunk;
-EVP_MD_CTX *ctx = NULL, *ctx_tmp = NULL, *ctx_init = NULL;
-EVP_PKEY *mac_key = NULL;
+EVP_MAC_CTX *ctx = NULL, *ctx_tmp = NULL, *ctx_init = NULL;
 unsigned char A1[EVP_MAX_MD_SIZE];
 size_t A1_len;
 int ret = 0;
@@ -188,47 +187,49 @@ static int tls1_prf_P_hash(const EVP_MD *md,
 if (!ossl_assert(chunk > 0))
 goto err;
 
-ctx = EVP_MD_CTX_new();
-ctx_tmp = EVP_MD_CTX_new();
-ctx_init = EVP_MD_CTX_new();
+ctx = EVP_MAC_CTX_new_id(EVP_MAC_HMAC);
+ctx_tmp = EVP_MAC_CTX_new_id(EVP_MAC_HMAC);
+ctx_init = EVP_MAC_CTX_new_id(EVP_MAC_HMAC);
 if (ctx == NULL || ctx_tmp == NULL || ctx_init == NULL)
 goto err;
-EVP_MD_CTX_set_flags(ctx_init, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW);
-mac_key = EVP_PKEY_new_raw_private_key(EVP_PKEY_HMAC, NULL, sec, sec_len);
-if (mac_key == NULL)
+if (EVP_MAC_ctrl(ctx_init, EVP_MAC_CTRL_SET_FLAGS, 
EVP_MD_CTX_FLAG_NON_FIPS_ALLOW) != 1)
 goto err;
-if (!EVP_DigestSignInit(ctx_init, NULL, md, NULL, mac_key))
+if (EVP_MAC_ctrl(ctx_init, EVP_MAC_CTRL_SET_MD, md) != 1)
 goto err;
-if (!EVP_MD_CTX_copy_ex(ctx, ctx_init))
+if (EVP_MAC_ctrl(ctx_init, EVP_MAC_CTRL_SET_KEY, sec, sec_len) != 1)
 goto err;
-if (seed != NULL && !EVP_DigestSignUpdate(ctx, seed, seed_len))
+if (!EVP_MAC_init(ctx_init))
 goto err;
-if (!EVP_DigestSignFinal(ctx, A1, _len))
+if (!EVP_MAC_CTX_copy(ctx, ctx_init))
+goto err;
+if (seed != NULL && !EVP_MAC_update(ctx, seed, seed_len))
+goto err;
+if (!EVP_MAC_final(ctx, A1, _len))
 goto err;
 
 for (;;) {
 /* Reinit mac contexts */
-if (!EVP_MD_CTX_copy_ex(ctx, ctx_init))
+if (!EVP_MAC_CTX_copy(ctx, ctx_init))
 goto err;
-if (!EVP_DigestSignUpdate(ctx, A1, A1_len))
+if (!EVP_MAC_update(ctx, A1, A1_len))
 goto err;
-if (olen > (size_t)chunk && !EVP_MD_CTX_copy_ex(ctx_tmp, ctx))
+if (olen > (size_t)chunk && !EVP_MAC_CTX_copy(ctx_tmp, ctx))
 goto err;
-if (seed && !EVP_DigestSignUpdate(ctx, seed, seed_len))
+if (seed != NULL && !EVP_MAC_update(ctx, seed, seed_len))
 goto err;
 
 if (olen > (size_t)chunk) {
 size_t mac_len;
-if (!EVP_DigestSignFinal(ctx, out, _len))
+if (!EVP_MAC_final(ctx, out, _len))
 goto err;
 out += mac_len;
 olen -= mac_len;
 /* calc the next A1 value */
-if (!EVP_DigestSignFinal(ctx_tmp, A1, _len))
+if (!EVP_MAC_final(ctx_tmp, A1, _len))
 goto err;
 } else {/* last one */
 
-if (!EVP_DigestSignFinal(ctx, A1, _len))
+if (!EVP_MAC_final(ctx, A1, _len))
 goto err;
 memcpy(out, A1, olen);
 break;
@@ -236,10 +237,9 @@ static int tls1_prf_P_hash(const EVP_MD *md,
 }
 ret = 1;
  err:
-EVP_PKEY_free(mac_key);
-EVP_MD_CTX_free(ctx);
-EVP_MD_CTX_free(ctx_tmp);
-EVP_MD_CTX_free(ctx_init);
+EVP_MAC_CTX_free(ctx);
+EVP_MAC_CTX_free(ctx_tmp);
+EVP_MAC_CTX_free(ctx_init);
 OPENSSL_cleanse(A1, sizeof(A1));
 return ret;
 }
_
openssl-commits mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits

[openssl-commits] [openssl] master update

[Kurt Roeckx]

The branch master has been updated
   via  04cd70c6899c6b36517b2b07d7a12b2cceba1bef (commit)
   via  5c587fb6b996d47771bcaecd71489e4849103f56 (commit)
  from  91c5473035aaf2c0d86e4039c2a29a5b70541905 (commit)


- Log -
commit 04cd70c6899c6b36517b2b07d7a12b2cceba1bef
Author: Kurt Roeckx 
Date:   Tue Sep 18 22:17:14 2018 +0200

Deprecate TLS_MAX_VERSION, DTLS_MAX_VERSION and DTLS_MIN_VERSION

Fixes: #7183

Reviewed-by: Matt Caswell 
GH: #7260

commit 5c587fb6b996d47771bcaecd71489e4849103f56
Author: Kurt Roeckx 
Date:   Sun Dec 9 20:53:05 2018 +0100

Use (D)TLS_MAX_VERSION_INTERNAL internally

Use 0 if we don't want to set a minimum or maximum version

Reviewed-by: Matt Caswell 
GH: #7260

---

Summary of changes:
 include/openssl/dtls1.h  |  8 +--
 include/openssl/tls1.h   |  4 +++-
 ssl/d1_lib.c |  2 +-
 ssl/ssl_locl.h   |  3 +++
 ssl/statem/statem_clnt.c |  2 +-
 ssl/statem/statem_lib.c  | 10 -
 ssl/t1_lib.c |  2 +-
 test/asynciotest.c   |  2 +-
 test/clienthellotest.c   |  2 +-
 test/dtlstest.c  |  8 +++
 test/fatalerrtest.c  |  2 +-
 test/gosttest.c  |  2 +-
 test/recordlentest.c |  2 +-
 test/servername_test.c   |  2 +-
 test/ssl_test.c  | 27 
 test/sslapitest.c| 55 +++-
 test/sslbuffertest.c |  2 +-
 test/sslcorrupttest.c|  2 +-
 test/ssltest_old.c   |  8 +++
 test/tls13ccstest.c  |  2 +-
 20 files changed, 72 insertions(+), 75 deletions(-)

diff --git a/include/openssl/dtls1.h b/include/openssl/dtls1.h
index 21b5252..f717afb 100644
--- a/include/openssl/dtls1.h
+++ b/include/openssl/dtls1.h
@@ -14,10 +14,14 @@
 extern "C" {
 #endif
 
+#include 
+
 # define DTLS1_VERSION   0xFEFF
 # define DTLS1_2_VERSION 0xFEFD
-# define DTLS_MIN_VERSIONDTLS1_VERSION
-# define DTLS_MAX_VERSIONDTLS1_2_VERSION
+# if !OPENSSL_API_3
+#  define DTLS_MIN_VERSIONDTLS1_VERSION
+#  define DTLS_MAX_VERSIONDTLS1_2_VERSION
+# endif
 # define DTLS1_VERSION_MAJOR 0xFE
 
 # define DTLS1_BAD_VER   0x0100
diff --git a/include/openssl/tls1.h b/include/openssl/tls1.h
index c57344c..166f15a 100644
--- a/include/openssl/tls1.h
+++ b/include/openssl/tls1.h
@@ -28,7 +28,9 @@ extern "C" {
 # define TLS1_1_VERSION  0x0302
 # define TLS1_2_VERSION  0x0303
 # define TLS1_3_VERSION  0x0304
-# define TLS_MAX_VERSION TLS1_3_VERSION
+# if !OPENSSL_API_3
+#  define TLS_MAX_VERSIONTLS1_3_VERSION
+# endif
 
 /* Special value for method supporting multiple versions */
 # define TLS_ANY_VERSION 0x1
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index 2da9ebb..d3f681b 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -192,7 +192,7 @@ int dtls1_clear(SSL *s)
 return 0;
 
 if (s->method->version == DTLS_ANY_VERSION)
-s->version = DTLS_MAX_VERSION;
+s->version = DTLS_MAX_VERSION_INTERNAL;
 #ifndef OPENSSL_NO_DTLS1_METHOD
 else if (s->options & SSL_OP_CISCO_ANYCONNECT)
 s->client_version = s->version = DTLS1_BAD_VER;
diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h
index c2e6474..2d68691 100644
--- a/ssl/ssl_locl.h
+++ b/ssl/ssl_locl.h
@@ -131,6 +131,9 @@
(c)[1]=(unsigned char)(((l)>> 8)&0xff), \
(c)[2]=(unsigned char)(((l))&0xff)),(c)+=3)
 
+# define TLS_MAX_VERSION_INTERNAL TLS1_3_VERSION
+# define DTLS_MAX_VERSION_INTERNAL DTLS1_2_VERSION
+
 /*
  * DTLS version numbers are strange because they're inverted. Except for
  * DTLS1_BAD_VER, which should be considered "lower" than the rest.
diff --git a/ssl/statem/statem_clnt.c b/ssl/statem/statem_clnt.c
index c1a572f..3b6cbb7 100644
--- a/ssl/statem/statem_clnt.c
+++ b/ssl/statem/statem_clnt.c
@@ -163,7 +163,7 @@ static int ossl_statem_client13_read_transition(SSL *s, int 
mt)
 return 1;
 }
 if (mt == SSL3_MT_CERTIFICATE_REQUEST) {
-#if DTLS_MAX_VERSION != DTLS1_2_VERSION
+#if DTLS_MAX_VERSION_INTERNAL != DTLS1_2_VERSION
 # error TODO(DTLS1.3): Restore digest for PHA before adding message.
 #endif
 if (!SSL_IS_DTLS(s) && s->post_handshake_auth == SSL_PHA_EXT_SENT) 
{
diff --git a/ssl/statem/statem_lib.c b/ssl/statem/statem_lib.c
index 9e68e05..1a9aa41 100644
--- a/ssl/statem/statem_lib.c
+++ b/ssl/statem/statem_lib.c
@@ -1417,7 +1417,7 @@ typedef struct {
 const SSL_METHOD *(*smeth) (void);
 } version_info;
 
-#if TLS_MAX_VERSION != TLS1_3_VERSION
+#if TLS_MAX_VERSION_INTERNAL != TLS1_3_VERSION
 # error Code n

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Kurt Roeckx]

On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote:
> One mitigating factor of the ETSI standard, i suppose, is that the
> CABForum's Baseline Requirements forbid issuance of a certificate with
> any subjectAltName other than dNSName or iPAddress, so otherName looks
> like it must not be issued by standard public CAs.
> 
> top of p. 44 of 
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf
> 
> Has anyone set up tools to monitor the CT logs for such a sAN to see
> whether that element of the BR is being honored?

All the linters will give an error about that, see for instance:
https://crt.sh/?id=1009623020=x509lint,cablint,zlint


Kurt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [openssl-project] Vote to update the security policy

[Kurt Roeckx]

On Thu, Nov 29, 2018 at 03:34:29PM +, Mark J Cox wrote:
> Changes to policies require an OMC vote which I've called to approve an
> update to the security policy.  This was as discussed at the face to face
> and the details and diff are at https://github.com/openssl/web/pull/96
> 
> 
> topic: Update security policy as per https://github.com/openssl/web/pull/96

This vote failed with 4 votes against and 3 people not voting.

The intend of voting against is to work on the wording and then
call a new vote.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Bug#915612: [Pkg-openssl-devel] Bug#915612: openssl: "genrsa" changed command line interface in stretch-security update

[Kurt Roeckx]

On Wed, Dec 05, 2018 at 10:03:50PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-12-05 11:09:25 [+0100], Manuel Montecelo wrote:
> > the subcommand genrsa changed interface from its previous version, and does 
> > not
> > accept -config or -batch options anymore:
> …
> 
> > I worked around the issue in other ways, and I know that "genpkey" is 
> > supposed
> > to supercede "genrsa", but this problem might affect scripts that the users
> > cannot easily change, and it's OK-ish for major versions but would be nice 
> > to
> > not affect systems with stable-security updates.
> > 
> > For reference, command that used to work:
> > 
> >  openssl genrsa -out "${KEY_FILE}" 4096 -config "${CONFIG_FILE}" -batch
> > 
> > As a workaround with "genrsa":
> > 
> >  OPENSSL_CONF="${CONFIG_FILE}" openssl genrsa -out "${KEY_FILE}" 4096
> 
> Are you sure that the workaround vs
>   openssl genrsa -out "${KEY_FILE}" 4096
> 
> makes a difference? 
> 
> I'm asking because bisect identifies commit 847997f98c28b ("Check # of
> arguments for remaining commands.") as the one that introduced the
> regression. This change only adds the error if you specify invalid
> arguments. Both `-config' and `-batch' are not part of accepted
> arguments.
> So I think 1.1.0f should produce the same result with or without those
> two options. Is it true?

It stops parsing for options when it doesn't find an argument that
start with a '-', so 4096 is not an option anymore, but it tries
to convert it to the number of bits. Everything after that was
just ignored, now it gives an error.

Also note that the manpage does put [numbits] at the end of the
arguments. It was clear to me that it needs to be the last
argument, but I can at least see why it might not be clear.


Kurt

[openssl-commits] [web] master update

[Kurt Roeckx]

The branch master has been updated
   via  0d92547742c3da2f066f4babaacf8a51bb2f5e3c (commit)
  from  be4639ae76f20fccfd718dea2aaa7def1dbe8a55 (commit)


- Log -
commit 0d92547742c3da2f066f4babaacf8a51bb2f5e3c
Author: Kurt Roeckx 
Date:   Wed Dec 5 22:22:04 2018 +0100

Update PGP key

---

Summary of changes:
 news/openssl-security.asc | 80 +++
 1 file changed, 40 insertions(+), 40 deletions(-)

diff --git a/news/openssl-security.asc b/news/openssl-security.asc
index fb0482f..9dddc89 100644
--- a/news/openssl-security.asc
+++ b/news/openssl-security.asc
@@ -11,33 +11,33 @@ 
Ce9tWq6oK+o1MEc1Ejb1/kn9CeCloKlF8HkzhFLpqqkZ//3j73/6kuK45UVg5PbO
 5HCnafDroN5wF9jMVxFhmDOOdXyIeYkBVF6swwIlyq8VlYSjYWGAUtIb3rOiUNWc
 zYY6spdAN6VtKTMnXTm608yH118p+UOB5rJuKBqk3tMaiIjoyOcya4ImenX85rfK
 eCOVNtdOC/0N8McfO0eFc6fZxcy7ykZ1a7FLyqQDexpZM7OLoM5SXObX1QARAQAB
-tCVPcGVuU1NMIE9NQyA8b3BlbnNzbC1vbWNAb3BlbnNzbC5vcmc+iQJUBBMBCgA+
-AhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAFiEE78CkZ9YTy4PH7W0w2JTizos9
-efUFAlvEwBgFCQmW/3kACgkQ2JTizos9efV3tBAAg/XTimvGMtCvMawu+ymbXshC
-W+PTt3tH2oI7parnm8F0DY3c70rwKN1uu28Cds0QOpAUR8wsYe9HbXXfT7w+4JG6
-qJm3mfAin9QA49D99SN3TgSTOK7qU1p88nCpEs0dib4aF5gO2zaqRiIEbTkiQSjQ
-lTzLS0kfznNmfynJI25XWNddLM2munn9ZS7XPQqzZ0G/RkDbuIayG0axRRcr8iG/
-uOkfFz3Iwk58MnzKVqPf+n7ZPTG6Z7EEcLF92Lo58x+s9tJ5afr0bTRG1wn5L8+I
-++OEIn32CwPQ0B6FeI42jeXGdd4rGjgzZyBbqvUD2zei85Sa306ZUOLoD5iuSAXt
-VkyK2rRRqfGy8m+R0TV1TQ25SkQadUf1fz1gS+QtyA4MhuM4f9PYR6kNUzjHkGAw
-w6KTG+bHiiQdAOKCEDYZgz9bY9wSD53fQTh8r5DhQ9edgFQAZsJ5R5jouZu+5beG
-8VP1OuvgKA478y/VWX6xnKLCqAfiF+p4ae0WDTm2cQiZyskTLQ2NaC0xEmAg9DgT
-d0v9NteVVMKeVppaGsE21vaX7s228Pj2sf8EAwl5iqtcJZMVVMHdmMerojd0HnmW
-PplbBVowaTTxLcMz/Xqlrxl7ylh6NqA3hFK1BwhFkAH6IEvXYmuAZNEtzFl+t4m5
-lsGHrlH+lstQuSl25v+0NE9wZW5TU0wgc2VjdXJpdHkgdGVhbSA8b3BlbnNzbC1z
-ZWN1cml0eUBvcGVuc3NsLm9yZz6JAlQEEwEKAD4CGwMFCwkIBwMFFQoJCAsFFgID
-AQACHgECF4AWIQTvwKRn1hPLg8ftbTDYlOLOiz159QUCW8TAJwUJCZb/eQAKCRDY
-lOLOiz159bbcEACpio13Jc6porVHoi5izZ9w9xCYiv6whrhgjdBCPm+JP6bPb0aN
-T0EkhQ4oBsOh3iCtVrBXjeagXK1NR1Sze/PH/kxARg9Nx6rafv9jRF2irO0E8+fY
-U2nV2z8Sjuej2uAIfMEJW0GnOJsR/pnn+a6P2Na8qwuwoEoWW2rTwqgCNOPwTWAW
-qgB5sYrt5M8RhmSZXW0v6NmCAQVrnGbEsqgCuBLo0WqyPszW6BEQqUsvj4aAAucS
-IZr2vaN4TnXhg0VdlI1f1E32ms2lSkNXECdSYWeT1eWVn2nPKibpePrJXuHHEP1G
-qM9z70+otqNn7qbIIr2aCu9aoAkcqbNCM6WN6FgZb0BH/XLByZM6ksLjO5OD1BHS
-PkK7HDTLDaTQFYbzH1ItpuWWvVh+l95a5Amm3Ic4JZyTbw0I7S4n0lo+JG4l89Wr
-WsYwAJsj1Chn0TitF/VTMG7JOtFHKBKzNvXOY7H85zU8AxvC5lis5vLepSc41NXw
-JoR7l+Cwi1hFIJIRO6RSVp3BwI+mASRZAn9ZaCqNyfDHhFQntpn607pRl2eHvO57
-KN1r1fJOZBx8P9p4S0sqBs9QXF4wNlBM2v/Te4MGq+wzQQFtofJuBSEpN0jHpVup
-HGZRWkCSydM4ToCRrwEhclv3GvUmi1WAzy25SBbaR408/BgEAT2Xr6TUXLQnT3Bl
+tDRPcGVuU1NMIHNlY3VyaXR5IHRlYW0gPG9wZW5zc2wtc2VjdXJpdHlAb3BlbnNz
+bC5vcmc+iQJUBBMBCgA+AhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAFiEE78Ck
+Z9YTy4PH7W0w2JTizos9efUFAlvEwCcFCQmW/3kACgkQ2JTizos9efW23BAAqYqN
+dyXOqaK1R6IuYs2fcPcQmIr+sIa4YI3QQj5viT+mz29GjU9BJIUOKAbDod4grVaw
+V43moFytTUdUs3vzx/5MQEYPTceq2n7/Y0RdoqztBPPn2FNp1ds/Eo7no9rgCHzB
+CVtBpzibEf6Z5/muj9jWvKsLsKBKFltq08KoAjTj8E1gFqoAebGK7eTPEYZkmV1t
+L+jZggEFa5xmxLKoArgS6NFqsj7M1ugREKlLL4+GgALnEiGa9r2jeE514YNFXZSN
+X9RN9prNpUpDVxAnUmFnk9XllZ9pzyom6Xj6yV7hxxD9RqjPc+9PqLajZ+6myCK9
+mgrvWqAJHKmzQjOljehYGW9AR/1ywcmTOpLC4zuTg9QR0j5Cuxw0yw2k0BWG8x9S
+Labllr1YfpfeWuQJptyHOCWck28NCO0uJ9JaPiRuJfPVq1rGMACbI9QoZ9E4rRf1
+UzBuyTrRRygSszb1zmOx/Oc1PAMbwuZYrOby3qUnONTV8CaEe5fgsItYRSCSETuk
+UladwcCPpgEkWQJ/WWgqjcnwx4RUJ7aZ+tO6UZdnh7zueyjda9XyTmQcfD/aeEtL
+KgbPUFxeMDZQTNr/03uDBqvsM0EBbaHybgUhKTdIx6VbqRxmUVpAksnTOE6Aka8B
+IXJb9xr1JotVgM8tuUgW2keNPPwYBAE9l6+k1Fy0JU9wZW5TU0wgT01DIDxvcGVu
+c3NsLW9tY0BvcGVuc3NsLm9yZz6JAlQEEwEKAD4CGwMFCwkIBwMFFQoJCAsFFgID
+AQACHgECF4AWIQTvwKRn1hPLg8ftbTDYlOLOiz159QUCW8TAGAUJCZb/eQAKCRDY
+lOLOiz159Xe0EACD9dOKa8Yy0K8xrC77KZteyEJb49O3e0fagjulquebwXQNjdzv
+SvAo3W67bwJ2zRA6kBRHzCxh70dtdd9PvD7gkbqombeZ8CKf1ADj0P31I3dOBJM4
+rupTWnzycKkSzR2JvhoXmA7bNqpGIgRtOSJBKNCVPMtLSR/Oc2Z/KckjbldY110s
+zaa6ef1lLtc9CrNnQb9GQNu4hrIbRrFFFyvyIb+46R8XPcjCTnwyfMpWo9/6ftk9
+MbpnsQRwsX3YujnzH6z20nlp+vRtNEbXCfkvz4j744QiffYLA9DQHoV4jjaN5cZ1
+3isaODNnIFuq9QPbN6LzlJrfTplQ4ugPmK5IBe1WTIratFGp8bLyb5HRNXVNDblK
+RBp1R/V/PWBL5C3IDgyG4zh/09hHqQ1TOMeQYDDDopMb5seKJB0A4oIQNhmDP1tj
+3BIPnd9BOHyvkOFD152AVABmwnlHmOi5m77lt4bxU/U66+AoDjvzL9VZfrGcosKo
+B+IX6nhp7RYNObZxCJnKyRMtDY1oLTESYCD0OBN3S/0215VUwp5WmloawTbW9pfu
+zbbw+Pax/wQDCXmKq1wlkxVUwd2Yx6uiN3QeeZY+mVsFWjBpNPEtwzP9eqWvGXvK
+WHo2oDeEUrUHCEWQAfogS9dia4Bk0S3MWX63ibmWwYeuUf6Wy1C5KXbm/7QnT3Bl
 blNTTCB0ZWFtIDxvcGVuc3NsLXRlYW1Ab3BlbnNzbC5vcmc+iQJZBDABCgBDFiEE
 78CkZ9YTy4PH7W0w2JTizos9efUFAlnZ9jUlHSBSZXBsYWNlZCBieSBvcGVuc3Ns
 LW9tY0BvcGVuc3NsLm9yZwAKCRDYlOLOiz159VAiD/wLVz8KE84z+iPBcDXJR4hr
@@ -63,17 +63,17 @@ 
ncd+VYvth6cM9jDWsTJAXEaqNoFjVfw227NnQ/hxqGCwEVzweBi7a7dix3nCa9JO
 w5eV3xCyezUohQ6nOBbDnoAnp3FLeUrhBJQXCPNtlb0fSMnj14EwBoD6EKO/xz/g
 EW5mr0a+xp+fjbkvHVX/c8UmU

Re: Incident report Certum CA: Corrupted certificates

[Kurt Roeckx via dev-security-policy]

On Tue, Dec 04, 2018 at 01:14:44PM -0500, Ryan Sleevi via dev-security-policy 
wrote:
> 
> > All issued certificates were unusable due to corrupted signature.
> >
> 
> Could you speak to more about how you assessed this? An incorrect signature
> on the CRL would not necessarily prevent the certificate from being used;
> it may merely prevent it from being revoked. That is, all 30,000 (revoked)
> certificates may have been usable due to the corrupted signature.

He explained before that the module that generated the corrupt
signature for the CRL was in a weird state after that and all
the newly issued certificates signed by that module also had
corrupt signatures.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Elfutils mips support

[Kurt Roeckx]

On Mon, Nov 26, 2018 at 05:54:51PM +0800, YunQiang Su wrote:
> Let me have a try and then maybe ask somebody help inner MIPS.

Any update on this?


Kurt

Re: Incident report Certum CA: Corrupted certificates

[Kurt Roeckx via dev-security-policy]

On 2018-12-04 10:25, Wojciech Trapczyński wrote:

On 04.12.2018 10:01, Kurt Roeckx via dev-security-policy wrote:

On 2018-12-04 7:24, Wojciech Trapczyński wrote:

Question 1: Was there a period during which this issuing CA had no
   validly signed non-expired CRL due to this incident?



Between 10.11.2018 01:05 (UTC±00:00) and 14.11.2018 07:35 (UTC±00:00) 
we were serving one CRL with corrupted signature.


Do you have any plans to prevent serving CRLs with an invalid 
signature and keep the old CRL in place until you have a valid one?


This one CRL with corrupted signature was serving between dates I 
mentioned. Starting from November 14th 07:35 (UTC±00:00) we are serving 
CRL with a valid signature. I have described it in the Bugzilla bug 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1511459#c2).


I think you misunderstood my question. I think you should never serve an 
invalid file. I think it's better to have a file that is 1 or 2 days old 
then it is to have an invalid file. So you could check that it's a valid 
file before you start serving it, and if it's invalid keep the old file.



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident report Certum CA: Corrupted certificates

[Kurt Roeckx via dev-security-policy]

On 2018-12-04 7:24, Wojciech Trapczyński wrote:

Question 1: Was there a period during which this issuing CA had no
   validly signed non-expired CRL due to this incident?



Between 10.11.2018 01:05 (UTC±00:00) and 14.11.2018 07:35 (UTC±00:00) we 
were serving one CRL with corrupted signature.


Do you have any plans to prevent serving CRLs with an invalid signature 
and keep the old CRL in place until you have a valid one?



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Bug#900160: closed by Didier Raboud (Bug#900160: fixed in ruby-eventmachine 1.0.7-4.1)

[Kurt Roeckx]

On Sun, Dec 02, 2018 at 11:36:06PM +0100, gregor herrmann wrote:
> On Sun, 02 Dec 2018 23:18:38 +0100, Sebastian Andrzej Siewior wrote:
> 
> > On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
> > > #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
> > >  ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
> > >  .
> > >* Non-maintainer upload.
> > >* Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
> > >  (Closes: #900160)
> > 
> > Please revert that one. We don't want more dependencies on
> > libssl1.0-dev. We want it actually out of testing and are down to one
> > package.
> > I wouldn't care much but since ruby-eventmachine is a key package it
> > might migrate to testing…
> 
> Raising the severity of the cloned #915287 which tracks this problem
> should prevent the migration.

It won't, since it affects also the version in testing, it can
just migrate.


Kurt

[DRE-maint] Bug#900160: closed by Didier Raboud (Bug#900160: fixed in ruby-eventmachine 1.0.7-4.1)

[Kurt Roeckx]

On Sun, Dec 02, 2018 at 11:36:06PM +0100, gregor herrmann wrote:
> On Sun, 02 Dec 2018 23:18:38 +0100, Sebastian Andrzej Siewior wrote:
> 
> > On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
> > > #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
> > >  ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
> > >  .
> > >* Non-maintainer upload.
> > >* Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
> > >  (Closes: #900160)
> > 
> > Please revert that one. We don't want more dependencies on
> > libssl1.0-dev. We want it actually out of testing and are down to one
> > package.
> > I wouldn't care much but since ruby-eventmachine is a key package it
> > might migrate to testing…
> 
> Raising the severity of the cloned #915287 which tracks this problem
> should prevent the migration.

It won't, since it affects also the version in testing, it can
just migrate.


Kurt

___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

Bug#900160: closed by Didier Raboud (Bug#900160: fixed in ruby-eventmachine 1.0.7-4.1)

[Kurt Roeckx]

On Sun, Dec 02, 2018 at 11:36:06PM +0100, gregor herrmann wrote:
> On Sun, 02 Dec 2018 23:18:38 +0100, Sebastian Andrzej Siewior wrote:
> 
> > On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
> > > #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
> > >  ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
> > >  .
> > >* Non-maintainer upload.
> > >* Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
> > >  (Closes: #900160)
> > 
> > Please revert that one. We don't want more dependencies on
> > libssl1.0-dev. We want it actually out of testing and are down to one
> > package.
> > I wouldn't care much but since ruby-eventmachine is a key package it
> > might migrate to testing…
> 
> Raising the severity of the cloned #915287 which tracks this problem
> should prevent the migration.

It won't, since it affects also the version in testing, it can
just migrate.


Kurt

Bug#907015: [Pkg-openssl-devel] Bug#907015: woraround for mbsync?

[Kurt Roeckx]

On Wed, Nov 28, 2018 at 02:35:42PM +, Christoph Groth wrote:
> My mbsync (isync package) setup stopped working for a particular IMAP server
> because of this bug.  I get the following error message:
> 
>   Socket error: secure connect to imap.server.com (1.2.3.4:993):
> error: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

Bug#907015: [Pkg-openssl-devel] Bug#907015: woraround for mbsync?

[Kurt Roeckx]

On Wed, Nov 28, 2018 at 02:35:42PM +, Christoph Groth wrote:
> My mbsync (isync package) setup stopped working for a particular IMAP server
> because of this bug.  I get the following error message:
> 
>   Socket error: secure connect to imap.server.com (1.2.3.4:993):
> error: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

Bug#914806: [Pkg-openssl-devel] Bug#914806: TLSv1.0/1.1 still apparently disabled in Debian testing

[Kurt Roeckx]

On Tue, Nov 27, 2018 at 07:59:39AM -0700, Ivan Stanton wrote:
> Package: openssl
> Version: 1.1.1a-1
> 
> I'm using openssl=1.1.1a-1:amd64, which according to this archive
> should now support TLS 1.0/1.1, but I still have issues connecting to
> the EAP network at my school because it is using TLS 1.0. Any update
> on how to work around this? A previous message stated that the
> workaround was in experimental; what is that workaround? Is it still
> in experimental? I would have reoponed #875423 but my attempt do do so
> returned "550 Unknown or archived bug."

Please see /usr/share/doc/libssl1.1/NEWS.Debian.gz


Kurt

Re: Elfutils mips support

[Kurt Roeckx]

On Mon, Nov 26, 2018 at 05:54:51PM +0800, YunQiang Su wrote:
> Let me have a try and then maybe ask somebody help inner MIPS.

I have an upstream bug at:
https://sourceware.org/bugzilla/show_bug.cgi?id=23902

Maybe it contains useful information for you.


Kurt

Elfutils mips support

[Kurt Roeckx]

Hi,

Elfutils is currently failing to build on mips* because it added a
new feature and the new callback abi_cfi is not implemented in the
mips backend. Is there someone that can write that?


Kurt

Bug#914492: libc0.1-dev: Has Linux-only mremap in headers on non-Linux

[Kurt Roeckx]

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

Bug#914492: libc0.1-dev: Has Linux-only mremap in headers on non-Linux

[Kurt Roeckx]

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

Bug#914477: Acknowledgement (rspamd: autopkgtest is flaky)

[Kurt Roeckx]

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.

Bug#914477: rspamd: autopkgtest is flaky

[Kurt Roeckx]

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

Re: [openssl-users] OpenSSL 1.0.2: CVE-2018-0735

[Kurt Roeckx]

On Tue, Nov 06, 2018 at 04:19:36PM -0600, Misaki Miyashita wrote:
> Hi,
> 
> According to the vulnerabilities website[1], OpenSSL 1.1.i and earlier and
> 1.1.1 are affected by CVE-2018-0735.
> Is it safe to assume that OpenSSL 1.0.2 is not affected by the CVE?

My understanding is that the code was not present in 1.0.2. To
address CVE-2018-5407, that code was backported to 1.0.2, but the
fixed version was used.


Kurt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: Audit Reminder Email Summary

[Kurt Roeckx via dev-security-policy]

On Tue, Oct 23, 2018 at 02:35:37PM -0700, Kathleen Wilson via 
dev-security-policy wrote:
> > > Mozilla: Audit Reminder
> > > Root Certificates:
> > > Certinomis - Root CA
> > > Standard Audit:
> > > https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
> > > Audit Statement Date: 2017-07-24
> > > BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
> > > BR Audit Statement Date: 2017-07-24
> > > CA Comments: null
> > 
> > This seems to be in French, and does not seem to even indicate
> > when the audit was done, just that the report itself is valid for
> > 2 years.
> 
> Our official requirement for the audit statements to be in English is new in
> version 2.6 of our policy (effective date July 1, 2018). Also, last July we
> were still having difficulty getting the ETSI auditors on board with
> specifying audit periods in their audit statements.

So it seems nothing changed related to this in the last month,
they are clearly late in providing a new audit statement.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: elfutils 0.175 released

[Kurt Roeckx]

On Fri, Nov 16, 2018 at 02:00:46PM +0100, Mark Wielaard wrote:
> ELFUTILS 0.175 - http://elfutils.org/
> 
> A new release of elfutils is available at:
> ftp://sourceware.org/pub/elfutils/0.175/
> or https://sourceware.org/elfutils/ftp/0.175/

I'm gettings errors on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=elfutils=riscv64=0.175-1=1542669684=0


Kurt

Accepted elfutils 0.175-1 (source) into unstable

[Kurt Roeckx]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 18 Nov 2018 23:01:23 +0100
Source: elfutils
Binary: elfutils libelf1 libelf-dev libdw-dev libdw1 libasm1 libasm-dev
Architecture: source
Version: 0.175-1
Distribution: unstable
Urgency: medium
Maintainer: Kurt Roeckx 
Changed-By: Kurt Roeckx 
Description:
 elfutils   - collection of utilities to handle ELF objects
 libasm-dev - libasm development libraries and header files
 libasm1- library with a programmable assembler interface
 libdw-dev  - libdw1 development libraries and header files
 libdw1 - library that provides access to the DWARF debug information
 libelf-dev - libelf1 development libraries and header files
 libelf1- library to read and write ELF files
Closes: 907562 911083 911276 911413 911414
Changes:
 elfutils (0.175-1) unstable; urgency=medium
 .
   * New upstream release
 - Build with gcc-8 (Closes: #911276)
 - Drop fix-gcc7-ftbfs.diff
 - Drop GNU_variable_value.patch
 - Drop locviews.patch
 - Update patches
   * Fixes CVE-2018-18521 (Closes: #911413)
   * Fixes CVE-2018-18520 (Closes: #911414)
   * Fixes CVE-2018-18310 (Closes: #911083)
   * Fixes CVE-2018-16403
   * Fixes CVE-2018-16402
   * Fixes CVE-2018-16062 (Closes: #907562)
Checksums-Sha1:
 a68e892c7347f0fe49158e9818e57607cb38c7c5 2568 elfutils_0.175-1.dsc
 361f835640ecffddc6d4543fb044eb53f673026f 8786600 elfutils_0.175.orig.tar.bz2
 a15f78114cad1c7dbe41b2c5710105563b83c481 488 elfutils_0.175.orig.tar.bz2.asc
 28eab328d1e8d8df41b13d9567c9d707dd5901d3 37404 elfutils_0.175-1.debian.tar.xz
 57e40bb1e428465522056af1907d7078559fc83e 8034 elfutils_0.175-1_source.buildinfo
Checksums-Sha256:
 32e42db07fa6c55697db27fb049b327b8bcee95e326c8b64498671dc9f3851ba 2568 
elfutils_0.175-1.dsc
 f7ef925541ee32c6d15ae5cb27da5f119e01a5ccdbe9fe57bf836730d7b7a65b 8786600 
elfutils_0.175.orig.tar.bz2
 103ae1a12d0b67e2d783f36dc780acd533d5c2a9d6241bcd62cfe1f6fa891a16 488 
elfutils_0.175.orig.tar.bz2.asc
 0de2c3f311d388a1dada67e4e37a41bd18fcf715c2a7bcb869d75f0815c70f23 37404 
elfutils_0.175-1.debian.tar.xz
 dd5c7a1153ee0bc3ede69fe22d30b9b939142f25f27dda99792fa8e3cc61 8034 
elfutils_0.175-1_source.buildinfo
Files:
 9b6749ac7b767a9df5861a5b13bacf6d 2568 libs optional elfutils_0.175-1.dsc
 9a02b0382b78cc2d515fb950275d4c02 8786600 libs optional 
elfutils_0.175.orig.tar.bz2
 54de34fe526466caf58f8dce879623b6 488 libs optional 
elfutils_0.175.orig.tar.bz2.asc
 c088129dfd51831d1ea2e664fac54eb8 37404 libs optional 
elfutils_0.175-1.debian.tar.xz
 d586e4cd298fec2e61a37ebf7bedfefd 8034 libs optional 
elfutils_0.175-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEUWHm1ANgDdycoJP748TdzR5MEkQFAlvzKXgACgkQ48TdzR5M
EkQ0mhAAqvoR6fm5a4w67O57UO3j+PM2t+3Slt4qDsfmB2ochhuQ81J5MYO+7kO9
Jen2DB4LMYBW1z0pY7/xvS91EXfxkrJqjhhELFmds0+2g6uyJrvFJ3l+lmTRpvCW
ijRUa5/PssXT8gH4blEBDERPz8Sdr6A3cwzUD5vHTQxF9F12rnDa9ofFeuyaFUW+
rxnubsksysSY7rJ91GG1JLAB9/n/DI2PgQyNwVJ6fT87oJuS6pN70JV7RJOodvRq
fYggTl1RWiuD6wAPlXmspDox4esGw5aYdgvwRR2AEO2wODxCkoMAltlUU0fPW7X7
TWDK23zVci1wtj9blquX3DUPu+L/E6tHV7p8t/HG0xpqfysTXgORkqV511DOJM8D
y3gkAh+jK2P2C88lrgWoLvDOQyfo/V81zbge82/wQzA9LAEbYojlDv7Jqx6YPqzz
nGac1sPvrR7tYrMDXH1CFBgtkpj+8SaHc39FAmP+wi8bg20wxjjRv5Tul9ffe34V
vVvoNjr+dJ5tpC1KPBH3kfDNU+gLocNK5rw00Hifm9ub3EKPT6pYZUSUpRRfDw3C
0ZuIuVAh+OhIhuvHOs/roWco0i8+Db3Sj/VnFbLvZeSgHerOqqvE08KNY1T0OD1k
uB88KJg7VFigV65sKwbGSQ78CCFhtlX++wg+G96+GXA6cGxe8+U=
=Dwb4
-END PGP SIGNATURE-

Re: elfutils 0.175 released

[Kurt Roeckx]

On Mon, Nov 19, 2018 at 07:53:07AM +0100, Mark Wielaard wrote:
> On Sun, Nov 18, 2018 at 11:46:29PM +0100, Kurt Roeckx wrote:
> > On Fri, Nov 16, 2018 at 02:00:46PM +0100, Mark Wielaard wrote:
> > > ELFUTILS 0.175 - http://elfutils.org/
> > > 
> > > A new release of elfutils is available at:
> > > ftp://sourceware.org/pub/elfutils/0.175/
> > > or https://sourceware.org/elfutils/ftp/0.175/
> > 
> > Trying to build this on Debian, I get 8 failures, but they all
> > seem to be white space differences. I've attached the
> > test-suite.log file.
> 
> That looks like you somehow are missing:
> 
> commit 704f5fc477efaf120980449e677deb563da8491f
> Author: Mark Wielaard 
> Date:   Wed Nov 29 15:43:26 2017 +0100
> 
> readelf: Adjust print_ops formatting.
> 
> Use only 2 spaces for index (there are never 1, the most seen in the
> wild is 64). Adjust re-indenting after GNU_entry_value.
> 
> Signed-off-by: Mark Wielaard 
> 
> But that is a commit from elfutils-0.171.
> Maybe you have a local patch that conflicts with it?

I somehow ended up with something that reverts it, no idea why.
After removing that everything seems to work.


Kurt

Bug#847096: Bug#905230: elfutils: FTBFS on x32 due to bugs in testsuite

[Kurt Roeckx]

On Thu, Aug 02, 2018 at 11:11:24PM +0200, Thorsten Glaser wrote:
> 
> Given #847096 it might be wise to just *always* disable the biarch stuff
> since Debian does not normally use biarch *anyway*, and since we test it
> on all architectures during their native build anyway.

I'm not conviced that that is a good solution. Elfutils supports
many different backends at the same time. You disable a test that
tests part of that functionality.

The only thing I've seen here so far is a setup that breaks
elfutils' test suite. As far as I understand, it's perfectly
possible to build the x32 version.


Kurt

Re: elfutils 0.175 released

[Kurt Roeckx]

On Fri, Nov 16, 2018 at 02:00:46PM +0100, Mark Wielaard wrote:
> ELFUTILS 0.175 - http://elfutils.org/
> 
> A new release of elfutils is available at:
> ftp://sourceware.org/pub/elfutils/0.175/
> or https://sourceware.org/elfutils/ftp/0.175/

Trying to build this on Debian, I get 8 failures, but they all
seem to be white space differences. I've attached the
test-suite.log file.


Kurt

==
   elfutils 0.175: tests/test-suite.log
==

# TOTAL: 204
# PASS:  195
# SKIP:  1
# XFAIL: 0
# FAIL:  8
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: run-readelf-const-values.sh
=

--- readelf.out 2018-11-18 23:43:41.610890094 +0100
+++ -   2018-11-18 23:43:41.616503487 +0100
@@ -21,7 +21,7 @@
  low_pc   (addr) 0x004004d0
  high_pc  (data8) 3 (0x004004d3)
  frame_base   (exprloc) 
-  [   0] call_frame_cfa
+  [ 0] call_frame_cfa
  call_all_calls   (flag_present) yes
  sibling  (ref4) [5e]
  [4d]  variable abbrev: 1
@@ -59,7 +59,7 @@
  low_pc   (addr) 0x004003e0
  high_pc  (data8) 7 (0x004003e7)
  frame_base   (exprloc) 
-  [   0] call_frame_cfa
+  [ 0] call_frame_cfa
  GNU_all_call_sites   (flag_present) yes
  sibling  (ref4) [   119]
  [b0]  variable abbrev: 3
FAIL run-readelf-const-values.sh (exit status: 1)

FAIL: run-readelf-twofiles.sh
=

--- readelf.out 2018-11-18 23:43:44.286830882 +0100
+++ -   2018-11-18 23:43:44.295663903 +0100
@@ -8,15 +8,15 @@
  [ 0] range 34, 35
   0x0040049c ..
   0x0040049c 
-   [   0] breg7 -8
+   [ 0] breg7 -8
   range 35, 46
   0x0040049d ..
   0x004004ad 
-   [   0] breg7 0
+   [ 0] breg7 0
   range 46, 47
   0x004004ae ..
   0x004004ae 
-   [   0] breg7 -8
+   [ 0] breg7 -8
 
 testfile14:
 
@@ -27,12 +27,12 @@
  [ 0] range 34, 35
   0x0040049c ..
   0x0040049c 
-   [   0] breg7 -8
+   [ 0] breg7 -8
   range 35, 46
   0x0040049d ..
   0x004004ad 
-   [   0] breg7 0
+   [ 0] breg7 0
   range 46, 47
   0x004004ae ..
   0x004004ae 
-   [   0] breg7 -8
+   [ 0] breg7 -8
FAIL run-readelf-twofiles.sh (exit status: 1)

FAIL: run-readelf-loc.sh


--- readelf.out 2018-11-18 23:43:44.446827342 +0100
+++ -   2018-11-18 23:43:44.458498779 +0100
@@ -5,17 +5,17 @@
  [ 0] range 0, d
   0x00400480 ..
   0x0040048c 
-   [   0] reg5
+   [ 0] reg5
  [23] range 5, d
   0x00400485 ..
   0x0040048c 
-   [   0] reg5
+   [ 0] reg5
 
  CU [e0] base: 0x004004a0 
  [46] range 12, 1a
   0x004004b2 ..
   0x004004b9 
-   [   0] breg5 0
+   [ 0] breg5 0
 
 DWARF section [34] '.debug_ranges' at offset 0xd94:
 
FAIL run-readelf-loc.sh (exit status: 1)

FAIL: run-readelf-variant.sh


--- testfile2.temp  2018-11-18 23:43:51.70686 +0100
+++ -   2018-11-18 23:43:51.714817340 +0100
@@ -1,7 +1,7 @@
  byte_size(exprloc) 
-  [   0] push_object_address
-  [   1] deref_size 1
+  [ 0] push_object_address
+  [ 1] deref_size 1
   [ 3] call4 [95]
-  [   8] plus_uconst 7
-  [  10] const1s -4
-  [  12] and
+  [ 8] plus_uconst 7
+  [10] const1s -4
+  [12] and
FAIL run-readelf-variant.sh (exit status: 1)

FAIL: run-readelf-types.sh
==

--- readelf.out 2018-11-18 23:43:56.682556562 +0100
+++ -   2018-11-18 23:43:56.694717935 +0100
@@ -19,7 +19,7 @@
  low_pc   (addr) 0x004005b0 
  high_pc  (data8) 11 (0x004005bb)
  frame_base   (exprloc) 
-  [   0] call_frame_cfa
+  [ 0] call_frame_cfa
  GNU_all_call_sites   (flag_present) yes
  [46]base_typeabbrev: 10
  byte_size(data1) 4
FAIL run-readelf-types.sh (exit status: 1)

FAIL: run-readelf-dwz-multi.sh
==

--- readelf.out 2018-11-18 23:43:56.790554172 +0100
+++ -   2018-11-18 23:43:56.801299743 +0100
@@ -26,7 +26,7 @@
  low_pc   (addr) 0x004006ac 
  high_pc

Bug#913959: kde4libs: Build-Depends on libssl1.0-dev

[Kurt Roeckx]

Source: kde4libs
Version: 4:4.14.38-2
Severity: serious

Hi,

It seems that kde4libs Build-Depends on libssl1.0-dev as a result
of #828363. There are currently no packages depending on
libssl1.0.2 left in testing, but this source package is the only
one that has a Build-Depends against libssl1.0-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

Bug#913959: kde4libs: Build-Depends on libssl1.0-dev

[Kurt Roeckx]

Source: kde4libs
Version: 4:4.14.38-2
Severity: serious

Hi,

It seems that kde4libs Build-Depends on libssl1.0-dev as a result
of #828363. There are currently no packages depending on
libssl1.0.2 left in testing, but this source package is the only
one that has a Build-Depends against libssl1.0-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

Bug#913959: kde4libs: Build-Depends on libssl1.0-dev

[Kurt Roeckx]

Source: kde4libs
Version: 4:4.14.38-2
Severity: serious

Hi,

It seems that kde4libs Build-Depends on libssl1.0-dev as a result
of #828363. There are currently no packages depending on
libssl1.0.2 left in testing, but this source package is the only
one that has a Build-Depends against libssl1.0-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

Bug#905230: elfutils: FTBFS on x32 due to bugs in testsuite

[Kurt Roeckx]

On Mon, Nov 12, 2018 at 11:15:48AM +, Laurence Parry wrote:
> This seems to be blocking me from building a x32 chroot using the
> documented process for doing so, because the ELF library is a required
> package (iproute2 depends on libelf-dev as of 4.6.0-2; see #812774). I
> appreciate that x32 is not a great priority, but it's not going to get
> better if we can't even spin up a build. >_>
> 
> The maintainer does not appear to have updated this package in the last
> year, so I'm not sure when the next "regular update" will be. Would it be
> 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

Bug#913535: sfcgal: large dependency chain

[Kurt Roeckx]

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 from libsfcgal1, and then from
> > libopenscenegraph100v5.
> > 
> > Is there some way to that the amount of dependencies can be reduced?
> > Avoiding the dependency on libopenscenegraph100v5 would be nice.
> 
> I guess you're on stretch, because this issue has been fixed since by
> splitting the OSG features into a separate library.
> 
> You can install libsfcgal1 from stretch-backports.

Yes, thanks, that looks much better.

> Another option is to not install recommends, as OSG has quite a number
> of those.

I tried disabling recommends (in stretch), but that didn't have
any effect.


Kurt

___
Pkg-grass-devel mailing list
Pkg-grass-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#913535: sfcgal: large dependency chain

[Kurt Roeckx]

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 from libsfcgal1, and then from
> > libopenscenegraph100v5.
> > 
> > Is there some way to that the amount of dependencies can be reduced?
> > Avoiding the dependency on libopenscenegraph100v5 would be nice.
> 
> I guess you're on stretch, because this issue has been fixed since by
> splitting the OSG features into a separate library.
> 
> You can install libsfcgal1 from stretch-backports.

Yes, thanks, that looks much better.

> Another option is to not install recommends, as OSG has quite a number
> of those.

I tried disabling recommends (in stretch), but that didn't have
any effect.


Kurt

Bug#913535: sfcgal: large dependency chain

[Kurt Roeckx]

Package: libsfcgal1

Hi,

When trying to install postgis, I get:
The following NEW packages will be installed:
  fonts-droid-fallback fonts-noto-mono ghostscript gsfonts i965-va-driver 
libaacs0 libaec0 libarmadillo7 libarpack2 libasound2 libasound2-data libass5 
libasyncns0 libaudio2 libavc1394-0 libavcodec57 libavdevice57 libavfilter6
  libavformat57 libavresample3 libavutil55 libbdplus0 libblas-common libblas3 
libbluray1 libboost-chrono1.62.0 libboost-date-time1.62.0 
libboost-filesystem1.62.0 libboost-program-options1.62.0 
libboost-serialization1.62.0
  libboost-system1.62.0 libboost-test1.62.0 libboost-thread1.62.0 
libboost-timer1.62.0 libbs2b0 libcaca0 libcdio-cdda1 libcdio-paranoia1 
libcdio13 libcgal12 libchromaprint1 libcoin80v5 libcrystalhd3 libcupsfilters1 
libcupsimage2 libdap23
  libdapclient6v5 libdapserver7v5 libdc1394-22 libdrm-amdgpu1 libdrm-intel1 
libdrm-nouveau2 libdrm-radeon1 libdrm2 libebur128-1 libegl1-mesa libepsilon1 
libfaad2 libfftw3-double3 libflac8 libflite1 libfreexl1 libgbm1 libgdal20
  libgeos-3.5.1 libgeos-c1v5 libgeotiff2 libgfortran3 libgif7 libgl1-mesa-dri 
libgl1-mesa-glx libglapi-mesa libgme0 libgraphicsmagick-q16-3 libgs9 
libgs9-common libgsm1 libhdf4-0-alt libhdf5-100 libice6 libiec61883-0 
libijs-0.35
  libiso9660-8 libjack-jackd2-0 libjbig2dec0 libkmlbase1 libkmlconvenience1 
libkmldom1 libkmlengine1 libkmlregionator1 libkmlxsd1 liblapack3 libldb1 
libllvm3.9 liblwgeom-2.3-0 libmad0 libminizip1 libmng1 libmodplug1 libmp3lame0 
libmpcdec6
  libmpg123-0 libnetcdf11 libnspr4 libnss3 libodbc1 libogdi3.2 libogg0 
libopenal-data libopenal1 libopencv-core2.4v5 libopencv-imgproc2.4v5 
libopenjp2-7 libopenmpt0 libopenscenegraph100v5 libopenthreads20 libopus0 
libpciaccess0
  libpgm-5.2-0 libpoppler-glib8 libpoppler64 libpostproc54 libproj12 libpulse0 
libqhull7 libqt4-dbus libqt4-opengl libqt4-xml libqtcore4 libqtdbus4 libqtgui4 
libraw1394-11 librubberband2 libsamplerate0 libsdl2-2.0-0 libsfcgal1 libshine3
  libsm6 libsmbclient libsnappy1v5 libsndfile1 libsndio6.1 libsoxr0 
libspatialite7 libspeex1 libssh-gcrypt-4 libsuperlu5 libswresample2 libswscale4 
libsz2 libtbb2 libtdb1 libtevent0 libtheora0 libtwolame0 libtxc-dxtn-s2tc 
liburiparser1
  libv4l-0 libv4lconvert0 libva-drm1 libva-x11-1 libva1 libvcdinfo0 
libvdpau-va-gl1 libvdpau1 libvorbis0a libvorbisenc2 libvorbisfile3 libvpx4 
libwavpack1 libwayland-client0 libwayland-cursor0 libwayland-egl1-mesa 
libwayland-server0
  libwbclient0 libwmf0.2-7 libx11-xcb1 libx264-148 libx265-95 libxcb-dri2-0 
libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-shape0 libxcb-sync1 
libxcb-xfixes0 libxerces-c3.1 libxine2 libxine2-bin libxine2-doc libxine2-ffmpeg
  libxine2-misc-plugins libxine2-plugins libxkbcommon0 libxshmfence1 libxss1 
libxt6 libxtst6 libxv1 libxvidcore4 libxxf86vm1 libzmq5 libzvbi-common libzvbi0 
mesa-va-drivers mesa-vdpau-drivers odbcinst odbcinst1debian2 poppler-data
  postgresql-9.5-postgis-2.3 postgresql-9.5-postgis-2.3-scripts proj-bin 
proj-data python-talloc qdbus qt-at-spi qtchooser qtcore4-l10n samba-libs 
va-driver-all vdpau-driver-all x11-common

Clearly I don't need all of this just for postgis.

Most of this seems to be a dependency from libsfcgal1, and then from
libopenscenegraph100v5.

Is there some way to that the amount 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

Bug#913535: sfcgal: large dependency chain

[Kurt Roeckx]

Package: libsfcgal1

Hi,

When trying to install postgis, I get:
The following NEW packages will be installed:
  fonts-droid-fallback fonts-noto-mono ghostscript gsfonts i965-va-driver 
libaacs0 libaec0 libarmadillo7 libarpack2 libasound2 libasound2-data libass5 
libasyncns0 libaudio2 libavc1394-0 libavcodec57 libavdevice57 libavfilter6
  libavformat57 libavresample3 libavutil55 libbdplus0 libblas-common libblas3 
libbluray1 libboost-chrono1.62.0 libboost-date-time1.62.0 
libboost-filesystem1.62.0 libboost-program-options1.62.0 
libboost-serialization1.62.0
  libboost-system1.62.0 libboost-test1.62.0 libboost-thread1.62.0 
libboost-timer1.62.0 libbs2b0 libcaca0 libcdio-cdda1 libcdio-paranoia1 
libcdio13 libcgal12 libchromaprint1 libcoin80v5 libcrystalhd3 libcupsfilters1 
libcupsimage2 libdap23
  libdapclient6v5 libdapserver7v5 libdc1394-22 libdrm-amdgpu1 libdrm-intel1 
libdrm-nouveau2 libdrm-radeon1 libdrm2 libebur128-1 libegl1-mesa libepsilon1 
libfaad2 libfftw3-double3 libflac8 libflite1 libfreexl1 libgbm1 libgdal20
  libgeos-3.5.1 libgeos-c1v5 libgeotiff2 libgfortran3 libgif7 libgl1-mesa-dri 
libgl1-mesa-glx libglapi-mesa libgme0 libgraphicsmagick-q16-3 libgs9 
libgs9-common libgsm1 libhdf4-0-alt libhdf5-100 libice6 libiec61883-0 
libijs-0.35
  libiso9660-8 libjack-jackd2-0 libjbig2dec0 libkmlbase1 libkmlconvenience1 
libkmldom1 libkmlengine1 libkmlregionator1 libkmlxsd1 liblapack3 libldb1 
libllvm3.9 liblwgeom-2.3-0 libmad0 libminizip1 libmng1 libmodplug1 libmp3lame0 
libmpcdec6
  libmpg123-0 libnetcdf11 libnspr4 libnss3 libodbc1 libogdi3.2 libogg0 
libopenal-data libopenal1 libopencv-core2.4v5 libopencv-imgproc2.4v5 
libopenjp2-7 libopenmpt0 libopenscenegraph100v5 libopenthreads20 libopus0 
libpciaccess0
  libpgm-5.2-0 libpoppler-glib8 libpoppler64 libpostproc54 libproj12 libpulse0 
libqhull7 libqt4-dbus libqt4-opengl libqt4-xml libqtcore4 libqtdbus4 libqtgui4 
libraw1394-11 librubberband2 libsamplerate0 libsdl2-2.0-0 libsfcgal1 libshine3
  libsm6 libsmbclient libsnappy1v5 libsndfile1 libsndio6.1 libsoxr0 
libspatialite7 libspeex1 libssh-gcrypt-4 libsuperlu5 libswresample2 libswscale4 
libsz2 libtbb2 libtdb1 libtevent0 libtheora0 libtwolame0 libtxc-dxtn-s2tc 
liburiparser1
  libv4l-0 libv4lconvert0 libva-drm1 libva-x11-1 libva1 libvcdinfo0 
libvdpau-va-gl1 libvdpau1 libvorbis0a libvorbisenc2 libvorbisfile3 libvpx4 
libwavpack1 libwayland-client0 libwayland-cursor0 libwayland-egl1-mesa 
libwayland-server0
  libwbclient0 libwmf0.2-7 libx11-xcb1 libx264-148 libx265-95 libxcb-dri2-0 
libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-shape0 libxcb-sync1 
libxcb-xfixes0 libxerces-c3.1 libxine2 libxine2-bin libxine2-doc libxine2-ffmpeg
  libxine2-misc-plugins libxine2-plugins libxkbcommon0 libxshmfence1 libxss1 
libxt6 libxtst6 libxv1 libxvidcore4 libxxf86vm1 libzmq5 libzvbi-common libzvbi0 
mesa-va-drivers mesa-vdpau-drivers odbcinst odbcinst1debian2 poppler-data
  postgresql-9.5-postgis-2.3 postgresql-9.5-postgis-2.3-scripts proj-bin 
proj-data python-talloc qdbus qt-at-spi qtchooser qtcore4-l10n samba-libs 
va-driver-all vdpau-driver-all x11-common

Clearly I don't need all of this just for postgis.

Most of this seems to be a dependency from libsfcgal1, and then from
libopenscenegraph100v5.

Is there some way to that the amount 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

___
Pkg-grass-devel mailing list
Pkg-grass-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#913129: [Pkg-openssl-devel] Bug#913129: Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[Kurt Roeckx]

On Sat, Nov 10, 2018 at 11:34:41PM +0100, BERTRAND Joël wrote:
> 
>   I have changed _both_ values and I cannot connect to orange.fr or
> hotmail.com with sendmail. If I use stable package, sendmail runs as
> expected.

hotmail.com works with the default settings, it actually supports
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

Bug#913129: [Pkg-openssl-devel] Bug#913129: Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[Kurt Roeckx]

On Sat, Nov 10, 2018 at 11:34:41PM +0100, BERTRAND Joël wrote:
> 
>   I have changed _both_ values and I cannot connect to orange.fr or
> hotmail.com with sendmail. If I use stable package, sendmail runs as
> expected.

hotmail.com works with the default settings, it actually supports
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

[openssl-commits] [openssl] OpenSSL_1_1_1-stable update

[Kurt Roeckx]

The branch OpenSSL_1_1_1-stable has been updated
   via  e37b7014f3f52124b787ca1b5b51b0111462a0ac (commit)
  from  98f62979b2e6233470619c9adfa44704a7036699 (commit)


- Log -
commit e37b7014f3f52124b787ca1b5b51b0111462a0ac
Author: Tomas Mraz 
Date:   Fri Oct 12 17:24:14 2018 +0200

Unbreak SECLEVEL 3 regression causing it to not accept any ciphers.

Reviewed-by: Kurt Roeckx 
Reviewed-by: Richard Levitte 
GH: #7391
(cherry picked from commit 75b68c9e4e8591a4ebe083cb207aeb121baf549f)

---

Summary of changes:
 ssl/ssl_cert.c |   4 +-
 test/recipes/80-test_ssl_new.t |   2 +-
 test/ssl-tests/28-seclevel.conf| 102 +
 test/ssl-tests/28-seclevel.conf.in |  48 +
 4 files changed, 153 insertions(+), 3 deletions(-)
 create mode 100644 test/ssl-tests/28-seclevel.conf
 create mode 100644 test/ssl-tests/28-seclevel.conf.in

diff --git a/ssl/ssl_cert.c b/ssl/ssl_cert.c
index 52a4a7e..7d7357f 100644
--- a/ssl/ssl_cert.c
+++ b/ssl/ssl_cert.c
@@ -951,8 +951,8 @@ static int ssl_security_default_callback(const SSL *s, 
const SSL_CTX *ctx,
 if (level >= 2 && c->algorithm_enc == SSL_RC4)
 return 0;
 /* Level 3: forward secure ciphersuites only */
-if (level >= 3 && (c->min_tls != TLS1_3_VERSION ||
-   !(c->algorithm_mkey & (SSL_kEDH | SSL_kEECDH
+if (level >= 3 && c->min_tls != TLS1_3_VERSION &&
+   !(c->algorithm_mkey & (SSL_kEDH | SSL_kEECDH)))
 return 0;
 break;
 }
diff --git a/test/recipes/80-test_ssl_new.t b/test/recipes/80-test_ssl_new.t
index e15d87e..da8302d 100644
--- a/test/recipes/80-test_ssl_new.t
+++ b/test/recipes/80-test_ssl_new.t
@@ -28,7 +28,7 @@ map { s/\^// } @conf_files if $^O eq "VMS";
 
 # We hard-code the number of tests to double-check that the globbing above
 # finds all files as expected.
-plan tests => 27;  # = scalar @conf_srcs
+plan tests => 28;  # = scalar @conf_srcs
 
 # Some test results depend on the configuration of enabled protocols. We only
 # verify generated sources in the default configuration.
diff --git a/test/ssl-tests/28-seclevel.conf b/test/ssl-tests/28-seclevel.conf
new file mode 100644
index 000..ddc2448
--- /dev/null
+++ b/test/ssl-tests/28-seclevel.conf
@@ -0,0 +1,102 @@
+# Generated with generate_ssl_tests.pl
+
+num_tests = 4
+
+test-0 = 0-SECLEVEL 3 with default key
+test-1 = 1-SECLEVEL 3 with ED448 key
+test-2 = 2-SECLEVEL 3 with ED448 key, TLSv1.2
+test-3 = 3-SECLEVEL 3 with P-384 key, X25519 ECDHE
+# ===
+
+[0-SECLEVEL 3 with default key]
+ssl_conf = 0-SECLEVEL 3 with default key-ssl
+
+[0-SECLEVEL 3 with default key-ssl]
+server = 0-SECLEVEL 3 with default key-server
+client = 0-SECLEVEL 3 with default key-client
+
+[0-SECLEVEL 3 with default key-server]
+Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
+CipherString = DEFAULT:@SECLEVEL=3
+PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
+
+[0-SECLEVEL 3 with default key-client]
+CipherString = DEFAULT
+VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
+VerifyMode = Peer
+
+[test-0]
+ExpectedResult = ServerFail
+
+
+# ===
+
+[1-SECLEVEL 3 with ED448 key]
+ssl_conf = 1-SECLEVEL 3 with ED448 key-ssl
+
+[1-SECLEVEL 3 with ED448 key-ssl]
+server = 1-SECLEVEL 3 with ED448 key-server
+client = 1-SECLEVEL 3 with ED448 key-client
+
+[1-SECLEVEL 3 with ED448 key-server]
+Certificate = ${ENV::TEST_CERTS_DIR}/server-ed448-cert.pem
+CipherString = DEFAULT:@SECLEVEL=3
+PrivateKey = ${ENV::TEST_CERTS_DIR}/server-ed448-key.pem
+
+[1-SECLEVEL 3 with ED448 key-client]
+CipherString = DEFAULT
+VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
+VerifyMode = Peer
+
+[test-1]
+ExpectedResult = Success
+
+
+# ===
+
+[2-SECLEVEL 3 with ED448 key, TLSv1.2]
+ssl_conf = 2-SECLEVEL 3 with ED448 key, TLSv1.2-ssl
+
+[2-SECLEVEL 3 with ED448 key, TLSv1.2-ssl]
+server = 2-SECLEVEL 3 with ED448 key, TLSv1.2-server
+client = 2-SECLEVEL 3 with ED448 key, TLSv1.2-client
+
+[2-SECLEVEL 3 with ED448 key, TLSv1.2-server]
+Certificate = ${ENV::TEST_CERTS_DIR}/server-ed448-cert.pem
+CipherString = DEFAULT:@SECLEVEL=3
+MaxProtocol = TLSv1.2
+PrivateKey = ${ENV::TEST_CERTS_DIR}/server-ed448-key.pem
+
+[2-SECLEVEL 3 with ED448 key, TLSv1.2-client]
+CipherString = DEFAULT
+VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
+VerifyMode = Peer
+
+[test-2]
+ExpectedResult = Success
+
+
+# ===
+
+[3-SECLEVEL 3 with P-384 key, X25519 ECDHE]
+ssl_conf = 3-SECLEVEL 

[openssl-commits] [openssl] master update

[Kurt Roeckx]

The branch master has been updated
   via  75b68c9e4e8591a4ebe083cb207aeb121baf549f (commit)
  from  65042182fcafbd4c0dd8fdabaefdf1fd38dc6287 (commit)


- Log -
commit 75b68c9e4e8591a4ebe083cb207aeb121baf549f
Author: Tomas Mraz 
Date:   Fri Oct 12 17:24:14 2018 +0200

Unbreak SECLEVEL 3 regression causing it to not accept any ciphers.

Reviewed-by: Kurt Roeckx 
Reviewed-by: Richard Levitte 
GH: #7391

---

Summary of changes:
 ssl/ssl_cert.c |   4 +-
 test/recipes/80-test_ssl_new.t |   2 +-
 test/ssl-tests/28-seclevel.conf| 102 +
 test/ssl-tests/28-seclevel.conf.in |  48 +
 4 files changed, 153 insertions(+), 3 deletions(-)
 create mode 100644 test/ssl-tests/28-seclevel.conf
 create mode 100644 test/ssl-tests/28-seclevel.conf.in

diff --git a/ssl/ssl_cert.c b/ssl/ssl_cert.c
index 52a4a7e..7d7357f 100644
--- a/ssl/ssl_cert.c
+++ b/ssl/ssl_cert.c
@@ -951,8 +951,8 @@ static int ssl_security_default_callback(const SSL *s, 
const SSL_CTX *ctx,
 if (level >= 2 && c->algorithm_enc == SSL_RC4)
 return 0;
 /* Level 3: forward secure ciphersuites only */
-if (level >= 3 && (c->min_tls != TLS1_3_VERSION ||
-   !(c->algorithm_mkey & (SSL_kEDH | SSL_kEECDH
+if (level >= 3 && c->min_tls != TLS1_3_VERSION &&
+   !(c->algorithm_mkey & (SSL_kEDH | SSL_kEECDH)))
 return 0;
 break;
 }
diff --git a/test/recipes/80-test_ssl_new.t b/test/recipes/80-test_ssl_new.t
index e15d87e..da8302d 100644
--- a/test/recipes/80-test_ssl_new.t
+++ b/test/recipes/80-test_ssl_new.t
@@ -28,7 +28,7 @@ map { s/\^// } @conf_files if $^O eq "VMS";
 
 # We hard-code the number of tests to double-check that the globbing above
 # finds all files as expected.
-plan tests => 27;  # = scalar @conf_srcs
+plan tests => 28;  # = scalar @conf_srcs
 
 # Some test results depend on the configuration of enabled protocols. We only
 # verify generated sources in the default configuration.
diff --git a/test/ssl-tests/28-seclevel.conf b/test/ssl-tests/28-seclevel.conf
new file mode 100644
index 000..ddc2448
--- /dev/null
+++ b/test/ssl-tests/28-seclevel.conf
@@ -0,0 +1,102 @@
+# Generated with generate_ssl_tests.pl
+
+num_tests = 4
+
+test-0 = 0-SECLEVEL 3 with default key
+test-1 = 1-SECLEVEL 3 with ED448 key
+test-2 = 2-SECLEVEL 3 with ED448 key, TLSv1.2
+test-3 = 3-SECLEVEL 3 with P-384 key, X25519 ECDHE
+# ===
+
+[0-SECLEVEL 3 with default key]
+ssl_conf = 0-SECLEVEL 3 with default key-ssl
+
+[0-SECLEVEL 3 with default key-ssl]
+server = 0-SECLEVEL 3 with default key-server
+client = 0-SECLEVEL 3 with default key-client
+
+[0-SECLEVEL 3 with default key-server]
+Certificate = ${ENV::TEST_CERTS_DIR}/servercert.pem
+CipherString = DEFAULT:@SECLEVEL=3
+PrivateKey = ${ENV::TEST_CERTS_DIR}/serverkey.pem
+
+[0-SECLEVEL 3 with default key-client]
+CipherString = DEFAULT
+VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
+VerifyMode = Peer
+
+[test-0]
+ExpectedResult = ServerFail
+
+
+# ===
+
+[1-SECLEVEL 3 with ED448 key]
+ssl_conf = 1-SECLEVEL 3 with ED448 key-ssl
+
+[1-SECLEVEL 3 with ED448 key-ssl]
+server = 1-SECLEVEL 3 with ED448 key-server
+client = 1-SECLEVEL 3 with ED448 key-client
+
+[1-SECLEVEL 3 with ED448 key-server]
+Certificate = ${ENV::TEST_CERTS_DIR}/server-ed448-cert.pem
+CipherString = DEFAULT:@SECLEVEL=3
+PrivateKey = ${ENV::TEST_CERTS_DIR}/server-ed448-key.pem
+
+[1-SECLEVEL 3 with ED448 key-client]
+CipherString = DEFAULT
+VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
+VerifyMode = Peer
+
+[test-1]
+ExpectedResult = Success
+
+
+# ===
+
+[2-SECLEVEL 3 with ED448 key, TLSv1.2]
+ssl_conf = 2-SECLEVEL 3 with ED448 key, TLSv1.2-ssl
+
+[2-SECLEVEL 3 with ED448 key, TLSv1.2-ssl]
+server = 2-SECLEVEL 3 with ED448 key, TLSv1.2-server
+client = 2-SECLEVEL 3 with ED448 key, TLSv1.2-client
+
+[2-SECLEVEL 3 with ED448 key, TLSv1.2-server]
+Certificate = ${ENV::TEST_CERTS_DIR}/server-ed448-cert.pem
+CipherString = DEFAULT:@SECLEVEL=3
+MaxProtocol = TLSv1.2
+PrivateKey = ${ENV::TEST_CERTS_DIR}/server-ed448-key.pem
+
+[2-SECLEVEL 3 with ED448 key, TLSv1.2-client]
+CipherString = DEFAULT
+VerifyCAFile = ${ENV::TEST_CERTS_DIR}/rootcert.pem
+VerifyMode = Peer
+
+[test-2]
+ExpectedResult = Success
+
+
+# ===
+
+[3-SECLEVEL 3 with P-384 key, X25519 ECDHE]
+ssl_conf = 3-SECLEVEL 3 with P-384 key, X25519 ECDHE-ssl
+
+[3-SECLEVEL 3 with P-384 key, X25519 ECDHE-ssl]
+

Bug#913129: [Pkg-openssl-devel] Bug#913129: Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[Kurt Roeckx]

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 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.orange.fr, reject=550 5.7.1 
> >>>>> ... do not try TLS with smtp-in.orange.fr [80.12.242.9]
> >>>>> Nov  7 09:17:31 rayleigh sm-mta[10148]: wA68PQwK006059: 
> >>>>> to=, delay=23:52:05, xdelay=00:00:01, mailer=esmtp, 
> >>>>> pri=77460547, relay=smtp-in.orange.fr. [80.12.242.9], dsn=5.0.0, 
> >>>>> stat=Service unavailable
> >>>>
> >>>> That server only seems to support TLS 1.0.
> >>>>
> >>>> Have you read: /usr/share/doc/libssl1.1/NEWS.Debian.gz
> >>>>
> >>>> Anyway, I suggest you file a bug against sendmail to override the
> >>>> defaults.
> >>>
> >>>   I have read /usr/share/doc/libssl1.1/NEWS.Debian.gz and tested all
> >>> workarounds without any success.
> >>
> >> And you restarted sendmail after changing /etc/ssl/openssl.cfg?
> > 
> > Any update on this?
> 
>   Of course, I have updated /etc/ssl/openssl.cfg with suggestions in NEWS
> file and restarted sendmail without success.

All I can say is that if I change both values to the value from
NEWS, I can connect to it, otherwise I can't.


Kurt

Bug#913129: [Pkg-openssl-devel] Bug#913129: Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[Kurt Roeckx]

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]: ruleset=try_tls, 
> > >> arg1=smtp-in.orange.fr, relay=smtp-in.orange.fr, reject=550 5.7.1 
> > >> ... do not try TLS with smtp-in.orange.fr [80.12.242.9]
> > >> Nov  7 09:17:31 rayleigh sm-mta[10148]: wA68PQwK006059: 
> > >> to=, delay=23:52:05, xdelay=00:00:01, mailer=esmtp, 
> > >> pri=77460547, relay=smtp-in.orange.fr. [80.12.242.9], dsn=5.0.0, 
> > >> stat=Service unavailable
> > > 
> > > That server only seems to support TLS 1.0.
> > > 
> > > Have you read: /usr/share/doc/libssl1.1/NEWS.Debian.gz
> > > 
> > > Anyway, I suggest you file a bug against sendmail to override the
> > > defaults.
> > 
> > I have read /usr/share/doc/libssl1.1/NEWS.Debian.gz and tested all
> > workarounds without any success.
> 
> And you restarted sendmail after changing /etc/ssl/openssl.cfg?

Any update on this?


Kurt

Bug#858938: fixed in kopete 4:18.04.1-1

[Kurt Roeckx]

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 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
> > > > > > > 
> > > > > > > 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?
> > > > > 
> > > > > There are just two packages left in testing which use openssl1.0. The
> > > > > last kopete upload was in mid June. Is there anything blocking an 
> > > > > upload
> > > > > to unstable?
> > > > 
> > > > The other one just got fixed in unstable, so this will soon be the
> > > > only package in testing still depending on libssl1.0.2.
> > > 
> > > kopete is the only package in testing still using libssl1.0.2. Could
> > > someone please comment on this?
> > 
> > This is in experimental for more than 5 months now.
> > 
> > If nobody replies to this, I will upload an NMU to unstable.
> 
> NMU *what*? Because if you upload the version in experimental to
> unstable, then you are effectively taking its maintainership.
> The version in experimental is *NOT* ready for unstable/testing,
> otherwise I would have uploaded it long ago.

And you could have answered this months ago that it was not ready,
or that you prefer to fix this the version in unstable instead, or
whatever.

> 
> OTOH, this kind of non-helping attitude for you openssl guys (for
> example not helping fixing these porting bugs, constant useless poking,
> breakage of openssl 1.1 in unstable) certainly does not help.
> If you want cooperation, then be ccoperative yourself, instead of just
> expecting others to follow whatever you do.
> 

If you need help with something, please ask. Just as you, we're
busy with various things, submitting patches for various packages.
This bug got closed, so as far as we know you don't need help.


Kurt

Bug#858938: fixed in kopete 4:18.04.1-1

[Kurt Roeckx]

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 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
> > > > > > > 
> > > > > > > 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?
> > > > > 
> > > > > There are just two packages left in testing which use openssl1.0. The
> > > > > last kopete upload was in mid June. Is there anything blocking an 
> > > > > upload
> > > > > to unstable?
> > > > 
> > > > The other one just got fixed in unstable, so this will soon be the
> > > > only package in testing still depending on libssl1.0.2.
> > > 
> > > kopete is the only package in testing still using libssl1.0.2. Could
> > > someone please comment on this?
> > 
> > This is in experimental for more than 5 months now.
> > 
> > If nobody replies to this, I will upload an NMU to unstable.
> 
> NMU *what*? Because if you upload the version in experimental to
> unstable, then you are effectively taking its maintainership.
> The version in experimental is *NOT* ready for unstable/testing,
> otherwise I would have uploaded it long ago.

And you could have answered this months ago that it was not ready,
or that you prefer to fix this the version in unstable instead, or
whatever.

> 
> OTOH, this kind of non-helping attitude for you openssl guys (for
> example not helping fixing these porting bugs, constant useless poking,
> breakage of openssl 1.1 in unstable) certainly does not help.
> If you want cooperation, then be ccoperative yourself, instead of just
> expecting others to follow whatever you do.
> 

If you need help with something, please ask. Just as you, we're
busy with various things, submitting patches for various packages.
This bug got closed, so as far as we know you don't need help.


Kurt

Bug#858938: fixed in kopete 4:18.04.1-1

[Kurt Roeckx]

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 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
> > > > > > > 
> > > > > > > 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?
> > > > > 
> > > > > There are just two packages left in testing which use openssl1.0. The
> > > > > last kopete upload was in mid June. Is there anything blocking an 
> > > > > upload
> > > > > to unstable?
> > > > 
> > > > The other one just got fixed in unstable, so this will soon be the
> > > > only package in testing still depending on libssl1.0.2.
> > > 
> > > kopete is the only package in testing still using libssl1.0.2. Could
> > > someone please comment on this?
> > 
> > This is in experimental for more than 5 months now.
> > 
> > If nobody replies to this, I will upload an NMU to unstable.
> 
> NMU *what*? Because if you upload the version in experimental to
> unstable, then you are effectively taking its maintainership.
> The version in experimental is *NOT* ready for unstable/testing,
> otherwise I would have uploaded it long ago.

And you could have answered this months ago that it was not ready,
or that you prefer to fix this the version in unstable instead, or
whatever.

> 
> OTOH, this kind of non-helping attitude for you openssl guys (for
> example not helping fixing these porting bugs, constant useless poking,
> breakage of openssl 1.1 in unstable) certainly does not help.
> If you want cooperation, then be ccoperative yourself, instead of just
> expecting others to follow whatever you do.
> 

If you need help with something, please ask. Just as you, we're
busy with various things, submitting patches for various packages.
This bug got closed, so as far as we know you don't need help.


Kurt

Bug#858938: fixed in kopete 4:18.04.1-1

[Kurt Roeckx]

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:
> > > > 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?
> > > 
> > > There are just two packages left in testing which use openssl1.0. The
> > > last kopete upload was in mid June. Is there anything blocking an upload
> > > to unstable?
> > 
> > The other one just got fixed in unstable, so this will soon be the
> > only package in testing still depending on libssl1.0.2.
> 
> kopete is the only package in testing still using libssl1.0.2. Could
> someone please comment on this?

This is in experimental for more than 5 months now.

If nobody replies to this, I will upload an NMU to unstable.


Kurt

Bug#858938: fixed in kopete 4:18.04.1-1

[Kurt Roeckx]

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:
> > > > 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?
> > > 
> > > There are just two packages left in testing which use openssl1.0. The
> > > last kopete upload was in mid June. Is there anything blocking an upload
> > > to unstable?
> > 
> > The other one just got fixed in unstable, so this will soon be the
> > only package in testing still depending on libssl1.0.2.
> 
> kopete is the only package in testing still using libssl1.0.2. Could
> someone please comment on this?

This is in experimental for more than 5 months now.

If nobody replies to this, I will upload an NMU to unstable.


Kurt

Re: Bug#858938: fixed in kopete 4:18.04.1-1

[Kurt Roeckx]

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:
> > > > 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?
> > > 
> > > There are just two packages left in testing which use openssl1.0. The
> > > last kopete upload was in mid June. Is there anything blocking an upload
> > > to unstable?
> > 
> > The other one just got fixed in unstable, so this will soon be the
> > only package in testing still depending on libssl1.0.2.
> 
> kopete is the only package in testing still using libssl1.0.2. Could
> someone please comment on this?

This is in experimental for more than 5 months now.

If nobody replies to this, I will upload an NMU to unstable.


Kurt

Bug#907219: Fwd: [ANN] M2Crypto 0.31.0 ... plenty of bugfixes (and support for OpenSSL 1.1.1)

[Kurt Roeckx]

--- 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 for Windows builds
  - Fixes of installs on AWS Lambda
  - Fixes of Mac OS X related failures
  - Fix Python 2.6 compatibility issues

Support for OpenSSL 1.1.1 is just minimal, to make test suite
pass. The biggest problem is that the latest OpenSSL doesn't
raise exceptions in some situations where the earliest versions
did so. Not sure, what is the proper reaction from M2Crypto size.

Also, reminder, that we have special email list for development
of M2Crypto. Its web page is http://redcrew.org/mailman/listinfo/
m2crypto and it is mailman with the posting address
m2cry...@lists.redcrew.org so all email commands work.

All complaints, support requests, and bug reports are welcome in
the email list or on the issue tracker
https://gitlab.com/m2crypto/m2crypto/issues

Happy security hacking!

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
A man who won't die for something is not fit to live.


signature.asc
Description: This is a digitally signed message part
--- End Message ---

Bug#907219: Fwd: [ANN] M2Crypto 0.31.0 ... plenty of bugfixes (and support for OpenSSL 1.1.1)

[Kurt Roeckx]

--- 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 for Windows builds
  - Fixes of installs on AWS Lambda
  - Fixes of Mac OS X related failures
  - Fix Python 2.6 compatibility issues

Support for OpenSSL 1.1.1 is just minimal, to make test suite
pass. The biggest problem is that the latest OpenSSL doesn't
raise exceptions in some situations where the earliest versions
did so. Not sure, what is the proper reaction from M2Crypto size.

Also, reminder, that we have special email list for development
of M2Crypto. Its web page is http://redcrew.org/mailman/listinfo/
m2crypto and it is mailman with the posting address
m2cry...@lists.redcrew.org so all email commands work.

All complaints, support requests, and bug reports are welcome in
the email list or on the issue tracker
https://gitlab.com/m2crypto/m2crypto/issues

Happy security hacking!

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
A man who won't die for something is not fit to live.


signature.asc
Description: This is a digitally signed message part
--- End Message ---

Bug#913129: [Pkg-openssl-devel] Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[Kurt Roeckx]

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.orange.fr, reject=550 5.7.1 
> >> ... do not try TLS with smtp-in.orange.fr [80.12.242.9]
> >> Nov  7 09:17:31 rayleigh sm-mta[10148]: wA68PQwK006059: 
> >> to=, delay=23:52:05, xdelay=00:00:01, mailer=esmtp, 
> >> pri=77460547, relay=smtp-in.orange.fr. [80.12.242.9], dsn=5.0.0, 
> >> stat=Service unavailable
> > 
> > That server only seems to support TLS 1.0.
> > 
> > Have you read: /usr/share/doc/libssl1.1/NEWS.Debian.gz
> > 
> > Anyway, I suggest you file a bug against sendmail to override the
> > defaults.
> 
>   I have read /usr/share/doc/libssl1.1/NEWS.Debian.gz and tested all
> workarounds without any success.

And you restarted sendmail after changing /etc/ssl/openssl.cfg?


Kurt

Bug#913129: [Pkg-openssl-devel] Bug#913129: openssl: TLS error (error 403 4.7.0 TLS handshake failed in sendmail logs)

[Kurt Roeckx]

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.orange.fr, reject=550 5.7.1 
> ... do not try TLS with smtp-in.orange.fr [80.12.242.9]
> Nov  7 09:17:31 rayleigh sm-mta[10148]: wA68PQwK006059: to=, 
> delay=23:52:05, xdelay=00:00:01, mailer=esmtp, pri=77460547, 
> relay=smtp-in.orange.fr. [80.12.242.9], dsn=5.0.0, stat=Service unavailable

That server only seems to support TLS 1.0.

Have you read: /usr/share/doc/libssl1.1/NEWS.Debian.gz

Anyway, I suggest you file a bug against sendmail to override the
defaults.


Kurt

Bug#900152: nsca-ng: FTBFS against openssl 1.1.1

[Kurt Roeckx]

On Mon, Nov 05, 2018 at 12:28:50AM +0100, Sebastian Andrzej Siewior wrote:
> 
> No, it is not. It is a TLS1.3 issue. If I limit max protocol to TLS1.2
> then the testsuite passes. The problem with TLS1.3 could be that
> SSL_read() could return SSL_ERROR_WANT_READ asking to do the same. Was
> there a workaround for this or do I mix up things?
> Anyway, it seems that SSL_connect() returns SSL_ERROR_WANT_READ.

I'm not sure if there actually changed something related to
SSL_connect(), it could always return SSL_ERROR_WANT_READ, I
expect it to return that for a non-blocking 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

Bug#900152: nsca-ng: FTBFS against openssl 1.1.1

[Kurt Roeckx]

On Mon, Nov 05, 2018 at 12:28:50AM +0100, Sebastian Andrzej Siewior wrote:
> 
> No, it is not. It is a TLS1.3 issue. If I limit max protocol to TLS1.2
> then the testsuite passes. The problem with TLS1.3 could be that
> SSL_read() could return SSL_ERROR_WANT_READ asking to do the same. Was
> there a workaround for this or do I mix up things?
> Anyway, it seems that SSL_connect() returns SSL_ERROR_WANT_READ.

I'm not sure if there actually changed something related to
SSL_connect(), it could always return SSL_ERROR_WANT_READ, I
expect it to return that for a non-blocking 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

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

[Kurt Roeckx]

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
> > > usual default openvpn config) it fails in 1.1.1 and works with
> > > 1.1.0
> > > 
> > > With client tls-version-min set to 1.0 it works with both.
> > 
> > Yes, and 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.
> 
> You're implying openvpn doesn't pick up the openssl.cnf changes so I
> have to set tls-version-min 1.0 in the server side configuration?  OK,
> that works too.  

Your client doesn't support the settings in the openssl.cfg file. Your
openvpn client by defaults does TLS 1.0 only. The only way for your client
to do something other than TLS 1.0 is set the tls-version-min variable
to something. If you set it to 1.0, it will do any version
supported by the openssl library higher than 1.0.

> > So I'm failing to see what this bug report is about.
> 
> When you upgrade from openssl 1.1.0 to 1.1.1 causes an openvpn
> connection failure which the upgrade instructions don't fix.  It also
> seems to me there are probably quite a few other openssl.cnf blind
> applications in the system which will fail in a similar fashion.

This is on the server side. As far as I know, changing the
openssl.cnf file should just work. openvpn in testing takes the
minimum of the openssl.cfg value and TLS 1.0. So if you set None,
it should set TLS 1.0 as minimum. I assume you don't set a minimum
tls version in your openvpn config file or on the command line.


Kurt

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

[Kurt Roeckx]

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
> usual default openvpn config) it fails in 1.1.1 and works with 1.1.0
> 
> With client tls-version-min set to 1.0 it works with both.

Yes, and 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

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

[Kurt Roeckx]

On Sun, Nov 04, 2018 at 11:39:59AM -0800, James Bottomley wrote:
> > 
> > On which side do you use tls-version-min?
> 
> client
> 
> >  Can you please give the version of both openvpn and openssl on both
> > sides.
> 
> Client is openwrt, server is debian testing.  The package of the server
> was already provided in the bug report, but again it's
> 
> openssl 1.1.1-2
> openvpn 2.4.6-1
> 
> Packages on the openwrt client are
> 
> libopenssl 1.0.2g-1
> openvpn-openssl  2.3.6-5

So you're saying that even with tls-version-min 1.0 on your
client side and with openssl.cnf changed on the server it's still
not working? Either of those changes should be enough to get it
working as far as I understand.

I have almost the reverse in my setup, where the server is 2.3.4
and the client runs testing. On the server I've set the
tls-version-min 1.0 and everything works for me.

I will try to look at this in a few days.


Kurt

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

[Kurt Roeckx]

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 instance TLS 1.2. It's then up to the server to
> > pick a version that the client supports, so one that is smaller than
> > TLS 1.2, and it might pick TLS 1.0 or 1.2. It will then send a server
> > hello with that version.
> 
> OK, so I'm weary of trying to construct a theory of what the bug
> actually is, why don't you try to come up with one.  The symptoms are
> that openvpn in openwrt works with server 1.1.0 and fails with server
> 1.1.1 if you don't specify tls-version-min 1.0 on the command line.

On which side do you use tls-version-min? Can you please give the
version of both openvpn and openssl on both sides.


Kurt

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

[Kurt Roeckx]

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 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.
> 
> There's a difference: if you don't specify the command line tls-
> version-min, it actually asks openssl for the minimum version.  If you
> do specify, it takes what you tell it.

There is no API in OpenSSL to ask the minimum supported version.
What 2.3.4 does is that if you don't specify anything, it tells
OpenSSL to use TLS 1.0 only. What 2.4 does it just tell OpenSSL to
use any version it supports.

You can also specify that minimum version in the config file.

> > 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.
> 
> Well, obviously because it doesn't work as the log attached in the bug
> report shows.
> 
> The values I have in openssl.cnf are the recommended
> 
> MinProtocol = None
> CipherString = DEFAULT
> 
> And it definitely works because imap has an android client at 0.9.8
> which didn't work before the addition of that.
> 
> The openssl code looks to use SSL_CTX_get_min_proto_version() if you
> don't specify a version, so it finds a protocol below tls 1.0 to
> present which causes the error.  From the ordering in openssl, this is
> likely to be SSLv3, isn't it?

With the above config SSL_CTX_get_min_proto_version() will return
0 indicating that all version supported at compile time are
supported. The minium at compile time is TLS 1.0.

> The bug here is that you shouldn't kill the negotiation just because
> the client offers to support SSLv3, you should move on to negotiate a
> more secure cipher and only error out if the client can't support any
> protocols openssl is told to consider secure.

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 instance TLS 1.2. It's then up to the server to
pick a version that the client supports, so one that is smaller than
TLS 1.2, and it might pick TLS 1.0 or 1.2. It will then send a server
hello with that version.

So there are normally 2 cases that can be a problem:
- The client sends TLS 1.0 and the server has 1.2 as minimum, so
  the server say it's not supported.
- The client sends TLS 1.2, the server answers with 1.0, the
  client says 1.0 is too low.

The error message you showed says that it's the server that is
rejecting the client's version, and that the server is running a
1.1.1 version. Are you sure you've actually restarted the server
after changing the config file?


Kurt

Bug#912864: [Pkg-openssl-devel] Bug#912864: openssl: new version of openssl breaks some openvpn clients

[Kurt Roeckx]

On Sun, Nov 04, 2018 at 08:59:05AM -0800, James Bottomley wrote:
> Package: openssl
> Version: 1.1.1-2
> Severity: important
> 
> I've applied all the downgrades recommended to the openssl.cnf file
> and most services are now working again with the exception of openvpn.
> 
> The only failure seems to be a VPN connection to an openwrt router.
> The router is running Chaos Calmer 15.05 and has an upgraded openssl
> (to 1.0.2g-1).
> 
> The error is on the debian server side and only shows up at openvpn
> extreme verbosity:
> 
> Sun Nov  4 08:40:04 2018 us=149552 50.35.68.20:56038 OpenSSL: 
> error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported 
> protocol
> 
> The full verbose negotiation is
> 
> Sun Nov  4 08:40:04 2018 us=116122 50.35.68.20:56038 Control Channel MTU 
> parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
> Sun Nov  4 08:40:04 2018 us=116160 50.35.68.20:56038 Data Channel MTU parms [ 
> L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
> Sun Nov  4 08:40:04 2018 us=116243 50.35.68.20:56038 Local Options String 
> (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,cipher 
> AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
> Sun Nov  4 08:40:04 2018 us=116263 50.35.68.20:56038 Expected Remote Options 
> String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto 
> UDPv4,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
> RSun Nov  4 08:40:04 2018 us=116336 50.35.68.20:56038 TLS: Initial packet 
> from [AF_INET]50.35.68.20:56038, sid=812b650a 26613bfb
> WRRWRSun Nov  4 08:40:04 2018 us=149552 50.35.68.20:56038 OpenSSL: 
> error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported 
> protocol
> Sun Nov  4 08:40:04 2018 us=150331 50.35.68.20:56038 TLS_ERROR: BIO read 
> tls_read_plaintext error
> Sun Nov  4 08:40:04 2018 us=150984 50.35.68.20:56038 TLS Error: TLS object -> 
> incoming plaintext read error
> Sun Nov  4 08:40:04 2018 us=151598 50.35.68.20:56038 TLS Error: TLS handshake 
> failed
> Sun Nov  4 08:40:04 2018 us=152357 50.35.68.20:56038 SIGUSR1[soft,tls-error] 
> received, client-instance restarting
> 
> Obviously this was all working with 1.1.0 so something seems to have
> changed in the tls negotiation routines.
> 
> I can fix this in the client by adding the openssl command
> --tls-version-min 1.0 so it probably means, the way openvpn works that
> the openssl version installed in openwrt has some strange TLS version
> < 1.0 but clearly openssl shouldn't error out when presented with
> lower 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

Bug#912759: [Pkg-openssl-devel] Bug#912759: "wrong signature type" with working websites

[Kurt Roeckx]

On Sat, Nov 03, 2018 at 07:18:06PM +0100, Nicolas George wrote:
> 
> Thanks for the work-around. Can you tell me how I could find this by
> myself using the documentation and error message?

It is mentioned in the NEWS file that we increased the security
level, and that that disabled SHA1. It does not document all
possible error messages.

Kurt

Bug#912759: [Pkg-openssl-devel] Bug#912759: "wrong signature type" with working websites

[Kurt Roeckx]

On Sat, Nov 03, 2018 at 05:44:50PM +0100, Nicolas George wrote:
> > I suggest you try to contact your bank so that they update their
> > software.
> 
> No need, I already know what they will answer: "use Chrome, it works".

I suggest that you try anyway. If that doesn't work, you can try
to publicly shame them:
https://www.troyhunt.com/the-effectiveness-of-publicly-shaming-bad-security/

They are running a software version that has doesn't even have
support anymore and has known security issues, otherwise you
wouldn't be getting this error.

> Please fix the interoperability bug.

As I already explained, the interoperability bug is on the server
side, where the ignore what you send and pick something you didn't
send, while they actually support what you did send.

This can be worked around by lowering the security level from 2 to
1, so that you also 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

Bug#912759: [Pkg-openssl-devel] Bug#912759: "wrong signature type" with working websites

[Kurt Roeckx]

On Sat, Nov 03, 2018 at 04:20:59PM +0100, Nicolas George wrote:
> Package: openssl
> Version: 1.1.1-2
> Severity: important
> 
> Hi.
> 
> OpenSSL fails to connect with my bank's server:
> 
> openssl s_client -connect voscomptesenligne.labanquepostale.fr:443
> 
> fails with:
> 
> 140481179165120:error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong 
> signature type:../ssl/t1_lib.c:1073:

This is a bug in the server side, they need to update their
software. They seems to be running F5 BIG-IP software.

For more information, see:
https://github.com/openssl/openssl/issues/7126

I suggest you try to contact your bank so that they update their
software.


Kurt

Re: [Imports] Import of Flemish Government data (building footprints and addresses)

[Kurt Roeckx]

On Sat, Nov 03, 2018 at 01:37:52PM +0100, Mateusz Konieczny wrote:
> 1. Nov 2018 16:30 by kevin.b.ke...@gmail.com :
> 
> 
> > In both use cases, the major purpose of the foreign key is to avoid manual 
> > review in the case where OSM will not be updated. If an object (retrieved 
> > by key) is unchanged since the last import, in both OSM and the external 
> > database, then there is no work to be done.
> 
> Is there some reason why storing "object with id in database XYZ was uploaded 
> as OSM object 
> with id 717373737" should be stored in OSM?
> 
> This data is useful only to whoever made the import and keeps updating data. 
> Others,
> even when working with the same data must anyway verify whatever OSM objects 
> really match
> objects in the external database.

So you're suggesting storing the relation between the 2 database
in a 3rd database?

After an edit in osm, you would also need to edit this other
database. Without tools to automate this, this looks very error
prone. I don't directly see how you can automate this in an
editor. On the other hand, importing the id in osm seems easy.


Kurt


___
Imports mailing list
Imports@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports

Bug#912737: [Pkg-openssl-devel] Bug#912737: openssl: SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed

[Kurt Roeckx]

On Sat, Nov 03, 2018 at 11:12:37AM +0100, Julien Lecomte wrote:
> Package: openssl
> Version: 1.1.1-2
> Severity: serious
> Justification: makes unrelated software on the system (or the whole system) 
> break
> 
> Dear Maintainer,
> 
> On a fresh install of Debian/Buster via the alpha3 dvd ISO, when I try to 
> access some SSL URLs, openssl fails to download said resource.
> 
> ~~~bash
> julien@desktop:/tmp$ curl  
> https://download.lenovo.com/pccbbs/mobiles/n1wuj23w.exe --output file
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
>   0 8169k0 278000 0   268k  0  0:00:30 --:--:--  0:00:30  268k
> curl: (56) OpenSSL SSL_read: error:1408F119:SSL 
> routines:ssl3_get_record:decryption failed or bad record mac, errno 0
> ~~~
> 
> URL above issues error "/tmp/mozilla_julien0/5wQP3KKa.bin.part could not be 
> saved, because the source file could not be read." under firefox-esr.

It works for me.

Are you saying it gives an error both with firefox and curl? Then
it would be 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

Bug#912737: [Pkg-openssl-devel] Bug#912737: openssl: SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed

[Kurt Roeckx]

On Sat, Nov 03, 2018 at 11:12:37AM +0100, Julien Lecomte wrote:
> Package: openssl
> Version: 1.1.1-2
> Severity: serious
> Justification: makes unrelated software on the system (or the whole system) 
> break
> 
> Dear Maintainer,
> 
> On a fresh install of Debian/Buster via the alpha3 dvd ISO, when I try to 
> access some SSL URLs, openssl fails to download said resource.
> 
> ~~~bash
> julien@desktop:/tmp$ curl  
> https://download.lenovo.com/pccbbs/mobiles/n1wuj23w.exe --output file
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
>   0 8169k0 278000 0   268k  0  0:00:30 --:--:--  0:00:30  268k
> curl: (56) OpenSSL SSL_read: error:1408F119:SSL 
> routines:ssl3_get_record:decryption failed or bad record mac, errno 0
> ~~~
> 
> URL above issues error "/tmp/mozilla_julien0/5wQP3KKa.bin.part could not be 
> saved, because the source file could not be read." under firefox-esr.

It works for me.

Are you saying it gives an error both with firefox and curl? Then
it would be 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

Bug#912650: openvpn: Version in jessie only does TLS 1.0 by default, breaking connections with version from testing

[Kurt Roeckx]

Package: openvpn
Version: 2.3.4-5+deb8u2
Severity: important

Hi,

The version in jessie only does TLS 1.0 by default. If you specify
"tls-version-min 1.0" in the config file, it will also support
TLS 1.0, 1.1 and 1.2.

The OpenSSL version currently in testing only supports TLS 1.2+ by
default, 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

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Kurt Roeckx]

On Thu, Nov 01, 2018 at 07:50:35PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Nov 01, 2018 at 11:18:14PM +0100, Sebastian Andrzej Siewior wrote:
> > Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
> > bare metal with nothing fancy I have:
> > [3.544985] systemd[1]: systemd 239 running in system mode. (+PAM…
> > [   10.363377] r8169 :05:00.0 eth0: link up
> > [   41.966375] random: crng init done
> > 
> > which means I have to wait about half a minute until I can ssh into. And
> > there is no way to speed it up?
> 
> So that surprises me.  Can you tell me more about the hardware?  Is it
> something like a Rasberry Pi?  Or is it an x86 server or desktop?  In
> my experience for most x86 platforms this isn't an issue.

The original poster had:
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)

But I'm not sure if that's a real machine or some virtual host,
I'm going to guess it's a virtual host.

Anyway, on my laptop I get:
[   12.675935] random: crng init done

If the TPM is enabled, I also have an /etc/hwrng, but rng-tools is
started later after the init is done.

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

Re: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Kurt Roeckx]

On Thu, Nov 01, 2018 at 07:50:35PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Nov 01, 2018 at 11:18:14PM +0100, Sebastian Andrzej Siewior wrote:
> > Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
> > bare metal with nothing fancy I have:
> > [3.544985] systemd[1]: systemd 239 running in system mode. (+PAM…
> > [   10.363377] r8169 :05:00.0 eth0: link up
> > [   41.966375] random: crng init done
> > 
> > which means I have to wait about half a minute until I can ssh into. And
> > there is no way to speed it up?
> 
> So that surprises me.  Can you tell me more about the hardware?  Is it
> something like a Rasberry Pi?  Or is it an x86 server or desktop?  In
> my experience for most x86 platforms this isn't an issue.

The original poster had:
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)

But I'm not sure if that's a real machine or some virtual host,
I'm going to guess it's a virtual host.

Anyway, on my laptop I get:
[   12.675935] random: crng init done

If the TPM is enabled, I also have an /etc/hwrng, but rng-tools is
started later after the init is done.

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


___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Kurt Roeckx]

On Thu, Nov 01, 2018 at 07:50:35PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Nov 01, 2018 at 11:18:14PM +0100, Sebastian Andrzej Siewior wrote:
> > Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
> > bare metal with nothing fancy I have:
> > [3.544985] systemd[1]: systemd 239 running in system mode. (+PAM…
> > [   10.363377] r8169 :05:00.0 eth0: link up
> > [   41.966375] random: crng init done
> > 
> > which means I have to wait about half a minute until I can ssh into. And
> > there is no way to speed it up?
> 
> So that surprises me.  Can you tell me more about the hardware?  Is it
> something like a Rasberry Pi?  Or is it an x86 server or desktop?  In
> my experience for most x86 platforms this isn't an issue.

The original poster had:
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)

But I'm not sure if that's a real machine or some virtual host,
I'm going to guess it's a virtual host.

Anyway, on my laptop I get:
[   12.675935] random: crng init done

If the TPM is enabled, I also have an /etc/hwrng, but rng-tools is
started later after the init is done.

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

Bug#912604: [Pkg-openssl-devel] Bug#912604: Bug#912604: libssl1.1: libssl version 1.1.1 breaks burp backup buster clients with stretch server

[Kurt Roeckx]

On Thu, Nov 01, 2018 at 09:52:12PM +0100, Sebastian Andrzej Siewior wrote:
> |$ openssl x509 -in 912604.cert -text | grep Signature
> |Signature Algorithm: sha1WithRSAEncryption
> |Signature Algorithm: sha1WithRSAEncryption
> 
> The point is that your server certificate is signed with SHA1 while
> the minimum is SHA256. Please note that all publicly issued certificates
> are signed with SHA256 these days.
> 
> I would suggest a *note* in burp to notify users of burp which created
> self-signed certificates with pre-Buster machines that they might need
> to recreate their certificate if it is sigend with SHA1. Thus
> resssigning to burp.
> I just tried the Buster version of burp and myClient.crt, myServer.crt
> and CA_myCA.crt is signed with SHA256. I would assume that the script
> does not set the signing method and the default is used which changed.

As far as I know, the default in stretch should also use sha256,
most likely those certificates are older.


Kurt

Bug#912439: [Pkg-openssl-devel] Bug#912439: OpenSSL in Debian Testing breaks SSL connectivity in some cases with hexchat/irssi

[Kurt Roeckx]

On Wed, Oct 31, 2018 at 11:08:18AM -0400, Justin Piszcz wrote:
> Package: openssl
> Version: 1.1.1-2
> 
> Bug: Connection failed (20337260938) error:141A318A:SSL
> routines:tls_process_ske_dhe:dh key too small)

During the upgrade you should have received the following message:

  Following various security recommendations, the default minimum TLS version
  has been changed from TLSv1 to TLSv1.2. Mozilla, Microsoft, Google and Apple
  plan to do same around March 2020.

  The default security level for TLS connections has also be increased from
  level 1 to level 2. This moves from the 80 bit security level to the 112 bit
  security level and will require 2048 bit or larger RSA and DHE keys, 224 bit
  or larger ECC keys, and SHA-2.

  The system wide settings can be changed in /etc/ssl/openssl.cnf. Applications
  might also have a way to override the defaults.

  In the default /etc/ssl/openssl.cnf there is a MinProtocol and CipherString
  line. The CipherString can also sets the security level. Information about the
  security levels can be found in the SSL_CTX_set_security_level(3ssl) manpage.
  The list of valid strings for the minimum protocol version can be found in
  SSL_CONF_cmd(3ssl). Other information can be found in ciphers(1ssl) and
  config(5ssl).

  Changing back the defaults in /etc/ssl/openssl.cnf to previous system wide
  defaults can be done using:
  MinProtocol = None
  CipherString = DEFAULT

  It's recommended that you contact the remote site in case the defaults cause
  problems.


Kurt

Re: Questions regarding the qualifications and competency of TUVIT

[Kurt Roeckx via dev-security-policy]

On 2018-10-31 16:42, Wiedenhorst, Matthias wrote:

In several emails, we answered to his complaint, explained our procedures and 
justified the classification of the encoding error as minor (non-critical) 
non-conformity.


I think we never consider encoding errors as a minor error.


Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy