[mapserver-commits] r8143 - trunk/docs/development/rfc

svn at osgeo.org svn at osgeo.org
Sun Nov 30 14:38:44 EST 2008


Author: hobu
Date: 2008-11-30 14:38:44 -0500 (Sun, 30 Nov 2008)
New Revision: 8143

Modified:
   trunk/docs/development/rfc/ms-rfc-14.txt
   trunk/docs/development/rfc/ms-rfc-15.txt
   trunk/docs/development/rfc/ms-rfc-16.txt
   trunk/docs/development/rfc/ms-rfc-18.txt
   trunk/docs/development/rfc/ms-rfc-19.txt
Log:
Styling, break at 80, formatting

Modified: trunk/docs/development/rfc/ms-rfc-14.txt
===================================================================
--- trunk/docs/development/rfc/ms-rfc-14.txt	2008-11-30 19:30:33 UTC (rev 8142)
+++ trunk/docs/development/rfc/ms-rfc-14.txt	2008-11-30 19:38:44 UTC (rev 8143)
@@ -94,4 +94,4 @@
 
 Passed
 
-.. _1547: http://trac.osgeo.org/mapserver/tickets/1547
\ No newline at end of file
+.. _1547: http://trac.osgeo.org/mapserver/ticket/1547
\ No newline at end of file

Modified: trunk/docs/development/rfc/ms-rfc-15.txt
===================================================================
--- trunk/docs/development/rfc/ms-rfc-15.txt	2008-11-30 19:30:33 UTC (rev 8142)
+++ trunk/docs/development/rfc/ms-rfc-15.txt	2008-11-30 19:38:44 UTC (rev 8143)
@@ -568,7 +568,7 @@
 
 Bug 1764_
  
-.. _1764: http://trac.osgeo.org/mapserver/tickets/1764
+.. _1764: http://trac.osgeo.org/mapserver/ticket/1764
 
 
 Voting history

Modified: trunk/docs/development/rfc/ms-rfc-16.txt
===================================================================
--- trunk/docs/development/rfc/ms-rfc-16.txt	2008-11-30 19:30:33 UTC (rev 8142)
+++ trunk/docs/development/rfc/ms-rfc-16.txt	2008-11-30 19:38:44 UTC (rev 8143)
@@ -9,7 +9,7 @@
 :Contact: warmerdam at pobox.com
 :Last Edited: May 22, 2006
 :Status: adopted and implemented
-:Version: MapServer 5.0
+:Version: MapServer 4.10
 
 Purpose
 --------
@@ -306,7 +306,7 @@
 Bug ID
 ------
 
-http://trac.osgeo.org/mapserver/tickets/1788
+http://trac.osgeo.org/mapserver/ticket/1788
 
 
 Voting history

Modified: trunk/docs/development/rfc/ms-rfc-18.txt
===================================================================
--- trunk/docs/development/rfc/ms-rfc-18.txt	2008-11-30 19:30:33 UTC (rev 8142)
+++ trunk/docs/development/rfc/ms-rfc-18.txt	2008-11-30 19:38:44 UTC (rev 8143)
@@ -14,19 +14,24 @@
 Overview
 --------
 
-This proposal provides a mechanism to protect database connection passwords used inside mapfiles by encrypting them instead of including them in plain text.
+This proposal provides a mechanism to protect database connection passwords 
+used inside :ref:`mapfiles <mapfile>` by encrypting them instead of including 
+them in plain text.
 
 Technical Solution
 ------------------
 
-MapServer will be extended to allow the use of encrypted passwords as part of the CONNECTION string for the following layer types:
+MapServer will be extended to allow the use of encrypted passwords as part 
+of the CONNECTION string for the following layer types:
 
 * Oracle Spatial
 * PostGIS
 * ESRI SDE
 * OGR
 
-The Tiny Encryption Algorithm (TEA) at  http://www.simonshepherd.supanet.com/tea.htm will be used for the encryption/decryption functions.
+The Tiny Encryption Algorithm (TEA) at 
+http://www.simonshepherd.supanet.com/tea.htm will be used for the 
+encryption/decryption functions.
 
 The implementation details follow...
 
@@ -34,9 +39,15 @@
 Encryption key
 --------------
 
-In order to safely protect the encrypted information, an encryption key will be required by this mechanism. The key will NOT be stored in the mapfile: it will be stored in a separate file on the server and should be kept in a safe area by the server administrator (especially outside of the web server's document directories). 
+In order to safely protect the encrypted information, an encryption key will 
+be required by this mechanism. The key will NOT be stored in the mapfile: it 
+will be stored in a separate file on the server and should be kept in a 
+safe area by the server administrator (especially outside of the web 
+server's document directories). 
 
-The location of the encryption key can be specified by two mechanisms, either by setting the environment variable MS_ENCRYPTION_KEY or using a CONFIG directive:
+The location of the encryption key can be specified by two mechanisms, 
+either by setting the environment variable MS_ENCRYPTION_KEY or using a 
+CONFIG directive:
 
 ::
 
@@ -45,7 +56,8 @@
 New "msencrypt" command-line utility
 ------------------------------------
 
-A "msencrypt" command-line utility will be provided to create an encryption key and to encrypt passwords (or any string) for use in a mapfile. 
+A "msencrypt" command-line utility will be provided to create an encryption 
+key and to encrypt passwords (or any string) for use in a mapfile. 
 
 To create an encryption key:
 
@@ -59,15 +71,21 @@
 
   msencrypt -key /path/to/mykey.txt <string_to_encrypt>
 
-If the MS_ENCRYPTION_KEY environment variable is set then the -key argument does not need to be specified.
+If the MS_ENCRYPTION_KEY environment variable is set then the -key 
+argument does not need to be specified.
 
 
 Encoding of encrypted strings
 -----------------------------
 
-Since the result of encryption is binary data that is not suitable for inclusion directly in a MapServer mapfile, hex encoding will be used for the encrypted strings in the mapfile as well as for storing the encryption key to disk.
+Since the result of encryption is binary data that is not suitable for 
+inclusion directly in a MapServer mapfile, hex encoding will be used for the 
+encrypted strings in the mapfile as well as for storing the encryption 
+key to disk.
 
-The { and } characters will be used as delimiters for encrypted strings inside database CONNECTIONs. This will allow the use of either plain text or encrypted passwords in mapfiles without any backwards compatibility issues.
+The { and } characters will be used as delimiters for encrypted strings 
+inside database CONNECTIONs. This will allow the use of either plain text or 
+encrypted passwords in mapfiles without any backwards compatibility issues.
 
 e.g. 
 
@@ -76,9 +94,12 @@
    CONNECTIONTYPE ORACLESPATIAL
    CONNECTION "user/{MIIBugIBAAKBgQCP0Yj+Seh8==}@service"
 
-Any part of a CONNECTION string can be encrypted and not just the password. This will allow protecting other information such as login name, hostname or port numbers if necessary. 
+Any part of a CONNECTION string can be encrypted and not just the password. 
+This will allow protecting other information such as login name, hostname 
+or port numbers if necessary. 
 
-For reference, here are examples of typical connection strings for the layer types that will be affected:
+For reference, here are examples of typical connection strings for the 
+layer types that will be affected:
 
 ::
 
@@ -98,17 +119,28 @@
 Modifications to the source code
 --------------------------------
 
-A msDecryptString() function will be created, it will take a CONNECTION string as input and decrypt any encrypted component that it may find in it. This function will be called by the various msXXXLayerOpen() methods before opening the connection to the database. 
+A msDecryptString() function will be created, it will take a CONNECTION 
+string as input and decrypt any encrypted component that it may find in it. 
+This function will be called by the various msXXXLayerOpen() methods before 
+opening the connection to the database. 
 
 ::
 
  char *msDecryptString(mapObj *map, const char *string)
 
-The first time that msDecryptString() is called for a given mapfile, it will load the encryption key from the file and store the key in a new private member of the mapObj (char * encryption_key).
+The first time that msDecryptString() is called for a given mapfile, it will 
+load the encryption key from the file and store the key in a new private 
+member of the mapObj (char * encryption_key).
 
-To reduce the chances of false matches in long CONNECTION strings such as OGR VRT data sources, msDecryptString() function will look for a pair of { + }, and then verify that all chars in the block are valid hex encoding chars (0-9,A-F) before proceeding with decryption.
+To reduce the chances of false matches in long CONNECTION strings such as 
+OGR VRT data sources, msDecryptString() function will look for a pair of 
+{ + }, and then verify that all chars in the block are valid hex encoding 
+chars (0-9,A-F) before proceeding with decryption.
 
-Note that the decrypted string will never be stored in the layerObj, it will be kept local to the function that opens the connection and destroyed as soon as the function is done with it. This is to prevent exposing the decrypted information in error messages or in calls to msSaveMap().
+Note that the decrypted string will never be stored in the layerObj, it will 
+be kept local to the function that opens the connection and destroyed as 
+soon as the function is done with it. This is to prevent exposing the 
+decrypted information in error messages or in calls to msSaveMap().
 
 Files affected
 --------------
@@ -133,7 +165,7 @@
 Bug ID
 ------
 
-1792: http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1792
+1792: http://trac.osgeo.org/mapserver/ticket/1792
 
 Voting history
 --------------
@@ -145,12 +177,28 @@
 Comments from the review period
 -------------------------------
 
-* There were concerns about the use of the {...} delimiter to indicate encrypted strings inside CONNECTIONs. Since there was not a better alternative we will stick to that.
+* There were concerns about the use of the {...} delimiter to indicate 
+  encrypted strings inside CONNECTIONs. Since there was not a better 
+  alternative we will stick to that.
 
-* There was a suggestion to use an ENCRYPTION_KEY mapfile keyword instead of CONFIG MS_ENCRYPTION_KEY. Since there was no strong argument either way we decided to stick to CONFIG MS_ENCRYPTION_KEY.
+* There was a suggestion to use an ENCRYPTION_KEY mapfile keyword 
+  instead of CONFIG MS_ENCRYPTION_KEY. Since there was no strong argument 
+  either way we decided to stick to CONFIG MS_ENCRYPTION_KEY.
 
-* There was a suggestion to consider the Blowfish algorithm (http://www.schneier.com/blowfish.html) instead of TEA. The sample implementations of Blowfish would require much more work to integrate than TEA, and since TEA is public domain and so much simpler (simpler is better!), we'll stick to TEA for now and can always change the underlying algorithm at a later time if we find that TEA is too weak (which doesn't appear to be an issue).
+* There was a suggestion to consider the Blowfish algorithm 
+  (http://www.schneier.com/blowfish.html) instead of TEA. The sample 
+  implementations of Blowfish would require much more work to integrate than 
+  TEA, and since TEA is public domain and so much simpler (simpler is 
+  better!), we'll stick to TEA for now and can always change the underlying 
+  algorithm at a later time if we find that TEA is too weak (which doesn't 
+  appear to be an issue).
 
-* Will the encryption methods be made available to MapScript? No plan to do so at this time, but this could easily be added later on.
+* Will the encryption methods be made available to MapScript? No plan to do 
+  so at this time, but this could easily be added later on.
 
-* Since the user running the web server (and MapServer) needs to have permissions to read the key, any web server process or user with permissions to read the key can decrypt the passwords using a trivial program. It should be made very clear in the documentation that this is just simple obfuscation and is by no means secure and that users should not place valuable passwords in mapfiles encrypted or not. 
\ No newline at end of file
+* Since the user running the web server (and MapServer) needs to have 
+  permissions to read the key, any web server process or user with permissions 
+  to read the key can decrypt the passwords using a trivial program. It 
+  should be made very clear in the documentation that this is just simple 
+  obfuscation and is by no means secure and that users should not place 
+  valuable passwords in mapfiles encrypted or not. 
\ No newline at end of file

Modified: trunk/docs/development/rfc/ms-rfc-19.txt
===================================================================
--- trunk/docs/development/rfc/ms-rfc-19.txt	2008-11-30 19:30:33 UTC (rev 8142)
+++ trunk/docs/development/rfc/ms-rfc-19.txt	2008-11-30 19:38:44 UTC (rev 8143)
@@ -10,7 +10,12 @@
 :Status: Passed (in process)
 :Version: MapServer 5.0
 
-Description: Presently MapServer supports binding of label and style properties for a few select attributes (e.g. angle). However, it is cumbersome to add new bindings which leads to unecessarily complex structures and code that is difficult to maintain. This RFC presents ideas to bring a bit of order to that chaos and make expansion of this capability easier to achive.
+Description: Presently MapServer supports binding of label and style 
+properties for a few select attributes (e.g. angle). However, it is 
+cumbersome to add new bindings which leads to unnecessarily complex 
+structures and code that is difficult to maintain. This RFC presents ideas to 
+bring a bit of order to that chaos and make expansion of this capability 
+easier to achieve.
 
 C Structural Changes
 ~~~~~~~~~~~~~~~~~~~~
@@ -34,7 +39,9 @@
   #define MS_LABEL_BINDING_LENGTH ...
   #define MS_LABEL_BINDING_ENUM { MS_LABEL_BINDING_SIZE, MS_LABEL_BINDING_ANGLE, ... };
 
-Several elements would be removed from layerObj and styleObj. For example, angleitem, angleitemindex and similar members would be removed. styleObj's and labelObj's would each take on 2 new members:
+Several elements would be removed from layerObj and styleObj. For example, 
+angleitem, angleitemindex and similar members would be removed. 
+styleObj's and labelObj's would each take on 2 new members:
 
 ::
 
@@ -44,7 +51,8 @@
 Mapfile/MapScript Changes
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Options like SIZEITEM and ANGLEITEM would go away. Instead a more logical syntax such as:
+Options like SIZEITEM and ANGLEITEM would go away. Instead a more 
+logical syntax such as:
 
 ::
 
@@ -55,9 +63,13 @@
     SYMBOL 'square'
   END
 
-Square brackets have been used in MapServer templates and expressions to bind to attributes so they are a natural choice to denote attribute bindings in this case.
+Square brackets have been used in MapServer templates and expressions to 
+bind to attributes so they are a natural choice to denote attribute 
+bindings in this case.
 
-Similarly MapScript would loose the ability to set/get the xxxITEM properties. Instead the style and label objects would get setBinding and deleteBinding methods:
+Similarly MapScript would loose the ability to set/get the xxxITEM 
+properties. Instead the style and label objects would get setBinding 
+and deleteBinding methods:
 
 ::
 
@@ -84,28 +96,39 @@
 
 - maplabel.c => add msLabelBindAttributes();
 - maplayer.c => fix msWhichItems() to populate the binding indexes
-- mapdraw.c => remove references to the xxxITEM properties, if a style or label has bindings then call msStyleBindAttributes or msLabelBindAttributes
-- mapfile.c => fix parsing to hangle strings in addition to numbers for all supported bindings (symbols already allow this), if a binding is defined flip the hasBindings flag, remove all references to xxxITEM properties, alter style and label writing code to honor bindings as part of output
+- mapdraw.c => remove references to the xxxITEM properties, if a style or 
+  label has bindings then call msStyleBindAttributes or msLabelBindAttributes
+- mapfile.c => fix parsing to hangle strings in addition to numbers for all 
+  supported bindings (symbols already allow this), if a binding is defined 
+  flip the hasBindings flag, remove all references to xxxITEM properties, 
+  alter style and label writing code to honor bindings as part of output
 - mapcopy.c => fix style and labeling copying
-- maplexer.l/mapfile.h => remove xxxITEM defines and lexer references, and to define a new raw type (similar to MS_STRING) called MS_BINDING
-- mapscript/swiginc/style.i => add setBinding and deleteBinding methods (similar for PHP/MapScript)
+- maplexer.l/mapfile.h => remove xxxITEM defines and lexer references, and 
+  to define a new raw type (similar to MS_STRING) called MS_BINDING
+- mapscript/swiginc/style.i => add setBinding and deleteBinding methods 
+  (similar for PHP/MapScript)
 
 Testing
 ~~~~~~~
 
 - Python suite: need tests to set and delete bindings
-- MsAutoTest suite: a mapfile testing various bindings would be developed (DNR tests have one example for labels)
+- MsAutoTest suite: a mapfile testing various bindings would be
+  developed (DNR tests have one example for labels)
 
 Backwards compatabilty issues
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-This does affect a number of parameters, however they are lightly used so this is probably worth the risk. The primary risk is breaking mapfiles as opposed to scripts. Given that this will definitely break some stuff I think it is most appropriate as a 5.0 change.
+This does affect a number of parameters, however they are lightly used so 
+this is probably worth the risk. The primary risk is breaking mapfiles as 
+opposed to scripts. Given that this will definitely break some stuff I 
+think it is most appropriate as a 5.0 change.
 
 Bug ID
 ~~~~~~~~
 
-2100
+2100_
 
+.. _2100: http://trac.osgeo.org/mapserver/ticket/2100
 Voting history
 ~~~~~~~~~~~~~~~~~
 



More information about the mapserver-commits mailing list