> That looks like the library is conditionally exporting different symbols
> depending on the build configuration
No more than any other compile-time control.
___
openssl-dev mailing list
To unsubscribe:
A simpler interpretation would be that application data should never be sent or
received with sequence number = 0; only finished messages may have this
sequence number.
For connections with NPN enabled, we may need a slightly more complex rule.
In TLS we can also assume that encrypted fragments
A simpler interpretation would be that application data should never be sent or
received with sequence number = 0; only finished messages may have this
sequence number.
For connections with NPN enabled, we may need a slightly more complex rule.
In TLS we can also assume that encrypted fragments
On 09/30/2015 12:53 PM, Salz, Rich wrote:
> No, it's this
> #ifdef OPENSSL_NO_STDIO
> #define BIO_new_file(f,m) NULL
> #endif
>
That looks like the library is conditionally exporting different symbols
depending on the build configuration, which I considered doing for my
work on
On Wed, 2015-09-30 at 17:45 +, Kaduk, Ben via RT wrote:
> Making things inline functions or macros requires exposing their
> implementation details to consumers of the header in question. That
> seems at odds with the goal of making structures opaque, though I don't
> know whether making BIO
No, it's this
#ifdef OPENSSL_NO_STDIO
#define BIO_new_file(f,m) NULL
#endif
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Wed, 2015-09-30 at 17:45 +, Kaduk, Ben via RT wrote:
> Making things inline functions or macros requires exposing their
> implementation details to consumers of the header in question. That
> seems at odds with the goal of making structures opaque, though I don't
> know whether making BIO
On 09/30/2015 12:59 PM, Salz, Rich wrote:
>> That looks like the library is conditionally exporting different symbols
>> depending on the build configuration
> No more than any other compile-time control.
>
Okay, I guess you have convinced me, in that the ship has already sailed.
-Ben
On Wed, 2015-09-30 at 02:01 +, Rich Salz via RT wrote:
> We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file
> return an alternate implementation that returns run-time failures. Almost all
> of the OpenSSL code uses the BIO object, so we didn't have to remove that.
As for running tests in the context of query, i.e. mingw
cross-compilation on Linux. It actually was possible to
perform under 'wine' before and surely can be fixed now. Is
'wine' an option in this case?
>>>
>>> I don't know if it actually works, but we can configure Travis
To question about OPENSSL_stderr() that was removed with "not used"
rationale. When it comes to a *library* you always run risk of finding
something that it not used by the library itself, something that is
meant to be used exclusively by somebody else's application. And
OPENSSL_stderr() is such
Matt Caswell wrote:
> On 28/09/15 12:35, Albe Laurenz via RT wrote:
>> Matt Caswell wrote:
>>> However, I have some concerns with the wording of the RFC. It seems to
>>> place no limits whatsoever on when it is valid to receive app data in
>>> the handshake. By the wording in the RFC it would be
Matt Caswell wrote:
> On 28/09/15 12:35, Albe Laurenz via RT wrote:
>> Matt Caswell wrote:
>>> However, I have some concerns with the wording of the RFC. It seems to
>>> place no limits whatsoever on when it is valid to receive app data in
>>> the handshake. By the wording in the RFC it would be
See http://www.infradead.org/rpr.html
> To question about OPENSSL_stderr() that was removed with "not used"
> rationale. When it comes to a *library* you always run risk of finding
> something that it not used by the library itself, something that is
> meant to be used exclusively by somebody
See http://www.infradead.org/rpr.html
> To question about OPENSSL_stderr() that was removed with "not used"
> rationale. When it comes to a *library* you always run risk of finding
> something that it not used by the library itself, something that is
> meant to be used exclusively by somebody
> See http://www.infradead.org/rpr.html
Must be poor timing. First DNS took forever, then I get unable to
connect, connection time-outs...
>> To question about OPENSSL_stderr() that was removed with "not used"
>> rationale. When it comes to a *library* you always run risk of finding
>> something
On Wed, Sep 30, 2015 at 02:01:54am +, Rich Salz via RT wrote:
> We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file
> return an alternate implementation that returns run-time failures. Almost all
> of the OpenSSL code uses the BIO object, so we didn't have to remove
Is your process terminated or still alive after printing the last trace
message?
" Going to call SSL_connect() 15"
If it is terminated already, is there any core dump file generated? If it is
still alive, pstack command could help you to see what is happening.
I don't see turning on debug
Is your process terminated or still alive after printing the last trace
message?
" Going to call SSL_connect() 15"
If it is terminated already, is there any core dump file generated? If it is
still alive, pstack command could help you to see what is happening.
I don't see turning on debug
On 09/30/2015 10:12 AM, Salz, Rich via RT wrote:
>> If things like BIO_new_file() were inline, or macros, then the compiler could
>> *see* that they'd return NULL. And lots of code in the *calling* functions
>> (basically everything but the error path) could be elided from the compiled
>>
On 30/09/15 10:22, Alessandro Ghedini via RT wrote:
> On Wed, Sep 30, 2015 at 02:01:54am +, Rich Salz via RT wrote:
>> We fixed this in a slightly different way. We made BIO_new_file and
>> BIO_s_file
>> return an alternate implementation that returns run-time failures. Almost all
>> of the
Hello,
I am using memory-based bio to handle dtls sessions. Crash happened after close
notify received and SSL was cleaned up ? OpenSSL version is 1.0.2d. If more
detailed information required, pls. let me known.
Thanks,
2015-09-29 22:59:32.968954 [ DEBUG ] [ StunTransManager.cpp ] [ 95 ]
> OPENSSL_stderr() is such thing. Well, for a Unix person it's really
> meaningless
> function, but it was introduced to solve small but irritating problem in FIPS
> module context on Windows.
I removed it :)
Since 1.1 doesn't support FIPS, that's okay. But we'll have something like
that for
On Wed, 2015-09-30 at 11:19 +, Andy Polyakov via RT wrote:
> > See http://www.infradead.org/rpr.html
>
> Must be poor timing. First DNS took forever, then I get unable to
> connect, connection time-outs...
Apologies. I'm travelling and in trying to avoid the mess of top-posted
HTML that
> OPENSSL_stderr() is such thing. Well, for a Unix person it's really
> meaningless
> function, but it was introduced to solve small but irritating problem in FIPS
> module context on Windows.
I removed it :)
Since 1.1 doesn't support FIPS, that's okay. But we'll have something like
that for
> If you want to keep it can we make it return a BIO? Many platforms could use
> it then for serial debug output etc.
That's what I'm going to do.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> If you want to keep it can we make it return a BIO? Many platforms could use
> it then for serial debug output etc.
That's what I'm going to do.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 30/09/15 16:06, Haiyang Yin via RT wrote:
> Hello, I am using memory-based bio to handle dtls sessions. Crash
> happened after close notify received and SSL was cleaned up ? OpenSSL
> version is 1.0.2d. If more detailed information required, pls. let me
> known.
Your gdb output is impossible
> If things like BIO_new_file() were inline, or macros, then the compiler could
> *see* that they'd return NULL. And lots of code in the *calling* functions
> (basically everything but the error path) could be elided from the compiled
> result...
Cool, will do that.
> If things like BIO_new_file() were inline, or macros, then the compiler could
> *see* that they'd return NULL. And lots of code in the *calling* functions
> (basically everything but the error path) could be elided from the compiled
> result...
Cool, will do that.
On 30/09/15 16:06, Haiyang Yin via RT wrote:
> Hello, I am using memory-based bio to handle dtls sessions. Crash
> happened after close notify received and SSL was cleaned up ? OpenSSL
> version is 1.0.2d. If more detailed information required, pls. let me
> known.
Your gdb output is impossible
On Wednesday 30 September 2015 09:37:37 Albe Laurenz wrote:
> Matt Caswell wrote:
> > On 28/09/15 12:35, Albe Laurenz via RT wrote:
> >> Matt Caswell wrote:
> >>> However, I have some concerns with the wording of the RFC. It
> >>> seems to place no limits whatsoever on when it is valid to
> >>>
32 matches
Mail list logo
