From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Upgrading to OpenSSL 1.1.0 Date: Mon, 15 Jan 2018 11:58:13 +0000 Message-ID: <1516017493.3647.78.camel@ipfire.org> In-Reply-To: <6BE3D5D6-CC5A-4B2A-A329-E2300B8DCCE6@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6233209152876825554==" List-Id: --===============6233209152876825554== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, wow, long email... On Sun, 2018-01-14 at 11:59 +0100, ummeegge wrote: > Hi Michael, >=20 >=20 > > Hmm, okay. I have no idea how I forgot about all these things. > >=20 > > Please pull the branch again and everything except openvpn will build now. >=20 > have pulled it again and all packages also OpenVPN has been build successfu= lly > except Bacula=C2=B4s ROOTFILE had some problems while packaging but the > installation process of the .iso via VM do not works and stops like before > with a "Unable to install language cache." and ends up in a "Setup has fail= ed. > Press OK to reboot." . So i could make only rudimentary checks with OpenVPN > the new OpenSSL in chroot (have listed them at the bottom). >=20 > I have had no problems building OpenVPN-2.4.4 --> > https://swupdate.openvpn.org/community/releases/openvpn-2.4.4.tar.xz without > any further modifications of the LFS (except the md5 and version number), > there was also no need for the LZ4 lib ? What problems appears for you ? None, I just haven't tried to build it because you are the maintainer of Open= VPN :) If it just builds, please send a patch for just that package. You can also send an extra patch that adds LZ4. > > > I think an update of Asterisk and his components should work also with = the > > > new > > > OpenSSL.=20 > > > At least in my environment Asterisk has build with OpenSSL-1.1.0g, but > > > there > > > was one more dependency (jansson) needed. Changes can be found in here = --> > > > https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire- > > > 2.x.git;a=3Dcommit;h=3D2d940ba2187a53cf52d2191a36c3897636b9600c . > >=20 > > I actually updated that myself before you sent your email, but please rev= iew > > my > > changes. >=20 > Looks here good either but since i do not use Asterisk it is problematic to > give it some testings and appropriate feedback. I am not using this either, but I can test it. I guess it should be fine. > > > OpenVPN-2.4.4 has build with OpenSSL-1.1.0g have included also the LZ4 > > > compression lib but otherwise it builds out of the box but OpenVPN won= =C2=B4t > > > start > > > without some changes in ovpnmain.cgi. In here --> > > > https://github.com/ummeegge/OpenVPN_30.08.2017/commit/7460cead169ea919f= 66a > > > d706 > > > 8e764fef37bf8f8b#diff-2011d5d928fd214cacb83844729c65cc a little more th= en > > > needed has been done but it describes very closely the needed changes. > >=20 > > Hmm, I am not sure if we will have a lot of client support. But it should= be > > a > > small library so that it wouldn't hurt too much to include it as well. >=20 > To my current knowledge MySQL (possibly only an updated one) can also use L= Z4 > may there are more candidates in IPFire which can participate from this > compression lib... Not sure if people are using MySQL too much on IPFire. Hopefully they don't do that for any performance-critical applications. I guess the only other useful application for LZ4 would be backups. >=20 > >=20 > > > The most important are: > > > 1) The script-security flag 'system' can not be used anymore the server > > > won=C2=B4t > > > start if this isn=C2=B4t fixed. > >=20 > > Where do we use that? >=20 > It can not be used over the WUI only since there is the need to add additio= nal > directives over the server.conf which calls external programs or scripts, b= ut > it can be consistently used via the "Additional configuration" > (client{server}.conf.local under /var/ipfire/ovpn/scripts/ ). OpenVPN have > dropped the 'system' flag due to the security implications with shell > expansions when executing scripts via the system() call . >=20 > Another point in here is IPFire uses currently the level 3 of --script- > security for the RW " 3 -- Allow passwords to be passed to scripts via > environmental variables (potentially unsafe)" which is important for some > kinds of authentication methods but which has also been marked as unsafe and > have also be again pointed out while the QuarkLabs and Cryptography > Engineering LCC audit --> > https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineer= Aud > its --> under "OVPN-08-1: OpenVPN configuration risks: --script-security 3" > you can find there also OpenVPNs statements causing this topic. AFAIK we don't use any of those authentication methods. Or are we? > >=20 > > > 2) OpenVPN have added an automatic cipher negotiation with 2.4.x which > > > should > > > be manageable in my opinion. If someone needs to have other ciphers then > > > the > > > strongest defaults e.g. for the usage of HWRNG this option should be > > > switchable with an OFF/ON checkbox.=20 > >=20 > > Who would want to switch off a HWRNG? OpenVPN should only use entropy from > > the > > kernel and nothing else. Never directly read from any HWRNGs. >=20 > The ON/OFF switch should be there to deactivate the automatic cipher > negotiation not the HWRNG. As far as i remember some crypto accelerators can > only be used with certain types of encryption e.g. --> https://doc.pfsense= .or > g/index.php/Are_cryptographic_accelerators_supported . So in my understandi= ng > if OpenVPN negotiates for example AES-256-GCM with the client cause the > appropriate OpenSSL lib do supports it some potential existing accelerators > like e.g. the "AMD Geode LX Security Block" won=C2=B4t be used. If i get th= at right > this might be one case where the automatic cipher negotiation should be > deactivated ? Another one might be setups with vast amounts of clients where > possible less computing power with smaller key lengths is wanted. > That=C2=B4s why i disabled the cipher negotiation per default and if wanted= one > click via checkbox can be used to enable it for all clients whereby the CCD > option can be used to deactivate the cipher negotiation for specific client= s.=20 > Not sure if this is the best practice and it might be great if someone can > give me feedback for this since this has not been debated since now !!! OpenSSL choses to activate these things automatically when they are available. There is no need to do anything. Even apache and things like that use them because they use OpenSSL. However, that is not an HWRNG. That is just a random number generator like RDRAND on Intel processors. AESNI is not called a HWRNG. I do not see a reason why people would want to disable this. They work and if someone wants to disable them (because they are malfunctioning), that should = be possible system-wide. We should not have too many switches. It makes the web UI complicated. >=20 > >=20 > > And about the negotiation, that would be nice, but does that work with ol= der > > clients? >=20 > The negotiation does not work with clients before 2.4.0 but in that case > OpenVPN uses the already configured and in server and client configuration > defined--cipher and --auth directive as a fall back. Have tested this with = an > older Tunnelblick client which used OpenVPN-2.3.18 on an old OS X version -= -> > Tunnelblick: OS X 10.7.5; Tunnelblick 3.5.17 (build 4270.4900) where OpenVPN > used an "peer info" function to investigate the client version -->=20 >=20 > Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 peer in= fo: > IV_VER=3D2.3.18 > Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 peer in= fo: > IV_PLAT=3Dmac > Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 peer in= fo: > IV_PROTO=3D2 > Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Outgoing > Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key > Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Outgoing > Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication > Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Incoming > Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key > Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Incoming > Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication > Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Control > Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit = RSA Yes, that is fine and I wouldn't have expected anything else since the client side needs to support the negotiation, too. > but the server.conf serves --ncp-ciphers but also --cipher and --auth --> >=20 > #OpenVPN Server conf >=20 > daemon openvpnserver > writepid /var/run/openvpn.pid > #DAN prepare OpenVPN for listening on blue and orange > ;local ue.*.org > dev tun > proto udp > port 1194 > script-security 3 > ifconfig-pool-persist /var/ipfire/ovpn/ovpn-leases.db 3600 > client-config-dir /var/ipfire/ovpn/ccd > tls-server > ca /var/ipfire/ovpn/ca/cacert.pem > cert /var/ipfire/ovpn/certs/servercert.pem > key /var/ipfire/ovpn/certs/serverkey.pem > dh /var/ipfire/ovpn/ca/dh1024.pem > server 10.2.17.0 255.255.255.0 > tun-mtu 1400 > mssfix 0 > route 10.1.4.0 255.255.255.252 > keepalive 10 60 > status-version 1 > status /var/run/ovpnserver.log 30 > ncp-ciphers AES-256-GCM:AES-256-CBC:CAMELLIA-256-CBC > cipher AES-256-CBC > auth SHA512 > tls-auth /var/ipfire/ovpn/certs/ta.key > max-clients 100 > tls-verify /usr/lib/openvpn/verify > crl-verify /var/ipfire/ovpn/crls/cacrl.pem > user nobody > group nobody > persist-key > persist-tun > verb 3 >=20 > so i think this should be no problem. So we need to add the ncp-ciphers. If we didn't we would have some sort of functionality just like OpenVPN 2.3. Which is fine with me for the moment, to= o. > > > I can do this but it might be great if i can make before some tests with > > > the > > > new OpenSSL lib. Would it be OK for you if i push the first part as in = the > > > Github example ? Have already changed the language file description and > > > left > > > Camellia out the --ncp-ciphers list (which is equal to OpenVPN manpage= ). > >=20 > > Please send any proposed changes as patches to the list. >=20 > Shouldn=C2=B4t i test OpenVPN with the new OpenSSL before pushing this, if = the iso > is working i can make an installation in my testing environment to break do= wn > the most important steps ? I thought that was tested already. However, the OpenSSL is branch is somewhat unstable and won't be released with the next core update. So if you send it n= ow, it wouldn't break anyone's system. > I forgot also one important point to mention which we discovered really lat= e. > OpenVPN-2.4.x refactors the CRL handling --> https://github.com/OpenVPN/ope= nvp > n/commit/160504a2955c4478cd2c0323452929e07016a336 which is a problem cause = the > CRL will now be checked in the "validBefore" and "validAfter" fields. Since > "default_crl_days" are set to 30 days we can run into a problem if the CRL = has > been expired. Error message looks like this: >=20 > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 VERIFY ERRO= R: > depth=3D0, error=3DCRL has expired: C=3DUS, O=3DTatoine, CN=3DLGG3 > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 OpenSSL: > error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify > failed > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS_ERROR: = BIO > read tls_read_plaintext error > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS Error: = TLS > object -> incoming plaintext read error > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS Error: = TLS > handshake failed > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 Fatal TLS > error (check_tls_errors_co), restarting > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 > SIGUSR1[soft,tls-error] received, client-instance restarting The CRL has a valid before and after date? In that case we just need to regenerate it. If the CA or some client certificates have expired, this is what we would expect, isn't it? > A more detailed discussion in the IPFire forum is here --> > https://forum.ipfire.org/viewtopic.php?f=3D50&t=3D18067&start=3D30#p112529 = located, > the Debian discussion --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug= =3D84 > 9909 and OpenVPN --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D84= 9909 > . An idea there was to set the "nextUpdate" value in a far future as the CA= expiry date is, we decided in the forum to leave this idea behind and starte= d to develop a first idea for an CRL updater, please check this in here --> h= ttps://forum.ipfire.org/viewtopic.php?f=3D50&t=3D18067&sid=3De623c9c726b7d0f5= fb14b9659b4a6625&start=3D45#p112737 . In that case we would need a script whi= ch checks periodically when a CRL update needs to be done.=20 Not a fan of cron jobs for things like this, but I guess we have no other choice. This looks good. > If you have better ideas for this or another script it might be really > helpful. No not really. We have to make sure that the CRL is up to date even when the system is not being rebooted in a while. So it has to be checked regularly wh= ich requires a cron job. Setting the expiry date to infinity would slightly ruin the idea of a CRL. > > > Yes i think so too. Nevertheless i think we should introduce at least t= he > > > new > > > Galois/Counter Mode (available with 128, 196 and 256 bit) which is some= how > > > the > > > default of the new OpenVPN if possible. Would do this with a second pat= ch > > > where it might also be an idea to list all the deprecated ciphers as s= uch > > > (via optgroup label) ? > >=20 > > Certainly GCM and all the other ones that include MAC. >=20 > OK, will do it like this with a second patch. >=20 > >=20 > > Peter has proposed a patch recently with improved crypto, please work > > together > > with him. >=20 > We can do this, no problem. @Peter would you write me to ummeegge at > ipfire.org ? It is here https://patchwork.ipfire.org/patch/1594/ -Michael >=20 >=20 > Am 13.01.2018 um 13:30 schrieb Jeffrey Walton: >=20 > > On Wed, Jan 10, 2018 at 12:08 PM, Michael Tremer > > wrote: > > > ... > > > So, again for me: What is the status of OpenVPN 2.4 now? I guess that > > > should build with OpenSSL 1.1 out of the box. > >=20 > > I believe OpenSSL 1.1.0 is not supported by a few key packages, like > > OpenVPN and OpenSSH. >=20 > Hi Jeffrey, a fast test in chroot after building process points the followi= ng > out. >=20 > OpenVPN-2.4.4 with OpenSSL-1.1.0g has been build with another: >=20 > ipfire build chroot (x86_64) root:/$ openvpn --version > OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] > [MH/PKTINFO] [AEAD] built on Jan 13 2018 > library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.09 > Originally developed by James Yonan > Copyright (C) 2002-2017 OpenVPN Technologies, Inc. > Compile time defines: enable_async_push=3Dno enable_comp_stub=3Dno > enable_crypto=3Dyes enable_crypto_ofb_cfb=3Dyes enable_debug=3Dyes > enable_def_auth=3Dyes enable_dlopen=3Dunknown enable_dlopen_self=3Dunknown > enable_dlopen_self_static=3Dunknown enable_fast_install=3Dyes enable_fragme= nt=3Dyes > enable_iproute2=3Dyes enable_libtool_lock=3Dyes enable_lz4=3Dyes enable_lzo= =3Dyes > enable_management=3Dyes enable_multihome=3Dyes enable_pam_dlopen=3Dno > enable_pedantic=3Dno enable_pf=3Dyes enable_pkcs11=3Dno enable_plugin_auth_= pam=3Dyes > enable_plugin_down_root=3Dyes enable_plugins=3Dyes enable_port_share=3Dyes > enable_selinux=3Dno enable_server=3Dyes enable_shared=3Dyes > enable_shared_with_static_runtimes=3Dno enable_small=3Dno enable_static=3Dy= es > enable_strict=3Dno enable_strict_options=3Dno enable_systemd=3Dno enable_we= rror=3Dno > enable_win32_dll=3Dyes enable_x509_alt_username=3Dno with_crypto_library=3D= openssl > with_gnu_ld=3Dyes with_mem_check=3Dno with_sysroot=3Dno >=20 >=20 > OpenVPN rudimentary crypto test: >=20 > ipfire build chroot (x86_64) root:/$ openvpn --genkey --secret /tmp/key > ipfire build chroot (x86_64) root:/$ ls /tmp > secret > ipfire build chroot (x86_64) root:/$ time openvpn --test-crypto --secret > /tmp/key --verb 0 --tun-mtu 20000 --cipher aes-256-cbc > Sun Jan 14 08:15:35 2018 disabling NCP mode (--ncp-disable) because not in > P2MP client or server mode >=20 > real 0m11.459s > user 0m11.452s > sys 0m0.000s >=20 > ipfire build chroot (x86_64) root:/tmp$ openvpn --test-crypto --secret key = -- > cipher AES-256-CBC > Sun Jan 14 08:18:15 2018 disabling NCP mode (--ncp-disable) because not in > P2MP client or server mode > Sun Jan 14 08:18:15 2018 OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL > (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 13 2018 > Sun Jan 14 08:18:15 2018 library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO > 2.09 > Sun Jan 14 08:18:15 2018 OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL > (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 13 2018 > Sun Jan 14 08:18:15 2018 Entering OpenVPN crypto self-test mode. > Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=3D1 > Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=3D2 >=20 > ... >=20 > Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=3D1499 > Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=3D1500 > Sun Jan 14 08:18:15 2018 OpenVPN crypto self-test mode SUCCEEDED. >=20 >=20 > OpenSSH_7.6p1 with OpenSSL-1.1.0g RSA key generation: >=20 > ipfire build chroot (x86_64) root:/tmp$ ssh -V > OpenSSH_7.6p1, OpenSSL 1.1.0g 2 Nov 2017 >=20 > ipfire build chroot (x86_64) root:/tmp$ ssh-keygen -t rsa > Generating public/private rsa key pair. > Enter file in which to save the key (/root/.ssh/id_rsa): /tmp/id_rsa > Enter passphrase (empty for no passphrase):=20 > Enter same passphrase again:=20 > Your identification has been saved in /tmp/id_rsa. > Your public key has been saved in /tmp/id_rsa.pub. > The key fingerprint is: > SHA256:jUS0782RoSmu7YQGcKJZh+yhEVP90XpMIN4NQaLJohQ root(a)ummeegge > The key's randomart image is: > +---[RSA 2048]----+ > > oE..o.=3D=3Do | > > =3D.=3D.+.+o. | > > o.@ +..=3D+ . | > > oO * o.o+ o o | > > =3D . . .S =3D o | > > . o o o . | > > o o . o | > > . + | > > ..o | >=20 > +----[SHA256]-----+ >=20 >=20 > ipfire build chroot (x86_64) root:/tmp$ cat id_rsa > -----BEGIN RSA PRIVATE KEY----- > Proc-Type: 4,ENCRYPTED > DEK-Info: AES-128-CBC,3C054B16BD28E8EA0E4B332AC5097309 >=20 > jfnNwOglRHJR7sSXmU+7JtxDiuf2N4+B/oaexzXmlE+rTpKPocW1Tj8mxo9Y5mOc > UtS24qF3PojMO4u6W7YAK+27RuIUa48bwXLODUk5+DOXblfgnnzgCF3ChT25tZ9x > L4yyvvp9Q9JbeaCbEZp4z6bFI7x/Fhb3ISK6bMMg9IjjhjAhd6pQScCl+4bifjF2 > I3LO97Me9kQ02rBOSXZqdVXFDbZzQU0mtIvcv2SxwfiijhWolrTp769LDpj0uOc+ > BHr3sAEDoxzq2BRUagUXy9yFHRZZl3xwPnm4akQWZnL6buye3H4IcPKEVk+pFY8e > hWMXhiVBAGkwSfV7bC2Nr2eAuWdiAM+ai8zXFz8lEBtw0XJDk0mHwadD9u4qUmf6 > 6TQv1weQkxV4l2OFARM56Aw9IioMP9Q1+UONLM35kPuiQKGHPdRJsTCDEovU5LHK > WRLoe3yOKVgM6BrA36YoSefgD8M1DClh4jmNgmx6BRPWwlaW1oDbOZzHi8anGnH+ > a03HbL77kIeFxpRkIm7gEC+c/YFTLoIrx8NHbjEid6rhgy0jqSRw2kJhHpzmP7Tj > +1a5s/j8l6yQcWbtkndCVMhdp0HVsYx0UMh20ey5z4nB0ZenyxdaAlM8bnBR8tfj > Z3E4a+wXVhs+ISwbkdKY6Gny8llimAqCVpJLJgLFNlVTdv6R7cgDFpL8+Y1oCQoz > F3TVJLyeuv96hQg5n3C0gab4x0CVv9xaAAhbEW3jwYIY3MXSSsmG8RXVjCaZbotr > 3QKkboAV8hoZE3jYkFIt5jeHwFU+BH7FsgK2Chewo5XLehQdFVYGOS2per+/TVap > t4/cGfdFOdvMHYcmNk8BqjrSfqnepvFZd8gIgPzJJGkOfa2ni2jI6VCwnXoCrJ3B > l3R50NNqNYyjq4q1vacYcJSGsWkGLSBJekKCn+aE17fZfme64InvE3raHdGWI6Og > hk3HTBw0JVZBVZjlkrtbqZjeU7VjaBl6KhqjaxIncgQbfgHfNVIk3qQkjuaf1bOQ > igiBDdixZrVnWaTR6aQCcfM5YX/fEqLa/EzBlA7j3YoHPgEvvIcRHx/iq5fGiV15 > 4+nlTklv6Yj+7LCr7P3UwI16Irkp7S6YN3+tpUbnglZbRgxoUV3Q0bRNbVDHAEC2 > 9Wlu0o7Pw1n9I0suoQxzMrZa/4Ia03Cir0H805/KFksI+YbMem9bkOBWeEAJVJWE > qbx9uqNznz/V2sdb32scxXR7IvlJ77jk+BpZub80icxSn+JydLDP4D7gFXkm2aeT > bcUR4/KdGImZGeD3SRfIY7TiQ92HIFqGzNpDSCmVOtFhgcLfalzEXtZ59ohUzADR > KCCueKsgM5/3LrsLHs6wyBkeUlbEU00mFCobHq7xzjs9dc8WVV5BELw3KlKoYlwX > yCEqm82ysukgQaTL1Exo7EJBIz/IOh0IYvN1JfI/Cn0bCz67CqGXflhRENm8JOuo > d0lWAIuGcwHId8XcevPrX3crsz90cpAxCEBTzc0sYZloosOeOeoGI+60TWh+ERVV > WShv08jUC2LrFoG/UvKW+hz1xkL2k/vjU4pwhZ0ueXQR/WeRbkb/TCCWtZlfKkTd > -----END RSA PRIVATE KEY----- >=20 >=20 > which looks not that bad but again this are only really fast overviews and = not > represantative ones. >=20 >=20 > All in all my feeling for this update is also without the new and not tested > OpenSSL currently somehow not good since there are elementary questions > (technical and design ones) open and very few people helped out in testing = all > that which hopefully will change before delivering the code to optimize the > design or a release to check the technical points. >=20 >=20 > Some news from here and a nice sunday to all. >=20 >=20 > Greetings, >=20 > Erik >=20 >=20 > >=20 >=20 >=20 --===============6233209152876825554== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl Mnlwa3R4Z0hudy8yK1FDUWNGQWxwY2wxVUFDZ2tRZ0hudy8yK1EKQ1FmZGZRLy9hR3V0VjRQaWs5 VlhZQ052VkUxRzBhcjdndDdaeTlFOU93ZXlGdE5RQVZ0emJDcFNpdFQvOFJaTwpoS3NSNkJGM3lD THM0SmRETkxuSzUwd2UySzNPZnl4WHA0bzVNS21jM1BEWms0WFhzcTFGT2cxbit2am9xQm1RCmtn MGR0c3lqdkpIdmlxZVB6YXc5Ni9OWWt4eXFqVWNEajVnbVNVa1NIQUFOQjF0R0xVL0NPMjZYT3ZF bWFTTzMKMi9Rblp0VDQ3QTRyWVJQdkhaUHcvZ0JweGl0MWE0T2R4RE1Qc3dmSmFNdlppeWd6akxK Y0x6UEhGM2YrT2ZZbApZMkFpcndPYngzdStzSGFYV2NxSExJK0t1Q1NSNm1SdEplWk4xcSs4allX YzQ3eUQweUtZMlJKTml6MCtBZmZLCmpqcmNvU3dyaUNFem1WQm5CRkFOb2gvak13Y1NhdWt4aVZV VXdzK3FCZUVrdnI4ZXlvWDI1NDJFQ2VyQWxyS3MKY1g0MXpQWkxiMUx3RC9yWHpKU0pmaTBqRkF3 amoyQzE5eGpRd1E0NmxJaWtYaElidGorcU5WSE9lSnkrSE1ZOQptb2hrOXBXTXpYMU9PdHVwaGVM QlczWnVvS09oSnVKZmgvWUFjd0hTQ3NHVFVDVHFYRHdvSkxoanlXSnE0akZiClhxak5WeWdvVDRa SlJPQ2l1TGJIMVlpakI5NllER1pLTWdhblkyTm1KcFZ1ZFhxbmV4TFlPcTVnSGIyYm5DYi8KUmlY a3diaW9KdXRRM3E2N1l3R3ZxcFFML3Ryd3YxTERmZlJGazhxYWFKWC9xMHJoYjV1dElIRDVUTmxZ NTRVSgp1WExGOEZWZWtoT3NGcHNteTZxM3N6aWZFOFcxTXpLaHJ6ZXFvUjJCMjgxNmI0VWNsQW89 Cj1GQ1llCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============6233209152876825554==--