Savannah Administration - News: Access to Development CVS Trees Restored

Access to Development CVS Trees Restored

Item posted by Bradley M. Kuhn <bkuhn> on Tue 23 Dec 2003 12:49:26 AM UTC.

A GPG-signed text file of this statement is available at:

   http://savannah.gnu.org/statements/trees-available.txt.asc

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Savannah is again a running and networked system, albeit with most
features turned off.  We have reinstalled the operating system on
completely new hardware and rolled out the new system.

Currently, we are providing only anonymous access to two separate CVS
trees via SSHv2:

   (0) The CVS trees from 16 September 2003, which are available via:

         :ext:anoncvs@subversions.gnu.org:/cvs-2003-09-16/<PROJECT>

   (1) The CVS trees as they were when we brought the system down, which
       are available via:

         :ext:anoncvs@subversions.gnu.org:/cvs-latest/<PROJECT>

Note that these CVS trees in (1) are unaudited and require vetting to
ensure that no malicious code has been inserted.  Note also that both
trees are available via anonymous access only; they will not function if
you attempt to authenticate in the usual way with your old savannah
account.

For example, to check out the CVS module "foo" in the Savannah project
of the same name, as it existed in the Savannah CVS tree when we
brought the system down, you would need to use the following commands:

  export CVS_RSH="ssh"
  cvs -d:ext:anoncvs@subversions.gnu.org:/cvs-latest/foo co foo

If you already have a subversions.gnu.org entry in your ~/.ssh/config
file with a "Protocol 1" line, you will need to change it to "Protocol
2".

The SSHv2 public key fingerprints for the machine hosting the cvs
trees are:

  RSA: 1024 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5
  DSA: 1024 4d:c8:dc:9a:99:96:ae:cc:ce:d3:2b:b0:a3:a4:95:a5


We cannot yet provide access to additional Savannah features,
including CVS commit access and the web interface and tools.  We are
currently auditing the Savannah source code and the surrounding CVS
tools to ensure that they have no security problems that can be
exploited to give local user shell access.  Given the advent of many
local-user-exploitable security problems, we want to verify that shell
access cannot be acquired through any of Savannah's interfaces.


Meanwhile, we encourage all developers to audit their packages to
verify that no malicious code has been inserted into their packages'
source.  To assist developers in these audits, we are working at top
priority on the following three projects:

   (a) We are running an automated comparison between the trusted 16
       September 2003 CVS trees against the current trees.  This audit
       will verify that no malicious code was inserted into versions
       of the software on or before 16 September 2003.

   (b) We are generating human-readable difference sets that will show
       all changes made since 16 September 2003.  We will mail these
       sets to the developers of each package so that they can audit
       the changes.

   (c) For high-profile packages that have particular security
       implications, we will independently audit the difference sets
       ourselves.  If you as a developer feel that your package
       warrants such a special audit and would like our assistance in
       doing so, please contact <savannah-compromise@gnu.org>.

We realize that developers may already use processes of their own to
verify changes as they are made.  For example, perhaps you carefully
check the difference sets sent to you automatically by the system as
commits occur.  If you have done such parallel checks regularly, and
would like our help in using that data to expedite the new security
checks, please contact us at <savannah-compromise@gnu.org>.


We are working as quickly as we can to restore various Savannah
services, and will keep the community apprised as our progress
continues.  In the meantime, in preparation for the restoration of
Savannah services, please note the following:

   * When the user database comes back online, all Savannah users will
     need to activate their Savannah accounts anew, and upload their
     SSHv2 keys.  Users will not need to make new SSHv2 keys; we know
     of no particular security threat to Savannah if you use the same
     one.  (However, you might want to consider making new keys in
     case your own private key security has been compromised.)  SSHv1
     access will no longer be provided.

   * Upload of GNU Privacy Guard (GPG) keys as part of the account
     activation process will no longer be optional; each Savannah
     developer must have a GPG key on-file at Savannah.  Additionally,
     one email address on the key must match the email address used by
     the developer on Savannah.  If you do not yet have a GPG key, and
     plan to reactivate your savannah account, we suggest that you
     generate a GPG key soon, so that it will be ready when regular
     user access is restored.


We appreciate the assistance and cooperation of the Free Software
development community as we work through these difficulties.  We are
moving slowly so that everyone will be assured that the replacement
Savannah system is more secure than the previous system.


Sincerely,

Bradley M. Kuhn
Executive Director, Free Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/1E5j53XjJNtBs4cRAi/GAJ9iJXp9t/sjNx9b6oXxj1x9IL27IACfb7HG
Yq5u5+ppQCwNxDIzYevaY2g=
=MYYw
-----END PGP SIGNATURE-----