savannah-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-cvs] [29] typos


From: Karl Berry Test
Subject: [Savannah-cvs] [29] typos
Date: Mon, 02 Sep 2013 23:46:06 +0000

Revision: 29
          http://svn.sv.gnu.org/viewvc/?view=rev&root=administration&revision=29
Author:   karltest
Date:     2013-09-02 23:46:05 +0000 (Mon, 02 Sep 2013)
Log Message:
-----------
typos

Modified Paths:
--------------
    trunk/sviki/AccessToCVSROOT.mdwn

Modified: trunk/sviki/AccessToCVSROOT.mdwn
===================================================================
--- trunk/sviki/AccessToCVSROOT.mdwn    2013-09-02 23:41:26 UTC (rev 28)
+++ trunk/sviki/AccessToCVSROOT.mdwn    2013-09-02 23:46:05 UTC (rev 29)
@@ -1,28 +1,24 @@
-We do not provide write access to CVSROOT in the CVS repositories for
-the following reason:
+We do not provide write access to CVSROOT in the CVS repositories because:
 
 -   CVSROOT permits server-side *hooks*, which means essentially giving
     shell access. We do not want to provide shell access at Savannah
     -   so that nasty people cannot run arbitrary commands (DoS,
         exploits...)
     -   so that the CVS repository cannot be damaged, either
-        intentionnaly or by mistake (the repository can only be modified
+        intentionally or by mistake (the repository can only be modified
         through `cvs server`)
 
 -   You can trick CVS pserver into becoming any user you want, using
     CVSROOT/config and CVSROOT/passwd. This is a security issue that we
     want to avoid.
 
-FAQ
----
-
 ### Question: SF provides write access to CVSROOT, how comes you don't?
 
-**A:** Note that you still do not have direct shell access to
-cvs.sf.net. You can bypass this restriction through CVSROOT hooks but
+**A:** Note that you still do not have direct shell access 
+at SF. You can bypass this restriction through CVSROOT hooks but
 that's still a risk for your repository integrity (a bug in a script of
 yours could corrupt your CVS history). We don't know how/if they protect
-against misuing `config` and `password` though - technically you could
+against miusing `config` and `password` though - technically you could
 commit as another system user that way. We would be interested in more
 information on that point.
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]