Kalle Korhonen | 28 Oct 18:44 2010
Picon

Re: [VOTE] Release Apache Shiro version 1.1.0

On Thu, Oct 28, 2010 at 9:10 AM, Alan D. Cabrera <list@...> wrote:
> Rat seems to pass fine.  I recommend that we explicitly remove crowd from the source for this release.

We are running rat (the maven plugin) integrated with the release. I
could just remove the classes from the tag but there's no absolute
need. Sorry, had to disable the module since the dependencies didn't
resolve (but it'll be an easy addition as an independent release
following 1.1.0).

Kalle

> On Oct 28, 2010, at 3:21 AM, Kalle Korhonen wrote:
>
>> This is the first release for Apache Shiro as a Top Level Project,
>> version 1.1.0.
>>
>> The issues solved for 1.1.0 (since the 1.0.0-incubating release):
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310950&styleName=Html&version=12314742
>>
>> The tag to be voted upon:
>> http://svn.apache.org/repos/asf/shiro/tags/shiro-root-1.1.0/
>>
>> Staging repo for binaries:
>> https://repository.apache.org/content/repositories/orgapacheshiro-002/
>>
>> Project website (just for informational purposes, not to be voted upon):
>> http://shiro.apache.org/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
(Continue reading)

Les Hazlewood | 28 Oct 18:59 2010

Re: [VOTE] Release Apache Shiro version 1.1.0

-1 at the moment because I think this is a bit premature.  I think
when attempting a release, we should at least have a quick email to
ask the other devs if there's anything left that needs to be resolved
before we can take a vote.

For example, there were a lot of issues moved to 1.2, but SHIRO-186
and SHIRO-197 have both been implemented but not yet resolved.  I left
them open on purpose in case we needed to do some additional work
based on users' testing.  Since we've received no feedback for them,
they can be marked resolved and included in 1.1.

Just a quick "hey, let's try to cut a release on Friday - let's clean
up anything that might need to happen in the next day or two" would be
nice.

I'd like to go through the moved issues today, resolve the ones that I
know have been open but should be resolved, and then take a re-vote if
that's ok.

Les

Les Hazlewood (JIRA | 28 Oct 19:12 2010
Picon

[jira] Updated: (SHIRO-186) Credentials Hashing: AuthenticationInfo should be able to return a salt for credentials comparison


     [
https://issues.apache.org/jira/browse/SHIRO-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Les Hazlewood updated SHIRO-186:
--------------------------------

    Fix Version/s:     (was: 1.2.0)
                   1.1.0

> Credentials Hashing: AuthenticationInfo should be able to return a salt for credentials comparison
> --------------------------------------------------------------------------------------------------
>
>                 Key: SHIRO-186
>                 URL: https://issues.apache.org/jira/browse/SHIRO-186
>             Project: Shiro
>          Issue Type: Improvement
>          Components: Authentication (log-in), Cryptography & Hashing
>    Affects Versions: 1.0.0, 1.0.1
>            Reporter: Les Hazlewood
>            Assignee: Les Hazlewood
>             Fix For: 1.1.0
>
>
> When hashing credentials, the CredentialsMatcher must be able to acquire a salt from the
AuthenticationInfo returned from the realm since salts are account/user-specific.
> The HashedCredentialsMatcher should be updated to acquire the salt, if it exists, from the
AuthenticationInfo and use that to perform a hash before comparing credentials.

--

-- 
(Continue reading)

Les Hazlewood (JIRA | 28 Oct 19:12 2010
Picon

[jira] Resolved: (SHIRO-186) Credentials Hashing: AuthenticationInfo should be able to return a salt for credentials comparison


     [
https://issues.apache.org/jira/browse/SHIRO-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Les Hazlewood resolved SHIRO-186.
---------------------------------

    Resolution: Fixed

> Credentials Hashing: AuthenticationInfo should be able to return a salt for credentials comparison
> --------------------------------------------------------------------------------------------------
>
>                 Key: SHIRO-186
>                 URL: https://issues.apache.org/jira/browse/SHIRO-186
>             Project: Shiro
>          Issue Type: Improvement
>          Components: Authentication (log-in), Cryptography & Hashing
>    Affects Versions: 1.0.0, 1.0.1
>            Reporter: Les Hazlewood
>            Assignee: Les Hazlewood
>             Fix For: 1.1.0
>
>
> When hashing credentials, the CredentialsMatcher must be able to acquire a salt from the
AuthenticationInfo returned from the realm since salts are account/user-specific.
> The HashedCredentialsMatcher should be updated to acquire the salt, if it exists, from the
AuthenticationInfo and use that to perform a hash before comparing credentials.

--

-- 
This message is automatically generated by JIRA.
(Continue reading)

Kalle Korhonen | 28 Oct 19:13 2010
Picon

Re: [VOTE] Release Apache Shiro version 1.1.0

On Thu, Oct 28, 2010 at 9:59 AM, Les Hazlewood <les@...> wrote:
> -1 at the moment because I think this is a bit premature.  I think
> when attempting a release, we should at least have a quick email to
> ask the other devs if there's anything left that needs to be resolved
> before we can take a vote.

This was discussed on private.

> For example, there were a lot of issues moved to 1.2, but SHIRO-186
> and SHIRO-197 have both been implemented but not yet resolved.  I left
> them open on purpose in case we needed to do some additional work
> based on users' testing.  Since we've received no feedback for them,
> they can be marked resolved and included in 1.1.

I did ask you before and you can still mark them as resolved.

> Just a quick "hey, let's try to cut a release on Friday - let's clean
> up anything that might need to happen in the next day or two" would be
> nice.

Please follow the private list; I wrote "I believe the right course of
action is to expedite the 1.1.0 release plan (our first release as
a TLP) as much as possible. Shiro PMC members, please make every
effort closing down the remaining issues for 1.1.0". There were
special circumstances cutting the release which is why this was
discussed there.

Kalle

(Continue reading)

Les Hazlewood | 28 Oct 19:39 2010
Picon

Re: [VOTE] Release Apache Shiro version 1.1.0

On Thu, Oct 28, 2010 at 10:13 AM, Kalle Korhonen
<kalle.o.korhonen@...> wrote:

>> -1 at the moment because I think this is a bit premature.  I think
>> when attempting a release, we should at least have a quick email to
>> ask the other devs if there's anything left that needs to be resolved
>> before we can take a vote.
>
> This was discussed on private.

That was the case, but because of a critical work deadline, I've been
out of the loop for the last 36 hours and the comment was embedded in
a long string of emails that I haven't fully caught up on (this
morning I've had my first bit of 'breathing room').

In the past, the project team has always dedicated a thread for
discussing prep for a release, and I assumed it would be the same this
time around and not embedded in a different thread.  I'm just asking
that we have such a dedicated discussion thread as a course of action
for anything that will probably lead to a vote ('e.g. 'Upcoming
Release: blah') - just so all members can clearly distinguish things
of this level of importance before being surprised by a full vote.

Alan's comment about the crowd source code is another example of why
this is a good idea.  That should have been surfaced in the release
discussion thread, not the vote thread IMO.

This isn't strictly required of course - just a requested courtesy.
The [VOTE] thread itself is obviously enough of an attention grabber
to catch any outstanding issues (as this one clearly did).
(Continue reading)

Les Hazlewood | 28 Oct 19:44 2010
Picon

Re: [VOTE] Release Apache Shiro version 1.1.0

Also, I agree with Alan's comments about the crowd support.  We don't
know 100% if that's totally compatible with the ASF 2.0 license based
on the crowd libraries.  We may be, but we'd better leave it out for
the release, just in case, and move it to 1.2.

Kalle, do you want to handle that while I address my Jira issues?  If
not, I'd be happy to do it afterwards.

Les

Kalle Korhonen | 28 Oct 19:54 2010
Picon

Re: [VOTE] Release Apache Shiro version 1.1.0

The code Alan wrote is certainly Apache licensed. We have no
dependencies to Crowd at the moment so I don't see any issue here.

Kalle

On Thu, Oct 28, 2010 at 10:44 AM, Les Hazlewood <lhazlewood@...> wrote:
> Also, I agree with Alan's comments about the crowd support.  We don't
> know 100% if that's totally compatible with the ASF 2.0 license based
> on the crowd libraries.  We may be, but we'd better leave it out for
> the release, just in case, and move it to 1.2.
>
> Kalle, do you want to handle that while I address my Jira issues?  If
> not, I'd be happy to do it afterwards.
>
> Les
>

Les Hazlewood | 28 Oct 20:06 2010
Picon

Re: [VOTE] Release Apache Shiro version 1.1.0

Ok, but why did Alan (who wrote the code) recommend that it stay out
of this release?  If it's not due to licensing issues, then it's
probably because it may not have been decently vetted and that it may
be changed enough later such that we could have likely
backwards-incompatibility issues.

If this is the reason, then it sounds like a good enough of one to me
to keep it out of the next minor release.

How hard is it to just tag what we have and delete that module?  Do
you have any objections Kalle?

Les

Les Hazlewood (JIRA | 28 Oct 20:12 2010
Picon

[jira] Resolved: (SHIRO-27) OSGi support


     [
https://issues.apache.org/jira/browse/SHIRO-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Les Hazlewood resolved SHIRO-27.
--------------------------------

       Resolution: Duplicate
    Fix Version/s: 1.1.0

Duplicates SHIRO-189

> OSGi support
> ------------
>
>                 Key: SHIRO-27
>                 URL: https://issues.apache.org/jira/browse/SHIRO-27
>             Project: Shiro
>          Issue Type: New Feature
>            Reporter: Alan Cabrera
>             Fix For: 1.1.0
>
>
> It would be nice to deploy JSecurity as an OSGi bundle, picking up 1 or more Realms from the OSGi discovery
service. This allows people to deploy JSecurity as a system wide Service in an application independent
manner (for those who use OSGi at least).

--

-- 
This message is automatically generated by JIRA.
-
(Continue reading)


Gmane