Patch has been applied to the master branch.
commit 2dca268a643d4cfe375ef46950b57ef660073711
Author: Gert Doering
Date: Fri Jun 9 22:50:29 2017 +0200
proxy.c refactoring: remove always-NULL gc parameter
Signed-off-by: Gert Doering
Acked-by: Steffan Karger
Message-Id: <201
From: Emmanuel Deloget
OpenSSL 1.1 does not allow us to directly access the internal of
any data type, including RSA. We have to use the defined
functions to do so.
Compatibility with OpenSSL 1.0 is kept by defining the corresponding
functions when they are not found in the library.
Signed-off-
From: Emmanuel Deloget
OpenSSL 1.1 does not allow us to directly access the internal of
any data type, including DSA. We have to use the defined
functions to do so.
Compatibility with OpenSSL 1.0 is kept by defining the corresponding
functions when they are not found in the library.
Signed-off-
From: Emmanuel Deloget
OpenSSL 1.1 does not allow us to directly access the internal of
any data type, including X509. We have to use the defined
functions to do so.
In x509_verify_ns_cert_type() in particular, this means that we
cannot directly check for the extended flags to find whether the
c
From: Emmanuel Deloget
OpenSSL 1.1 does not allow us to directly access the internal of
any data type, including EVP_MD_CTX. We have to use the defined
functions to do so.
Compatibility with OpenSSL 1.0 is kept by defining the corresponding
functions when they are not found in the library.
Sign
This is version 7 of the OpenSSL 1.1 patch series. It has been rebased
on top of the latest git revision.
It builds upon the previous version and adds the following:
* fix a memory leak when playing with internal ASN1 strings
* introduce RSA_bits() and DSA_bits()
* add a few comments to explain
From: Emmanuel Deloget
OpenSSL 1.1 does not allow us to directly access the internal of
any data type, including EVP_PKEY. We have to use the defined
functions to do so.
Compatibility with OpenSSL 1.0 is kept by defining the corresponding
functions when they are not found in the library.
Signed
From: Emmanuel Deloget
OpenSSL 1.1 does not allow us to directly access the internal of
any data type, including EVP_CIPHER_CTX. We have to use the defined
functions to do so.
Compatibility with OpenSSL 1.0 is kept by defining the corresponding
functions when they are not found in the library.
From: Emmanuel Deloget
OpenSSL 1.1 does not allow us to directly access the internal of
any data type, including HMAC_CTX. We have to use the defined
functions to do so.
Compatibility with OpenSSL 1.0 is kept by defining the corresponding
functions when they are not found in the library.
Signed
From: Emmanuel Deloget
We are in control of meth->name (we string_alloc() it in RSA_meth_new())
so we know that we can free() it when it's no longer needed. Yet we have
to force the value to be non-const to avoid a compiler warning -- due to
the fact that OpenSSL defines the value as a const char
*bump*
Is there no explanation ?
On 07/06/17 17:41, debbie10t wrote:
Hi,
I have a basic setup and discovered that my W10 client was assigning a
second IPv6 address to TAP even though it is *not* being pushed by the
server. The second address is an old address from a server that I
sometim
ACK. I'm not sure if this can ever be exploited (there's enough NULLs
on the stack to eventually terminate), but it's certainly not looking
healthy.
I've reformatted your commit message & un-wrapped a number of broken long
lines.
Your patch has been applied to the master, release/2.4 and releas
Gert Doering writes:
> ACK, thanks.
>
> (While I'm not exactly happy with the mess we have in syshead.h, this
> is not your fault - you just happen to add the 6th identical chunk...)
>
> Applying this to all branches to fix the bug, putting "rework syshead.h
> for master, to clean up the zillion
ACK. The patch looks generally reasonable ("if there is no such cipher,
do not try to use it but print a clear message") though I have not been
able to verify actual *failure* - tried on FreeBSD 9.3, which' openssl
claims "no AES-256-CTR", but still, "PASS: tls_crypt_testdriver"
Since this is *te
Hi,
wading through my heap of mails that did not get proper attention...
On Fri, May 05, 2017 at 02:24:02PM -0400, selva.n...@gmail.com wrote:
> From: Selva Nair
>
> If static challenge is in use, the password passed to the plugin by openvpn
> is of the form "SCRV1:base64-pass:base64-response".
On Mon, Jun 12, 2017 at 2:14 PM, Gert Doering wrote:
> Hi,
>
> wading through my heap of mails that did not get proper attention...
>
> On Fri, May 05, 2017 at 02:24:02PM -0400, selva.n...@gmail.com wrote:
> > From: Selva Nair
> >
> > If static challenge is in use, the password passed to the plu
On 12/06/17 20:14, Gert Doering wrote:
>
> What is the status of this one? Does it need updating after 1/2 got
> changed to v2 and v3 are these independent enough that 2/2 is standalone?
>
> From a cursory glance, it calls secure_memzero() which is now, I think,
> plugin_secure_memzero() - right
On Wed, Jun 7, 2017 at 12:41 PM, debbie10t wrote:
> Hi,
>
> I have a basic setup and discovered that my W10 client was assigning a
> second IPv6 address to TAP even though it is *not* being pushed by the
> server. The second address is an old address from a server that I
> sometimes connect to.
ACK "because it makes sense" - tested, works.
Your patch has been applied to the release/2.2 branch.
commit 9162db3d2850f2edf2db5bc3a47220d899370c9d
Author: Steffan Karger
Date: Thu May 11 23:13:39 2017 +0200
Update sample-keys
Signed-off-by: Steffan Karger
Acked-by: Gert Doer
19 matches
Mail list logo
