OpenSSL.rand.bytes() to get a random bytes

I ported these changes to the tip of trunk, and
committed a new branch lp:~rick-fdd/pyopenssl/rand_bytes2
It has updates to test cases and documentation.

In the doc directory only pyOpenSSL.tex is original, and
the rest are derived from it, right? The committed
pyOpenSSL.txt is out of date even before my changes.
The HTML source gets a bunch of trivial changes from
my version of the derivation tools, so I'll let you do it.

What is our policy on referencing OpenSSL C function
names, so users can consult that documentation if
need be?

OpenSSL.rand.cleanup() was missing TEX documentation.

I added a test case for load_file() and write_file()
and status(). The test cases now use OpenSSL.test.util().

> In the doc directory only pyOpenSSL.tex is original, and the rest are derived from it, right? The committed pyOpenSSL.txt is out of date even before my changes. The HTML source gets a bunch of trivial changes from my version of the derivation tools, so I'll let you do it.

Right. I was rebuilding the docs for every trunk commit for a while, but I'm giving up on that. I plan to just do it before releases (and maybe get rid of all the generated files from the repository).

> What is our policy on referencing OpenSSL C function names, so users can consult that documentation if need be?

It's probably a good idea to do that.

Looking at the RAND_bytes man page, it looks like this function can fail. rand_bytes should probably be checking its return value and raising an OpenSSL Error of some sort if it does.

Yes. Agreed. Derived items should not be checked into a VCS.

--
Rick

On Tue, Jul 07, 2009 at 06:52:33PM -0000, Jean-Paul Calderone wrote:
> > In the doc directory only pyOpenSSL.tex is original, and the rest are
> derived from it, right? The committed pyOpenSSL.txt is out of date even
> before my changes. The HTML source gets a bunch of trivial changes from
> my version of the derivation tools, so I'll let you do it.
>
> Right. I was rebuilding the docs for every trunk commit for a while,
> but I'm giving up on that. I plan to just do it before releases (and
> maybe get rid of all the generated files from the repository).
>
> > What is our policy on referencing OpenSSL C function names, so users
> can consult that documentation if need be?
>
> It's probably a good idea to do that.
>
> --
> OpenSSL.rand.bytes() to get a random bytes
> https://bugs.launchpad.net/bugs/334570
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in pyOpenSSL: New
>
> Bug description:
> This patch implements OpenSSL.rand.bytes() so retreiving
> them doesn't require OpenSSL.rand.write_file(). The patch includes
> a test case, and supports named parameters. It applies to
> revision 95 of branch ext-context, and probably others. I release
> this code under v2 and later of the LGPL.
>
> To get a random unsigned long long integer use...
>
> from OpenSSL import rand
> import struct
> m = struct.unpack("Q", rand.bytes(8))

I added support for OpenSSL.rand.Error. I also silenced some
benign C compiler warnings. The changes have been pushed to
lp:~rick-fdd/pyopenssl/rand_bytes2

Unfortunately, I am unable to raise one of these errors, so my
testing is somewhat incomplete. They don't seem to happen
when the entropy pool is depleted, or when the pool is
unseeded. Fortunately, the exception code is very similar to
SSL and crypto.

It seems a little unfortunate that our base error for each is
simply named "Error". If someone does a
"from OpenSSL.rand import *" they might clobber another
in their local namespace, but I suppose they asked for it, and
it's a bad practice anyway. It's painfully too late to change
the name now.

In a separate patch, I would like to convert the three
exception_from_error_queue() macros to an single function.
It should be defined in util.c next to error_queue_to_list(), and
receive the exception object as an arg.

I pushed the de-macroization of exception_to_error_queue()
to lp:~rick-fdd/pyopenssl/rand_bytes2 revision 117.
Besides code maintainability, this makes our fast path
shorter for better cache performance.