Hello,
And, I'd like to point out one more time, we know of cases where a
blocking
read after a select will block. For example, if someone interposes OpenSSL
between select/read/write and the OS. Someone *can* do this and people *do*
do this.
I'd like to point out one more time, that
Title: SMIME subcommand
I am running OpenSSL 0.9.7d 17 Mar 2004 on SunOS 5.9 Generic_118558-14 sun4u sparc SUNW,Ultra-Enterprise.
The smime subcommand of openssl coredumps. Is there a known bug or is this supposed to work?
$ openssl smime -encrypt -in msgtext -to [EMAIL PROTECTED] \
Hello,
And, I'd like to point out one more time, we know of cases
where a blocking
read after a select will block. For example, if someone
interposes OpenSSL
between select/read/write and the OS. Someone *can* do this and
people *do*
do this.
I'd like to point out one more
Hello,
David,
Please post a link to a manpage or other documentation that
justifies your
description of select.
I posted a link to the SuSv2 description of 'select'. There is no
guarantee
there that a future operation will not block.
Hello,
David,
Please post a link to a manpage or other documentation that
justifies your
description of select.
I posted a link to the SuSv2 description of 'select'. There is no
guarantee
there that a future operation will not block.
David Schwartz wrote:
David you are bringing completely unrelated issues into the situation.
No, you are failing to understand my argument.
A Kernel does its job of arbitration like this on a shared/duped file
descriptor that both processes have as fd=4:
Thread/Process A
Marek Marcola wrote:
Your next argument will be:
if you do select() and space shuttle is flying ...
I am in complete agreement here.
The crux of the situation is that I'm (we're) saying its possible to
have working OpenSSL blocking mode that uses a blocking socket which
conforms the to
David Schwartz wrote:
David Schwartz wrote:
I hate to be rude, but do you understand *anything* about programming to
standards? The 'select' and 'read' functions are standardized, as is
blocking and non-blocking I/O. You have the guarantees specifically
enumerated in the standard and
Combined replies.
Maybe we should look on other papers, for example part of select(2)
man page from hpux 11.23:
Ttys and sockets are ready for reading or writing, respectively, if a
read() or write() would not block for one or more of the following
reasons:
+ input data is available.
Hello
This would be a valid argument if the standard didn't specifically
provide
us a way to get the exact guarantee you want. It's this simple:
1) You need a particular guarantee, specifically, that a 'read' won't
block.
2) The standard provides you a clear way to get
Hi All,First, before I get blasted for asking the some old question that has been asked at least 100 times this year,Yes, I read the FAQ, and the very large number of posts on this subject.PEM_write_PrivateKey AND /MD So everyone knows.Now then,I have successfully compiled and ran the
If we are talking about standards, maybe you should read new releases
of documents which you are citing as an authority. From 1997 to 2004
many things changed:
http://www.opengroup.org/onlinepubs/009695399/functions/select.html
Nothing that bears on this issue.
For short:
A
On Thu, 22 Jun 2006, David Schwartz wrote:
Bingo! And work may or may not translate into application data.
I thought that a recv on a blocking socket returns immediately after it
was able to do some work, no matter whether it resulted in receiving any
actual data (e.g. socket closed).
Hello,
For short:
A descriptor shall be considered ready for reading when a call to an
input function with O_NONBLOCK clear would not block, whether or not
the function would transfer data successfully.
(The function might return data, an end-of-file indication,
or an error other
Hi
This is my sugestion
for the developers ...
Why SSE2 are not
enabled atcompilationand at library init check if CPU support it
using CPUID ?
Best
Regards
Leandro Gustavo Biss Becker
Engenheiro Eletrônico / Electronic
Engineer
eSysTech -
Embedded Systems TechnologiesTravessa da
On Thu, 22 Jun 2006, David Schwartz wrote:
Bingo! And work may or may not translate into application data.
I thought that a recv on a blocking socket returns immediately after it
was able to do some work, no matter whether it resulted in receiving any
actual data (e.g. socket closed).
No, not they mean, you have no authority to tell what they mean.
You have only authority to tell what is your interpretation
of this text.
Only authors may tell what they mean (are you one of them ?)
What? I presented an argument to show that they must mean this. You
snipped
it.
Same thing, no guarantee about what an actual future operation will
do. By
would not block, they mean a hypothetical operation taking place at
the
time the indication is given to you.
No. That's stupid. It's useless. By 'would not block' they mean 'if
nobody else messes with the
Same thing, no guarantee about what an actual future operation will
do. By
would not block, they mean a hypothetical operation taking place at
the
time the indication is given to you.
No. That's stupid. It's useless.
Not at all. It's the same as every other status
Hello everybody !
David Schwartz wrote:
Since 'select' does not guarantee that a subsequent read operation won't
block (since it can't even know what operation that's going to be), the
subsequent read operation (which was 'SSL_read') blocked. That's because
SSL_read blocks for
On Thu, Jun 22, 2006 at 07:35:15AM -0700, David Schwartz wrote:
Since 'select' does not guarantee that a subsequent read operation won't
block (since it can't even know what operation that's going to be), the
subsequent read operation (which was 'SSL_read') blocked. That's because
Hello,
* A readability event can disappear (after it has been first indicated
by poll/select and no read() family of functions have been called,
recvmsg()/recv() etc...
* A writability event can disappear (after it has been first indicated
by poll/select and no write() family of functions
David Schwartz wrote:
On Thu, 22 Jun 2006, David Schwartz wrote:
Bingo! And work may or may not translate into application data.
I thought that a recv on a blocking socket returns immediately after it
was able to do some work, no matter whether it resulted in receiving any
actual
Alain Damiral wrote:
I'm wondering if it would not be highly appropriate to have an
'SSL_select' call defined by OpenSSL to have all operations on sockets
fully encapsulated and allow to reach the desired behaviour without
short-circuiting the layer approach... (it would provide similar
(combined responses)
No, of course no. In this context we are talking of kernel/system
implementation of select()/read() and you mix this with SSL.
Because it demonstrates precisely the problem. The 'select' function
has no
way to know what type of read function will follow, and
On Wednesday June 21st 2006 TIM TAYLOR wrote:
I am running OpenSSL 0.9.7d 17 Mar 2004 on SunOS 5.9 Generic_118558-14
sun4u sparc SUNW,Ultra-Enterprise.
The smime subcommand of openssl coredumps. Is there a known bug or is
this supposed to work?
$ openssl smime -encrypt -in msgtext -to
David Schwartz wrote:
I don't get it.
DS
Ah, finally something concrete.
Hey thats ok; sit back and relax. I'm sure a patch is on its way.
Darryl
__
OpenSSL Project
Darryl Miles wrote:
All you have to do inside OpenSSL is know if your underlying IO mode is
blocking or non-blocking and set a flag everytime to you enter a
high-level call from the application context.
Then _BEFORE_ you issue any low-level I/O you test to see it your
low-level IO is in
Hello,
No, of course no. In this context we are talking of kernel/system
implementation of select()/read() and you mix this with SSL.
Because it demonstrates precisely the problem. The 'select' function
has no
way to know what type of read function will follow, and there are
Greetings,
Folks, how do you access the manual pages for openssl?
I know that there
are man pages downloaded with the software
but I am unable to
find how to open and display them using
openssl.
Thanks in advance.
Bob Richardson
Allina Hospitals and Clinics
Minneapolis, MN
This
Hello,
Folks, how do you access the manual pages for openssl?
I know that there are man pages downloaded with the software
but I am unable to find how to open and display them using
openssl.
If you have installed OpenSSL (for example in /usr/local/openssl)
you may:
$ nroff
Darryl Miles wrote:
David Schwartz wrote:
I don't get it.
DS
Ah, finally something concrete.
Hey thats ok; sit back and relax. I'm sure a patch is on its way.
God I hope so.. I'm right in the middle of trying to get this
non-blocking stuff to work consistently (with a
(combined responses)
What is true for two stacked layers, maybe false for one.
(and the other way round).
No standard guarantees that you are only dealing with one layer. In
fact,
in the Windows world, multiple layers (hidden from the programmer) are
common thanks to LSPs. (And yes, a
On Thu, Jun 22, 2006 at 10:24:02AM -0700, David Schwartz wrote:
(combined responses)
What is true for two stacked layers, maybe false for one.
(and the other way round).
No standard guarantees that you are only dealing with one layer. In
fact,
in the Windows world, multiple
David Schwartz wrote:
God I hope so.. I'm right in the middle of trying to get this
non-blocking stuff to work consistently (with a timeline fast
approachingarg!) and I can't tell if it's something I am doing wrong
and what exactly that is. Too many variables to be easy.
If you
On 22/06/06, Marek Marcola [EMAIL PROTECTED] wrote:
If you have installed OpenSSL (for example in /usr/local/openssl)
you may:
$ nroff -man /usr/local/openssl/ssl/man/man1/rsa.1 | more
or:
$ export MANPATH=$MANPATH:/usr/local/openssl/ssl/man
$ man rsa
If you have
Hello
And for the great unwashed using Windows Marek :-)
Is it just the online versions?
On Unix pod2man.pl script is used.
I think that pod2chm from CPAN perl module may help :-)
Best regards,
--
Marek Marcola [EMAIL PROTECTED]
I would like to give OpenSSL the first part of the initial SSL connect
negotiation.
This is because my application has already read it from the socket
(which was in plain text), but then I'm happy for OpenSSL to use the
socket directly after that.
Would creating a temporary BIO containing
Hello,
This is because my application has already read it from the socket
(which was in plain text), but then I'm happy for OpenSSL to use the
socket directly after that.
Would creating a temporary BIO containing the over read data work, allow
OpenSSL to read it in. Then once empty
SSL_peek() there isn't much documentation about this one.
My situation is this:
* I'm using full non-blocking IO.
* My application's main task in the moment is sending bulk data, a lot
of data (enough to cause flow control bottleneck).
* My application is not interested in reading any
Wow. I guess I should play the lottery.
Thanks for the info. I will upgrade to the FIPS level.
regards,
TT
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marco Roeland
Sent: Thursday, June 22, 2006 11:34 AM
To: openssl-users@openssl.org
Subject: Re:
SSL_CTX_set_mode(3)
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
Make it possible to retry SSL_write() with changed buffer
location (the buffer contents must stay the same). This is not the
default to avoid the mis-
conception that non-blocking SSL_write() behaves like
My program is being told by the operating system I can write(), the
operating system socket send buffers are empty, but OpenSSL is returning
WANT_READ to SSL_write(), so I need to stop calling SSL_write() and wait
for data to arrive. This means temporally ignoring the operating
systems
Comments below
David Schwartz wrote:
My program is being told by the operating system I can write(), the
operating system socket send buffers are empty, but OpenSSL is returning
WANT_READ to SSL_write(), so I need to stop calling SSL_write() and wait
for data to arrive. This
Our application consists of multiple Unix processes each of
which creates its own OpenSSL instance. Does it violate the Security Policy if some
of those processes set OpenSSL into FIPS mode while others do not? In other
words, does the existence of non-FIPS mode toolkit instances
David Schwartz wrote:
My program is being told by the operating system I can write(), the
operating system socket send buffers are empty, but OpenSSL is returning
WANT_READ to SSL_write(), so I need to stop calling SSL_write() and wait
for data to arrive. This means temporally ignoring
All cryptography used by the US Federal Government must be done in
compliance with FIPS 140-2. (Other entities may choose to require
FIPS compliance for their cryptographic functions as well.) Thus, if
you are selling to an entity that requires FIPS, all OpenSSL (and
other encryption) libraries
Darryl Miles wrote:
SSL_CTX_set_mode(3)
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
Make it possible to retry SSL_write() with changed buffer
location (the buffer contents must stay the same). This is not the
default to avoid the mis-
conception that non-blocking SSL_write()
Yes, what I meant by My application's main task in the moment is
sending bulk data, a lot of data (enough to cause flow control
bottleneck). meant exactly what you are asking. A previous SSL_write()
returns WANT_WRITE, which I presume is because the OpenSSL BIO_s_socket
did a write() which
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is likely for those OSes (*glares
at Windows in particular*) which require locking allocated memory in
place, performing an operation on it, and then unlocking it (to allow
the OS to manage the placement of the memory block in physical
memory).
It's not the
On 6/22/06, David Schwartz [EMAIL PROTECTED] wrote:
I would like OpenSSL to be an efficient approach and elegant solution
but the more I look the less happy I'm becoming.
I find bio pairs elegant, but your point is well taken.
DS
BIO pairs are very nice if you use them
Mikhail Kruk wrote:
I'm probably missing something, but what's wrong with select()'ing for
read when your SSL_write returns WANT_READ?
See relatively elegant read_write() implementation from
http://www.rtfm.com/openssl-examples/
Nothing, but how do I know when I can start my SSL_write()
David Schwartz wrote:
Having thought about the issue some more, what scenarios can cause a
WANT_READ for SSL_write() call ?
If the SSL protocol requires the server to get some information before
it
can send any information. For example, if it's still doing the original
negotiation,
I'm probably missing something, but what's wrong with select()'ing for
read when your SSL_write returns WANT_READ?
See relatively elegant read_write() implementation from
http://www.rtfm.com/openssl-examples/
Nothing, but how do I know when I can start my SSL_write() again,
Mikhail Kruk wrote:
After every SSL_peek()/SSL_read() do I try to issue a new SSL_write()
and if there is movement I consider it cleared ?
You don't need SSL_peak/SSL_read. SSL_write will do the reading that it
wants to do.
Hmm.. I believe that any of SSL_peek()/SSL_read() or SSL_write()
Nothing, but how do I know when I can start my SSL_write() again,
because the WANT_READ condition that is stopping SSL_write() from taking
any more data has cleared ?
I recommend a very conservative approach. Any time you make any forward
progress or might have made any forward
56 matches
Mail list logo
