[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [tortoisesvn] r23145 committed - Add optional "force" options to scripts. If set,...

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Thu, 9 Aug 2012 19:34:22 +0200

On Thu, Aug 9, 2012 at 4:01 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> On Thu, Aug 9, 2012 at 12:20 AM, <tortoisesvn_at_googlecode.com> wrote:
>> Revision: 23145
>> Author: stefan.fuhrmann.1974
>> Date: Wed Aug 8 15:19:46 2012
>> Log: Add optional "force" options to scripts. If set,
>> the respective script will be applied without
>> prior approval by the users. Also, forced scripts
>> cannot be ignored after failure.
>
> Uh-oh!
> That's exactly why I didn't implement this in earlier versions: this
> is a big, big security risk!
> Executing something without asking the user first is a NO-NO. It
> doesn't matter if its useful or not. And it doesn't matter if its
> optional.

I agree that executing commands from the repository content is
unsafe. I will change that as follows:

* hook settings via tsvn:* properties will always require user approval
  (at least once)
* if "force" has been set here, it will disable the "retry w/o hook"
  button in the progress dialog
* "force"d hooks configured via settings menu have - by definition -
  already been approved by user (or someone with access to the machine)

This should eliminate the attack vector of some outside committer
executing code on your machine w/o prior approval.

Locally configured hooks are as trustworthy as the hook content itself.
The approval does not give extra security in that case.

> Is there a specific reason you implemented this?
> If not, I'd rather revert this change.

I've got that from customers (even prior to WANdisco): The hook
scripts will tell them "your stuff does not work" but TSVN gives
them a "what the hell - commit it anyway!" button.

A "force" option would work perfectly in 1.7.x as it simply hides
that button. But in 1.8 we need a more sophisticated set of rules.
It will not be watertight: since we won't trust repository dictated
hooks, a user must be allowed to not run them but still be able
to continue with the actual SVN operation. Everything else would
open a DOS attack vector.

-- Stefan^2.

-- 
Join us this October for Subversion Live 2012 – 2 full days of
training, networking, live demos and more! 25% off before Aug. 10th
with discount code “earlybird.”
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2997610
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-08-09 19:35:03 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.