Marek Marcola wrote:
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,
Another option may be using http://www.openssl.org/docs/crypto/,
h
> 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 prog
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() a
> > 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,
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, it
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() aga
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 e
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 def
> 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()
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() behav
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 m
> 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 temporall
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 invalidate
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 means
> 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
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
non-blocking
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: S
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 more
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 empt
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
> 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]>
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 untar
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 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, mul
(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,
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 timeli
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:
$ nro
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
Minneap
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
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 block
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 http://ww
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
(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 the
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
behav
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 da
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 f
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
> SS
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 *applica
> >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 s
>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 d
> 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
snippe
> 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 clo
Hi
This is my sugestion
for the developers ...
Why SSE2 are not
enabled at compilation and at library init check if CPU support it
using CPUID ?
Best
Regards
Leandro Gustavo Biss Becker
Engenheiro Eletrônico / Electronic
Engineer
eSysTech -
Embedded Systems TechnologiesTraves
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 er
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).
> 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
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 th
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
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 avai
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 can
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 h
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
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.
> http://www.opengroup.org/online
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.
> http://www.opengroup.org/online
> 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
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] \
-fro
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, th
57 matches
Mail list logo
