A gui is overkill here. -----Original Message----- From: Oleg Gusakov [mailto:[email protected]] 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:[email protected]] 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 >> [email protected] >> http://blogs.exist.com/bporter/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
