Bug 890589 - Review Request: csprng - Entropy source using the cryptographically secure pseudo-random number generator
Summary: Review Request: csprng - Entropy source using the cryptographically secure ps...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-12-28 01:21 UTC by Jiri Hladky
Modified: 2021-05-30 17:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2021-05-22 13:10:46 UTC
Type: ---

Attachments (Terms of Use)

Description Jiri Hladky 2012-12-28 01:21:56 UTC
Spec URL: http://jhladky.fedorapeople.org/csprng.spec
SRPM URL: http://jhladky.fedorapeople.org/csprng-1.1.1-0.fc16.src.rpm
The csprng project provides cryptographically secure pseudo-random number
generator. It consists of

* C library
* csprng-generate utility to generate stream of random numbers written to file
or to STDOUT
* Linux daemon csprngd to fill entropy of Linux kernel random device /dev/random 

It combines these three components to provide a high quality cascade random
number generator:

* HAVEGE hardware random number generator. HAVEGE combines on-the-fly hardware
volatile entropy gathering with pseudo-random number generation. The internal
state of HAVEGE includes thousands of internal volatile hardware states of the
CPU and is merely unmonitorable. The CPU intern states include caches, branch
predictors, TLBs, long pipelines, instruction level parallelism, ... The state
of these components is not architectural (i.e. the result of an ordinary
application does not depend on it), it is also volatile and cannot be directly
monitored by the user. Every invocation of the operating system modifies
thousands of these binary volatile states.

* Cryptographically secure pseudo-random number generator (CSPRNGD): block
cipher AES-128 working in the counter mode based Deterministic Random Bit
Generator as defined by NIST SP800-90 document

* Run-time random number statistical testing and verification as defined
by FIPS PUB 140-2
  * Monobit test
  * Poker test
  * Runs test
  * Long run test
  * Continuous run test

Fedora Account System Username:jhladky

Comment 1 Eduardo Echeverria 2012-12-28 06:22:29 UTC
Hi Jiri, 
Initial comments:
- please document the need for automake in BR
- please document the need for GDB in BR
- BuildRequires and Requires entries can be listed one-by-one, is easier to read for reviewers 
- coreutils not needed in BR. see http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2
- not think there is the need to call to: 
/sbin/ldconfig openssl in Requires(post)
/sbin/ldconfig in Requires(postun)
- the code is using hardcode specific library paths when linking binaries /usr/sbin/csprngd ['/usr/lib64']
see http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
see http://fedoraproject.org/wiki/Packaging:Guidelines#Removing_Rpath

- Don't use the macros:
such macros are deprecated and shouldn't be used anymore, see
- Please be consistent in the use of the macros $RPM_BUILD_ROOT or %{buildroot}, choose one of two
- Specify if you want to ship your package to EPEL5 , otherwise please remove
* BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) see https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#BuildRoot_tag
* rm -rf %{buildroot} after %install
* The section %clean see http://fedoraproject.org/wiki/Packaging:Guidelines#.25clean
* and the %defattr(-, root, root, -) in %files see http://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions

the output of licensecheck is:

GPL (v3.1)

GPL (v3 or later)

Unknown or generated

MIT/X11 (BSD like)

ISC GPL (v3 or later)

In my experience, when there are many licenses involved in the upstream source files and these licenses do not apply to your own source, is clear indication that may contain bundled libs or bundled files

See https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Since you are the developer of upstream, tell me if this is so

in case the header or source file is in Fedora patch the Makefile to build against them, otherwise build the devel package containing these files.

fixed these points, I'll do the formal review

Best Regards

Comment 2 Jiri Hladky 2013-01-04 23:08:36 UTC
Hi Eduardo,

thanks for the hints. I have fixed all the issues with the SPEC file. Please note that I do plan to provide the package for the EPEL5 and EPEL6 so I have to keep certain sections in the SPEC file.

The only point I do not follow is the issue with the rpath. I do have following in my ~/.rpmmacros

$more ~/.rpmmacros 
%__arch_install_post            \
/usr/lib/rpm/check-rpaths     \

and not rpath problem was reported. Do you see rpath issue on any of the provided executable files?

Regarding the bundled libraries - the project is not using any bundled libraries. There are however parts of the other GNU projects reused.

1) One part is project haveged. http://www.issihosts.com/haveged/ The project haveged implements HAVEGE RNG but it does not provide any developement libraries. I have taken parts of the project and modified so it can be used as the standalone library. I'm now working with the haveged upstream to merge my changes and provide haveged-devel package. The maintainer of the haveged project has commited to do the merge but it will take some time.

2) The other part is the implementation of the CTR DRBG algorithm. I took the basic example implementation from the year 2007 from Henric Jungheim as the basis and added prediction resitance. POLARSSL provides now the similar functionality starting from F18. However, recent versions of POLARSSL do not compile on the EPEL5 and EPEL6. 

I would therefore suggest to release the current package tp provide the fnctionality for EPEL and older versions of the Fedora. I do plan to update the package to use polarssl in the newer releases.

Spec URL: http://jhladky.fedorapeople.org/csprng.spec
SRPM URL: http://jhladky.fedorapeople.org/csprng-1.1.3-0.fc16.src.rpm

Tested on Koji:

Comment 3 Eduardo Echeverria 2013-01-05 05:49:14 UTC
(In reply to comment #2)

> The only point I do not follow is the issue with the rpath. I do have
> following in my ~/.rpmmacros
> $more ~/.rpmmacros 
> %__arch_install_post            \
> /usr/lib/rpm/check-rpaths     \
> /usr/lib/rpm/check-buildroot
> and not rpath problem was reported. Do you see rpath issue on any of the
> provided executable files?

Hi Jiri:
- Try rebuilding the package:
rpmbuild --rebuild csprng-1.1.3-0.fc16.src.rpm

Give an error output about RPATH

*    0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
*               issue but are introducing redundant searchpaths without
*               providing a benefit. They can also cause errors in multilib
*               environments.

ERROR   0001: file '/usr/bin/csprng-generate' contains a standard rpath '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/sbin/csprngd' contains a standard rpath '/usr/lib64' in [/usr/lib64]

you can also check the output rpmlint:

rpmlint -v csprng-1.1.3-0.fc17.x86_64.rpm 
csprng.x86_64: I: checking
csprng.x86_64: W: spelling-error Summary(en_US) cryptographically -> photographically, typographically, topographically
csprng.x86_64: W: spelling-error %description -l en_US cryptographically -> photographically, typographically, topographically
csprng.x86_64: W: spelling-error %description -l en_US dev -> deb, derv, div
csprng.x86_64: W: spelling-error %description -l en_US unmonitorable -> unmemorable
csprng.x86_64: I: checking-url http://code.google.com/p/csrng/ (timeout 10 seconds)
csprng.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/csprng-generate ['/usr/lib64']
csprng.x86_64: E: binary-or-shlib-defines-rpath /usr/sbin/csprngd ['/usr/lib64']
1 packages and 0 specfiles checked; 2 errors, 4 warnings.

- Usually, subpackages other than devel should require the base package
using a fully versioned dependency.
Please use 
Requires: %{name}%{?_isa} = %{version}-%{release} 
in the devel package

- In the devel package there a issue with unowned directories

should be

Please see: https://fedoraproject.org/wiki/Packaging:UnownedDirectories

Comment 4 Eduardo Echeverria 2013-01-10 03:05:26 UTC
One detail that I forget:
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

instead of


Comment 5 Package Review 2020-07-10 00:47:49 UTC
This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time, but it seems
that the review is still being working out by you. If this is right, please
respond to this comment clearing the NEEDINFO flag and try to reach out the
submitter to proceed with the review.

If you're not interested in reviewing this ticket anymore, please clear the
fedora-review flag and reset the assignee, so that a new reviewer can take
this ticket.

Without any reply, this request will shortly be resetted.

Comment 6 Package Review 2020-11-13 00:45:38 UTC
This is an automatic action taken by review-stats script.

The ticket reviewer failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we reset the status and the assignee of this ticket.

Comment 7 Otto Urpelainen 2021-05-22 07:33:21 UTC
This review request is really old. If you still want to include this package in Fedora, please clear the needinfo tag and explain how you intend to continue. I can review. Otherwise, just leave the tag in place and this request should be automatically closed in a month.

Comment 8 Jiri Hladky 2021-05-22 13:10:46 UTC
H Otto,

thanks for the reminder. I don't plan to include the package in Fedora anymore. Let me close the ticket. 


Note You need to log in before you can comment on or make changes to this bug.