maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: settings security: --enc-passwd / --enc-master-passwd options
Date Thu, 26 Feb 2009 13:51:34 GMT

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message