You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2009/02/20 12:19:26 UTC
settings security: --enc-passwd / --enc-master-passwd options
Hi,
To make it a bit easier to remember, I added two options to the CLI
for 2.1: --enc-master-passwd and --enc-passwd; which are equivalent to
-m and -p on DefaultSecDispatcher.
For consistency with other options, it takes the password as an option
on the CLI rather than delegating to the DSD prompting. Afterwards it
terminates (like -v).
What do others think - is this the best way to configure it?
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Paul Benedict <pb...@apache.org>.
I think that is completely unintuitive no matter how "common" it is.
I've had to use passwords in maven plugins before (e.g., SCM, release
plugin), and it's not abbreviated like that.
So I did a "mvn -h"... and out of the some 20 options spelled out,
none use abbreviations. So I am -1 on the spelling: it is not
intuitive, no other option uses an abbreviated long version, and
plugins commonly spell out "password".
Paul
On Thu, Feb 26, 2009 at 7:34 AM, Brett Porter <br...@apache.org> wrote:
> It's now --encrypt-passwd (and --encrypt-master-passwd) based on Oleg's
> suggestion. passwd is pretty common, and you can see it from mvn -h.
>
> Cheers,
> Brett
>
> On 27/02/2009, at 12:30 AM, Paul Benedict wrote:
>
>> My only comment is this:
>>
>> I don't want to have to remember how you guys have uniquely
>> abbreviated password. "Enc" is fine, "passwd" is a guessing game, and
>> I believe should be spelled out.
>>
>> Paul
>>
>> On Thu, Feb 26, 2009 at 5:27 AM, Brett Porter <br...@apache.org> wrote:
>>>
>>> With 2.1.0 imminent, we'll need to finalise on this soon - are the
>>> current
>>> options satisfactory?
>>>
>>> Cheers,
>>> Brett
>>>
>>> On 24/02/2009, at 1:41 AM, Brett Porter wrote:
>>>
>>>>
>>>> On 23/02/2009, at 4:45 PM, Oleg Gusakov wrote:
>>>>
>>>>>
>>>>>
>>>>> Brett Porter wrote:
>>>>>>
>>>>>>
>>>>>> I don't view this as a temporary measure - as my second comment said,
>>>>>> you may need a password to get the plugin in the first place. How
>>>>>> would you
>>>>>> address this case?
>>>>>>
>>>>> I have never seen an environment where read-only access to central or
>>>>> central replica is authenticated. Short of that it's just another
>>>>> plugin to
>>>>> be downloaded and used. Or I completely missed the question?
>>>>
>>>> That's right, it's the situation I was thinking of. I was thinking along
>>>> the lines of a vetted repository where direct use of central is not
>>>> used.
>>>> It's maybe still unlikely that would be authenticated, but I wouldn't
>>>> rule
>>>> it out.
>>>>
>>>> Thinking it through, to me this actually feels a more natural fit in the
>>>> CLI now, along with the other settings-based operations, pretty much
>>>> symmetrical with the location of the operation to decode the passwords
>>>> in
>>>> the settings file. For a user, manipulation of the settings file is
>>>> generally a set-up task, before you do anything else. This location also
>>>> makes it very snappy, not going through the whole plugin cycle, and had
>>>> very
>>>> little impact on the code since it was already mostly achieved through
>>>> the
>>>> sec-dispatcher and cipher. A plugin for this would see infrequent
>>>> releases -
>>>> perhaps none - which seems an odd evolutionary cycle for an independent
>>>> piece of code.
>>>>
>>>> Not that tied to it being in the CLI if a suitable replacement is
>>>> already
>>>> in place, but I hope this is somewhat convincing :)
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Brett Porter <br...@apache.org>.
It's now --encrypt-passwd (and --encrypt-master-passwd) based on
Oleg's suggestion. passwd is pretty common, and you can see it from
mvn -h.
Cheers,
Brett
On 27/02/2009, at 12:30 AM, Paul Benedict wrote:
> My only comment is this:
>
> I don't want to have to remember how you guys have uniquely
> abbreviated password. "Enc" is fine, "passwd" is a guessing game, and
> I believe should be spelled out.
>
> Paul
>
> On Thu, Feb 26, 2009 at 5:27 AM, Brett Porter <br...@apache.org>
> wrote:
>> With 2.1.0 imminent, we'll need to finalise on this soon - are the
>> current
>> options satisfactory?
>>
>> Cheers,
>> Brett
>>
>> On 24/02/2009, at 1:41 AM, Brett Porter wrote:
>>
>>>
>>> On 23/02/2009, at 4:45 PM, Oleg Gusakov wrote:
>>>
>>>>
>>>>
>>>> Brett Porter wrote:
>>>>>
>>>>>
>>>>> I don't view this as a temporary measure - as my second comment
>>>>> said,
>>>>> you may need a password to get the plugin in the first place.
>>>>> How would you
>>>>> address this case?
>>>>>
>>>> I have never seen an environment where read-only access to
>>>> central or
>>>> central replica is authenticated. Short of that it's just another
>>>> plugin to
>>>> be downloaded and used. Or I completely missed the question?
>>>
>>> That's right, it's the situation I was thinking of. I was thinking
>>> along
>>> the lines of a vetted repository where direct use of central is
>>> not used.
>>> It's maybe still unlikely that would be authenticated, but I
>>> wouldn't rule
>>> it out.
>>>
>>> Thinking it through, to me this actually feels a more natural fit
>>> in the
>>> CLI now, along with the other settings-based operations, pretty much
>>> symmetrical with the location of the operation to decode the
>>> passwords in
>>> the settings file. For a user, manipulation of the settings file is
>>> generally a set-up task, before you do anything else. This
>>> location also
>>> makes it very snappy, not going through the whole plugin cycle,
>>> and had very
>>> little impact on the code since it was already mostly achieved
>>> through the
>>> sec-dispatcher and cipher. A plugin for this would see infrequent
>>> releases -
>>> perhaps none - which seems an odd evolutionary cycle for an
>>> independent
>>> piece of code.
>>>
>>> Not that tied to it being in the CLI if a suitable replacement is
>>> already
>>> in place, but I hope this is somewhat convincing :)
>>>
>>> Cheers,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Paul Benedict <pb...@apache.org>.
My only comment is this:
I don't want to have to remember how you guys have uniquely
abbreviated password. "Enc" is fine, "passwd" is a guessing game, and
I believe should be spelled out.
Paul
On Thu, Feb 26, 2009 at 5:27 AM, Brett Porter <br...@apache.org> wrote:
> With 2.1.0 imminent, we'll need to finalise on this soon - are the current
> options satisfactory?
>
> Cheers,
> Brett
>
> On 24/02/2009, at 1:41 AM, Brett Porter wrote:
>
>>
>> On 23/02/2009, at 4:45 PM, Oleg Gusakov wrote:
>>
>>>
>>>
>>> Brett Porter wrote:
>>>>
>>>>
>>>> I don't view this as a temporary measure - as my second comment said,
>>>> you may need a password to get the plugin in the first place. How would you
>>>> address this case?
>>>>
>>> I have never seen an environment where read-only access to central or
>>> central replica is authenticated. Short of that it's just another plugin to
>>> be downloaded and used. Or I completely missed the question?
>>
>> That's right, it's the situation I was thinking of. I was thinking along
>> the lines of a vetted repository where direct use of central is not used.
>> It's maybe still unlikely that would be authenticated, but I wouldn't rule
>> it out.
>>
>> Thinking it through, to me this actually feels a more natural fit in the
>> CLI now, along with the other settings-based operations, pretty much
>> symmetrical with the location of the operation to decode the passwords in
>> the settings file. For a user, manipulation of the settings file is
>> generally a set-up task, before you do anything else. This location also
>> makes it very snappy, not going through the whole plugin cycle, and had very
>> little impact on the code since it was already mostly achieved through the
>> sec-dispatcher and cipher. A plugin for this would see infrequent releases -
>> perhaps none - which seems an odd evolutionary cycle for an independent
>> piece of code.
>>
>> Not that tied to it being in the CLI if a suitable replacement is already
>> in place, but I hope this is somewhat convincing :)
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Oleg Gusakov <ol...@gmail.com>.
John,
John Casey wrote:
> not to mention that it introduces a lot of risk that the plugin will
> blow up on a headless machine. Don't forget CI setups here, please.
CI is too precious a resource to forget about :)
I added -Dsettings.master.password, -Dsettings.server.password system
properties and equivalent --settings-master-password,
--settings-server-password CLI options - either one would work.
I agree with Brian that plugin does not give too much, but maybe having
a nice (optional!) gui helps people to maintain passwords? Say if you
starts with --settings.password.gui will bring up the GUI .
I will post a note as soon as I test it all the long option names and
publish the new component.
Thanks,
Oleg
>
>
> Brian E. Fox wrote:
>> A gui is overkill here.
>>
>> -----Original Message-----
>> From: Oleg Gusakov [mailto:oleg.subscriptions@gmail.com] Sent:
>> Thursday, February 26, 2009 11:28 AM
>> To: Maven Developers List
>> Subject: Re: settings security: --enc-passwd / --enc-master-passwd
>> options
>>
>>
>>
>> Jason van Zyl wrote:
>>> This doesn't need to go into the core, I think a plugin is better.
>> I was thinking about GUI in the plugin - that way we either go by
>> -Dsettings-master-password and -Dsettings-server-password or have the
>> same options available via swing GUI
>>
>> Thanks,
>> Oleg
>>> On 26-Feb-09, at 6:22 AM, Brian E. Fox wrote:
>>>
>>>> +1 for no abbreviations. We have enough crazy options to memorize
>>>> on the
>>>> cli as it is. (ie is it maven.tests.skip or maven.skip.tests?)
>>>>
>>>> -----Original Message-----
>>>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>>>> Porter
>>>> Sent: Thursday, February 26, 2009 8:52 AM
>>>> To: Maven Developers List
>>>> Subject: Re: settings security: --enc-passwd / --enc-master-passwd
>>>> options
>>>>
>>>>
>>>> On 27/02/2009, at 12:45 AM, Jason van Zyl wrote:
>>>>
>>>>> I thought Oleg asked for the use of the password?
>>>> Did you mean plugin?
>>>>
>>>>> I don't want there to be a way in 2.1.x and then it be completely
>>>>> different in the 3.x line. It needs to be the same.
>>>> Certainly - would follow with an IT if we agree to have a CLI option
>>>> (and what the spelling should be :)
>>>>
>>>>>
>>>>> On 26-Feb-09, at 3:27 AM, Brett Porter wrote:
>>>>>
>>>>>> With 2.1.0 imminent, we'll need to finalise on this soon - are the
>>>>>> current options satisfactory?
>>>>>>
>>>>>> Cheers,
>>>>>> Brett
>>>>>>
>>>>>>>> I have never seen an environment where read-only access to
>>>>>>>> central or central replica is authenticated. Short of that it's
>>>>>>>> just another plugin to be downloaded and used. Or I completely
>>>>>>>> missed the question?
>>>>>>> That's right, it's the situation I was thinking of. I was thinking
>>>>>>> along the lines of a vetted repository where direct use of central
>>>>>>> is not used. It's maybe still unlikely that would be
>>>>>>> authenticated, but I wouldn't rule it out.
>>>>>>>
>>>>>>> Thinking it through, to me this actually feels a more natural fit
>>>>>>> in the CLI now, along with the other settings-based operations,
>>>>>>> pretty much symmetrical with the location of the operation to
>>>>>>> decode the passwords in the settings file. For a user,
>>>>>>> manipulation of the settings file is generally a set-up task,
>>>>>>> before you do anything else. This location also makes it very
>>>>>>> snappy, not going through the whole plugin cycle, and had very
>>>>>>> little impact on the code since it was already mostly achieved
>>>>>>> through the sec-dispatcher and cipher. A plugin for this would see
>>>>>>> infrequent releases - perhaps none - which seems an odd
>>>>>>> evolutionary cycle for an independent piece of code.
>>>>>>>
>>>>>>> Not that tied to it being in the CLI if a suitable replacement is
>>>>>>> already in place, but I hope this is somewhat convincing :)
>>>>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by John Casey <jd...@commonjava.org>.
not to mention that it introduces a lot of risk that the plugin will
blow up on a headless machine. Don't forget CI setups here, please.
Brian E. Fox wrote:
> A gui is overkill here.
>
> -----Original Message-----
> From: Oleg Gusakov [mailto:oleg.subscriptions@gmail.com]
> Sent: Thursday, February 26, 2009 11:28 AM
> To: Maven Developers List
> Subject: Re: settings security: --enc-passwd / --enc-master-passwd options
>
>
>
> Jason van Zyl wrote:
>> This doesn't need to go into the core, I think a plugin is better.
> I was thinking about GUI in the plugin - that way we either go by
> -Dsettings-master-password and -Dsettings-server-password or have the
> same options available via swing GUI
>
> Thanks,
> Oleg
>> On 26-Feb-09, at 6:22 AM, Brian E. Fox wrote:
>>
>>> +1 for no abbreviations. We have enough crazy options to memorize on the
>>> cli as it is. (ie is it maven.tests.skip or maven.skip.tests?)
>>>
>>> -----Original Message-----
>>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>>> Porter
>>> Sent: Thursday, February 26, 2009 8:52 AM
>>> To: Maven Developers List
>>> Subject: Re: settings security: --enc-passwd / --enc-master-passwd
>>> options
>>>
>>>
>>> On 27/02/2009, at 12:45 AM, Jason van Zyl wrote:
>>>
>>>> I thought Oleg asked for the use of the password?
>>> Did you mean plugin?
>>>
>>>> I don't want there to be a way in 2.1.x and then it be completely
>>>> different in the 3.x line. It needs to be the same.
>>> Certainly - would follow with an IT if we agree to have a CLI option
>>> (and what the spelling should be :)
>>>
>>>>
>>>> On 26-Feb-09, at 3:27 AM, Brett Porter wrote:
>>>>
>>>>> With 2.1.0 imminent, we'll need to finalise on this soon - are the
>>>>> current options satisfactory?
>>>>>
>>>>> Cheers,
>>>>> Brett
>>>>>
>>>>>>> I have never seen an environment where read-only access to
>>>>>>> central or central replica is authenticated. Short of that it's
>>>>>>> just another plugin to be downloaded and used. Or I completely
>>>>>>> missed the question?
>>>>>> That's right, it's the situation I was thinking of. I was thinking
>>>>>> along the lines of a vetted repository where direct use of central
>>>>>> is not used. It's maybe still unlikely that would be
>>>>>> authenticated, but I wouldn't rule it out.
>>>>>>
>>>>>> Thinking it through, to me this actually feels a more natural fit
>>>>>> in the CLI now, along with the other settings-based operations,
>>>>>> pretty much symmetrical with the location of the operation to
>>>>>> decode the passwords in the settings file. For a user,
>>>>>> manipulation of the settings file is generally a set-up task,
>>>>>> before you do anything else. This location also makes it very
>>>>>> snappy, not going through the whole plugin cycle, and had very
>>>>>> little impact on the code since it was already mostly achieved
>>>>>> through the sec-dispatcher and cipher. A plugin for this would see
>>>>>> infrequent releases - perhaps none - which seems an odd
>>>>>> evolutionary cycle for an independent piece of code.
>>>>>>
>>>>>> Not that tied to it being in the CLI if a suitable replacement is
>>>>>> already in place, but I hope this is somewhat convincing :)
>>>>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: settings security: --enc-passwd / --enc-master-passwd options
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
A gui is overkill here.
-----Original Message-----
From: Oleg Gusakov [mailto:oleg.subscriptions@gmail.com]
Sent: Thursday, February 26, 2009 11:28 AM
To: Maven Developers List
Subject: Re: settings security: --enc-passwd / --enc-master-passwd options
Jason van Zyl wrote:
> This doesn't need to go into the core, I think a plugin is better.
I was thinking about GUI in the plugin - that way we either go by
-Dsettings-master-password and -Dsettings-server-password or have the
same options available via swing GUI
Thanks,
Oleg
>
> On 26-Feb-09, at 6:22 AM, Brian E. Fox wrote:
>
>> +1 for no abbreviations. We have enough crazy options to memorize on the
>> cli as it is. (ie is it maven.tests.skip or maven.skip.tests?)
>>
>> -----Original Message-----
>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>> Porter
>> Sent: Thursday, February 26, 2009 8:52 AM
>> To: Maven Developers List
>> Subject: Re: settings security: --enc-passwd / --enc-master-passwd
>> options
>>
>>
>> On 27/02/2009, at 12:45 AM, Jason van Zyl wrote:
>>
>>> I thought Oleg asked for the use of the password?
>>
>> Did you mean plugin?
>>
>>> I don't want there to be a way in 2.1.x and then it be completely
>>> different in the 3.x line. It needs to be the same.
>>
>> Certainly - would follow with an IT if we agree to have a CLI option
>> (and what the spelling should be :)
>>
>>>
>>>
>>> On 26-Feb-09, at 3:27 AM, Brett Porter wrote:
>>>
>>>> With 2.1.0 imminent, we'll need to finalise on this soon - are the
>>>> current options satisfactory?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>>>> I have never seen an environment where read-only access to
>>>>>> central or central replica is authenticated. Short of that it's
>>>>>> just another plugin to be downloaded and used. Or I completely
>>>>>> missed the question?
>>>>>
>>>>> That's right, it's the situation I was thinking of. I was thinking
>>>>> along the lines of a vetted repository where direct use of central
>>>>> is not used. It's maybe still unlikely that would be
>>>>> authenticated, but I wouldn't rule it out.
>>>>>
>>>>> Thinking it through, to me this actually feels a more natural fit
>>>>> in the CLI now, along with the other settings-based operations,
>>>>> pretty much symmetrical with the location of the operation to
>>>>> decode the passwords in the settings file. For a user,
>>>>> manipulation of the settings file is generally a set-up task,
>>>>> before you do anything else. This location also makes it very
>>>>> snappy, not going through the whole plugin cycle, and had very
>>>>> little impact on the code since it was already mostly achieved
>>>>> through the sec-dispatcher and cipher. A plugin for this would see
>>>>> infrequent releases - perhaps none - which seems an odd
>>>>> evolutionary cycle for an independent piece of code.
>>>>>
>>>>> Not that tied to it being in the CLI if a suitable replacement is
>>>>> already in place, but I hope this is somewhat convincing :)
>>>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Oleg Gusakov <ol...@gmail.com>.
Jason van Zyl wrote:
> This doesn't need to go into the core, I think a plugin is better.
I was thinking about GUI in the plugin - that way we either go by
-Dsettings-master-password and -Dsettings-server-password or have the
same options available via swing GUI
Thanks,
Oleg
>
> On 26-Feb-09, at 6:22 AM, Brian E. Fox wrote:
>
>> +1 for no abbreviations. We have enough crazy options to memorize on the
>> cli as it is. (ie is it maven.tests.skip or maven.skip.tests?)
>>
>> -----Original Message-----
>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
>> Porter
>> Sent: Thursday, February 26, 2009 8:52 AM
>> To: Maven Developers List
>> Subject: Re: settings security: --enc-passwd / --enc-master-passwd
>> options
>>
>>
>> On 27/02/2009, at 12:45 AM, Jason van Zyl wrote:
>>
>>> I thought Oleg asked for the use of the password?
>>
>> Did you mean plugin?
>>
>>> I don't want there to be a way in 2.1.x and then it be completely
>>> different in the 3.x line. It needs to be the same.
>>
>> Certainly - would follow with an IT if we agree to have a CLI option
>> (and what the spelling should be :)
>>
>>>
>>>
>>> On 26-Feb-09, at 3:27 AM, Brett Porter wrote:
>>>
>>>> With 2.1.0 imminent, we'll need to finalise on this soon - are the
>>>> current options satisfactory?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>>>> I have never seen an environment where read-only access to
>>>>>> central or central replica is authenticated. Short of that it's
>>>>>> just another plugin to be downloaded and used. Or I completely
>>>>>> missed the question?
>>>>>
>>>>> That's right, it's the situation I was thinking of. I was thinking
>>>>> along the lines of a vetted repository where direct use of central
>>>>> is not used. It's maybe still unlikely that would be
>>>>> authenticated, but I wouldn't rule it out.
>>>>>
>>>>> Thinking it through, to me this actually feels a more natural fit
>>>>> in the CLI now, along with the other settings-based operations,
>>>>> pretty much symmetrical with the location of the operation to
>>>>> decode the passwords in the settings file. For a user,
>>>>> manipulation of the settings file is generally a set-up task,
>>>>> before you do anything else. This location also makes it very
>>>>> snappy, not going through the whole plugin cycle, and had very
>>>>> little impact on the code since it was already mostly achieved
>>>>> through the sec-dispatcher and cipher. A plugin for this would see
>>>>> infrequent releases - perhaps none - which seems an odd
>>>>> evolutionary cycle for an independent piece of code.
>>>>>
>>>>> Not that tied to it being in the CLI if a suitable replacement is
>>>>> already in place, but I hope this is somewhat convincing :)
>>>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Jason van Zyl <jv...@sonatype.com>.
This doesn't need to go into the core, I think a plugin is better.
On 26-Feb-09, at 6:22 AM, Brian E. Fox wrote:
> +1 for no abbreviations. We have enough crazy options to memorize on
> the
> cli as it is. (ie is it maven.tests.skip or maven.skip.tests?)
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
> Porter
> Sent: Thursday, February 26, 2009 8:52 AM
> To: Maven Developers List
> Subject: Re: settings security: --enc-passwd / --enc-master-passwd
> options
>
>
> On 27/02/2009, at 12:45 AM, Jason van Zyl wrote:
>
>> I thought Oleg asked for the use of the password?
>
> Did you mean plugin?
>
>> I don't want there to be a way in 2.1.x and then it be completely
>> different in the 3.x line. It needs to be the same.
>
> Certainly - would follow with an IT if we agree to have a CLI option
> (and what the spelling should be :)
>
>>
>>
>> On 26-Feb-09, at 3:27 AM, Brett Porter wrote:
>>
>>> With 2.1.0 imminent, we'll need to finalise on this soon - are the
>>> current options satisfactory?
>>>
>>> Cheers,
>>> Brett
>>>
>>>>> I have never seen an environment where read-only access to
>>>>> central or central replica is authenticated. Short of that it's
>>>>> just another plugin to be downloaded and used. Or I completely
>>>>> missed the question?
>>>>
>>>> That's right, it's the situation I was thinking of. I was thinking
>>>> along the lines of a vetted repository where direct use of central
>>>> is not used. It's maybe still unlikely that would be
>>>> authenticated, but I wouldn't rule it out.
>>>>
>>>> Thinking it through, to me this actually feels a more natural fit
>>>> in the CLI now, along with the other settings-based operations,
>>>> pretty much symmetrical with the location of the operation to
>>>> decode the passwords in the settings file. For a user,
>>>> manipulation of the settings file is generally a set-up task,
>>>> before you do anything else. This location also makes it very
>>>> snappy, not going through the whole plugin cycle, and had very
>>>> little impact on the code since it was already mostly achieved
>>>> through the sec-dispatcher and cipher. A plugin for this would see
>>>> infrequent releases - perhaps none - which seems an odd
>>>> evolutionary cycle for an independent piece of code.
>>>>
>>>> Not that tied to it being in the CLI if a suitable replacement is
>>>> already in place, but I hope this is somewhat convincing :)
>>>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: settings security: --enc-passwd / --enc-master-passwd options
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
+1 for no abbreviations. We have enough crazy options to memorize on the
cli as it is. (ie is it maven.tests.skip or maven.skip.tests?)
-----Original Message-----
From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett
Porter
Sent: Thursday, February 26, 2009 8:52 AM
To: Maven Developers List
Subject: Re: settings security: --enc-passwd / --enc-master-passwd
options
On 27/02/2009, at 12:45 AM, Jason van Zyl wrote:
> I thought Oleg asked for the use of the password?
Did you mean plugin?
> I don't want there to be a way in 2.1.x and then it be completely
> different in the 3.x line. It needs to be the same.
Certainly - would follow with an IT if we agree to have a CLI option
(and what the spelling should be :)
>
>
> On 26-Feb-09, at 3:27 AM, Brett Porter wrote:
>
>> With 2.1.0 imminent, we'll need to finalise on this soon - are the
>> current options satisfactory?
>>
>> Cheers,
>> Brett
>>
>>>> I have never seen an environment where read-only access to
>>>> central or central replica is authenticated. Short of that it's
>>>> just another plugin to be downloaded and used. Or I completely
>>>> missed the question?
>>>
>>> That's right, it's the situation I was thinking of. I was thinking
>>> along the lines of a vetted repository where direct use of central
>>> is not used. It's maybe still unlikely that would be
>>> authenticated, but I wouldn't rule it out.
>>>
>>> Thinking it through, to me this actually feels a more natural fit
>>> in the CLI now, along with the other settings-based operations,
>>> pretty much symmetrical with the location of the operation to
>>> decode the passwords in the settings file. For a user,
>>> manipulation of the settings file is generally a set-up task,
>>> before you do anything else. This location also makes it very
>>> snappy, not going through the whole plugin cycle, and had very
>>> little impact on the code since it was already mostly achieved
>>> through the sec-dispatcher and cipher. A plugin for this would see
>>> infrequent releases - perhaps none - which seems an odd
>>> evolutionary cycle for an independent piece of code.
>>>
>>> Not that tied to it being in the CLI if a suitable replacement is
>>> already in place, but I hope this is somewhat convincing :)
>>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Brett Porter <br...@apache.org>.
On 27/02/2009, at 12:45 AM, Jason van Zyl wrote:
> I thought Oleg asked for the use of the password?
Did you mean plugin?
> I don't want there to be a way in 2.1.x and then it be completely
> different in the 3.x line. It needs to be the same.
Certainly - would follow with an IT if we agree to have a CLI option
(and what the spelling should be :)
>
>
> On 26-Feb-09, at 3:27 AM, Brett Porter wrote:
>
>> With 2.1.0 imminent, we'll need to finalise on this soon - are the
>> current options satisfactory?
>>
>> Cheers,
>> Brett
>>
>>>> I have never seen an environment where read-only access to
>>>> central or central replica is authenticated. Short of that it's
>>>> just another plugin to be downloaded and used. Or I completely
>>>> missed the question?
>>>
>>> That's right, it's the situation I was thinking of. I was thinking
>>> along the lines of a vetted repository where direct use of central
>>> is not used. It's maybe still unlikely that would be
>>> authenticated, but I wouldn't rule it out.
>>>
>>> Thinking it through, to me this actually feels a more natural fit
>>> in the CLI now, along with the other settings-based operations,
>>> pretty much symmetrical with the location of the operation to
>>> decode the passwords in the settings file. For a user,
>>> manipulation of the settings file is generally a set-up task,
>>> before you do anything else. This location also makes it very
>>> snappy, not going through the whole plugin cycle, and had very
>>> little impact on the code since it was already mostly achieved
>>> through the sec-dispatcher and cipher. A plugin for this would see
>>> infrequent releases - perhaps none - which seems an odd
>>> evolutionary cycle for an independent piece of code.
>>>
>>> Not that tied to it being in the CLI if a suitable replacement is
>>> already in place, but I hope this is somewhat convincing :)
>>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Jason van Zyl <jv...@sonatype.com>.
I thought Oleg asked for the use of the password? I don't want there
to be a way in 2.1.x and then it be completely different in the 3.x
line. It needs to be the same.
On 26-Feb-09, at 3:27 AM, Brett Porter wrote:
> With 2.1.0 imminent, we'll need to finalise on this soon - are the
> current options satisfactory?
>
> Cheers,
> Brett
>
> On 24/02/2009, at 1:41 AM, Brett Porter wrote:
>
>>
>> On 23/02/2009, at 4:45 PM, Oleg Gusakov wrote:
>>
>>>
>>>
>>> Brett Porter wrote:
>>>>
>>>>
>>>> I don't view this as a temporary measure - as my second comment
>>>> said, you may need a password to get the plugin in the first
>>>> place. How would you address this case?
>>>>
>>> I have never seen an environment where read-only access to central
>>> or central replica is authenticated. Short of that it's just
>>> another plugin to be downloaded and used. Or I completely missed
>>> the question?
>>
>> That's right, it's the situation I was thinking of. I was thinking
>> along the lines of a vetted repository where direct use of central
>> is not used. It's maybe still unlikely that would be authenticated,
>> but I wouldn't rule it out.
>>
>> Thinking it through, to me this actually feels a more natural fit
>> in the CLI now, along with the other settings-based operations,
>> pretty much symmetrical with the location of the operation to
>> decode the passwords in the settings file. For a user, manipulation
>> of the settings file is generally a set-up task, before you do
>> anything else. This location also makes it very snappy, not going
>> through the whole plugin cycle, and had very little impact on the
>> code since it was already mostly achieved through the sec-
>> dispatcher and cipher. A plugin for this would see infrequent
>> releases - perhaps none - which seems an odd evolutionary cycle for
>> an independent piece of code.
>>
>> Not that tied to it being in the CLI if a suitable replacement is
>> already in place, but I hope this is somewhat convincing :)
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Brett Porter <br...@apache.org>.
With 2.1.0 imminent, we'll need to finalise on this soon - are the
current options satisfactory?
Cheers,
Brett
On 24/02/2009, at 1:41 AM, Brett Porter wrote:
>
> On 23/02/2009, at 4:45 PM, Oleg Gusakov wrote:
>
>>
>>
>> Brett Porter wrote:
>>>
>>>
>>> I don't view this as a temporary measure - as my second comment
>>> said, you may need a password to get the plugin in the first
>>> place. How would you address this case?
>>>
>> I have never seen an environment where read-only access to central
>> or central replica is authenticated. Short of that it's just
>> another plugin to be downloaded and used. Or I completely missed
>> the question?
>
> That's right, it's the situation I was thinking of. I was thinking
> along the lines of a vetted repository where direct use of central
> is not used. It's maybe still unlikely that would be authenticated,
> but I wouldn't rule it out.
>
> Thinking it through, to me this actually feels a more natural fit in
> the CLI now, along with the other settings-based operations, pretty
> much symmetrical with the location of the operation to decode the
> passwords in the settings file. For a user, manipulation of the
> settings file is generally a set-up task, before you do anything
> else. This location also makes it very snappy, not going through the
> whole plugin cycle, and had very little impact on the code since it
> was already mostly achieved through the sec-dispatcher and cipher. A
> plugin for this would see infrequent releases - perhaps none - which
> seems an odd evolutionary cycle for an independent piece of code.
>
> Not that tied to it being in the CLI if a suitable replacement is
> already in place, but I hope this is somewhat convincing :)
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Brett Porter <br...@apache.org>.
On 23/02/2009, at 4:45 PM, Oleg Gusakov wrote:
>
>
> Brett Porter wrote:
>>
>>
>> I don't view this as a temporary measure - as my second comment
>> said, you may need a password to get the plugin in the first place.
>> How would you address this case?
>>
> I have never seen an environment where read-only access to central
> or central replica is authenticated. Short of that it's just another
> plugin to be downloaded and used. Or I completely missed the question?
That's right, it's the situation I was thinking of. I was thinking
along the lines of a vetted repository where direct use of central is
not used. It's maybe still unlikely that would be authenticated, but I
wouldn't rule it out.
Thinking it through, to me this actually feels a more natural fit in
the CLI now, along with the other settings-based operations, pretty
much symmetrical with the location of the operation to decode the
passwords in the settings file. For a user, manipulation of the
settings file is generally a set-up task, before you do anything else.
This location also makes it very snappy, not going through the whole
plugin cycle, and had very little impact on the code since it was
already mostly achieved through the sec-dispatcher and cipher. A
plugin for this would see infrequent releases - perhaps none - which
seems an odd evolutionary cycle for an independent piece of code.
Not that tied to it being in the CLI if a suitable replacement is
already in place, but I hope this is somewhat convincing :)
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Oleg Gusakov <ol...@gmail.com>.
Brett Porter wrote:
>
>
> I don't view this as a temporary measure - as my second comment said,
> you may need a password to get the plugin in the first place. How
> would you address this case?
>
I have never seen an environment where read-only access to central or
central replica is authenticated. Short of that it's just another plugin
to be downloaded and used. Or I completely missed the question?
Thanks,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Brett Porter <br...@apache.org>.
On 21/02/2009, at 6:52 AM, Oleg Gusakov wrote:
>
>
> Brett Porter wrote:
>>
>> On 20/02/2009, at 10:19 PM, Brett Porter wrote:
>>
>>> Hi,
>>>
>>> To make it a bit easier to remember, I added two options to the
>>> CLI for 2.1: --enc-master-passwd and --enc-passwd; which are
>>> equivalent to -m and -p on DefaultSecDispatcher.
>>>
>>> For consistency with other options, it takes the password as an
>>> option on the CLI rather than delegating to the DSD prompting.
>>> Afterwards it terminates (like -v).
>>>
>>> What do others think - is this the best way to configure it?
>>
>> To reply to self - after talking to Benjamin and also reading the
>> docs I saw there was some plan to use a plugin to generate these.
>> This would also be useful for more general uses of the encryption,
>> but the reason I chose the CLI here is that you might need the
>> passwords to get the plugin in the first place, so this is more
>> convenient for a typical setup use case.
> I have a problem with this alteration: as this CLI is a temporary
> measure - I'd rather not have too many efforts to change that: -m
> and -p are a clear indication that it's temporary.
>
> If you start adding more stuff around temporary solutions, people
> expect them supported in the future. Please remove them - the plugin
> wil take care of the users long term.
I don't view this as a temporary measure - as my second comment said,
you may need a password to get the plugin in the first place. How
would you address this case?
>
>
> Another one: "enc" is usually used for encoding, so it's at least
> misleading.
Happy to change that to the full word if kept.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Oleg Gusakov <ol...@gmail.com>.
Brett Porter wrote:
>
> On 20/02/2009, at 10:19 PM, Brett Porter wrote:
>
>> Hi,
>>
>> To make it a bit easier to remember, I added two options to the CLI
>> for 2.1: --enc-master-passwd and --enc-passwd; which are equivalent
>> to -m and -p on DefaultSecDispatcher.
>>
>> For consistency with other options, it takes the password as an
>> option on the CLI rather than delegating to the DSD prompting.
>> Afterwards it terminates (like -v).
>>
>> What do others think - is this the best way to configure it?
>
> To reply to self - after talking to Benjamin and also reading the docs
> I saw there was some plan to use a plugin to generate these. This
> would also be useful for more general uses of the encryption, but the
> reason I chose the CLI here is that you might need the passwords to
> get the plugin in the first place, so this is more convenient for a
> typical setup use case.
I have a problem with this alteration: as this CLI is a temporary
measure - I'd rather not have too many efforts to change that: -m and -p
are a clear indication that it's temporary.
If you start adding more stuff around temporary solutions, people expect
them supported in the future. Please remove them - the plugin wil take
care of the users long term.
Another one: "enc" is usually used for encoding, so it's at least
misleading.
Thanks,
Oleg
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: settings security: --enc-passwd / --enc-master-passwd options
Posted by Brett Porter <br...@apache.org>.
On 20/02/2009, at 10:19 PM, Brett Porter wrote:
> Hi,
>
> To make it a bit easier to remember, I added two options to the CLI
> for 2.1: --enc-master-passwd and --enc-passwd; which are equivalent
> to -m and -p on DefaultSecDispatcher.
>
> For consistency with other options, it takes the password as an
> option on the CLI rather than delegating to the DSD prompting.
> Afterwards it terminates (like -v).
>
> What do others think - is this the best way to configure it?
To reply to self - after talking to Benjamin and also reading the docs
I saw there was some plan to use a plugin to generate these. This
would also be useful for more general uses of the encryption, but the
reason I chose the CLI here is that you might need the passwords to
get the plugin in the first place, so this is more convenient for a
typical setup use case.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/