Subversion

Upgrade Subversion Now: Security Threat Identified

Posted 3 months ago by nob...@example.com (Ashley Russell)

Recently Subversion 1.6.4 and Subversion 1.5.7 were released because a security problem has been identified in all earlier version of Subversion (SVN) i.e. all versions of Subversion prior to 1.5.7

Seventeen million downloads on Sourceforge

Posted 3 months ago by nob...@example.com (Lübbe)

and rank 34 in the all time downloads chart.

Source: http://sourceforge.net/top/topalltime.php and
http://sourceforge.net/top/toplist.php?type=downloads_week

Subversion Path-Based Permissions in CollabNet TeamForge

Posted 3 months ago by nob...@example.com (Jeremy Whitlock)

CollabNet TeamForge (CTF) 5.2 has been out for a while now but I thought
I would help introduce the most significant feature added as a result of
its release: Subversion path-based permissions. Prior to CTF 5.2, when
you wanted to manage ... [More] access control for your Subversion repositories, you
were able to provide only "blanket level" permissioning. This means that
you either had no access, read access or read/write access and that
access applied for the whole repository. There was no way to open up or
lock down subsets of the repository tree. For many, this was fine but
often resulted in some process of maintaining multiple repositories to
suit their needs. The problem was even bigger for those that came from
other solutions where they were use to full control.

Well, with the release of CTF 5.2, you now have the ability to use
path-based permissions to take full control of the repository access for
your project's repositories. Once you create a Subversion repository,
path-based permissions are available just like the rest of the CTF tools.
For those of you that do not want or need path-based permissions, CTF
still works with blanket-level access.

(Note: The purpose of this article is not to teach you how to create a
CTF integration, project or repository and assumes that you've got a
Subversion repository already created and ready to work with.)

As with previous releases of CTF, to start we need to get to the project
Permissions by performing the following steps:

1. Click the "Project Admin" tab

2. Click the "Permissions" menu item to the left

Now we can create a new role or modify an existing role so that we can
create some new path-based permissions for our repository. To provide a
full example, we'll create a few roles:

* Developer: Has complete access to the repository except the /tags
directory where he can only read.

* Manager: Has complete access to the repository

* Contractor: Has no access anywhere except /trunk/contractor and
/branches/b1/contractor

(As with any CTF role, you can add individual users or you can create
groups of users and then add those groups to the role.) To get started,
let's click the "Create" button on the Permissions page. Fill out the
form with the following values:

* Role Name: Developer

* Description: This role is for developers.

Once you've done this, click the "Create" button once more. At this
point, the role is created but it has no real permissions set. Since
we're here for path-based permissions, click the "Source Code" menu item
to the left. This is where the magic happens for path-based permissions.
To set/manipulate path-based permissions, look down in the "Permissions
for Specific Repositories" section of this page to see a list of
repositories. (Only Subversion repositories have the ability to have
path-based permissions set for them.) To get started, click the
"Path-based Permissions" radio button and you should see that a sub-form
is displayed. This is where you will add these path-based permissions.

Let's go ahead and setup the Developer role. To do this, follow these
steps:

1. Change the default permission for the "/" path to be "View and
Commit" by selecting the "View and Commit" radio button

2. Click the "Add" button

3. In the newly displayed text box, type in "/tags"

4. Beside the "/tags" row, select the "View" radio button.

5. Click the "Save" button

At this point, we have fulfilled the requirements for the Developer role.
Based on our permissions model, any user with the Developer role will
have full read/write access to the repository except for the "/tags"
directory and everything below it, where the user will have read access
only. Below is a screenshot of what you might expect to see:

Developer Role

Now that we know how to create a role in CTF and modify its "Source Code"
permissions to use path-based permissions for Subversion, let's quickly
go through configuring the other two roles, starting with the Manager
role.

To configure the "Source Code" permissions for the Manager role, follow
these steps:

1. Create the role using the same steps above (The "Role Name" should
be "Manager" and the description should be "This role is for
managers.")

2. Get to the "Source Code" permissions for this role using the same
steps above

3. Enable path-based permissions using the same steps above

4. Click the "View and Commit" radio button for the default repository
path

5. Click "Save"

As with the Developer role, here is an example screenshot:

Manager Role

The last role we have to configure is the Contractor role. To configure
it, follow these steps:

1. Create the role using the same steps above (The "Role Name" should
be "Contractor" and the description should be "This role is for
contractors.")

2. Get to the "Source Code" permissions for this role using the same
steps above

3. Enable path-based permissions using the same steps above (Since
we'll not be giving access to any parts of the repository by default,
we will not be updating the default path permissions.)

4. Click the "Add" button

5. In the newly displayed text box, type "/branches/b1/contractor"

6. Beside the "/branches/b1/contractor" row, click the "View and
Commit" radio button

7. Click the "Add" button

8. In the newly displayed text box, type "/trunk/contractor"

9. Beside the "/trunk/contractor" row, click the "View and Commit"
radio button

10. Click the "Save" button

Here is an example of the configuration:

Contractor Role

At this point you have all of your roles created and you could start
adding project members with their respective roles, which is outside the
scope of this article. One more thing before we move on is to explain how
these permissions are used to give you access.

When it comes to generating the internal "model" of what you have access
to, CTF plays by the same rules as Subversion's authorization model. The
idea here is that you can give/restrict access at any path and the
permission for that path applies for said path and all paths below that
path. Sounds simple enough. Now...to "override" a higher-level
permission, all you have to do is create a path-based permission for the
path you want to enable/restrict access for. You saw an example of this
in the Contractor role. While we initially said that the Contractor role
would have no access at "/", we then enabled access at
"/branches/b1/contractor" and "/trunk/contractor" by creating a more
specific rule and that rule applies at that path and everything below
that path unless overridden by a lower-level rule. So to summarize:
Permissions for a path are inherited from their parent unless you create
a new path-based permission for the path in question overriding its
parent's permission.

So what else is there to learn about path-based permissions in CTF? Well,
you should know the CTF tools that path-based permissions are enforced
on. Sure Subversion access is a given but here is the full list of CTF
tooling that path-based permissions impact the access of:

* Subversion access

* Source code browsing (This includes the enablement/display of the
"Source Code" toolbar button, the listing of the repositories when
the "Source Code" button is clicked and the actual content rendered
when you click a repository and start browsing its content.)

* Commit viewer (Much like the source code browsing, when you view
commit objects in the Commit Viewer, the content rendered depends on
your access permissions.)

* Repository monitoring

Well, that pretty much sums up path-based permissions in CTF. As you can
tell by the information above, path-based permissions are a very simple
yet very powerful way to restrict access to your source code and the CTF
tooling related to source code. If you have any question about path-based
permissions or anything in CollabNet TeamForge, please visit our
community site for mailing lists, forums, articles and help
documentation. [Less]

Subversion Path-Based Permissions in CollabNet TeamForge

Posted 3 months ago by nob...@example.com (Jeremy Whitlock)

CollabNet TeamForge (CTF) 5.2 has been out for a while now but I thought
I would help introduce the most significant feature added as a result of
its release: Subversion path-based permissions. Prior to CTF 5.2, when
you wanted to manage ... [More] access control for your Subversion repositories, you
were able to provide only "blanket level" permissioning. This means that
you either had no access, read access or read/write access and that
access applied for the whole repository. There was no way to open up or
lock down subsets of the repository tree. For many, this was fine but
often resulted in some process of maintaining multiple repositories to
suit their needs. The problem was even bigger for those that came from
other solutions where they were use to full control.

Well, with the release of CTF 5.2, you now have the ability to use
path-based permissions to take full control of the repository access for
your project's repositories. Once you create a Subversion repository,
path-based permissions are available just like the rest of the CTF tools.
For those of you that do not want or need path-based permissions, CTF
still works with blanket-level access.

(Note: The purpose of this article is not to teach you how to create a
CTF integration, project or repository and assumes that you've got a
Subversion repository already created and ready to work with.)

As with previous releases of CTF, to start we need to get to the project
Permissions by performing the following steps:

1. Click the "Project Admin" tab

2. Click the "Permissions" menu item to the left

Now we can create a new role or modify an existing role so that we can
create some new path-based permissions for our repository. To provide a
full example, we'll create a few roles:

* Developer: Has complete access to the repository except the /tags
directory where he can only read.

* Manager: Has complete access to the repository

* Contractor: Has no access anywhere except /trunk/contractor and
/branches/b1/contractor

(As with any CTF role, you can add individual users or you can create
groups of users and then add those groups to the role.) To get started,
let's click the "Create" button on the Permissions page. Fill out the
form with the following values:

* Role Name: Developer

* Description: This role is for developers.

Once you've done this, click the "Create" button once more. At this
point, the role is created but it has no real permissions set. Since
we're here for path-based permissions, click the "Source Code" menu item
to the left. This is where the magic happens for path-based permissions.
To set/manipulate path-based permissions, look down in the "Permissions
for Specific Repositories" section of this page to see a list of
repositories. (Only Subversion repositories have the ability to have
path-based permissions set for them.) To get started, click the
"Path-based Permissions" radio button and you should see that a sub-form
is displayed. This is where you will add these path-based permissions.

Let's go ahead and setup the Developer role. To do this, follow these
steps:

1. Change the default permission for the "/" path to be "View and
Commit" by selecting the "View and Commit" radio button

2. Click the "Add" button

3. In the newly displayed text box, type in "/tags"

4. Beside the "/tags" row, select the "View" radio button.

5. Click the "Save" button

At this point, we have fulfilled the requirements for the Developer role.
Based on our permissions model, any user with the Developer role will
have full read/write access to the repository except for the "/tags"
directory and everything below it, where the user will have read access
only. Below is a screenshot of what you might expect to see:

Developer Role

Now that we know how to create a role in CTF and modify its "Source Code"
permissions to use path-based permissions for Subversion, let's quickly
go through configuring the other two roles, starting with the Manager
role.

To configure the "Source Code" permissions for the Manager role, follow
these steps:

1. Create the role using the same steps above (The "Role Name" should
be "Manager" and the description should be "This role is for
managers.")

2. Get to the "Source Code" permissions for this role using the same
steps above

3. Enable path-based permissions using the same steps above

4. Click the "View and Commit" radio button for the default repository
path

5. Click "Save"

As with the Developer role, here is an example screenshot:

Manager Role

The last role we have to configure is the Contractor role. To configure
it, follow these steps:

1. Create the role using the same steps above (The "Role Name" should
be "Contractor" and the description should be "This role is for
contractors.")

2. Get to the "Source Code" permissions for this role using the same
steps above

3. Enable path-based permissions using the same steps above (Since
we'll not be giving access to any parts of the repository by default,
we will not be updating the default path permissions.)

4. Click the "Add" button

5. In the newly displayed text box, type "/branches/b1/contractor"

6. Beside the "/branches/b1/contractor" row, click the "View and
Commit" radio button

7. Click the "Add" button

8. In the newly displayed text box, type "/trunk/contractor"

9. Beside the "/trunk/contractor" row, click the "View and Commit"
radio button

10. Click the "Save" button

Here is an example of the configuration:

Contractor Role

At this point you have all of your roles created and you could start
adding project members with their respective roles, which is outside the
scope of this article. One more thing before we move on is to explain how
these permissions are used to give you access.

When it comes to generating the internal "model" of what you have access
to, CTF plays by the same rules as Subversion's authorization model. The
idea here is that you can give/restrict access at any path and the
permission for that path applies for said path and all paths below that
path. Sounds simple enough. Now...to "override" a higher-level
permission, all you have to do is create a path-based permission for the
path you want to enable/restrict access for. You saw an example of this
in the Contractor role. While we initially said that the Contractor role
would have no access at "/", we then enabled access at
"/branches/b1/contractor" and "/trunk/contractor" by creating a more
specific rule and that rule applies at that path and everything below
that path unless overridden by a lower-level rule. So to summarize:
Permissions for a path are inherited from their parent unless you create
a new path-based permission for the path in question overriding its
parent's permission.

So what else is there to learn about path-based permissions in CTF? Well,
you should know the CTF tools that path-based permissions are enforced
on. Sure Subversion access is a given but here is the full list of CTF
tooling that path-based permissions impact the access of:

* Subversion access

* Source code browsing (This includes the enablement/display of the
"Source Code" toolbar button, the listing of the repositories when
the "Source Code" button is clicked and the actual content rendered
when you click a repository and start browsing its content.)

* Commit viewer (Much like the source code browsing, when you view
commit objects in the Commit Viewer, the content rendered depends on
your access permissions.)

* Repository monitoring

Well, that pretty much sums up path-based permissions in CTF. As you can
tell by the information above, path-based permissions are a very simple
yet very powerful way to restrict access to your source code and the CTF
tooling related to source code. If you have any question about path-based
permissions or anything in CollabNet TeamForge, please visit our
community site for mailing lists, forums, articles and help
documentation. [Less]

Subversion Path-Based Permissions in CollabNet TeamForge

Posted 3 months ago by Jeremy Whitlock

Subversion Path-Based Permissions in CollabNet TeamForge

Posted 3 months ago by Jeremy Whitlock

TortoiseSVN 1.6.5 released

Posted 3 months ago by nob...@example.com (Stefan)

TortoiseSVN 1.6.5 has been released.

This is a bugfix release, which also contains an updated version of the
neon library which adresses the following security fixes:
CVE-2009-2473
CVE-2009-2474

read more

Subversion 1.6.5 Released

Posted 3 months ago

I'm happy to announce Subversion 1.6.5, available ... [More] from:

http://subversion.tigris.org/downloads/subversion-1.6.5.tar.bz2
http://subversion.tigris.org/downloads/subversion-1.6.5.tar.gz
http://subversion.tigris.org/downloads/subversion-1.6.5.zip
http://subversion.tigris.org/downloads/subversion-deps-1.6.5.tar.bz2
http://subversion.tigris.org/downloads/subversion-deps-1.6.5.tar.gz
http://subversion.tigris.org/downloads/subversion-deps-1.6.5.zip

There are two test failures when running 'make check-swig-rb' on the ruby
swig bindings. These failures are due to a known defect in the tests. The
patch applied to Subversion's trunk in r38886 can be applied to 1.6.5 to make
the tests pass again.

The MD5 checksums are:

1a53a0e72bee0bf814f4da83a9b6a636 subversion-1.6.5.tar.bz2
1aa6819d0834fad6f5970e25f79e6731 subversion-1.6.5.tar.gz
e447511cd01b0417a283e0647335fec9 subversion-1.6.5.zip
8272316e1670d4d2bea451411e438bde subversion-deps-1.6.5.tar.bz2
988d6c1535c30c72ffa57b80360afcb1 subversion-deps-1.6.5.tar.gz
0758f11f958091e1e740747156d7de6c subversion-deps-1.6.5.zip

The SHA1 checksums are:

c575c5facf972e501049ad47a9be05c5cf228388 subversion-1.6.5.tar.bz2
ea3a18443f4afcb84e66b48c0ba2af16ada4d25a subversion-1.6.5.tar.gz
442b93e31fef876c678cf2e4f3d66a80670ee330 subversion-1.6.5.zip
8a0a6f225118f94bd27aa17e30bf9ac5bd75e3cf subversion-deps-1.6.5.tar.bz2
27162103785e12ee2be88544bcec0695829c922d subversion-deps-1.6.5.tar.gz
4f8c2bb4770b30b927fdd1c29f06fd2c4620bfe5 subversion-deps-1.6.5.zip

PGP Signatures are available at:

http://subversion.tigris.org/downloads/subversion-1.6.5.tar.bz2.asc
http://subversion.tigris.org/downloads/subversion-1.6.5.tar.gz.asc
http://subversion.tigris.org/downloads/subversion-1.6.5.zip.asc
http://subversion.tigris.org/downloads/subversion-deps-1.6.5.tar.bz2.asc
http://subversion.tigris.org/downloads/subversion-deps-1.6.5.tar.gz.asc
http://subversion.tigris.org/downloads/subversion-deps-1.6.5.zip.asc

For this release, the following people have provided PGP signatures:

Senthil Kumaran S [1024D/6CCD4038] with fingerprint:
8035 16A5 1D6E 50E2 1ECD DE56 F68D 46FB 6CCD 4038
C. Michael Pilato [1024D/1706FD6E] with fingerprint:
20BF 14DC F02F 2730 7EA4 C7BB A241 06A9 1706 FD6E
Paul T. Burba [1024D/53FCDC55] with fingerprint:
E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55
Julian Foad [1024D/353E25BC] with fingerprint:
6604 5A4B 43BC F994 7777 5728 351F 33E4 353E 25BC
Blair Zajac [1024D/DA561D91] with fingerprint:
3FAE C7E1 ADE8 572F 613C F086 C572 2326 DA56 1D91
Arfrever Frehtes Taifersar Arahesis [1024D/E06AFE3E] with fingerprint:
17D9 DFDA EC0F E896 428A D821 2041 9549 E06A FE3E
Stefan Sperling [1024D/F59D25F0] with fingerprint:
B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0
Mark Phippard [1024D/035A96A9] with fingerprint:
D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9
Hyrum K. Wright [1024D/4E24517C] with fingerprint:
3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C
Bert Huijben [1024D/9821F7B2] with fingerprint:
2017 F51A 2572 0E78 8827 5329 FCFD 6305 9821 F7B2

Release notes for the 1.6.x release series may be found at:

http://subversion.tigris.org/svn_1.6_releasenotes.html

You can find the list of changes between 1.6.5 and earlier versions at:

http://svn.collab.net/repos/svn/tags/1.6.5/CHANGES [Less]

Git User Survey 2009 is now available

Posted 4 months ago by nob...@example.com (Ashley Russell)

Git is an open source, distributed version control system designed to
handle small and large projects with speed and efficiency.

Every Git clone is a

TortoiseSVN 1.6.4 released

Posted 4 months ago by nob...@example.com (Stefan)

TortoiseSVN 1.6.4 has been released.

This is a security release, addressing the issue described at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-2411.

read more