[p4] Scripting and ticket authentication

[Shawn Hladky]

That's true but I suspect 'p4 -P <ticket>' isn't encrypted either.  I don't
think there's any solution that's 100% secure.  In my situation, we (the
Perforce folks) don't control all the servers that automation runs on.
Given the corporate culture and resource constraints, that fact is not going
to change.  So if someone wants to setup automation, we send them
instructions to configure p4.  Today, those instructions include a p4config
file with P4PASSWORD set to a long-lived ticket from 'p4 login -a'.  The
problem is that they can use this file anywhere and with any scripts... not
just the scenario we initially agreed upon.  Usually the problem isn't even
malicious.  Developer A asks developer B how to setup a Perforce scheduled
task, and developer B gives A the p4config files w/o even thinking about
it.  With the new setup, we'll have a little more control with NT ACLs and
possibly firewall rules... without having to create more Perforce users or
complicate the protections table.

BTW, the new undoc SSO-Auth triggers may be the best way to really secure
Perforce... but I haven't had a chance to play with them yet.

On 7/17/07, Jeff Grills <jgrills at drivensnow.org> wrote:
>
>
> In your new strategy, wouldn't the contents of the ticket file be
> transferred unencrypted over the network?  And since the tickets are valid
> for all IP addresses (due to the -a option to login), wouldn't that allow
> anyone who snooped the network to gain the script's access to perforce
> from
> their own machine?  That seems like a bad security hole.  Of course, you
> might inherently trust your network, in which case it might not be an
> issue
> for you.
>
> j
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com ] On Behalf Of Shawn Hladky
> Sent: Tuesday, July 17, 2007 3:48 PM
> To: Bob Van Zant
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] Scripting and ticket authentication
>
>
> Currently we do the following:
> use P4CONFIG files
> in the p4config set P4PASSWD to a ticket value that doesn't expire for a
> long time.
>
> I've been prototyping a new strategy:
> Set P4TICKETS to a centralized remote share.  Access to the share is
> restricted by the system account (NT in our case) running the script. On a
> secure server, run a script to update the ticket on the central server (p4
> logout -a & p4 login -a) daily.
>
> The theory behind this is that the NT accounts should already be secure,
> and
> you'll need that secure access to get a current ticket.  The downside is
> that fileshare becomes a single point of failure for the scripts, and
> cross-platform stuff gets tricky.
>
>