10.3 blocker issue - DERBY-2728

[Myrna van Lunteren <m....@gmail.com>]

Hi,

We have a bump in our 10.3 release path - DERBY-2728.

I'd like the opinion of the community as to how we can address this;
how long would a fix take (and thus delay a release); who would be
willing to implement a fix?

Should we make a release candidate while the fixing is in progress?

Please give your 2 (or other #) cents.

Regards,
Myrna

Re: 10.3 blocker issue - DERBY-2728

[Kathey Marsden <km...@sbcglobal.net>]

Mike Matrigali wrote:
>
> I do wonder if there would be value to only apply the new options to 
> 10.3 databases.  Should we maintain exact compatibility in the soft
> upgrade case?
>
I tend to think it is better to have the new behavior even in soft 
upgrade mode.  The model normally is to test your application in soft 
upgrade and then hard upgrade if all went well.    If the new behaviour 
is masked until hard upgrade, there is no option to go back, so I'd 
rather see the hit on soft upgrade, but I can see the other point of 
view.  I agree that the incompatibility is a justified  incompatibility 
and upgrade risk if sql authorization is used.

Kathey

Re: 10.3 blocker issue - DERBY-2728

[Mike Matrigali <mi...@sbcglobal.net>]

Daniel John Debrunner wrote:
> Rick Hillegas wrote:
> 
>> It appears to me that three solutions have been proposed:
>>
>> 1) Call the release 11.0 rather than 10.3. That is, accept the 
>> incompatibilities.
> 
> 
> I don't actually see how changing the version number helps, it's still 
> incompatible.
> 
>> 2) Add an extra security knob. The default setting would be the old 
>> 10.2 behavior.
> 
> 
> -0.9 Adding properties is not good for the long run, leads to increased 
> complexity support cost as the number of permutations of runtime modes 
> increases.
> 
>> 3) Only restrict upgrade/encrypt/shutdown powers to the DBO if both 
>> authorization and authentication are turned on. This does not 
>> eliminate the incompatibilities but should greatly reduce the number 
>> of affected customers.
>>
>> My vote is for option (3).
> 
> 
> +1 for 3)
of the 3 I also would vote for +1 for 3) in hard upgrade/new databases.

I do wonder if there would be value to only apply the new options to 
10.3 databases.  Should we maintain exact compatibility in the soft
upgrade case?

> 
> Dan.
> 
> 

Re: 10.3 blocker issue - DERBY-2728

[Lars Heill <La...@Sun.COM>]

Daniel John Debrunner wrote, On 05/30/07 18:01:
> Rick Hillegas wrote:
> 
>> It appears to me that three solutions have been proposed:
>>
>> 1) Call the release 11.0 rather than 10.3. That is, accept the 
>> incompatibilities.
> 
> I don't actually see how changing the version number helps, it's still 
> incompatible.

I believe Rick may have wanted to express popular release taxonomy in which
[significant] incompatible changes are typically introduced in major version
releases (11.0) only, and not in minor (and lesser) version releases (10.3)
do not?

A new major version number send a major "heads-up" message to the user :)

-- Lars

Re: 10.3 blocker issue - DERBY-2728

[Daniel John Debrunner <dj...@apache.org>]

Rick Hillegas wrote:

> It appears to me that three solutions have been proposed:
> 
> 1) Call the release 11.0 rather than 10.3. That is, accept the 
> incompatibilities.

I don't actually see how changing the version number helps, it's still 
incompatible.

> 2) Add an extra security knob. The default setting would be the old 10.2 
> behavior.

-0.9 Adding properties is not good for the long run, leads to increased 
complexity support cost as the number of permutations of runtime modes 
increases.

> 3) Only restrict upgrade/encrypt/shutdown powers to the DBO if both 
> authorization and authentication are turned on. This does not eliminate 
> the incompatibilities but should greatly reduce the number of affected 
> customers.
> 
> My vote is for option (3).

+1 for 3)

Dan.

Re: 10.3 blocker issue - DERBY-2728

[David Van Couvering <da...@vancouvering.com>]

+1 to option 3.  What's crucial to me is that someone who is running
in a very secure environment or who doesn't care about the security of
the database (e.g. during development) does not have to deal with this
usability overhead.  Good to have for production, but keep it out of
the way for development and other "I don't care about security
"environments.

If someone has already taken the time to enable SqlAuthorization and
created the DBO role, then it's very likely they're in an environment
where they care about security and will probably like this added
security, even if it impacts compatibility.

We do have to keep a very close eye on compatibility, as many of the
use cases I am seeing has Derby embedded in some application
distributed across a wide array of machines where the user doesn't
know and doesn't want to know there is a database in there somewhere.

Thanks,

David

On 5/30/07, Rick Hillegas <Ri...@sun.com> wrote:
> Myrna van Lunteren wrote:
> > Hi,
> >
> > We have a bump in our 10.3 release path - DERBY-2728.
> >
> > I'd like the opinion of the community as to how we can address this;
> > how long would a fix take (and thus delay a release); who would be
> > willing to implement a fix?
> >
> > Should we make a release candidate while the fixing is in progress?
> Hi Myrna,
>
> I think we need to agree on a solution first. I don't think you can
> create a release branch (or candidate) until we know whether we're going
> to call the release 10.3 or 11.0.
> >
> > Please give your 2 (or other #) cents.
> >
> > Regards,
> > Myrna
> It appears to me that three solutions have been proposed:
>
> 1) Call the release 11.0 rather than 10.3. That is, accept the
> incompatibilities.
>
> 2) Add an extra security knob. The default setting would be the old 10.2
> behavior.
>
> 3) Only restrict upgrade/encrypt/shutdown powers to the DBO if both
> authorization and authentication are turned on. This does not eliminate
> the incompatibilities but should greatly reduce the number of affected
> customers.
>
> My vote is for option (3).
>
> Regards,
> -Rick
>

Re: 10.3 blocker issue - DERBY-2728

[Rick Hillegas <Ri...@Sun.COM>]

Myrna van Lunteren wrote:
> Hi,
>
> We have a bump in our 10.3 release path - DERBY-2728.
>
> I'd like the opinion of the community as to how we can address this;
> how long would a fix take (and thus delay a release); who would be
> willing to implement a fix?
>
> Should we make a release candidate while the fixing is in progress?
Hi Myrna,

I think we need to agree on a solution first. I don't think you can 
create a release branch (or candidate) until we know whether we're going 
to call the release 10.3 or 11.0.
>
> Please give your 2 (or other #) cents.
>
> Regards,
> Myrna
It appears to me that three solutions have been proposed:

1) Call the release 11.0 rather than 10.3. That is, accept the 
incompatibilities.

2) Add an extra security knob. The default setting would be the old 10.2 
behavior.

3) Only restrict upgrade/encrypt/shutdown powers to the DBO if both 
authorization and authentication are turned on. This does not eliminate 
the incompatibilities but should greatly reduce the number of affected 
customers.

My vote is for option (3).

Regards,
-Rick

Re: 10.3 blocker issue - DERBY-2728

[Stanley Bradbury <St...@gmail.com>]

Dag H. Wanvik wrote:
> Myrna van Lunteren <m....@gmail.com> writes:
>
>   
>> Hi,
>>
>> We have a bump in our 10.3 release path - DERBY-2728.
>>     
    =   =   =   = SNIP =  =====
> If we choose to tie enforcement to SQLAuthorization being on, I think
> this is a fairly small patch; the existing tests still have test cases
> for this (authentication + SQLauthorization), so they could be tweaked
> easily too. I expect most work would be to change the documentation
> (DERBY-2520). The release note for DERBY-2264 would need to change as
> well. I'd be willing to do this work if we choose that approach. I'd
> need a week; generally pushing releases less than 2 weeks seems not
> worth it, so I suggest a 2 week delay.
>
> DERBY-2728 speaks about making the semantics optional a *upgrade
> time*, though, which is another approach. This could imply some
> persistence of the fact that the database was upgraded and should have
> different semantics than a freshly created one, or use of extra
> properties.  If someone volunteers to make such a solution, thats fine
> with me.
>
> Note that even if we tie enforcement to SQLAuthorization, some
> existing application may still be impacted, although presumably much
> fewer applications, since this is a 10.2 feature, and already implies
> a database owner concept and is probably less likely to be used in an
> embedded context (Kathey's concern).
>
> Thanks,
> Dag
>
>   
>> Should we make a release candidate while the fixing is in progress?
>>     
   Hi -
Dag's suggestion seems like a best-approach to me.  +1

It solves the problem with a 'fairly small patch' and can be done with 
minimal impact on the release date.   The change will allow people who 
have not already set SQLAuthorization to test the impact of the new DBO 
role on their system and opt out of implementing it at this time.  As 
Dag points out, people who have already stepped up to using 
SQLAuthorization will have identified the DBO account and  designed the 
system accordingly so the change should be less dramatic.

As a side note I think it good to encourage Derby users to plan for and 
implement the DBO role at their earliest convenience.  Once the required 
changes are made and tested the flag can be set and the system will have 
the benefit of improved security.

And the question about: 

Should we make a release candidate while the fixing is in progress?

This seems like extra work for the Release Manager so, unless someone is aware of a critical need for a full release candidate build in the next week or two I would hold off.  Of course I am not the Release Manager and it is her call.

Re: 10.3 blocker issue - DERBY-2728

["Dag H. Wanvik" <Da...@Sun.COM>]

Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:

> If we choose to tie enforcement to SQLAuthorization being on, I think
> this is a fairly small patch; the existing tests still have test cases
> for this (authentication + SQLauthorization), so they could be tweaked
> easily too. I expect most work would be to change the documentation
> (DERBY-2520). The release note for DERBY-2264 would need to change as
> well. I'd be willing to do this work if we choose that approach. 

It seems most people have had their say about this issue, and the
votes seem to indicate that this approach is the preferred one.

There is a patch which implements this approach attached to
DERBY-2264. I intend to commit that early next week if no further
objections are raised and also tweak the attached 'releaseNote.html'
accordingly.

Next, I will start modifying the documentation (DERBY-2520) to reflect
the change.

Thanks,
Dag

Re: 10.3 blocker issue - DERBY-2728

["Dag H. Wanvik" <Da...@Sun.COM>]

Myrna van Lunteren <m....@gmail.com> writes:

> Hi,
>
> We have a bump in our 10.3 release path - DERBY-2728.
>
> I'd like the opinion of the community as to how we can address this;
> how long would a fix take (and thus delay a release); who would be
> willing to implement a fix?

If we choose to tie enforcement to SQLAuthorization being on, I think
this is a fairly small patch; the existing tests still have test cases
for this (authentication + SQLauthorization), so they could be tweaked
easily too. I expect most work would be to change the documentation
(DERBY-2520). The release note for DERBY-2264 would need to change as
well. I'd be willing to do this work if we choose that approach. I'd
need a week; generally pushing releases less than 2 weeks seems not
worth it, so I suggest a 2 week delay.

DERBY-2728 speaks about making the semantics optional a *upgrade
time*, though, which is another approach. This could imply some
persistence of the fact that the database was upgraded and should have
different semantics than a freshly created one, or use of extra
properties.  If someone volunteers to make such a solution, thats fine
with me.

Note that even if we tie enforcement to SQLAuthorization, some
existing application may still be impacted, although presumably much
fewer applications, since this is a 10.2 feature, and already implies
a database owner concept and is probably less likely to be used in an
embedded context (Kathey's concern).

Thanks,
Dag

>
> Should we make a release candidate while the fixing is in progress?
>
> Please give your 2 (or other #) cents.
>
> Regards,
> Myrna
>

-- 
Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101