[ This question belongs on openssl-users, not openssl-dev. Please
reply only to openssl-users. ]
On Tue, Apr 26, 2016 at 05:17:46AM +0200, Alex Hultman wrote:
> SSL_write followed by SSL_shutdown does not actually send the data passed
> to SSL_write if the total data size sent is less than
Hi Benjamin,
Thanks for the answer. I actually found a working solution just a couple of
minutes after I posted but I still wanted to hear what you recommended. I
just did ssl->references++; and also the same on the attached BIO's before
SSL_set_fd. This works perfectly and I'm able to take over
Hi,
I've found a very central bug that affects all my OpenSSL applications
including the official server example code, the vanilla Node.js HTTPs
server and my (arguably non-correct) own server project.
https://github.com/openssl/openssl/issues/992
SSL_write followed by SSL_shutdown does not
Praveen Kariyanahalli via RT wrote:
> Is there is a reason why openssl has restriction of auth before encrypt
> order ? I dont believe there is an algo restriction, was wondering why
> openssl has this.
>
It *is* inherent in the algorithm. The authentication tag for the AAD is
Why do you want GCM then?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4521
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Is there is a reason why openssl has restriction of auth before encrypt
order ? I dont believe there is an algo restriction, was wondering why
openssl has this.
*int CRYPTO_gcm128_aad(GCM128_CONTEXT *ctx, const unsigned char *aad,*
* size_t len)*
*{*
*[snip]*
*if
So, listening to what everyone had to say, perhaps this PR is better
then:
https://github.com/openssl/openssl/pull/995
In message
on Mon,
25 Apr 2016 17:45:05 +, "Salz, Rich" said:
rsalz>
rsalz> >
The change
https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed
introduced a typo in the last line of file crypto/camellia/build.info.
The fix is:
--- crypto/camellia/build.info2016-03-16 19:18:09.0 +0100
+++ crypto/camellia/build.info2016-04-19
On Mon, Apr 25, 2016 at 05:45:05PM +, Salz, Rich wrote:
> After a "set0" call, set your pointer to NULL, it's no longer yours :)
That half of the ruleset. The other half is:
You must "own" any object passed to a set0 call that takes
ownership of its argument (we have a few that don't
> The 3-slot function is I think cleaner.
>
> I'll leave the decision of whether and when to support NULL parameters to
> the folks working on that code, but it is pretty clear that one must not pass
> an
> object one does not "own", such as one returned from a "get0" function, to a
> function
> Yes, but this difference adds convenience, IMHO. My preference is this:
> RSA_set0_key(rsa, n, e, d); with any parameter (except for rsa :) potentially
> NULL.
This defeats a main point: partial construction is a bad thing.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4518
On Mon, Apr 25, 2016 at 07:21:56PM +0200, Richard Levitte wrote:
> openssl-users> Perhaps the documentation can be made more clear. If users
> really
> openssl-users> need an interface for modifying a subset of the components of
> an
> openssl-users> already initialized key, then (if we don't
>There isn't much difference between this:
>
>RSA_set0_key(rsa, n, NULL, NULL);
>RSA_set0_key(rsa, NULL, e, NULL);
>RSA_set0_key(rsa, NULL, NULL, d);
>
>and something like this:
>
>RSA_set0_n(rsa, n);
>RSA_set0_e(rsa, e);
>RSA_set0_d(rsa, d);
The attractiveness of
In message <20160425141410.gx26...@mournblade.imrryr.org> on Mon, 25 Apr 2016
14:14:10 +, Viktor Dukhovni said:
openssl-users> Perhaps the documentation can be made more clear. If users
really
openssl-users> need an interface for modifying a subset of the
On 04/23/2016 12:26 AM, Alex Hultman wrote:
> Hi,
>
> I'm having trouble "duping" an SSL connection. I have an SSL *pointer
> that is going to be SSL_free'd, so I need to clone it or up the ref
> count or somehow make it stay alive. I see that in OpenSSL 1.1.0 it
> seems you added the SSL_up_ref -
> Should I make similar in https://rt.openssl.org/ or it is enough to have in
> github.com?
We prefer bug reports in RT, not as issues. PR's on GitHub are fine.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Should I make similar in https://rt.openssl.org/ or it is enough to have in
> github.com?
We prefer bug reports in RT, not as issues. PR's on GitHub are fine.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4519
Please log in as guest with password guest if prompted
--
Hello.
We have made new bug report https://github.com/openssl/openssl/issues/993
Should I make similar in https://rt.openssl.org/ or it is enough to have in
github.com?
Jaan Murumets
Estonian ID-Software product manager
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4519
On Mon, Apr 25, 2016 at 02:08:09PM +, Richard Levitte via RT wrote:
> I'm not sure how I'd change the following:
>
> Calling this function transfers the memory management of the values to the
> RSA object, and therefore the values that have been passed in should not
> be freed by
On Mon, Apr 25, 2016 at 01:39:09PM +, Richard Levitte via RT wrote:
> rt> I agree it shouldn't happen, but do we want to protect against that? I
> could be convinced either way.
>
> Ah ok... sorry, I misread the intention.
>
> Agreed that we could make sure not to free the pointers in
In message on Mon, 25
Apr 2016 14:04:27 +, Tomas Mraz via RT said:
rt> On Po, 2016-04-25 at 13:39 +, Richard Levitte via RT wrote:
rt> > In message on
rt> >
On Po, 2016-04-25 at 13:39 +, Richard Levitte via RT wrote:
> In message on
> Mon, 25 Apr 2016 13:19:38 +, "Salz, Rich via RT"
> said:
>
> rt> No, he means setting the same value twice. For example, making
> this
On Po, 2016-04-25 at 13:39 +, Richard Levitte via RT wrote:
> In message on
> Mon, 25 Apr 2016 13:19:38 +, "Salz, Rich via RT"
> said:
>
> rt> No, he means setting the same value twice. For example, making
> this
I believe this PR fixes the issue for RSA, DSA and DH (they all share
the same concept).
https://github.com/openssl/openssl/pull/994
Cheers,
Richard
In message on Mon, 25 Apr
2016 13:39:09 +, Richard Levitte via RT
In message on Mon, 25
Apr 2016 13:19:38 +, "Salz, Rich via RT" said:
rt> No, he means setting the same value twice. For example, making this change:
rt> If (r=->n != n) BN_free(r->n);
rt> If(r->e != e)
Freeing of the values by the caller is not the issue.
The issue is RSA_set0_key requires n and e to be none NULL.
It the caller use RSA_get0_key to find the n and e then calculates a new d,
than calls RSA_set0_key with the the same n and e pointers and the new d.
RSA_set0_key will free n and e,
Freeing of the values by the caller is not the issue.
The issue is RSA_set0_key requires n and e to be none NULL.
It the caller use RSA_get0_key to find the n and e then calculates a new d,
than calls RSA_set0_key with the the same n and e pointers and the new d.
RSA_set0_key will free n and e,
On Po, 2016-04-25 at 13:08 +, Richard Levitte via RT wrote:
>
> rsalz> > If nothing else, all the RSA_set0 routines should test if
> the same pointer
> rsalz> > value is being replaced if so do not free it.
> rsalz> >
> rsalz> > The same logic need to be done for all the RSA_set0_*
>
On Po, 2016-04-25 at 13:08 +, Richard Levitte via RT wrote:
>
> rsalz> > If nothing else, all the RSA_set0 routines should test if
> the same pointer
> rsalz> > value is being replaced if so do not free it.
> rsalz> >
> rsalz> > The same logic need to be done for all the RSA_set0_*
>
No, he means setting the same value twice. For example, making this change:
If (r=->n != n) BN_free(r->n);
If(r->e != e) BN_free(r->e);
If (r->d != d) BN_free(r->d);
I agree it shouldn't happen, but do we want to protect against that? I could
be convinced either way.
--
Ticket
No, he means setting the same value twice. For example, making this change:
If (r=->n != n) BN_free(r->n);
If(r->e != e) BN_free(r->e);
If (r->d != d) BN_free(r->d);
I agree it shouldn't happen, but do we want to protect against that? I could
be convinced either way.
--
In message
<6b097acbe9d94724ac545f2529e45...@usma1ex-dag1mb1.msg.corp.akamai.com> on Mon,
25 Apr 2016 11:38:47 +, "Salz, Rich" said:
rsalz> > If nothing else, all the RSA_set0 routines should test if the same
pointer
rsalz> > value is being replaced if so do not free it.
> Would not a set of routines like:
> BIGNUM* RSA_get0_key_n(RSA *rsa);
> int RSA_set0_key_n(RSA *rsa, BIGNUM *n); (A set for: n, e, d, p, q, idmp1,
> idmq1, iqmp) be much more backward compatible?
We had discussed this in the team, and decided that it was better to have a
single API that took
> Would not a set of routines like:
> BIGNUM* RSA_get0_key_n(RSA *rsa);
> int RSA_set0_key_n(RSA *rsa, BIGNUM *n); (A set for: n, e, d, p, q, idmp1,
> idmq1, iqmp) be much more backward compatible?
We had discussed this in the team, and decided that it was better to have a
single API that took
34 matches
Mail list logo