Re: [Phpgroupware-users] Savannah Status

[Peter Neal]

Dave Hall (address@hidden) wrote:
>
>Hi all,
>
>This is an update on what is happening with Savannah.  For the original
>see http://savannah.gnu.org/statement.html
>
>Cheers
>
>Dave
>
>
>
>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:address@hidden:/cvs-2003-09-16/
>
>   (1) The CVS trees as they were when we brought the system down, which
>       are available via:
>
>         :ext:address@hidden:/cvs-latest/
>
>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:address@hidden:/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 <address@hidden>.
>
>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 <address@hidden>.
>
>
>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
>