You certainly are persistent Christian. While it still goes against my
better judgement I am inclined to let these changes in. The main reasons
being:
* our policy has always been fuzzy on this and GSIP 77 has not yet become
official, so we have no hard and fast rule
* Victor has stated the release is being pushed back a few days until
Thursday
So if the other PSC members consent I would say go ahead for now.
But please note that this will really be the only exception to this rule. I
believe Andrea is going to be updating the GSIP 77 proposal to be clearer
about this. But after the proposal lands there will be no exceptions like
this. If the developer doesn't have things in order before hitting the
stable deadline then its too bad. They must wait no matter how inconvenient
it will be for them.
Also moving forward please ensure that you don't lump large changesets into
single commits in your git repo. A good rule of thumb is a single commit
for a single JIRA issue. This would have made things a lot easier from the
start.
-Justin
On Mon, Jun 18, 2012 at 8:03 AM, Christian Mueller <[email protected]>wrote:
> Hi all
>
> @Justin, the modifications concerning GeoServerSecurityManager are
> described in http://jira.codehaus.org/browse/GEOS-5101. The patch
> finishes this concept we agreed on 17th of May. I added some additional
> description.
>
> @Andrea, the default xml role service is also affected by GEOS-5101. As an
> example, a user can create two xml role services and add the identical role
> (Let us call it ROLE_XXX) to both services. Then the role in the first
> service is assigned to user1, the role in the second service is assigned to
> user2. Now open the access control page for data or services. You will see
> ROLE_XXX once. First confusion. You have to check what the actual role
> service is and perhaps, you have to modify this setting. The patch avoids
> such situations by checking uniqueness across all role services.
>
> For access control, you need to see all the roles present in the system.
> At the moment, you only see the roles of the actual role service. Next
> confusion. Believe me, I tested with multiple role and user/group services
> and I was confused by myself very often.
>
> As you pointed out, most of the patch is about replacing deprecations.
> During the deprecation work, I also found some bugs concerning wrong
> assignments of deprecated constants to not deprecated constants and some
> failures in the resource files, --> wrong or missing error messages. The
> JDBC stuff also covers GEOS-5101 and bug fixes.
>
> @Ben, the patch does not introduce new functionality. If finishes the role
> concept which is already in trunk partially , but it does not work
> correctly. The rest of the bug fixes is essential and I think, resolving
> deprecations is not a major refactoring.
>
> But anyway, if the patch goes not it, it is ok. I want to point out some
> consequences.
>
> 1) The security systems requires a migration. Without the patch, I have to
> split the migration into two steps, making things more complicated. The
> second step is migration code for the role service.
>
> 2) Users using more than one role service may produce configurations
> making step 2 of the migration impossible. (Additionally to the problems
> described above).
>
> 3) If it is not possible to bring the changes at least to 2.2.1 but only
> to 2.3.0, I have no idea how to continue. I even stopped working on the
> security documentation because I am not sure how to describe things related
> to roles.
>
> Christian
>
>
>
>
> 2012/6/18 Ben Caradoc-Davies <[email protected]>
>
>> Short version: I vote to hold the security patch until after RC and then
>> apply it only to trunk.
>>
>>
>> On 16/06/12 16:45, Christian Mueller wrote:
>>
>>> Waiting 4-6 weeks is no problem
>>>
>>
>> It is worse than that. To clarify, when the RC is made, we will also be
>> branching 2.2.x. Only essential bugfixes will made before 2.2.0 is
>> released. New functionality will only be backported after testing on trunk
>> and then only if low risk and with a PSC vote. Major refactoring is not
>> allowed on stable.
>> http://geoserver.org/display/**GEOS/GSIP+77+-+Time+boxed+**release+model<http://geoserver.org/display/GEOS/GSIP+77+-+Time+boxed+release+model>
>>
>> I voted +1 for GSIP 77.
>>
>>
>> To close this issue, I need a decision of the PSC.
>>>
>>
>> I vote to hold the security patch until after RC; this means that it will
>> miss 2.2.x and only be applied to 2.3.x (trunk). Once it has been shown to
>> work reliably on trunk, it might backported at some future date, but not if
>> it requires major refactoring.
>>
>> Yes, this means that a lot of the new security functionality will suck on
>> 2.2.0 and later stable.
>>
>> The purpose of the stable branch is to maintain stability, that it, to
>> avoid introducing unpleasant surprises for users, such as new bugs,
>> functional changes, or file format incompatibilities. It does not mean that
>> stable is bug free, just that the behaviour of the software is known. Users
>> should be able to upgrade a stable production system to a later patch
>> version of the stable branch and have a reasonable expectation that nothing
>> that was working will break. While security will be pretty hurty, that is
>> just tough. It will be no worse than before your patch. New code equals new
>> bugs. That is just the way it is. Stable is where we avoid adding bugs.
>> While some users will feel pain, the herd will settle on one stable code
>> base and learn how to cope.
>>
>> Releasing more often is a good practice. Andrea has done a great job on
>> GSIP 77 and it would be a pity for our good intentions to be derailed so
>> soon. No dessert until we eat all our vegetables.
>>
>> - Holding off releases has left stable so far behind app-schema on trunk
>> that we have for over a year been warning users to never use 2.1.x for
>> app-schema.
>>
>> - I know at least two other developers who have work that cannot go in RC
>> and must go on trunk. Delaying RC blocks their work.
>>
>> Note that throughout, references to security mean security subsystem
>> changes. Vulnerabilities to external attack (perhaps spelled "SECURITY"?)
>> must always be patched on stable and trunk as soon as possible.
>>
>> Kind regards,
>>
>> --
>> Ben Caradoc-Davies <[email protected]>
>> Software Engineer
>> CSIRO Earth Science and Resource Engineering
>> Australian Resources Research Centre
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
