Forum OpenACS Improvement Proposals (TIPs): TIP #33 (Approved): deprecate the PayflowPro package

As you can read in this thread: , the latest version of the Verisign SDK is statically linked with an older version of OpenSSL and causes our module to periodically crash AOLserver. Since Verisign has indicated that they don't intend to fix the problem, this situation is not likely to change.

Having the module to support PayflowPro in the toolkit is going to encourage people to use it, and it seems likely that most of them are going to have problems. Therefore, I am proposing that we deprecate the payflowpro package. It should probably be moved to contrib, rather than removing it entirely, so that anyone who wishes to try using it can do so.

One thing that just occurred to me is that I don't actually know if the linking issue is specific to Linux or not. IOW the module *might* function correctly on Solaris, FreeBSD, etc. Since most OpenACS installations are on Linux I think this is still a valid proposal; those who really want to use the module can retrieve it from contrib.

Approve the moving to contrib. Please write a note within that package, describing the risks and problems that have been faced so far along with a link to the Forum discussion and this TIP).
Posted by Don Baccus on
Your TIP should probably point out that we fully support so folks know we still have a viable payment charging solution, no?

It would be awfully nice if someone could verify whether or not this is a problem for FreeBSD, Solaris etc so anyone picking it up from contrib knows what the scoop is.  I guess for now just documenting it along with a request to post any additional information if someone decides to pursue the issue would be just fine.

Posted by C. R. Oldham on

Another reason to deprecate this is that is statically linked against an *old* version of OpenSSL (0.9.5-something).  Since Verisign is loathe to provide an updated version, you may be opening your site to an attack of some sort if bugs in that version of OpenSSL can be exploited somehow via

Granted, the attack surface is pretty small, but you never know.

Posted by Jeff Davis on
I approve of this as well (if only because verisign
is the devil).
Posted by Janine Ohmer on
I will wait the full week on this, but it looks like it will be approved.  I will add the requested documentation.

Did we ever decide the proper way to move a package, and if so, can someone please summarize and/or point me to the thread?  I can't find it.  If not, we need to decide it now.  Back when I was last in charge of a CVS tree it was always done by moving files within the repository, but I know that caused an uproar last time someone did it.  So what's the currently acceptable right way?

What do we want the difference between a package in "contrib" versus "deprecated"?

I would propose "deprecated" for packages we do not want people to use because there is a better package.

Then "Contrib" would be for unmaintained packages with no guarantee of them working or quality.

If we used these definitions then PayFlowPro should move to contrib I think.

Actually looking at CVS ( there is not "depricated" area.  There seems to be contrib/packages and contrib/obsolete-packages. I approve a move to contrib/packages if that is what Janine intended.
Janine, the "uproar" was only because it was done wrong.
Posted by Janine Ohmer on
Ok, what I got from following the link Andrew posted is that what I should do is 'cvs add' the files into contrib/packages and 'cvs rm' them from packages.  Is oacs-5-0 still the right tag to check out on to set up for doing this?  I'm pretty sure it is but I don't want to do this in the wrong place!

I'm assuming this change will make it into HEAD automagically when the branch is merged back in.  Somebody please speak up if I need to do it in both places.

Posted by Janine Ohmer on
Ok, this is done on the oacs-5-0 branch - I won't do anything to HEAD unless asked.
Janine, well, you probably realized this, but while "moving" files in CVS by doing just a simple cvs add and cvs remove is indeed adequate, I don't think it's optimal, and it's certainly not what I recommended in that other thread.