You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Bernt M. Johnsen" <Be...@Sun.COM> on 2007/02/20 13:24:38 UTC
Q: Should Derby 10.3 be Derby 11?
Hi,
I raise this question because it has now been introduced functionality
that will make Derby 10.3 not entirely compatible with 10.2.
It might seem innocent, but I think it deserves some discussion.
With the "secure by default" functionality, Rick H. has committed a
patch which requires me in my environment to start using the new
-unsecure option when a started a network server.
Consider the follwing quotes from two ongoing issues which describes
incompatible behaviour:
http://issues.apache.org/jira/browse/DERBY-2196 :
> New Default Behavior - By default, the network server now comes up
> with a Basic security policy. The customer may want to edit this
> policy, using the demo/templates/server.policy template. Among other
> side-effects, this may affect the running of customer-written
> procedures and functions as well as other parts of the application
> which run in the same VM with the engine. The customer may need to
> instrument her code to run under a SecurityManager or she may need
> to consider running with the security-disabling -unsecure option.
http://issues.apache.org/jira/browse/DERBY-2264 :
> DBA Limits - The application may need to be changed to account for
> the fact that only the Database Owner can shutdown, encrypt, and
> upgrade a database.
So, the question is then: Is this a Derby 10 release, or should it
really be Derby 11?
Myself, I have no strong feelings, but wanted to raise the discussion.
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:
>>
>>> Thanks, Dan. I have updated the wiki page to clarify that the
>>> restrictions depend on authentication.
>>
>> Thanks, two more questions:
>>
>> In the first table there is the phrase "Among other side-effects"
>> What are these side effects, as it is it doesn't really help anyone
>> make a judgment call as to if they will be effected or not?
>>
>> In the first table there are the phrases "instrument her code" and
>> "instrument the rest of her application". I don't know what
>> "instrument" means here, could you expand on what such a user would
>> need to do?
>>
>> I update the sections a little to be clear on if authentication was
>> system or database, feel free to modify if what's I've changed is wrong.
>>
>> Thanks,
>> Dan.
>>
> Thanks for the additional feedback. I have tried to clarify the
> incompatibility entries for the secure server.
Thanks, I modified the page to make it reflect reality. Simply adding
privilege blocks will not work when running with policy file installed
by the network server.
Also removed the "may affect", since there's no "may" about it,
operations in routines that need security checks will fail with the
security policy installed by the network server.
Dan.
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>
>> Thanks, Dan. I have updated the wiki page to clarify that the
>> restrictions depend on authentication.
>
> Thanks, two more questions:
>
> In the first table there is the phrase "Among other side-effects"
> What are these side effects, as it is it doesn't really help anyone
> make a judgment call as to if they will be effected or not?
>
> In the first table there are the phrases "instrument her code" and
> "instrument the rest of her application". I don't know what
> "instrument" means here, could you expand on what such a user would
> need to do?
>
> I update the sections a little to be clear on if authentication was
> system or database, feel free to modify if what's I've changed is wrong.
>
> Thanks,
> Dan.
>
Thanks for the additional feedback. I have tried to clarify the
incompatibility entries for the secure server.
Regards,
-Rick
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Thanks, Dan. I have updated the wiki page to clarify that the
> restrictions depend on authentication.
Thanks, two more questions:
In the first table there is the phrase "Among other side-effects"
What are these side effects, as it is it doesn't really help anyone make
a judgment call as to if they will be effected or not?
In the first table there are the phrases "instrument her code" and
"instrument the rest of her application". I don't know what "instrument"
means here, could you expand on what such a user would need to do?
I update the sections a little to be clear on if authentication was
system or database, feel free to modify if what's I've changed is wrong.
Thanks,
Dan.
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Daniel John Debrunner wrote:
>>> Rick Hillegas wrote:
>>>> Daniel John Debrunner wrote:
>>>>> ...
>>>>>
>>>>> A wiki page with the proposed backwards compatibility issues
>>>>> listed together and with definition(s) of secure-by-default would
>>>>> be good. Since Rick seems to be proposing most of the backwards
>>>>> compatibility issues he seems like a good candidate to write the
>>>>> initial version of the page. :-) It could be just the collection
>>>>> of tables from the various functional specs.
>>>> The 10.3 release page now ends with a section which describes
>>>> incompatibilities with the previous release:
>>>> http://wiki.apache.org/db-derby/DerbyTenThreeRelease
>>>
>>> Thanks Rick, from a quick look the DBA powers section doesn't seem
>>> to match the comments in DERBY-2264 related to requiring
>>> authentication. But I'm not sure where that stands, (which is why a
>>> summary is a good thing ;-)
>>>
>>> Dan.
>>>
>> Hi Dan,
>>
>> I'm afraid I'm blind this morning. What discrepancy do you see
>> between the 10.3 incompatibility section and the comments on DERBY-2264?
>
> The DBA powers section on the wiki page makes no mention that this
> change is only in effect if authentication is enabled.
> This comment in DERBY-2264 seems to say that the restrictions are
> enforced when authentication is enabled.
> https://issues.apache.org/jira/browse/DERBY-2264#action_12474538
>
> Dan.
>
Thanks, Dan. I have updated the wiki page to clarify that the
restrictions depend on authentication.
Regards,
-Rick
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:
>>> Daniel John Debrunner wrote:
>>>> ...
>>>>
>>>> A wiki page with the proposed backwards compatibility issues listed
>>>> together and with definition(s) of secure-by-default would be good.
>>>> Since Rick seems to be proposing most of the backwards compatibility
>>>> issues he seems like a good candidate to write the initial version
>>>> of the page. :-) It could be just the collection of tables from the
>>>> various functional specs.
>>> The 10.3 release page now ends with a section which describes
>>> incompatibilities with the previous release:
>>> http://wiki.apache.org/db-derby/DerbyTenThreeRelease
>>
>> Thanks Rick, from a quick look the DBA powers section doesn't seem to
>> match the comments in DERBY-2264 related to requiring authentication.
>> But I'm not sure where that stands, (which is why a summary is a good
>> thing ;-)
>>
>> Dan.
>>
> Hi Dan,
>
> I'm afraid I'm blind this morning. What discrepancy do you see between
> the 10.3 incompatibility section and the comments on DERBY-2264?
The DBA powers section on the wiki page makes no mention that this
change is only in effect if authentication is enabled.
This comment in DERBY-2264 seems to say that the restrictions are
enforced when authentication is enabled.
https://issues.apache.org/jira/browse/DERBY-2264#action_12474538
Dan.
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Daniel John Debrunner wrote:
>>> ...
>>>
>>> A wiki page with the proposed backwards compatibility issues listed
>>> together and with definition(s) of secure-by-default would be good.
>>> Since Rick seems to be proposing most of the backwards compatibility
>>> issues he seems like a good candidate to write the initial version
>>> of the page. :-) It could be just the collection of tables from the
>>> various functional specs.
>> The 10.3 release page now ends with a section which describes
>> incompatibilities with the previous release:
>> http://wiki.apache.org/db-derby/DerbyTenThreeRelease
>
> Thanks Rick, from a quick look the DBA powers section doesn't seem to
> match the comments in DERBY-2264 related to requiring authentication.
> But I'm not sure where that stands, (which is why a summary is a good
> thing ;-)
>
> Dan.
>
Hi Dan,
I'm afraid I'm blind this morning. What discrepancy do you see between
the 10.3 incompatibility section and the comments on DERBY-2264?
Thanks,
-Rick
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> ...
>>
>> A wiki page with the proposed backwards compatibility issues listed
>> together and with definition(s) of secure-by-default would be good.
>> Since Rick seems to be proposing most of the backwards compatibility
>> issues he seems like a good candidate to write the initial version of
>> the page. :-) It could be just the collection of tables from the
>> various functional specs.
> The 10.3 release page now ends with a section which describes
> incompatibilities with the previous release:
> http://wiki.apache.org/db-derby/DerbyTenThreeRelease
Thanks Rick, from a quick look the DBA powers section doesn't seem to
match the comments in DERBY-2264 related to requiring authentication.
But I'm not sure where that stands, (which is why a summary is a good
thing ;-)
Dan.
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> ...
>
> A wiki page with the proposed backwards compatibility issues listed
> together and with definition(s) of secure-by-default would be good.
> Since Rick seems to be proposing most of the backwards compatibility
> issues he seems like a good candidate to write the initial version of
> the page. :-) It could be just the collection of tables from the
> various functional specs.
The 10.3 release page now ends with a section which describes
incompatibilities with the previous release:
http://wiki.apache.org/db-derby/DerbyTenThreeRelease
Regards,
-Rick
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Thanks for raising this issue, Bernt. Here's my $.02:
>
> Making Derby secure-by-default is a high priority for many people on
> this list. Since we're moving from wide-open, unsecure default behavior,
> we have a lot of work to do. I expect we'll be making significant
> security improvements for at least the next two feature releases. Once
> we start advertising Derby as a secure database, I think we're committed
> to closing security holes as they come up. I agree that we're changing
> the network server disruptively.
I think this discussion really needs to be grounded in some facts:
1) about what backwards compatibility issues there are with the
various changes
2) a good definition of "secure-by-default".
A wiki page with the proposed backwards compatibility issues listed
together and with definition(s) of secure-by-default would be good.
Since Rick seems to be proposing most of the backwards compatibility
issues he seems like a good candidate to write the initial version of
the page. :-) It could be just the collection of tables from the various
functional specs.
I don't think one can take a stand of compatibility is always better
than security or vice-versa, it's a case by case basis.
Dan.
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Francois Orsini <fr...@gmail.com>.
Assuming you're not running Derby as an embedded server ;)
It would be great to have some backward compatibilty when running Derby
embedded "local" (no server mode), at a minimum...
On 2/20/07, David Van Couvering <da...@vancouvering.com> wrote:
>
> I would like to suggest we include the user community on this
> discussion. It is the users who are most impacted by decisions around
> security and compatibility.
>
> Making the call that secure-by-default trumps frictionless upgrade
> really needs to be done with their input and overall approval.
>
> For example, if most people are using Derby embedded, then
> secure-by-default in terms of authentication seems to me very low
> priority. If I were a using Derby in embedded mode, and I were asked
> which was more important, backward compatibility or secure by default, I
> would definitely pick compatibility...
>
> David
>
> Rick Hillegas wrote:
> > Thanks for raising this issue, Bernt. Here's my $.02:
> >
> > Making Derby secure-by-default is a high priority for many people on
> > this list. Since we're moving from wide-open, unsecure default behavior,
> > we have a lot of work to do. I expect we'll be making significant
> > security improvements for at least the next two feature releases. Once
> > we start advertising Derby as a secure database, I think we're committed
> > to closing security holes as they come up. I agree that we're changing
> > the network server disruptively. If this kind of change makes us bump to
> > a major release number, then I think we face the possibility that our
> > next several feature releases will all be major revisions.
> >
> > There is an unhappy tension between frictionless-upgrade and
> > security-by-default. I don't think the proposed compatibility rules
> > address that tension:
> >
> http://wiki.apache.org/db-derby/ForwardCompatibility#head-fb84926793e6687822e8397203265a6497911efe
> >
> > For instance, the third bullet under "JVM Support and Version
> > Interoperability" makes cross-rev network connections negotiate down to
> > the lower rev of the protocol even if the lower rev is less secure. That
> > seems wrong to me. Before voting on these guidelines, I think they
> > should be revised so that security-by-default trumps
> frictionless-upgrade.
> >
> > Regards,
> > -Rick
> >
> > Bernt M. Johnsen wrote:
> >> Hi,
> >>
> >> I raise this question because it has now been introduced functionality
> >> that will make Derby 10.3 not entirely compatible with 10.2.
> >>
> >> It might seem innocent, but I think it deserves some discussion.
> >>
> >> With the "secure by default" functionality, Rick H. has committed a
> >> patch which requires me in my environment to start using the new
> >> -unsecure option when a started a network server.
> >>
> >> Consider the follwing quotes from two ongoing issues which describes
> >> incompatible behaviour:
> >>
> >> http://issues.apache.org/jira/browse/DERBY-2196 :
> >>
> >>> New Default Behavior - By default, the network server now comes up
> >>> with a Basic security policy. The customer may want to edit this
> >>> policy, using the demo/templates/server.policy template. Among other
> >>> side-effects, this may affect the running of customer-written
> >>> procedures and functions as well as other parts of the application
> >>> which run in the same VM with the engine. The customer may need to
> >>> instrument her code to run under a SecurityManager or she may need
> >>> to consider running with the security-disabling -unsecure option.
> >>>
> >>
> >> http://issues.apache.org/jira/browse/DERBY-2264 :
> >>
> >>> DBA Limits - The application may need to be changed to account for
> >>> the fact that only the Database Owner can shutdown, encrypt, and
> >>> upgrade a database.
> >>>
> >>
> >> So, the question is then: Is this a Derby 10 release, or should it
> >> really be Derby 11?
> >>
> >> Myself, I have no strong feelings, but wanted to raise the discussion.
> >>
> >>
> >
> >
>
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Daniel John Debrunner <dj...@apache.org>.
David Van Couvering wrote:
> I would like to suggest we include the user community on this
> discussion. It is the users who are most impacted by decisions around
> security and compatibility.
>
> Making the call that secure-by-default trumps frictionless upgrade
> really needs to be done with their input and overall approval.
No it doesn't. :-)
This is an Apache open source project, it's fine if the development
community takes a project in a direction that doesn't match the current
users' demands or expectations. Such a project will just end up with a
different set of users.
Any user can always ensure their interests are represented in a project
by becoming an active part of the development community.
> For example, if most people are using Derby embedded, then
> secure-by-default in terms of authentication seems to me very low
> priority.
and so I assume you wouldn't work on it. But to someone else who cares
about security in a network server environment it would be a high
priority and so they would work on it, it's their itch to scratch.
> If I were a using Derby in embedded mode, and I were asked
> which was more important, backward compatibility or secure by default, I
> would definitely pick compatibility...
and someone else would pick secure by default, but it doesn't really
matter. All that matters is who is willing to put in the development
effort to make the changes happen, Apache is a "do-ocracy" -- power of
those who do.
Note that I'm not suggesting the Derby development community should
ignore its users, but there's more to it than just saying the majority
of users do X so Y is or is not important. Derby has upgrade, backward
compatibility, security etc. only because people were active* in the
development community to make it happen. They scratched itches, and most
of the time that benefits most of the community, some of the time it may
only benefit a couple of people, it doesn't really matter.
Dan.
*active here being making the changes, discussing various approaches,
helping others, reviewing changes, running tests etc.
Re: Q: Should Derby 10.3 be Derby 11?
Posted by David Van Couvering <da...@vancouvering.com>.
I would like to suggest we include the user community on this
discussion. It is the users who are most impacted by decisions around
security and compatibility.
Making the call that secure-by-default trumps frictionless upgrade
really needs to be done with their input and overall approval.
For example, if most people are using Derby embedded, then
secure-by-default in terms of authentication seems to me very low
priority. If I were a using Derby in embedded mode, and I were asked
which was more important, backward compatibility or secure by default, I
would definitely pick compatibility...
David
Rick Hillegas wrote:
> Thanks for raising this issue, Bernt. Here's my $.02:
>
> Making Derby secure-by-default is a high priority for many people on
> this list. Since we're moving from wide-open, unsecure default behavior,
> we have a lot of work to do. I expect we'll be making significant
> security improvements for at least the next two feature releases. Once
> we start advertising Derby as a secure database, I think we're committed
> to closing security holes as they come up. I agree that we're changing
> the network server disruptively. If this kind of change makes us bump to
> a major release number, then I think we face the possibility that our
> next several feature releases will all be major revisions.
>
> There is an unhappy tension between frictionless-upgrade and
> security-by-default. I don't think the proposed compatibility rules
> address that tension:
> http://wiki.apache.org/db-derby/ForwardCompatibility#head-fb84926793e6687822e8397203265a6497911efe
>
> For instance, the third bullet under "JVM Support and Version
> Interoperability" makes cross-rev network connections negotiate down to
> the lower rev of the protocol even if the lower rev is less secure. That
> seems wrong to me. Before voting on these guidelines, I think they
> should be revised so that security-by-default trumps frictionless-upgrade.
>
> Regards,
> -Rick
>
> Bernt M. Johnsen wrote:
>> Hi,
>>
>> I raise this question because it has now been introduced functionality
>> that will make Derby 10.3 not entirely compatible with 10.2.
>>
>> It might seem innocent, but I think it deserves some discussion.
>>
>> With the "secure by default" functionality, Rick H. has committed a
>> patch which requires me in my environment to start using the new
>> -unsecure option when a started a network server.
>>
>> Consider the follwing quotes from two ongoing issues which describes
>> incompatible behaviour:
>>
>> http://issues.apache.org/jira/browse/DERBY-2196 :
>>
>>> New Default Behavior - By default, the network server now comes up
>>> with a Basic security policy. The customer may want to edit this
>>> policy, using the demo/templates/server.policy template. Among other
>>> side-effects, this may affect the running of customer-written
>>> procedures and functions as well as other parts of the application
>>> which run in the same VM with the engine. The customer may need to
>>> instrument her code to run under a SecurityManager or she may need
>>> to consider running with the security-disabling -unsecure option.
>>>
>>
>> http://issues.apache.org/jira/browse/DERBY-2264 :
>>
>>> DBA Limits - The application may need to be changed to account for
>>> the fact that only the Database Owner can shutdown, encrypt, and
>>> upgrade a database.
>>>
>>
>> So, the question is then: Is this a Derby 10 release, or should it
>> really be Derby 11?
>>
>> Myself, I have no strong feelings, but wanted to raise the discussion.
>>
>>
>
>
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks for raising this issue, Bernt. Here's my $.02:
Making Derby secure-by-default is a high priority for many people on
this list. Since we're moving from wide-open, unsecure default behavior,
we have a lot of work to do. I expect we'll be making significant
security improvements for at least the next two feature releases. Once
we start advertising Derby as a secure database, I think we're committed
to closing security holes as they come up. I agree that we're changing
the network server disruptively. If this kind of change makes us bump to
a major release number, then I think we face the possibility that our
next several feature releases will all be major revisions.
There is an unhappy tension between frictionless-upgrade and
security-by-default. I don't think the proposed compatibility rules
address that tension:
http://wiki.apache.org/db-derby/ForwardCompatibility#head-fb84926793e6687822e8397203265a6497911efe
For instance, the third bullet under "JVM Support and Version
Interoperability" makes cross-rev network connections negotiate down to
the lower rev of the protocol even if the lower rev is less secure. That
seems wrong to me. Before voting on these guidelines, I think they
should be revised so that security-by-default trumps frictionless-upgrade.
Regards,
-Rick
Bernt M. Johnsen wrote:
> Hi,
>
> I raise this question because it has now been introduced functionality
> that will make Derby 10.3 not entirely compatible with 10.2.
>
> It might seem innocent, but I think it deserves some discussion.
>
> With the "secure by default" functionality, Rick H. has committed a
> patch which requires me in my environment to start using the new
> -unsecure option when a started a network server.
>
> Consider the follwing quotes from two ongoing issues which describes
> incompatible behaviour:
>
> http://issues.apache.org/jira/browse/DERBY-2196 :
>
>> New Default Behavior - By default, the network server now comes up
>> with a Basic security policy. The customer may want to edit this
>> policy, using the demo/templates/server.policy template. Among other
>> side-effects, this may affect the running of customer-written
>> procedures and functions as well as other parts of the application
>> which run in the same VM with the engine. The customer may need to
>> instrument her code to run under a SecurityManager or she may need
>> to consider running with the security-disabling -unsecure option.
>>
>
> http://issues.apache.org/jira/browse/DERBY-2264 :
>
>> DBA Limits - The application may need to be changed to account for
>> the fact that only the Database Owner can shutdown, encrypt, and
>> upgrade a database.
>>
>
> So, the question is then: Is this a Derby 10 release, or should it
> really be Derby 11?
>
> Myself, I have no strong feelings, but wanted to raise the discussion.
>
>
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Rick Hillegas <Ri...@Sun.COM>.
For the sake of people who don't monitor the user mailing list: I posed
these questions on derby-user. Two responses came back. They concurred:
1) Calling the release 11.0 would make them read the Release Notes more
carefully.
2) Calling the release 11.0 would not discourage them from adopting it.
Regards,
-Rick
Myrna van Lunteren wrote:
> On 2/28/07, Rick Hillegas <Ri...@sun.com> wrote:
>> Myrna van Lunteren wrote:
>> > On 2/28/07, Lars Heill <La...@sun.com> wrote:
>> >> Rick Hillegas wrote:
>> >> >
>> >> > Everyone else seemed non-committal. Unless the community
>> continues the
>> >> > discussion and reaches consensus, the decision may be up to the
>> next
>> >> > release manager.
>> >>
>> >> Nice one :)
>> >>
>> >> Cheers,
>> >> Lars
>> >>
>> > I thought I saw a comment re asking the user list, but I can't
>> > remember seeing one. Did I invent/miss something?
>> >
>> > Myrna
>> Hi Myrna,
>>
>> David made that suggestion. Dan noted that our conventions don't give
>> the user list a decisive say here. I'm a little unclear about what
>> question to pose. Perhaps one of these:
>>
>> 1) Would calling this release 11.0 make it less likely that you would be
>> blindsided by these incomatibilities?
>>
>> 2) Would calling this release 11.0 make it less likely that you would
>> install this release?
>>
>> Regards,
>> -Rick
>>
> No, the user list doesn't give a decisive say, but seems we're not
> decisive right now either... :-)
> Yeah, I think those are what we don't know. Maybe make explicit 11.0
> instead of 10.3.
> Are there other incompatibilities that we've been holding off for
> 11.0? I don't think so?
>
> I also suspect most developers on the list have kept mum because
> (they/we) either
> 1. really don't care (a rose by another name is still a rose...)
> 2. find it easier to go with 10.3 because that's what we've been
> working on, and we think of version 11 as something that should hold
> lots of new functionality, but don't want cause users unnecessary
> trouble.
>
> Myrna
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Myrna van Lunteren <m....@gmail.com>.
On 2/28/07, Rick Hillegas <Ri...@sun.com> wrote:
> Myrna van Lunteren wrote:
> > On 2/28/07, Lars Heill <La...@sun.com> wrote:
> >> Rick Hillegas wrote:
> >> >
> >> > Everyone else seemed non-committal. Unless the community continues the
> >> > discussion and reaches consensus, the decision may be up to the next
> >> > release manager.
> >>
> >> Nice one :)
> >>
> >> Cheers,
> >> Lars
> >>
> > I thought I saw a comment re asking the user list, but I can't
> > remember seeing one. Did I invent/miss something?
> >
> > Myrna
> Hi Myrna,
>
> David made that suggestion. Dan noted that our conventions don't give
> the user list a decisive say here. I'm a little unclear about what
> question to pose. Perhaps one of these:
>
> 1) Would calling this release 11.0 make it less likely that you would be
> blindsided by these incomatibilities?
>
> 2) Would calling this release 11.0 make it less likely that you would
> install this release?
>
> Regards,
> -Rick
>
No, the user list doesn't give a decisive say, but seems we're not
decisive right now either... :-)
Yeah, I think those are what we don't know. Maybe make explicit 11.0
instead of 10.3.
Are there other incompatibilities that we've been holding off for
11.0? I don't think so?
I also suspect most developers on the list have kept mum because
(they/we) either
1. really don't care (a rose by another name is still a rose...)
2. find it easier to go with 10.3 because that's what we've been
working on, and we think of version 11 as something that should hold
lots of new functionality, but don't want cause users unnecessary
trouble.
Myrna
Re: Q: Should Derby 10.3 be Derby 11?
Posted by David Van Couvering <da...@vancouvering.com>.
No, that's fine with me. It wasn't clear to me what the conclusion was
on this thread.
I do think it would be reasonable to let the users know ahead of time
what the incompatibilities are they should expect, so they can raise any
issues now rather than after the release.
David
Rick Hillegas wrote:
> I thought we were operating under the assumption that the next release
> was going to go out the door with the incompatibilities listed on the
> 10.3 release page: http://wiki.apache.org/db-derby/DerbyTenThreeRelease.
> Up until now this thread has focused on the release name, not altering
> its contents. I thought that the developer community had reached
> consensus that, in these cases, the extra security justifies the
> incompatibilities.
>
> Are you yourself not comfortable with that decision? Are you
> recommending that we ask the user community whether they agree what has
> been, up until now, the consensus on derby-dev?
>
> Regards,
> -Rick
>
> David Van Couvering wrote:
>> I wanted the question to be more of the form "is compatibility between
>> minor releases more important to you than client/server
>> secure-by-default functionality?" -- with the suspicion that an
>> embedded user doesn't really care about client/server security and
>> thus would opt for compatibility. But even client/server users may
>> care more about compatibility than increased security. Just to help
>> us inform our decision here.
>>
>> This is assuming, if I understand things right, that the
>> incompatibility arises because we're improving authentication between
>> the network client and the server, with this security enabled by default.
>>
>> David
>>
>> Rick Hillegas wrote:
>>> Myrna van Lunteren wrote:
>>>> On 2/28/07, Lars Heill <La...@sun.com> wrote:
>>>>> Rick Hillegas wrote:
>>>>> >
>>>>> > Everyone else seemed non-committal. Unless the community
>>>>> continues the
>>>>> > discussion and reaches consensus, the decision may be up to the next
>>>>> > release manager.
>>>>>
>>>>> Nice one :)
>>>>>
>>>>> Cheers,
>>>>> Lars
>>>>>
>>>> I thought I saw a comment re asking the user list, but I can't
>>>> remember seeing one. Did I invent/miss something?
>>>>
>>>> Myrna
>>> Hi Myrna,
>>>
>>> David made that suggestion. Dan noted that our conventions don't give
>>> the user list a decisive say here. I'm a little unclear about what
>>> question to pose. Perhaps one of these:
>>>
>>> 1) Would calling this release 11.0 make it less likely that you would
>>> be blindsided by these incomatibilities?
>>>
>>> 2) Would calling this release 11.0 make it less likely that you would
>>> install this release?
>>>
>>> Regards,
>>> -Rick
>>>
>>>
>>>
>
>
>
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Rick Hillegas <Ri...@Sun.COM>.
I thought we were operating under the assumption that the next release
was going to go out the door with the incompatibilities listed on the
10.3 release page: http://wiki.apache.org/db-derby/DerbyTenThreeRelease.
Up until now this thread has focused on the release name, not altering
its contents. I thought that the developer community had reached
consensus that, in these cases, the extra security justifies the
incompatibilities.
Are you yourself not comfortable with that decision? Are you
recommending that we ask the user community whether they agree what has
been, up until now, the consensus on derby-dev?
Regards,
-Rick
David Van Couvering wrote:
> I wanted the question to be more of the form "is compatibility between
> minor releases more important to you than client/server
> secure-by-default functionality?" -- with the suspicion that an
> embedded user doesn't really care about client/server security and
> thus would opt for compatibility. But even client/server users may
> care more about compatibility than increased security. Just to help
> us inform our decision here.
>
> This is assuming, if I understand things right, that the
> incompatibility arises because we're improving authentication between
> the network client and the server, with this security enabled by default.
>
> David
>
> Rick Hillegas wrote:
>> Myrna van Lunteren wrote:
>>> On 2/28/07, Lars Heill <La...@sun.com> wrote:
>>>> Rick Hillegas wrote:
>>>> >
>>>> > Everyone else seemed non-committal. Unless the community
>>>> continues the
>>>> > discussion and reaches consensus, the decision may be up to the next
>>>> > release manager.
>>>>
>>>> Nice one :)
>>>>
>>>> Cheers,
>>>> Lars
>>>>
>>> I thought I saw a comment re asking the user list, but I can't
>>> remember seeing one. Did I invent/miss something?
>>>
>>> Myrna
>> Hi Myrna,
>>
>> David made that suggestion. Dan noted that our conventions don't give
>> the user list a decisive say here. I'm a little unclear about what
>> question to pose. Perhaps one of these:
>>
>> 1) Would calling this release 11.0 make it less likely that you would
>> be blindsided by these incomatibilities?
>>
>> 2) Would calling this release 11.0 make it less likely that you would
>> install this release?
>>
>> Regards,
>> -Rick
>>
>>
>>
Re: Q: Should Derby 10.3 be Derby 11?
Posted by David Van Couvering <da...@vancouvering.com>.
I wanted the question to be more of the form "is compatibility between
minor releases more important to you than client/server
secure-by-default functionality?" -- with the suspicion that an embedded
user doesn't really care about client/server security and thus would opt
for compatibility. But even client/server users may care more about
compatibility than increased security. Just to help us inform our
decision here.
This is assuming, if I understand things right, that the incompatibility
arises because we're improving authentication between the network client
and the server, with this security enabled by default.
David
Rick Hillegas wrote:
> Myrna van Lunteren wrote:
>> On 2/28/07, Lars Heill <La...@sun.com> wrote:
>>> Rick Hillegas wrote:
>>> >
>>> > Everyone else seemed non-committal. Unless the community continues the
>>> > discussion and reaches consensus, the decision may be up to the next
>>> > release manager.
>>>
>>> Nice one :)
>>>
>>> Cheers,
>>> Lars
>>>
>> I thought I saw a comment re asking the user list, but I can't
>> remember seeing one. Did I invent/miss something?
>>
>> Myrna
> Hi Myrna,
>
> David made that suggestion. Dan noted that our conventions don't give
> the user list a decisive say here. I'm a little unclear about what
> question to pose. Perhaps one of these:
>
> 1) Would calling this release 11.0 make it less likely that you would be
> blindsided by these incomatibilities?
>
> 2) Would calling this release 11.0 make it less likely that you would
> install this release?
>
> Regards,
> -Rick
>
>
>
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Myrna van Lunteren wrote:
> On 2/28/07, Lars Heill <La...@sun.com> wrote:
>> Rick Hillegas wrote:
>> >
>> > Everyone else seemed non-committal. Unless the community continues the
>> > discussion and reaches consensus, the decision may be up to the next
>> > release manager.
>>
>> Nice one :)
>>
>> Cheers,
>> Lars
>>
> I thought I saw a comment re asking the user list, but I can't
> remember seeing one. Did I invent/miss something?
>
> Myrna
Hi Myrna,
David made that suggestion. Dan noted that our conventions don't give
the user list a decisive say here. I'm a little unclear about what
question to pose. Perhaps one of these:
1) Would calling this release 11.0 make it less likely that you would be
blindsided by these incomatibilities?
2) Would calling this release 11.0 make it less likely that you would
install this release?
Regards,
-Rick
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Myrna van Lunteren <m....@gmail.com>.
On 2/28/07, Lars Heill <La...@sun.com> wrote:
> Rick Hillegas wrote:
> >
> > Everyone else seemed non-committal. Unless the community continues the
> > discussion and reaches consensus, the decision may be up to the next
> > release manager.
>
> Nice one :)
>
> Cheers,
> Lars
>
I thought I saw a comment re asking the user list, but I can't
remember seeing one. Did I invent/miss something?
Myrna
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Lars Heill <La...@Sun.COM>.
Rick Hillegas wrote:
>
> Everyone else seemed non-committal. Unless the community continues the
> discussion and reaches consensus, the decision may be up to the next
> release manager.
Nice one :)
Cheers,
Lars
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Laura Stewart wrote:
> On 2/20/07, Bernt M. Johnsen <Be...@sun.com> wrote:
>> Hi,
>>
>> I raise this question because it has now been introduced functionality
>> that will make Derby 10.3 not entirely compatible with 10.2.
>>
> (snip)
>
>> So, the question is then: Is this a Derby 10 release, or should it
>> really be Derby 11?
>
> I have gotten a bit lost in all of the conversation in this thread...
> has there been sufficent discussion to decide if 10.3 should be 11?
>
>
Hi Laura,
Thanks for reviving this thread. So far, I'm aware of only two clear
opinions:
Kathey: Believed that the incompatibilities were significant enough to
warrant a jump to major release 11.
Bryan: Wanted to stay at 10.3 despite the incompatibilities and worried
that a major release jump would discourage users from adopting the next
release.
Everyone else seemed non-committal. Unless the community continues the
discussion and reaches consensus, the decision may be up to the next
release manager.
Regards,
-Rick
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Laura Stewart <sc...@gmail.com>.
On 2/20/07, Bernt M. Johnsen <Be...@sun.com> wrote:
> Hi,
>
> I raise this question because it has now been introduced functionality
> that will make Derby 10.3 not entirely compatible with 10.2.
>
(snip)
> So, the question is then: Is this a Derby 10 release, or should it
> really be Derby 11?
I have gotten a bit lost in all of the conversation in this thread...
has there been sufficent discussion to decide if 10.3 should be 11?
--
Laura Stewart
Re: Q: Should Derby 10.3 be Derby 11?
Posted by David Van Couvering <da...@vancouvering.com>.
I was *this* close to doing a vote for this. Maybe it's time to make
this happen?
David
Dyre.Tjeldvoll@Sun.COM wrote:
> "Bernt M. Johnsen" <Be...@Sun.COM> writes:
>
>> So, the question is then: Is this a Derby 10 release, or should it
>> really be Derby 11?
>>
>> Myself, I have no strong feelings, but wanted to raise the discussion.
>
> Me neither, but here are my observations:
>
> 1) Derby's charter doesn't mention backward compatibility (or forward
> compatibility) at all
>
> 2) It has been argued that backward compatibility is implied by the
> "easy to use" requirement, but I think this discussion shows this
> to be inadequate. Clearly, both "secure by default" and "backward
> comatibility" could be seen as ease of use features (The charter
> only says "Secure". It doesn't mention "secure by default"). But
> which ease of use feature is more important? I think the implicit
> "backward compatibility" requirement and its importance relative to
> other requirements should be added to the charter.
>
> 3) As far as I can tell (from the Derby website), the idea that an
> incompatibility is OK iff you bump the major version number has not
> been formally accepted/ratified by the Derby community. David van
> Couvering has written a Wiki page about this,
>
> http://wiki.apache.org/db-derby/ForwardCompatibility#head-fb84926793e6687822e8397203265a6497911efe
>
> which (in my interpretation) suggests that requiring the -unsecure
> option is an INCOMPATIBLE change to a STABLE interface, and that
> this should only be allowed when changing the major version
> number. However, this wiki page has numerous disclaimers which
> state that this is "just a draft" and "work in progress".
>
> If there has been a vote on this, it is not recorded on
>
> http://wiki.apache.org/db-derby/VoteResults
>
> According to nabble the last discussion about this seems
> to be
>
> http://www.nabble.com/-PRE-VOTE-DISCUSSION--Compatibility-rules-and-interface-table-tf1782536.html#a4854300
>
> which doesn't seem to reach a consensus. There doesn't seem to be
> any major disagreement though...
>
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Dy...@Sun.COM.
"Bernt M. Johnsen" <Be...@Sun.COM> writes:
> So, the question is then: Is this a Derby 10 release, or should it
> really be Derby 11?
>
> Myself, I have no strong feelings, but wanted to raise the discussion.
Me neither, but here are my observations:
1) Derby's charter doesn't mention backward compatibility (or forward
compatibility) at all
2) It has been argued that backward compatibility is implied by the
"easy to use" requirement, but I think this discussion shows this
to be inadequate. Clearly, both "secure by default" and "backward
comatibility" could be seen as ease of use features (The charter
only says "Secure". It doesn't mention "secure by default"). But
which ease of use feature is more important? I think the implicit
"backward compatibility" requirement and its importance relative to
other requirements should be added to the charter.
3) As far as I can tell (from the Derby website), the idea that an
incompatibility is OK iff you bump the major version number has not
been formally accepted/ratified by the Derby community. David van
Couvering has written a Wiki page about this,
http://wiki.apache.org/db-derby/ForwardCompatibility#head-fb84926793e6687822e8397203265a6497911efe
which (in my interpretation) suggests that requiring the -unsecure
option is an INCOMPATIBLE change to a STABLE interface, and that
this should only be allowed when changing the major version
number. However, this wiki page has numerous disclaimers which
state that this is "just a draft" and "work in progress".
If there has been a vote on this, it is not recorded on
http://wiki.apache.org/db-derby/VoteResults
According to nabble the last discussion about this seems
to be
http://www.nabble.com/-PRE-VOTE-DISCUSSION--Compatibility-rules-and-interface-table-tf1782536.html#a4854300
which doesn't seem to reach a consensus. There doesn't seem to be
any major disagreement though...
--
dt
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Bryan Pendleton <bp...@amberpoint.com>.
I'm somewhat concerned that, by labeling this release 11,
we will actually *discourage* people from moving to it
rapidly. People will tend to think it is more incompatible
than it actually is, and will tend to think it is more
volatile and less stable than it actually is, and so it will
slow acceptance of the release.
In most respects, setting this Network Server security policy
stuff aside for the time being, it seems to me that 10.2 was
a bigger jump from 10.1 than the upcoming release will be from 10.2.
I guess that makes me sort of a "0" position, neither really
in favor of relabeling the release nor really opposed.
thanks,
bryan
Re: Q: Should Derby 10.3 be Derby 11?
Posted by Kathey Marsden <km...@sbcglobal.net>.
Bernt M. Johnsen wrote:
> Hi,
>
> I raise this question because it has now been introduced functionality
> that will make Derby 10.3 not entirely compatible with 10.2.
>
> It might seem innocent, but I think it deserves some discussion.
>
> With the "secure by default" functionality, Rick H. has committed a
> patch which requires me in my environment to start using the new
> -unsecure option when a started a network server.
>
I think security is a good enough reason to break compatibility and I
agree we should bump to 11 for this change. My only concern in doing
that is that it will be seen as free license for other incompatible
changes which it shouldn't be.
Kathey