Re: [PEAR-QA] BC Break mess with Auth/Auth_HTTP

Try and release a fixed version in the next few days, If it's not
possible, remove the release?

I assume it broke your code, or did it just reduce the security, not
quite clear from the email.

If it broke code: please release the code in 2-3 days otherwise pull the
release
If it just reduced security: please release the code in 1-2ws
otherwise pull the release

David - have you filed a bug?

Sound reasonable?

Regards
Alan

David Costa wrote:

> Rui,
> I spent the last 2 hours fixing the  Auth_HTTP installation at my
> employer server where we use it extensively for some professional
> applications.
> The combination
> Auth                  1.2.3   stable
> Auth_HTTP      2.1.1   beta
>
> Works fine as I did fixed the SessionSharing mess. Now, if you install
> Auth_HTTP 2.1.2 we have a BC break and the user is asked to upgrade to
> Auth 1.3.0r2.
>
> Now, this is serious.
>
> Auth_HTTP should have gone stable with 2.1.1. where I fixed the major
> SessionSharing issue.  Why? because now a user which has the default
> stable as preferred status (
> the great majority) will end up with the combination Auth 1.2.3 and
> Auth_HTTP 2.0.
>
> This combination expose the users of  Auth_HTTP 2.0 to  the major
> Session Sharing bug and possible a security problem.
>
> What's that ? if you have 2 protected areas on your site (separate
> areas with different
> realms, let' say an area called users and an area called
> administrators) a user who gained access to the first realm will be
> automatically logged on the second separate realm
> regardless of his credentials. In fact he will not even be prompted
> for a secondary log in.
>
> To summarize, I don't understand how you released Auth_HTTP 2.1.2
> requiring Auth 1.3.0r2. without
> a) dropping me a line, after all I am lead on this package ;
> b) breaking BC ( and obviously without testing. Every simple test will
> reveal that 2.1.2 and 1.3.0r2 don't work with a previous Auth_HTTP
> implementation).
>
> 2.1.1 should go stable and, even if 4 days elapsed, I would go to
> pull/remove 2.1.2.
>
> Suggestions from other QA members are very welcome,
> Regards
> David Costa
>

On Aug 19, 2004, at 3:42 AM, Alan Knowles wrote:

>
> Try and release a fixed version in the next few days, If it's not
> possible, remove the release?
>
> I assume it broke your code, or did it just reduce the security, not
> quite clear from the email.
>

sorry if it wasn't sufficiently clear.

Let me try again:

a) combination Auth  1.2.3   stable  with Auth_HTTP 2.1.1 beta  ==
works fine ( I fixed the bugs when we released 2.1.0 and 2.1.1 is still
fine)
b) combination Auth_HTTP 2.1.2 which requires  Auth >= 1.3.0r2.  breaks
the code.
Results:  blank pages after authentication etc. (I didn't spent a lot
of time on debugging because that's very time consuming and since I
wasn't asked before it was
released... but it doesn't work on existing code which works fine under
a )
c) the stable combination of both Auth and Auth_HTTP (Auth 1.2.3 stable
and Auth_HTTP 2.0) is working but has the security reduced to zero or
very close ;)

> If it broke code: please release the code in 2-3 days otherwise pull
> the release

I think pulling is the case. I am a lead in this package and is really
strange that I just learned about the new release by seeing existing
code dying all over!

Perhaps Rui probably tested the new release with a very simple scheme:
one page, one login. This is not how Auth_HTTP is used. Normally there
are different
protected areas  (realms) and extensive testing is required. True,
testing Auth_HTTP can be a pain (you have to close-re open the browser
at each attempt etc) but is the only way to go.

> If it just reduced security: please release the code in 1-2ws
> otherwise pull the release
>

I would be glad to fix the code again but we need to find an agreement
among leads. I fixed this package after extensive testings on 2.1.0.
Of course there is no need to
ask me to release a bug fixes release but if we change the dependency
versioning etc more tests are required to ensure BC compatibility.

Rui please remove 2.1.2. We need to bring 2.1.1. which works on a
stable level and not to change the API requiring a non stable version
of Auth...

> David - have you filed a bug?
>
I didn't because I think the best way to proceed is to pull the release
>
Cheers
David Costa

David,

I tried to remove Auth_HTTP 2.1.2 from [url]http://pear.php.net/package-edit.php?id=1,[
/url]
but it caused an error shown belows, and it failed.

Fatal error: Call to undefined function: isqa() in
/usr/local/www/pearweb/include/pear-database.php on line 1787

Someone can try to fix the problem or remove the release ?

I have plan to release the stable Auth_HTTP 2.1.3 having compatibility
with Auth 1.2.3, and release the new beta Auth_HTTP 2.2.0 for Auth 1.3.0
later.
Is it ok for you ?

Rui

On Thu, 19 Aug 2004 12:03:46 +0200
David Costa <gurug@php.net> wrote:

>
> On Aug 19, 2004, at 3:42 AM, Alan Knowles wrote:
> 
>
> sorry if it wasn't sufficiently clear.
>
> Let me try again:
>
> a) combination Auth  1.2.3   stable  with Auth_HTTP 2.1.1 beta  ==
> works fine ( I fixed the bugs when we released 2.1.0 and 2.1.1 is still
> fine)
> b) combination Auth_HTTP 2.1.2 which requires  Auth >= 1.3.0r2.  breaks
> the code.
> Results:  blank pages after authentication etc. (I didn't spent a lot
> of time on debugging because that's very time consuming and since I
> wasn't asked before it was
> released... but it doesn't work on existing code which works fine under
> a )
> c) the stable combination of both Auth and Auth_HTTP (Auth 1.2.3 stable
> and Auth_HTTP 2.0) is working but has the security reduced to zero or
> very close ;)
> 
>
> I think pulling is the case. I am a lead in this package and is really
> strange that I just learned about the new release by seeing existing
> code dying all over!
>
> Perhaps Rui probably tested the new release with a very simple scheme:
> one page, one login. This is not how Auth_HTTP is used. Normally there
> are different
> protected areas  (realms) and extensive testing is required. True,
> testing Auth_HTTP can be a pain (you have to close-re open the browser
> at each attempt etc) but is the only way to go.
> 
>
> I would be glad to fix the code again but we need to find an agreement
> among leads. I fixed this package after extensive testings on 2.1.0.
> Of course there is no need to
> ask me to release a bug fixes release but if we change the dependency
> versioning etc more tests are required to ensure BC compatibility.
>
> Rui please remove 2.1.2. We need to bring 2.1.1. which works on a
> stable level and not to change the API requiring a non stable version
> of Auth...
> 
> I didn't because I think the best way to proceed is to pull the release 
> Cheers
> David Costa

--
Rui Hirokawa <rui_hirokawa@ybb.ne.jp>

On Aug 19, 2004, at 4:58 PM, Rui Hirokawa wrote:

Hi Rui thanks for your prompt reply.

>
> David,
>
> I tried to remove Auth_HTTP 2.1.2 from
> http://pear.php.net/package-edit.php?id=1,
> but it caused an error shown belows, and it failed.
>
> Fatal error: Call to undefined function: isqa() in
> /usr/local/www/pearweb/include/pear-database.php on line 1787
>
same for me

> Someone can try to fix the problem or remove the release ?
>
> I have plan to release the stable Auth_HTTP 2.1.3 having compatibility
> with Auth 1.2.3, and release the new beta Auth_HTTP 2.2.0 for Auth
> 1.3.0
> later.
> Is it ok for you ?
>

That is exactly what I meant. Thanks again. The source for 2.1.1 was
good enough for stable release with 1.2.3
I don't mind a new beta 2.2 linked to auth 1.3.

Cheers
David Costa


> Rui
>
> On Thu, 19 Aug 2004 12:03:46 +0200
> David Costa <gurug@php.net> wrote:
> 
>
> --
> Rui Hirokawa <rui_hirokawa@ybb.ne.jp>
>
> --
> PEAR QA Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

On Thu, Aug 19, 2004 at 11:58:55PM +0900, Rui Hirokawa wrote:
>
> Fatal error: Call to undefined function: isqa() in
> /usr/local/www/pearweb/include/pear-database.php on line 1787

Fixed in CVS.

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409