The problem is just that EL6 provides a too old version of python-crypto to provide Crypto/Random.  It would be very helpful to have it though.  Perhaps it could be updated?

Please update to a version that provides Crypto/Random.

No longer needed, code re-written to not use python-crypto.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

OpenStack RDO requires a functional up-to-date python-crypto to operate on both RHEL6 and CentOS6.  Without this update, RDO will be nonfunctional on those platforms.

(In reply to Steven Dake from comment #6)
> OpenStack RDO requires a functional up-to-date python-crypto to operate on
> both RHEL6 and CentOS6.  Without this update, RDO will be nonfunctional on
> those platforms.

Could you please specify "up-to-date"? If we really need to do this, I'd like to know the minimal version you're asking for, so that I can evaluate the risks of regressions/incompatibilities introduced by rebase.

Changing needinfo to pbrady since he is the one with the most relevant data on which version is needed as he manages the RDO process.

upstream openstack says python-pycrypto >= 2.6

el7 currently has python-crypto-2.6.1-1 so it would be sensible to go with that I think

The problem with updating to 2.6.1 are backwards incompatibilities. Please note that we're talking about dozens of upstream commits. Most of these add new functionality, which is ok; but some of them are also removals and API changes. To document some of them:

- Changing method signatures (noLeftOvers argument removed from decode()) [1]
- Renamed classes (SHA renamed to SHA1, RIPEMD renamed to RIPEMD160) [2]
- Changes in return value types [3]

And numerous other changes, the list would be too long.

I'm afraid we can't afford this level of incompatibility inside one RHEL release. I'd suggest introducing new package (e.g. python-crypto2.6) or using a software collection for this. If no objections are raised, I'll close this as wontfix in a week or so.

[1] https://github.com/dlitz/pycrypto/commit/5a0ee14e9904335cb90c0dd7a4e10f1523435c52
[2] https://github.com/dlitz/pycrypto/commit/755375bb7d866a01e19153f5809772f4474eb94d
[3] https://github.com/dlitz/pycrypto/commit/ab25c6fe95ee92fac3187dcd90e0560ccacb084a

But all of those commits are only present in v2.7a1, right?

(In reply to Jeff Peeler from comment #11)
> But all of those commits are only present in v2.7a1, right?

No, all of these commits happened before 2.6.1 was released (the releasing commit of 2.6.1 is [1]).

[1] https://github.com/dlitz/pycrypto/commit/7fd528d03b5eae58eef6fd219af5d9ac9c83fa50

(In reply to Bohuslav "Slavek" Kabrda from comment #12)
> (In reply to Jeff Peeler from comment #11)
> > But all of those commits are only present in v2.7a1, right?
> 
> No, all of these commits happened before 2.6.1 was released (the releasing
> commit of 2.6.1 is [1]).
> 
> [1]
> https://github.com/dlitz/pycrypto/commit/
> 7fd528d03b5eae58eef6fd219af5d9ac9c83fa50

Those commits did happen before 2.6.1 was released, but commit dates do not dictate was is or isn't present in a tag. For example:

$ git log --format="%s%n%cd" 7fd528d03b5eae58eef6fd219af5d9ac9c83fa50 -1
Release v2.6.1
Mon Oct 14 14:37:38 2013 -0700

$ git log --format="%s%n%cd" 755375bb7d866a01e19153f5809772f4474eb94d -1
Hash: Rename SHA->SHA1 and RIPEMD->RIPEMD160 (1/2)
Sat Feb 16 16:20:23 2013 -0800

However, if you check the actual tag, you'll find the renaming isn't in the 2.6.1 release:

$ git tag --contains 755375bb7d866a01e19153f5809772f4474eb94d
v2.7a1

But the release commit obviously is.

git tag --contains 7fd528d03b5eae58eef6fd219af5d9ac9c83fa50
v2.6.1
v2.7a1

Hope that's helpful for future commit checking. Please do let me know if I'm confused about any of this.

I agree with Jeff wrt commit 755375bb at least.
One has to take branches into a/c so dates don't cut it.
Another way to check is to traverse the changes between
a tag and a commit, and if there are no commits returned,
then the change is included in the tag: I.E.:

  git log v2.6.1..755375bb

That returns many items and so that commit is not in 2.6.1

(In reply to Jeff Peeler from comment #13)
> Hope that's helpful for future commit checking. Please do let me know if I'm
> confused about any of this.

You're right, sorry for the confusion. So I checked the history of v2.6.1 (that comes from 2.6.x branch) and I still see some backwards incompatible commits (I hope I looked right this time, please correct me if not). Quick skimming through the commits between 2.0.1 and 2.6.1 gives me these examples of incompatibilities:

- Changes to public API [1]
- Removing algorithms [2]

So I still remain convinced that there are significant backwards incompatible changes. The greatest problem about this is, that we would have to go through *all* commits to see and fix backward incompatibilities - and I'm sure there are more than just these 2.

I'm afraid that it's just not feasible to do such a huge leap between versions inside a RHEL major release; we can't afford to break applications of people who already use the provided pycrypto.


[1] https://github.com/dlitz/pycrypto/commit/3bcc2b84c009ba5eaad0c08b0e4d220776d9a852
[2] https://github.com/dlitz/pycrypto/commit/cc990c02f3297342c6f059a8795b9790de0751f2

I don't this this needs to be SCLized (parallel installable).
We've already got an updated python-crypto in el6 RDO icehouse now,
and we should do the same for OSP5