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

Collapse
1: TIP #33 (Approved): deprecate the PayflowPro package
Posted by Janine Ohmer on 12/01/03 04:06 PM
As you can read in this thread: https://openacs.org/forums/message-view?message_id=93102 , 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.

Collapse
3: Re: TIP #33 (Proposed): deprecate the PayflowPro package (approved by Malte) (response to 1)
Posted by Malte Sussdorff on 12/01/03 04:36 PM
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).
Collapse
4: Re: TIP #33 APPROVED: deprecate the PayflowPro package (response to 1)
Posted by Don Baccus on 12/01/03 04:55 PM
Your TIP should probably point out that we fully support authorize.net 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.

Collapse
2: Re: TIP #33 (Proposed): deprecate the PayflowPro package (response to 1)
Posted by C. R. Oldham on 12/01/03 06:39 PM
Greetings,

Another reason to deprecate this is that libpfpro.so 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 libpfpro.so.

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

Collapse
5: Re: TIP #33 (Proposed): deprecate the PayflowPro package (response to 2)
Posted by Jeff Davis on 12/04/03 03:02 PM
I approve of this as well (if only because verisign
is the devil).
Collapse
6: Re: TIP #33 (Proposed): deprecate the PayflowPro package (response to 1)
Posted by Janine Ohmer on 12/04/03 04:26 PM
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?

Collapse
7: Re: TIP #33 (Proposed): deprecate the PayflowPro package (response to 1)
Posted by Caroline Meeks on 12/04/03 07:24 PM
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.

Collapse
8: Re: TIP #33 (Proposed): deprecate the PayflowPro package (response to 1)
Posted by Caroline Meeks on 12/04/03 11:18 PM
Actually looking at CVS (http://cvs.openacs.org/cvs/openacs-4/contrib/) 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.
Collapse
9: Re: TIP #33 (Proposed): deprecate the PayflowPro package (response to 6)
Posted by Andrew Piskorski on 12/05/03 07:50 PM
Janine, the "uproar" was only because it was done wrong.
Collapse
10: Re: TIP #33 (Proposed): deprecate the PayflowPro package (response to 1)
Posted by Janine Ohmer on 12/22/03 03:37 PM
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.

Collapse
11: Re: TIP #33 (Approved): deprecate the PayflowPro package (response to 1)
Posted by Janine Ohmer on 12/23/03 05:05 PM
Ok, this is done on the oacs-5-0 branch - I won't do anything to HEAD unless asked.
Collapse
12: Re: TIP #33 (Proposed): deprecate the PayflowPro package (response to 10)
Posted by Andrew Piskorski on 12/31/03 12:38 AM
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.