web-erp-developers — Discussion on development of webERP

Re: [WebERP-developers] New branch working for DB_query parameterisation work

[icedlava <ice...@gm...>]

Hi Phil,

For reference here on the list, I have committed the code as requested.
You have updated the original function I committed which changes and I 
did make a point to you in email that these changes will not work.

As per your request I've forwarded your response to the mailing list but 
posting here for completeness in this thread.

Note that the latest changes will not work because it is not the fact 
that the query is prepared, it is the fact the query is paramaterized 
that makes it secure.
Parameterized queries, done in the way I did it work because the query 
string and the variables are sent separately to the database server and 
only there are put together.

The changes you made are no different to the original DB_query that 
mysql_db_escapes the data - except there is more code and separated 
parameters. The key issue:

In your new code:
$result=mysqli_query($Conn, $SQLString); is the problem. No different to 
prior old DB_query.

The query is already 'put together' with query and variables before it 
goes to the server. That is the insecure nature of it and why I changed 
it.

Appreciate your work and thought on it so far.

Cheers,




On 25 Mar 2014, at 17:10, Phil Daintree wrote:

> I've made up a new branch so we can mess with this a bit
>
> svn checkout --username=XXXXX
> svn+ssh://XX...@sv.../p/web-erp/code/branches/working
> yourworkingcopy
>
> where XXXXX is your sourceforge login.
>
> Jo, if you commit the code you want for the new DB_query - and I 
> propose
> we should keep it the same name - but with a new optional parameter 
> for
> the array of parameters.
>
>
> -- 
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890
> http://www.logicworks.co.nz
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and 
> their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[WebERP-developers] Fwd: mysqli_real_escape_string() vs prepare/execute parameterisied queries

[icedlava <ice...@gm...>]

Forwarding message from Phil. This was sent in response to my email 
about a commit to the new branch on DB_query changes.
Phil has requested to continue discussion on list in response to email 
(also below).

Message content from Phil :
-------------------------------------------------------------

Ha!! After all that, I forgot to mysqli_real_escape_string() the 
parameters ... forgive my dementia :-)

The guts of my code for DB_query() follows:

function DB_query ($SQL,
+					&$Conn,
+					$ErrorMessage='',
+					$DebugMessage= '',
+					$Transaction=false,
+					$TrapErrors=true,
+					$Parameters=array()){
+
+	global $debug;
+	global $PathPrefix;
+
+	$SQLChunks = explode('?',$SQL);
+	if (count($SQLChunks)-1 != count($Parameters)){
+		prnMsg(_('The number of parameters provided with this SQL did not 
equal the number of parameters expected by the SQL string'),'error');
+		if ($debug==1){
+			prnMsg($DebugMessage. '<br />' . $SQL . '<br />','error',_('Database 
SQL Failure'));
+			print_r($Parameters);
+			print_r($SQLChunks);
+		}
+		include($PathPrefix . 'includes/footer.inc');
+		exit;
+	}
+	$SQLString ='';
+	$i=0;
+	foreach ($SQLChunks as $SQLChunk) {
+		if (isset($Parameters[$i])){
+			$SQLString .= $SQLChunk . " '" . mysqli_real_escape_string($Conn, 
$Parameters[$i]) . "'";
+		} else {
+			$SQLString .= $SQLChunk;
+		}
+		$i++;
+	}
+	/*
+	 * if (mb_strrpos($SQL,'?')==mb_strlen($SQL)){
+		$SQLChunks[]=''; //append an empty string so the count of the arrays 
match
+	}
+	*/
+	
+	$result=mysqli_query($Conn, $SQLString);
+


.... snipped out all the guff for audit trail last insert id etc

return $result;
+
+}


The reason why I had a go at this was firstly because my understanding 
of prepared statements is that there is some server compilation and 
query plan cached so that multiple runs of the query with different 
parameters will be quicker - this is not how we are using mysql. There 
are certain limited examples of where we could use this approach 
efficiently. Security must come first too.

I accept we need to escape parameters going to the DB differently to 
parameters to be displayed in html... this is the nub of the problem we 
are trying to solve here - whilst maintaining the protection against SQL 
injection attacks. We have had secunia and every other security outfit 
all over us and if there was some vulnerability then it would be public 
knowledge. So what we have works - and what we are doing is quoting all 
SQL parameters and mysqli_real_escape_string() all parameters - as well 
as all $_POST and $_GET output to html - which we need to treat 
differently.

The link you sent me

http://stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection/12202218#12202218


Wrapping Up

If you:

* Use Modern Versions of MySQL (late 5.1, all 5.5, 5.6, etc)

*OR*

* Use|mysql_set_charset()|/|$mysqli->set_charset()|

*OR*

* Use the DSN charset parameter to PDO

*OR*

* Don't use GBK or BIG-5 (you only use UTF-8 / UCS-2 / Latin-1 / ASCII)

You're 100% safe.


So we use:

webERP/includes/ConnectDB_mysqli.inc:mysqli_set_charset($db, 'utf8');

and mysql version >= 5.1

Safe examples:

Because the server's expecting UTF-8...

|mysql_set_charset('GBK');
$var=  mysql_real_escape_string(chr(0xbf)  .  chr(0x27)  .  " OR 1=1 
/*");
$query=  "SELECT * FROM test WHERE name = '$var' LIMIT 1";|


This seems to corroborate my understanding?

However, I note the preference for parameterising queries in
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
although it does say that escaping input is a valid method ... although 
a bit scathing of this approach, without really explaining why.

I have not found an explanation of why the data type of the parameter is 
important to the mysqli_real_escape_string
However, I have found a number of places that concur that parameterised 
queries are the ultimate defence vs injection.


Using ? in a parameter is no problem - it will be escaped. If there is a 
? somewhere else - other than as a parameter marker in the SQL would be 
a problem but this would not be valid SQL anyway.

Why can't we have a $DBType = 'PDO';

and an

includes/DB_Connect_PDO.inc

containing the necessary abstraction functions?

I think what I did (with an important addition of 
mysql_real_escape_string($Parameters[$i])) would work and be quicker and 
more readable that the bindvars solution - but I will have another play 
with the bindvars code you made up and see if I can get my head around 
it.

Thanks for your patience with me Jo :-)

Again - please do forward to the list if you wish - personally I prefer 
all webERP related discussion to be on list - and other stuff WAY OFF 
list!!

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 26/03/14 23:13, icedlava wrote:
> Hi Phil,
>
> Sent this to users.sf.net but it got rejected. Sending again.
>
> Forwarded message:
>
> From: icedlava <ice...@gm...>
> To: dai...@us...
> Subject: Re: [Web-erp-svn] SF.net SVN: web-erp:[6641] branches/working
> Date: Wed, 26 Mar 2014 20:09:39 +1030
>
> Hi Phil,
>
> Thanks for the work on this so far.
>
> I do have a problem with the new DB_query you committed- how does it 
> prevent the SQL injection and how does it escape the data in a 
> contextual way - e.g. discriminate between string and integer which 
> are the main ones?
>
> As it stands it seems to make more work using parameters passed in but 
> ends up just putting a query string back together again resulting in 
> no advantage.
>
> Or I might be missing something?
>
> Apologies if I sound critical, just trying to work out what your 
> intent is here.
>
> Cheers,
>> Jo
>>
>> On 26 Mar 2014, at 17:03, dai...@us... wrote:
>>
>> Revision: 6641
>> http://sourceforge.net/p/web-erp/reponame/6641
>> Author:   daintree
>> Date:     2014-03-26 06:33:38 +0000 (Wed, 26 Mar 2014)
>> Log Message:
>> -----------
>> DB_query alternative?
>>
>> Modified Paths:
>> --------------
>> branches/working/AccountGroups.php
>> branches/working/AddCustomerContacts.php
>> branches/working/includes/ConnectDB_mysqli.inc
>> branches/working/includes/UserLogin.php
>>
>> Modified: branches/working/AccountGroups.php
>> ===================================================================
>> --- branches/working/AccountGroups.php	2014-03-25 17:13:55 UTC (rev 
>> 6640)
>> +++ branches/working/AccountGroups.php	2014-03-26 06:33:38 UTC (rev 
>> 6641)
>> @@ -23,9 +23,9 @@
>> 	do {
>> 		$sql = "SELECT parentgroupname
>> 				FROM accountgroups
>> -				WHERE groupname='" . $GroupName ."'";
>> -
>> -		$result = DB_query($sql,$db,$ErrMsg,$DbgMsg);
>> +				WHERE groupname=?";
>> +		$Parameters = array($GroupName);
>> +		$result = 
>> DB_query($sql,$db,$ErrMsg,$DbgMsg,'',false,true,$Parameters);
>> 		$myrow = DB_fetch_row($result);
>> 		if ($ParentGroupName == $myrow[0]){
>> 			return true;
>> @@ -46,10 +46,11 @@
>> $Errors = array();
>>
>> if (isset($_POST['MoveGroup'])) {
>> -	$sql="UPDATE chartmaster SET group_='" . 
>> $_POST['DestinyAccountGroup'] . "' WHERE group_='" . 
>> $_POST['OriginalAccountGroup'] . "'";
>> +	$sql="UPDATE chartmaster SET group_=? WHERE group_=?";
>> +	$Parameters = array($_POST['DestinyAccountGroup'], 
>> $_POST['OriginalAccountGroup']);
>> 	$ErrMsg = _('An error occurred in moving the account group');
>> 	$DbgMsg = _('The SQL that was used to move the account group was');
>> -	$result = DB_query($sql,$db,$ErrMsg,$DbgMsg);
>> +	$result = DB_query($sql,$db,$ErrMsg,$DbgMsg,false,true, 
>> $Parameters);
>> 	echo '<div class="centre"><a href="' . 
>> htmlspecialchars($_SERVER['PHP_SELF'], ENT_QUOTES, 'UTF-8') . '">' . 
>> _('Review Account Groups') . '</a></div>';
>> 	prnMsg( _('All accounts in the account group:') . ' ' . 
>> $_POST['OriginalAccountGroup'] . ' ' . _('have been changed to the 
>> account group:') . ' ' . $_POST['DestinyAccountGroup'],'success');
>> }
>> @@ -68,12 +69,12 @@
>>
>> 	$sql="SELECT count(groupname)
>> 			FROM accountgroups
>> -			WHERE groupname='" . $_POST['GroupName'] . "'";
>> -
>> +			WHERE groupname=? ";
>> +	$Parameters=array($_POST['GroupName']);
>> 	$DbgMsg = _('The SQL that was used to retrieve the information 
>> was');
>> 	$ErrMsg = _('Could not check whether the group exists because');
>>
>> -	$result=DB_query($sql, $db,$ErrMsg,$DbgMsg);
>> +	$result=DB_query($sql, $db,$ErrMsg,$DbgMsg,false,true,$Parameters);
>> 	$myrow=DB_fetch_row($result);
>>
>> 	if ($myrow[0] != 0 AND $_POST['SelectedAccountGroup'] == '') {
>> @@ -105,12 +106,12 @@
>> 						sequenceintb,
>> 						sectioninaccounts
>> 					FROM accountgroups
>> -					WHERE groupname='" . $_POST['ParentGroupName'] . "'";
>> -
>> +					WHERE groupname=?";
>> +			$Parameters = array($_POST['ParentGroupName']);
>> 			$DbgMsg = _('The SQL that was used to retrieve the information 
>> was');
>> 			$ErrMsg = _('Could not check whether the group is recursive 
>> because');
>>
>> -			$result = DB_query($sql,$db,$ErrMsg,$DbgMsg);
>> +			$result = 
>> DB_query($sql,$db,$ErrMsg,$DbgMsg,false,true,$Parameters);
>>
>> 			$ParentGroupRow = DB_fetch_array($result);
>> 			$_POST['SequenceInTB'] = $ParentGroupRow['sequenceintb'];
>> @@ -147,31 +148,38 @@
>> 			DB_IgnoreForeignKeys($db);
>>
>> 			$sql = "UPDATE chartmaster
>> -					SET group_='" . $_POST['GroupName'] . "'
>> -					WHERE group_='" . $_POST['SelectedAccountGroup'] . "'";
>> +					SET group_=?
>> +					WHERE group_=?";
>> +			$Parameters = array($_POST['GroupName'],
>> +								$_POST['SelectedAccountGroup']);
>> 			$ErrMsg = _('An error occurred in renaming the account group');
>> 			$DbgMsg = _('The SQL that was used to rename the account group 
>> was');
>>
>> -			$result = DB_query($sql, $db, $ErrMsg, $DbgMsg);
>> +			$result = DB_query($sql, $db, $ErrMsg, 
>> $DbgMsg,false,true,$Parameters);
>>
>> 			$sql = "UPDATE accountgroups
>> -					SET parentgroupname='" . $_POST['GroupName'] . "'
>> -					WHERE parentgroupname='" . $_POST['SelectedAccountGroup'] . 
>> "'";
>> +					SET parentgroupname=?
>> +					WHERE parentgroupname=?";
>>
>> -			$result = DB_query($sql, $db, $ErrMsg, $DbgMsg);
>> +			$result = DB_query($sql, $db, $ErrMsg, 
>> $DbgMsg,false,true,$Parameters);
>>
>> 			DB_ReinstateForeignKeys($db);
>> 		}
>>
>> -		$sql = "UPDATE accountgroups SET groupname='" . 
>> $_POST['GroupName'] . "',
>> -										sectioninaccounts='" . $_POST['SectionInAccounts'] . "',
>> -										pandl='" . $_POST['PandL'] . "',
>> -										sequenceintb='" . $_POST['SequenceInTB'] . "',
>> -										parentgroupname='" . $_POST['ParentGroupName'] . "'
>> -									WHERE groupname = '" . $_POST['SelectedAccountGroup'] . 
>> "'";
>> +		$sql = "UPDATE accountgroups SET groupname=?,
>> +										sectioninaccounts=?,
>> +										pandl=?,
>> +										sequenceintb=?,
>> +										parentgroupname=?
>> +									WHERE groupname=?";
>> 		$ErrMsg = _('An error occurred in updating the account group');
>> 		$DbgMsg = _('The SQL that was used to update the account group 
>> was');
>> -
>> +		$Parameters = array($_POST['GroupName'],
>> +							$_POST['SectionInAccounts'],
>> +							$_POST['PandL'],
>> +							$_POST['SequenceInTB'],
>> +							$_POST['ParentGroupName'],
>> +							$_POST['SelectedAccountGroup']);
>> 		$msg = _('Record Updated');
>> 	} elseif ($InputError !=1) {
>>
>> @@ -182,47 +190,52 @@
>> 											sequenceintb,
>> 											pandl,
>> 											parentgroupname
>> -										) VALUES (
>> -											'" . $_POST['GroupName'] . "',
>> -											'" . $_POST['SectionInAccounts'] . "',
>> -											'" . $_POST['SequenceInTB'] . "',
>> -											'" . $_POST['PandL'] . "',
>> -											'" . $_POST['ParentGroupName'] . "')";
>> +										) VALUES (	?,
>> +													?,
>> +													?,
>> +													?,
>> +													?)";
>> 		$ErrMsg = _('An error occurred in inserting the account group');
>> 		$DbgMsg = _('The SQL that was used to insert the account group 
>> was');
>> +		$Parameters = array($_POST['GroupName'],
>> +							$_POST['SectionInAccounts'],
>> +							$_POST['SequenceInTB'],
>> +							$_POST['PandL'],
>> +							$_POST['ParentGroupName']);
>> 		$msg = _('Record inserted');
>> 	}
>>
>> 	if ($InputError!=1){
>> 		//run the SQL from either of the above possibilites
>> -		$result = DB_query($sql,$db,$ErrMsg,$DbgMsg);
>> +		$result = DB_query($sql, $db, $ErrMsg, 
>> $DbgMsg,false,true,$Parameters);
>> 		prnMsg($msg,'success');
>> 		unset ($_POST['SelectedAccountGroup']);
>> 		unset ($_POST['GroupName']);
>> 		unset ($_POST['SequenceInTB']);
>> 	}
>> -} elseif (isset($_GET['delete'])) {
>> +} elseif (isset($_GET['Delete'])) {
>> //the link to delete a selected record was clicked instead of the 
>> submit button
>>
>> // PREVENT DELETES IF DEPENDENT RECORDS IN 'ChartMaster'
>>
>> -	$sql= "SELECT COUNT(group_) AS groups FROM chartmaster WHERE 
>> chartmaster.group_='" . $_GET['SelectedAccountGroup'] . "'";
>> +	$sql= "SELECT COUNT(group_) AS groups FROM chartmaster WHERE 
>> chartmaster.group_=?";
>> 	$ErrMsg = _('An error occurred in retrieving the group information 
>> from chartmaster');
>> 	$DbgMsg = _('The SQL that was used to retrieve the information 
>> was');
>> -	$result = DB_query($sql,$db,$ErrMsg,$DbgMsg);
>> +	$Parameters = array($_GET['SelectedAccountGroup']);
>> +	
>> +	$result = DB_query($sql, $db, $ErrMsg, 
>> $DbgMsg,false,true,$Parameters);
>> 	$myrow = DB_fetch_array($result);
>> 	if ($myrow['groups']>0) {
>> 		prnMsg( _('Cannot delete this account group because general ledger 
>> accounts have been created using this group'),'warn');
>> 		echo '<br />' . _('There are') . ' ' . $myrow['groups'] . ' ' . 
>> _('general ledger accounts that refer to this account group');
>> -		echo '<br /><form method="post" id="AccountGroups" action="' . 
>> htmlspecialchars($_SERVER['PHP_SELF'], ENT_QUOTES, 'UTF-8') . '">';
>> +		echo '<br /><form method="post" id="AccountGroups" action="' . 
>> htmlspecialchars($_SERVER['PHP_SELF'], ENT_QUOTES, 'UTF-8') . '">
>> +				<input type="hidden" name="FormID" value="' . 
>> $_SESSION['FormID'] . '" />
>> +				<table class="selection">
>> +					<input  type="hidden" name="OriginalAccountGroup" value="' . 
>> $_GET['SelectedAccountGroup'] . '" />
>> +					<tr>
>> +						<td>' . _('Parent Group') . ':' . '</td>
>> +						<td><select tabindex="2" ' . 
>> (in_array('ParentGroupName',$Errors) ?  'class="selecterror"' : '' ) 
>> . '  name="DestinyAccountGroup">';
>>
>> -		echo '<input type="hidden" name="FormID" value="' . 
>> $_SESSION['FormID'] . '" />';
>> -		echo '<table class="selection">';
>> -		echo '<input  type="hidden" name="OriginalAccountGroup" value="' . 
>> $_GET['SelectedAccountGroup'] . '" />';
>> -		echo '<tr>
>> -				<td>' . _('Parent Group') . ':' . '</td>
>> -				<td><select tabindex="2" ' . 
>> (in_array('ParentGroupName',$Errors) ?  'class="selecterror"' : '' ) 
>> . '  name="DestinyAccountGroup">';
>> -
>> 		$sql = "SELECT groupname FROM accountgroups";
>> 		$GroupResult = DB_query($sql, $db,$ErrMsg,$DbgMsg);
>> 		while ($GroupRow = DB_fetch_array($GroupResult) ) {
>> @@ -233,28 +246,30 @@
>> 				echo '<option value="'.htmlentities($GroupRow['groupname'], 
>> ENT_QUOTES,'UTF-8').'">' .htmlentities($GroupRow['groupname'], 
>> ENT_QUOTES,'UTF-8') . '</option>';
>> 			}
>> 		}
>> -		echo '</select>';
>> -		echo '</td></tr>';
>> -		echo '<tr>
>> -				<td colspan="2"><div class="centre"><input tabindex="6" 
>> type="submit" name="MoveGroup" value="' . _('Move Group') . '" 
>> /></div></td>
>> -		  </tr>
>> -		  </table>';
>> +		echo '</select></td>
>> +				</tr>
>> +				<tr>
>> +					<td colspan="2"><div class="centre"><input tabindex="6" 
>> type="submit" name="MoveGroup" value="' . _('Move Group') . '" 
>> /></div></td>
>> +				</tr>
>> +			</table>';
>>
>> 	} else {
>> -		$sql = "SELECT COUNT(groupname) groupnames FROM accountgroups 
>> WHERE parentgroupname = '" . $_GET['SelectedAccountGroup'] . "'";
>> +		$sql = "SELECT COUNT(groupname) groupnames FROM accountgroups 
>> WHERE parentgroupname=?";
>> 		$ErrMsg = _('An error occurred in retrieving the parent group 
>> information');
>> 		$DbgMsg = _('The SQL that was used to retrieve the information 
>> was');
>> -		$result = DB_query($sql,$db,$ErrMsg,$DbgMsg);
>> +		$Parameters = array($_GET['SelectedAccountGroup']);
>> +		$result = DB_query($sql, $db, $ErrMsg, 
>> $DbgMsg,false,true,$Parameters);
>> +	
>> 		$myrow = DB_fetch_array($result);
>> 		if ($myrow['groupnames']>0) {
>> 			prnMsg( _('Cannot delete this account group because it is a parent 
>> account group of other account group(s)'),'warn');
>> 			echo '<br />' . _('There are') . ' ' . $myrow['groupnames'] . ' ' 
>> . _('account groups that have this group as its/there parent account 
>> group');
>> -
>> 		} else {
>> -			$sql="DELETE FROM accountgroups WHERE groupname='" . 
>> $_GET['SelectedAccountGroup'] . "'";
>> +			$sql="DELETE FROM accountgroups WHERE groupname=?";
>> 			$ErrMsg = _('An error occurred in deleting the account group');
>> 			$DbgMsg = _('The SQL that was used to delete the account group 
>> was');
>> -			$result = DB_query($sql,$db,$ErrMsg,$DbgMsg);
>> +			$Parameters = array($_GET['SelectedAccountGroup']);
>> +			$result = DB_query($sql, $db, $ErrMsg, 
>> $DbgMsg,false,true,$Parameters);
>> 			prnMsg( $_GET['SelectedAccountGroup'] . ' ' . _('group has been 
>> deleted') . '!','success');
>> 		}
>>
>> @@ -323,7 +338,7 @@
>> 			<td>' . $PandLText . '</td>
>> 			<td>' . $myrow['parentgroupname'] . '</td>';
>> 		echo '<td><a href="' . htmlspecialchars($_SERVER['PHP_SELF'] . 
>> '?SelectedAccountGroup=' . urlencode($myrow['groupname']), 
>> ENT_QUOTES,'UTF-8') . '">' . _('Edit') . '</a></td>';
>> -		echo '<td><a href="' . htmlspecialchars($_SERVER['PHP_SELF'] . 
>> '?SelectedAccountGroup=' . urlencode($myrow['groupname']), 
>> ENT_QUOTES,'UTF-8') . '&amp;delete=1" onclick="return confirm(\'' . 
>> _('Are you sure you wish to delete this account group?') . '\');">' . 
>> _('Delete')  . '</a></td></tr>';
>> +		echo '<td><a href="' . htmlspecialchars($_SERVER['PHP_SELF'] . 
>> '?SelectedAccountGroup=' . urlencode($myrow['groupname']), 
>> ENT_QUOTES,'UTF-8') . '&amp;Delete=1" onclick="return confirm(\'' . 
>> _('Are you sure you wish to delete this account group?') . '\');">' . 
>> _('Delete')  . '</a></td></tr>';
>>
>> 	} //END WHILE LIST LOOP
>> 	echo '</table>';
>> @@ -334,7 +349,7 @@
>> 	echo '<div class="centre"><br /><a href="' . 
>> htmlspecialchars($_SERVER['PHP_SELF'], ENT_QUOTES, 'UTF-8') . '">' . 
>> _('Review Account Groups') . '</a></div>';
>> }
>>
>> -if (!isset($_GET['delete'])) {
>> +if (!isset($_GET['Delete'])) {
>>
>> 	echo '<form method="post" id="AccountGroups" action="' . 
>> htmlspecialchars($_SERVER['PHP_SELF'], ENT_QUOTES, 'UTF-8') . '">';
>> echo '<div><br />';
>> @@ -349,11 +364,12 @@
>> 						pandl,
>> 						parentgroupname
>> 				FROM accountgroups
>> -				WHERE groupname='" . $_GET['SelectedAccountGroup'] ."'";
>> +				WHERE groupname=?";
>>
>> 		$ErrMsg = _('An error occurred in retrieving the account group 
>> information');
>> 		$DbgMsg = _('The SQL that was used to retrieve the account group 
>> and that failed in the process was');
>> -		$result = DB_query($sql, $db,$ErrMsg,$DbgMsg);
>> +		$Parameters = array($_GET['SelectedAccountGroup']);
>> +		$result = DB_query($sql, $db, $ErrMsg, 
>> $DbgMsg,false,true,$Parameters);
>> 		if (DB_num_rows($result) == 0) {
>> 			prnMsg( _('The account group name does not exist in the 
>> database'),'error');
>> 			include('includes/footer.inc');
>> @@ -471,4 +487,4 @@
>>
>> } //end if record deleted no point displaying form to add record
>> include('includes/footer.inc');
>> -?>
>> +?>
>> \ No newline at end of file
>>
>> Modified: branches/working/AddCustomerContacts.php
>> ===================================================================
>> --- branches/working/AddCustomerContacts.php	2014-03-25 17:13:55 UTC 
>> (rev 6640)
>> +++ branches/working/AddCustomerContacts.php	2014-03-26 06:33:38 UTC 
>> (rev 6641)
>> @@ -56,8 +56,7 @@
>> 							$_POST['ContactNotes'],
>> 							$_POST['ContactEmail'],
>> 							$DebtorNo,
>> -							(int)$Id
>> -							);
>> +							(int)$Id);
>> 		$sql = "UPDATE custcontacts SET contactname=?,
>> 										role=?,
>> 										phoneno=?,
>> @@ -72,8 +71,7 @@
>> 						$_POST['ContactRole'],
>> 						$_POST['ContactPhone'],
>> 						$_POST['ContactNotes'],
>> -						$_POST['ContactEmail']
>> -						);
>> +						$_POST['ContactEmail']);
>> 		$sql = "INSERT INTO custcontacts (debtorno,
>> 										contactname,
>> 										role,
>>
>> Modified: branches/working/includes/ConnectDB_mysqli.inc
>> ===================================================================
>> --- branches/working/includes/ConnectDB_mysqli.inc	2014-03-25 
>> 17:13:55 UTC (rev 6640)
>> +++ branches/working/includes/ConnectDB_mysqli.inc	2014-03-26 
>> 06:33:38 UTC (rev 6641)
>> @@ -1,11 +1,6 @@
>> <?php
>> /* $Id$ */
>>
>> -/* PeterMoulding.com
>> -20071102 Change from mysql to mysqli;
>> -20071102 Add $db to DB_escape_string();
>> -*/
>> -
>> define ('LIKE','LIKE');
>>
>> if (!isset($mysqlport)){
>> @@ -16,14 +11,13 @@
>> $db = mysqli_connect($host , $DBUser, 
>> $DBPassword,$_SESSION['DatabaseName'], $mysqlport);
>> //$result=DB_query('SET sql_mode = ANSI', $db);
>>
>> -
>> //this statement sets the charset to be used for sending data to and 
>> from the db server
>> //if not set, both mysqli server and mysqli client/library may assume 
>> otherwise
>> mysqli_set_charset($db, 'utf8');
>>
>> /* check connection */
>> if (mysqli_connect_errno()) {
>> -	printf("Connect failed: %s\n", mysqli_connect_error());
>> +	echo _('Connect failed') . ': ' . mysqli_connect_error();
>> 	session_unset();
>> 	session_destroy();
>> 	echo '<p>' . _('Click') . ' ' . '<a href="index.php">' . _('here') . 
>> '</a>' . ' '  ._('to try logging in again') . '</p>';
>> @@ -70,7 +64,101 @@
>> *
>> * @return  $result associative array
>> */
>> +
>> +
>> function DB_query ($SQL,
>> +					&$Conn,
>> +					$ErrorMessage='',
>> +					$DebugMessage= '',
>> +					$Transaction=false,
>> +					$TrapErrors=true,
>> +					$Parameters=array()){
>> +
>> +	global $debug;
>> +	global $PathPrefix;
>> +
>> +	$SQLChunks = explode('?',$SQL);
>> +	if (count($SQLChunks)-1 != count($Parameters)){
>> +		prnMsg(_('The number of parameters provided with this SQL did not 
>> equal the number of parameters expected by the SQL string'),'error');
>> +		if ($debug==1){
>> +			prnMsg($DebugMessage. '<br />' . $SQL . '<br 
>> />','error',_('Database SQL Failure'));
>> +			print_r($Parameters);
>> +			print_r($SQLChunks);
>> +		}
>> +		include($PathPrefix . 'includes/footer.inc');
>> +		exit;
>> +	}
>> +	$SQLString ='';
>> +	$i=0;
>> +	foreach ($SQLChunks as $SQLChunk) {
>> +		if (isset($Parameters[$i])){
>> +			$SQLString .= $SQLChunk . " '" . $Parameters[$i] . "'";
>> +		} else {
>> +			$SQLString .= $SQLChunk;
>> +		}
>> +		$i++;
>> +	}
>> +	/*
>> +	 * if (mb_strrpos($SQL,'?')==mb_strlen($SQL)){
>> +		$SQLChunks[]=''; //append an empty string so the count of the 
>> arrays match
>> +	}
>> +	*/
>> +	
>> +	$result=mysqli_query($Conn, $SQLString);
>> +
>> +	$_SESSION['LastInsertId'] = mysqli_insert_id($Conn);
>> +
>> +	if ($DebugMessage == '') {
>> +		$DebugMessage = _('The SQL that failed was');
>> +	}
>> +
>> +	if (DB_error_no($Conn) != 0 AND $TrapErrors==true){
>> +		if ($TrapErrors){
>> +			require_once($PathPrefix . 'includes/header.inc');
>> +		}
>> +		prnMsg($ErrorMessage . '<br />' . DB_error_msg($Conn),'error', 
>> _('Database Error'). ' ' .DB_error_no($Conn));
>> +		if ($debug==1){
>> +			prnMsg($DebugMessage. '<br />' . $SQLString . '<br 
>> />','error',_('Database SQL Failure'));
>> +		}
>> +		if ($Transaction){
>> +			$SQL = 'rollback';
>> +			$Result = DB_query($SQL,$Conn);
>> +			if (DB_error_no($Conn) !=0){
>> +				prnMsg(_('Error Rolling Back Transaction'), 'error', _('Database 
>> Rollback Error'). ' ' .DB_error_no($Conn) );
>> +			}else{
>> +				prnMsg(_('Rolling Back Transaction OK'), 'error', _('Database 
>> Rollback Due to Error Above'));
>> +			}
>> +		}
>> +		if ($TrapErrors){
>> +			include($PathPrefix . 'includes/footer.inc');
>> +			exit;
>> +		}
>> +	} elseif (isset($_SESSION['MonthsAuditTrail']) and 
>> (DB_error_no($Conn)==0 AND $_SESSION['MonthsAuditTrail']>0) AND 
>> (DB_affected_rows($result)>0)){
>> +
>> +		$SQLArray = explode(' ', $SQLString);
>> +
>> +		if (($SQLArray[0] == 'INSERT')
>> +			OR ($SQLArray[0] == 'UPDATE')
>> +			OR ($SQLArray[0] == 'DELETE')) {
>> +
>> +			if ($SQLArray[2]!='audittrail'){ // to ensure the auto delete of 
>> audit trail history is not logged
>> +				$AuditSQL = "INSERT INTO audittrail (transactiondate,
>> +									userid,
>> +									querystring)
>> +						VALUES('" . Date('Y-m-d H:i:s') . "',
>> +							'" . trim($_SESSION['UserID']) . "',
>> +							'" . $SQLString . "')";
>> +
>> +				$AuditResult = mysqli_query($Conn, $AuditSQL);
>> +			}
>> +		}
>> +	}
>> +	return $result;
>> +
>> +}
>> +
>> +
>> +function DB_query_JO ($SQL,
>> 				   &$Conn,
>> 				   $ErrorMessage='',
>> 				   $DebugMessage= '',
>>
>> Modified: branches/working/includes/UserLogin.php
>> ===================================================================
>> --- branches/working/includes/UserLogin.php	2014-03-25 17:13:55 UTC 
>> (rev 6640)
>> +++ branches/working/includes/UserLogin.php	2014-03-26 06:33:38 UTC 
>> (rev 6641)
>> @@ -42,12 +42,13 @@
>> 		/* The SQL to get the user info must use the * syntax because the 
>> field name could change between versions if the fields are specifed 
>> directly then the sql fails and the db upgrade will fail */
>> 		$sql = "SELECT *
>> 				FROM www_users
>> -				WHERE www_users.userid='" . $Name . "'
>> -				AND (www_users.password='" . CryptPass($Password) . "'
>> -				OR  www_users.password='" . $Password . "')";
>> +				WHERE www_users.userid=?
>> +				AND (www_users.password=?
>> +				OR  www_users.password=?)";
>> +		$Parameters = array($Name, CryptPass($Password), $Password);
>> 		$ErrMsg = _('Could not retrieve user details on login because');
>> 		$debug =1;
>> -		$Auth_Result = DB_query($sql, $db,$ErrMsg);
>> +		$Auth_Result = DB_query($sql, 
>> $db,$ErrMsg,'',false,true,$Parameters);
>> 		// Populate session variables with data base results
>> 		if (DB_num_rows($Auth_Result) > 0) {
>> 			$myrow = DB_fetch_array($Auth_Result);
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and 
>> their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Web-erp-svn mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-svn

Re: [WebERP-developers] tax.php: Error in tax amount displayed in report.

[Rafael C. <raf...@gm...>]

Hi All,

Any comments or suggestions?


Best regards, Rafael.

2014-03-21 5:23 GMT-06:00 Rafael Chacón <raf...@gm...>:
> Hi,
>
> In tax.php (line 46) we have:
>
> (debtortrans.ovamount+debtortrans.ovfreight)/debtortrans.rate AS netamount,
> debtortrans.ovfreight/debtortrans.rate AS freightamount,
> debtortranstaxes.taxamount/debtortrans.rate AS tax
>
> ***dividing by exchange rate***
>
> but
> In ConfirmDispatch_Invoice.php (line  830) we use: $SQL = "INSERT INTO
> debtortranstaxes.taxamount VALUES ('" . $TaxAmount/$_SESSION['CurrencyRate']
> . "')";
> In ConfirmDispatch_Invoice.php (line 1615) we use: $SQL = "INSERT INTO
> gltrans.amount VALUES ('" .
> round((-$TaxAmount/$_SESSION['CurrencyRate']),$_SESSION['CompanyRecord']['decimalplaces'])
> . "')";
> In CounterReturns.php (line  965) we use: $SQL = "INSERT INTO
> debtortranstaxes.taxamount VALUES ('" . -$TaxAmount/$ExRate . "')";
> In CounterReturns.php (line 1428) we use: $SQL = "INSERT INTO gltrans.amount
> VALUES ('" . ($TaxAmount/$ExRate) . "')";
> In CounterSales.php (line 1383) we use: $SQL = "INSERT INTO
> debtortranstaxes.taxamount VALUES ('" . $TaxAmount/$ExRate . "')";
> In CounterSales.php (line 1885) we use: $SQL = "INSERT INTO gltrans.amount
> VALUES ('" . (-$TaxAmount/$ExRate) . "')";
> In Credit_Invoice.php (line 644) we use: $SQL = "INSERT INTO
> debtortranstaxes.taxamount VALUES ('" .
> (-$TaxAmount/$_SESSION['CurrencyRate']) . "')";
> In RecurringSalesOrdersProcess.php (line 692) we use: $SQL = "INSERT INTO
> debtortranstaxes.taxamount VALUES ('" .
> filter_number_format($Tax['FXAmount']/$CurrencyRate) . "')";
> In SelectCreditItems.php (line 1178) we use: $SQL = "INSERT INTO
> debtortranstaxes.taxamount VALUES ('" .
> -$TaxAmount/$_SESSION['CurrencyRate'] . "')";
> In SupplierCredit.php (line 1158) we use: $SQL = "INSERT INTO
> supptranstaxes.taxamount VALUES ('" . -$TaxTotals->TaxOvAmount . "')";
> In SupplierInvoice.php (1514) we use: $SQL = "INSERT INTO
> supptranstaxes.taxamount VALUES ('" . $TaxTotals->TaxOvAmount . "')";
>
> I guess it must be corrected to:
>
> (debtortrans.ovamount+debtortrans.ovfreight)/debtortrans.rate AS netamount,
> debtortrans.ovfreight/debtortrans.rate AS freightamount,
> debtortranstaxes.taxamount AS tax
>
> ***NOT dividing by exchange rate***
>
> Also, I have also doubt to what it serves the field debtortrans.ovgst. What
> is the difference between tax saved in debtortrans.ovgst and
> debtortranstaxes.taxamount? Is it exchange rate?
>
> Best regards, Rafael Chacon.

[WebERP-developers] More convenient feature for preparing goods in warehouse and confirm delivery

[ExsonQu <hex...@gm...>]

*Dear all:*

          I'm considering to add a feature to make warehouse preparing the
goods for sales orders and Accountant or Sales can know the goods are ready
to delivery or not more transparent. The scenario is like this:

          1. First Sales select those orders should be arranged to delivery. 

          2. Warehouse man check the order delivery schedule. And mark the
order lines when it's ready.

          3. Sales(Or accountant) confirm the delivery and issue invoice
according to the marked orders.
 
          4. warehouse actually delivery. 

         Not sure if it's a redundant feature. 

         Any comments are very welcome.

         Best regards!

         Exson

          

          



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/More-convenient-feature-for-preparing-goods-in-warehouse-and-confirm-delivery-tp4657290.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] New branch working for DB_query parameterisation work

[icedlava <ice...@gm...>]

> I've made up a new branch so we can mess with this a bit

Thanks for setting that up Phil.

> we should keep it the same name - but with a new optional parameter 
> for
> the array of parameters.

Ok, so, in order to keep consistency with the existing function 
signature, we should likely have the new $bindvar array of parameters at 
the end of the signature  list.
I'll start with that and we can change things as we need.

Cheers,



On 25 Mar 2014, at 17:10, Phil Daintree wrote:

> I've made up a new branch so we can mess with this a bit
>
> svn checkout --username=XXXXX
> svn+ssh://XX...@sv.../p/web-erp/code/branches/working
> yourworkingcopy
>
> where XXXXX is your sourceforge login.
>
> Jo, if you commit the code you want for the new DB_query - and I 
> propose
> we should keep it the same name - but with a new optional parameter 
> for
> the array of parameters.
>
>
> -- 
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890
> http://www.logicworks.co.nz
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and 
> their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

[WebERP-developers] New branch working for DB_query parameterisation work

[Phil D. <ph...@lo...>]

I've made up a new branch so we can mess with this a bit

svn checkout --username=XXXXX 
svn+ssh://XX...@sv.../p/web-erp/code/branches/working 
yourworkingcopy

where XXXXX is your sourceforge login.

Jo, if you commit the code you want for the new DB_query - and I propose 
we should keep it the same name - but with a new optional parameter for 
the array of parameters.


-- 
Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

Re: [WebERP-developers] Future Suggestion: Quality Control Features.

[ExsonQu <hex...@gm...>]

*Hi, Muthu,*

         Thank you for your great proposals. 

         Any progress for the BOM sequences no project? Or do you have any
plan about it? I'd like to improve this parts with you and quality control
parts too.

         Best regards!

         Exson



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Future-Suggestion-Quality-Control-Features-tp4657217p4657279.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] A new coding rules?

[Phil D. <ph...@lo...>]

Yes - I realise (realize) the code has some American spellings in the 
text - which it really should not. The American translation is where 
this gets translated. Perhaps I should add a little bit to the coding 
guidelines. I certainly don't wish to alienate anyone - just that the 
code is 95% British/Phil's/Tim's English so easier to adopt it as the 
standard. The thing about changing existing American spellings though is 
that this will damage the existing translations so not worth it IMHO.

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 22/03/14 18:30, ExsonQu wrote:
> *Hi, Phil,*
>
>             I've noted that you've made some US locale in the trunk. It's an
> interesting things for me. I'm curious if we should follow the standard to
> code in the future? In another words, we should have dictionary and make
> Britain English as the first locale during coding?
>
>             Thanks and best regards!
>
>             Exson
>
>             
>
>             
>
>
>
> --
> View this message in context: http://weberp-accounting.1478800.n4.nabble.com/A-new-coding-rules-tp4657277.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

[WebERP-developers] A new coding rules?

[ExsonQu <hex...@gm...>]

*Hi, Phil,*

           I've noted that you've made some US locale in the trunk. It's an
interesting things for me. I'm curious if we should follow the standard to
code in the future? In another words, we should have dictionary and make
Britain English as the first locale during coding?

           Thanks and best regards!

           Exson

           

           



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/A-new-coding-rules-tp4657277.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

[WebERP-developers] Ready to embrace Hack?

[ExsonQu <hex...@gm...>]

*Dear all:*

          As a guidance of Platform undependable, we seems have only one no
choice is PHP language. Things seems to change as Hack coming. Maybe one day
we can choose Hack instead of PHP and HHVM instead of Zend Engine?

          For those who may be interested  in it: 
https://code.facebook.com/posts/264544830379293/hack-a-new-programming-language-for-hhvm/
<https://code.facebook.com/posts/264544830379293/hack-a-new-programming-language-for-hhvm/>  

           http://hacklang.org/ <http://hacklang.org/>  

           https://blog.engineyard.com/2014/hhvm-hack
<https://blog.engineyard.com/2014/hhvm-hack>  

          Best regards!

          Exson



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Ready-to-embrace-Hack-tp4657276.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] Is negative quantity reasonable in GoodsReceived?

[ExsonQu <hex...@gm...>]

*Hi, Rafael Chacon*

          Thank you for your reply. And thanks for Tim's reply. 

         I found there is some scenarios for the negative input:

              1. Sometime users have to receive those goods temporarily. For
instance it's near day off, they have to time to count the actual quantity.
So just receive it an pending warehouse (location in weberp). Then they have
time to count it tomorrow. And find the quantity is less than expected, so
they use the negative quantity to correct it. The the goods was transferred
from pending warehouse to raw material house.

              2. For quality control reason, since we have no quality
control feature now, those goods will be received into pending warehouse.
The can return some rejected goods by this feature.

         But if we want to use this feature, we must need some improvement
for it:

             1. We should have a choice for users that the PO should not be
marked completed otherwise, we cannot retrieve the PO back.
             2. We should add a control to prevent a new lot/batch/serial no
from keying again for controlled items.
             3. We have add a authority control for this feature. For
instance, assigned it to a token for special role or mail the negative
receive to warehouse manager just like stock adjustments.

             Maybe something I've overlooked? Any comments are highly
appreciated!

             Thanks and best regards!

             Exson

               



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Is-negative-quantity-reasonable-in-GoodsReceived-tp4657266p4657275.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] Is negative quantity reasonable in GoodsReceived?

[Rafael C. <raf...@gm...>]

Hi Exson,

IMHO, I think it should not be allowed negative values. Inventory
adjustments should be made elsewhere and by someone else different to the
manager of the inventory. In this way, we eliminate a chance that the
manager of the warehouse alters the inventory (control reason).

Best regards, Rafael Chacon.


2014-03-18 2:52 GMT-06:00 ExsonQu <hex...@gm...>:

> *Dear all:*
>
>             Thank you for your great contribution to webERP.
>
>             During study the script of GoodsReceived.php, I found that it
> allows a negative quantity to input in Goods Receiving. Does this make
> sense? webERP deduce inventory while issuing an invoice, it makes the
> inventory control quite tight and warehouse person usually can only add the
> inventory quantity, even the stock adjustment has set up an email trigger
> to
> superiors that inventory has been adjusted.
>
>            So my question here is why a negative quantity is allowed here?
>
>            Any comments are highly appreciated!
>
>            Best regards!
>
>            Exson
>
>
>
>
>
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/Is-negative-quantity-reasonable-in-GoodsReceived-tp4657266.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

[WebERP-developers] tax.php: Error in tax amount displayed in report.

[Rafael C. <raf...@gm...>]

Hi,

In tax.php (line 46) we have:

(debtortrans.ovamount+debtortrans.ovfreight)/debtortrans.rate AS netamount,
debtortrans.ovfreight/debtortrans.rate AS freightamount,
debtortranstaxes.taxamount/debtortrans.rate AS tax

***dividing by exchange rate***

but
In ConfirmDispatch_Invoice.php (line  830) we use: $SQL = "INSERT INTO
debtortranstaxes.taxamount VALUES ('" .
$TaxAmount/$_SESSION['CurrencyRate'] . "')";
In ConfirmDispatch_Invoice.php (line 1615) we use: $SQL = "INSERT INTO
gltrans.amount VALUES ('" .
round((-$TaxAmount/$_SESSION['CurrencyRate']),$_SESSION['CompanyRecord']['decimalplaces'])
. "')";
In CounterReturns.php (line  965) we use: $SQL = "INSERT INTO
debtortranstaxes.taxamount VALUES ('" . -$TaxAmount/$ExRate . "')";
In CounterReturns.php (line 1428) we use: $SQL = "INSERT INTO
gltrans.amount VALUES ('" . ($TaxAmount/$ExRate) . "')";
In CounterSales.php (line 1383) we use: $SQL = "INSERT INTO
debtortranstaxes.taxamount VALUES ('" . $TaxAmount/$ExRate . "')";
In CounterSales.php (line 1885) we use: $SQL = "INSERT INTO gltrans.amount
VALUES ('" . (-$TaxAmount/$ExRate) . "')";
In Credit_Invoice.php (line 644) we use: $SQL = "INSERT INTO
debtortranstaxes.taxamount VALUES ('" .
(-$TaxAmount/$_SESSION['CurrencyRate']) . "')";
In RecurringSalesOrdersProcess.php (line 692) we use: $SQL = "INSERT INTO
debtortranstaxes.taxamount VALUES ('" .
filter_number_format($Tax['FXAmount']/$CurrencyRate) . "')";
In SelectCreditItems.php (line 1178) we use: $SQL = "INSERT INTO
debtortranstaxes.taxamount VALUES ('" .
-$TaxAmount/$_SESSION['CurrencyRate'] . "')";
In SupplierCredit.php (line 1158) we use: $SQL = "INSERT INTO
supptranstaxes.taxamount VALUES ('" . -$TaxTotals->TaxOvAmount . "')";
In SupplierInvoice.php (1514) we use: $SQL = "INSERT INTO
supptranstaxes.taxamount VALUES ('" . $TaxTotals->TaxOvAmount . "')";

I guess it must be corrected to:

(debtortrans.ovamount+debtortrans.ovfreight)/debtortrans.rate AS netamount,
debtortrans.ovfreight/debtortrans.rate AS freightamount,
debtortranstaxes.taxamount AS tax

***NOT dividing by exchange rate***

Also, I have also doubt to what it serves the field debtortrans.ovgst. What
is the difference between tax saved in debtortrans.ovgst and
debtortranstaxes.taxamount? Is it exchange rate?

Best regards, Rafael Chacon.

[WebERP-developers] Is negative quantity reasonable in GoodsReceived?

[ExsonQu <hex...@gm...>]

*Dear all:*

            Thank you for your great contribution to webERP.

            During study the script of GoodsReceived.php, I found that it
allows a negative quantity to input in Goods Receiving. Does this make
sense? webERP deduce inventory while issuing an invoice, it makes the
inventory control quite tight and warehouse person usually can only add the
inventory quantity, even the stock adjustment has set up an email trigger to
superiors that inventory has been adjusted. 

           So my question here is why a negative quantity is allowed here? 

           Any comments are highly appreciated!

           Best regards!

           Exson

            



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Is-negative-quantity-reasonable-in-GoodsReceived-tp4657266.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

[WebERP-developers] AllowAnyone No Problem

[web e. <web...@ya...>]

Phil,

What spreads FUD about a project is your censoring any 
debate about such issues. Even now you rejected my post explaining how 
once a user doesn't need to log in to gain access to the database they 
can generate errors revealing damaging information about the webERP 
implementation.

Typically, you make cryptic comments about my 
"alternative agenda" and then don't back this up with any fact. What on 
earth does "alternative agenda" mean?? What agenda?? Please specify if 
you are going to make these allegations. As a webERP developer I earn my
 living from the good name of webERP. What would I have to gain by 
damaging it? It is your stupid vendetta against me that damages the 
project. Contributions should be accepted on a basis of the merit of the
 code, not on some silly personal vendetta of yours, however you 
repeatedly reject my contributions. It seems to me it is you who damage 
the project and you who spreads what you call FUD.

Tim

Re: [WebERP-developers] AllowAnyone No Problem

[gilberto d. s. a. <gs...@gm...>]

+1 from me.
may be this url [1] from django could help to bring ideas, procedures and
standard procedures like you propose.
See details that djangoproject.com is not using sourceforge.net but one own
domain. IMO i set -1 for sourceforge lists is advertising on foot pages and
on lists these ads inside of lot of places are handled like spam.

Thanks for your time.

[1]
https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/


2014-03-14 23:00 GMT-03:00 Phil Daintree <ph...@lo...>:

> It seems that Tim's "critical vulnerability" issue identified relates to
> the use of $AllowAnyone which circumvents the normal authentication
> mechanism.
>
> These are the scripts where $AllowAnyone is set to true.
>
> 1. webERP/GLTrialBalance_csv.php://$AllowAnyone = true;
>
> YES - this script was a problem as previously advised when it was first
> identified. This script should be removed from any webERP installation.
>
> 2. webERP/Logout.php:$AllowAnyone=True; /* Allow all users to log off  */
>
> It seems reasonable that anyone should be allowed to log off?
>
> 3. webERP/RecurringSalesOrdersProcess.php:$AllowAnyone = true;
>
> This script can be run by anyone too and it just processes any recurring
> order templates into orders based on the frequency of recurrence ... you
> can run this as many times as you like - there is no output and it is
> intended to be run from cron using wget.
>
> 4. webERP/api/api_php.php:    $AllowAnyone = true;
>
> This allows the api to run - there is separate authentication required.
> No problem
>
> 5. webERP/MailInventoryValuation.php:$AllowAnyone = true;
>
> This scripts sends an inventory valuation email to the users defined in
> the script - no output to anyone externally - no risk to anyone - also
> intended to be run from cron
>
> 6. webERP/MailSalesReport_csv.php:$AllowAnyone = true;
>
> This scripts sends an email of a sales report as a csv to the users
> defined in the script - no output to anyone externally - no risk to
> anyone - also intended to be run from cron
>
> 7. webERP/report_runner.php:$AllowAnyone = true;
>
> This script sends an email of a sales report to the users defined in the
> script - no output to anyone externally - no risk to anyone - also
> intended to be run from cron
>
> 8. webERP/MailSalesReport.php:$AllowAnyone = true;
>
> This scripts sends an email of a sales report to the users defined in
> the script - no output to anyone externally - no risk to anyone - also
> intended to be run from cron
>
>
> So .... IMHO - none of these last 7 scripts represent a security risk
> (only the GLTrialBalance_csv.php - already identified). Maybe they
> present a potential spam risk.
> I am keen to avoid the propagation of FUD on the mailing lists and
> forums - hence my perhaps heavy handed moderation. I do particularly
> watch Tim given his alternative agenda. However, his knowledgeable
> contributions have been good more recently. Perhaps he didn't look at
> what these scripts do, he is normally pretty smart. Perhaps I should
> have given him the benefit of the doubt.
>
> Hopefully we have a clear reporting mechanism for reporting issues that
> people may worry about publicly identifying for fear of exposing other
> users webERP installations. icedlava's suggestion was that the email -
> sec...@we... be used and this sends email to Exson, icedlava and
> myself - so we can have a look privately before alerting the community
> as necessary.
>
> --
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890
> http://www.logicworks.co.nz
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>



-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

[WebERP-developers] AllowAnyone No Problem

[Phil D. <ph...@lo...>]

It seems that Tim's "critical vulnerability" issue identified relates to 
the use of $AllowAnyone which circumvents the normal authentication 
mechanism.

These are the scripts where $AllowAnyone is set to true.

1. webERP/GLTrialBalance_csv.php://$AllowAnyone = true;

YES - this script was a problem as previously advised when it was first 
identified. This script should be removed from any webERP installation.

2. webERP/Logout.php:$AllowAnyone=True; /* Allow all users to log off  */

It seems reasonable that anyone should be allowed to log off?

3. webERP/RecurringSalesOrdersProcess.php:$AllowAnyone = true;

This script can be run by anyone too and it just processes any recurring 
order templates into orders based on the frequency of recurrence ... you 
can run this as many times as you like - there is no output and it is 
intended to be run from cron using wget.

4. webERP/api/api_php.php:    $AllowAnyone = true;

This allows the api to run - there is separate authentication required. 
No problem

5. webERP/MailInventoryValuation.php:$AllowAnyone = true;

This scripts sends an inventory valuation email to the users defined in 
the script - no output to anyone externally - no risk to anyone - also 
intended to be run from cron

6. webERP/MailSalesReport_csv.php:$AllowAnyone = true;

This scripts sends an email of a sales report as a csv to the users 
defined in the script - no output to anyone externally - no risk to 
anyone - also intended to be run from cron

7. webERP/report_runner.php:$AllowAnyone = true;

This script sends an email of a sales report to the users defined in the 
script - no output to anyone externally - no risk to anyone - also 
intended to be run from cron

8. webERP/MailSalesReport.php:$AllowAnyone = true;

This scripts sends an email of a sales report to the users defined in 
the script - no output to anyone externally - no risk to anyone - also 
intended to be run from cron


So .... IMHO - none of these last 7 scripts represent a security risk 
(only the GLTrialBalance_csv.php - already identified). Maybe they 
present a potential spam risk.
I am keen to avoid the propagation of FUD on the mailing lists and 
forums - hence my perhaps heavy handed moderation. I do particularly 
watch Tim given his alternative agenda. However, his knowledgeable 
contributions have been good more recently. Perhaps he didn't look at 
what these scripts do, he is normally pretty smart. Perhaps I should 
have given him the benefit of the doubt.

Hopefully we have a clear reporting mechanism for reporting issues that 
people may worry about publicly identifying for fear of exposing other 
users webERP installations. icedlava's suggestion was that the email - 
sec...@we... be used and this sends email to Exson, icedlava and 
myself - so we can have a look privately before alerting the community 
as necessary.

-- 
Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

Re: [WebERP-developers] Security vulnerabilities

[Julie S. <jul...@op...>]

Hi

 

Could you please remove my email from this discussion.  I am not a developer
at all, just a general everyday user and don't want to be part of this
discussion.

 

Thanks

 

Julie Saville

 

From: Tim Schofield [mailto:tim...@gm...] 
Sent: Thursday, 13 March 2014 7:57 PM
To: Reg Pro
Cc: Phil Daintree; webERP Developers; Joe Lwe; iced lava; ExsonQu; Pak
Ricard; Rafael Emilio Chacon; aga...@re...; Avinash Ranka;
jul...@op...; ha...@ne...; Gilberto Dos Santos Alves;
buecher; muthu samy; su...@ou...; Heinrich Steuber; Robert
Thomas
Subject: Re: [WebERP-developers] Security vulnerabilities

 

Phil, you say on the nabble forums that you were unaware of the other
scripts where there was potentially a problem, and in that case I apologise
as I was given to believe that you had been informed. However that was all
you needed to say. If it is ok with Exson I can forward you the log of the
chat we had and you can see the issues that came up.

Blocking the accounts of people who bring up security concerns is a sure way
of generating FUD as it convinces people that you are trying to cover
something up. It's always better to be up front and honest Phil.

Tim

 

On 13 March 2014 07:30, Tim Schofield <tim...@gm...> wrote:

As far as I am aware I have never done anything to consciously hurt webERP.
Of course I may have made some mistakes but so have all of us, we are all
human.

I have never consciously said anything untrue about Phil, or the project.

I don't give a damn about admin access, if Phil wants his name up in lights
then that is fine by me.

All I am saying here is that it is the best interests of the project if I be
given access to the forums to help users by passing on some of the knowledge
I have gained over the years with webERP. Removing my access and removing
some of the advice I have previously given is just daft.

If I have hurt Phil's feelings by asking about the security vulnerability
then I hereby publicly apologise. Can we move on from this silliness please?

Tim

 

On 12 March 2014 22:54, <reg...@gm...> wrote:

Tim and Phil,
We NEED you both.
Tim: please stop it there. No explanations or reasoning.

Phil, please look at Tim's concerns objectively.

I am not in a position to know how potentially critical an Admin access is
to the project but certainly some minor mods can be done to give Tim access
to a non detrimental access until confidence is rebuilt or security tokens
modified for a super-admin.

Avid Weberpian

Sent from my BlackBerryR device from Digicel

  _____  

From: Tim Schofield <tim...@gm...> 

Date: Wed, 12 Mar 2014 17:58:26 +0000

To: Reg Pro<reg...@gm...>

Cc: Joe Lwe<lw...@gm...>; Phil Daintree<ph...@lo...>; iced
lava<ice...@gm...>; ExsonQu<hex...@gm...>; Pak
Ricard<pak...@gm...>; Rafael Emilio
Chacon<raf...@gm...>; <aga...@re...>; Avinash
Ranka<avi...@gm...>; <jul...@op...>;
<ha...@ne...>; Gilberto Dos Santos Alves<gs...@gm...>;
buecher<bu...@op...>; muthu samy<map...@gm...>;
<su...@ou...>; Heinrich Steuber<mr...@gm...>; Robert
Thomas<rf...@as...>

Subject: Re: [WebERP-developers] Security vulnerabilities

 

Hi, well I thought we had started out after Phil and I spoke on the phone
recently, but somehow Phil took offence to something either me or Exson said
regarding the security vulnerability. I would have thought he would have had
the courtesy to say something to me first, but then he still hasn't had the
courtesy to tell me that he has removed me as an administrator on
sourceforge.

I will admit that in the past I may have tried to wind Phil up, but this has
really taken me by surprise. Exson and I had a private chat about scripts
with $AllowAnyone set, and as a result of that gchat he wrote to Phil
regarding these issues we suspected were still in the code. Yesterday I
wrote a polite note to the forums asking if any progress had been made as it
was some time since Exson wrote. I didn't mention any details of the
potential vulnerability. Suddenly I found that my forum account was blocked,
and several of my posts had randomly been deleted. When I created another
account so that I could carry on giving people help on the forum I find that
advice gets deleted and the accounts blocked.

I am at a loss to explain why my accounts are blocked, I am at a loss to
explain why helpful advice I have given people on the forum is now being
randomly deleted. I did not seek any confrontation and it all seems
completely barmy to me. If anyone can explain then please do.

Tim

 

On 12 March 2014 14:20, <reg...@gm...> wrote:

I second and third Joe's message as both of you are and have been great
leaders in this great erp system.

We, the weberp community have the most to loose with the bickering and we
may even have to choose sides one day.

Please Gentlemen, start over a fresh leaf and leave personalities and
history out.

Russ 

Sent from my BlackBerryR device from Digicel

  _____  

From: Joe Lwe <lw...@gm...> 

Date: Wed, 12 Mar 2014 12:39:34 +0300

To: Tim Schofield<tim...@gm...>

Cc: Phil Daintree<ph...@lo...>; iced lava<ice...@gm...>;
ExsonQu<hex...@gm...>; Pak Ricard<pak...@gm...>; Rafael Emilio
Chacon<raf...@gm...>; <aga...@re...>;
<avi...@gm...>; <jul...@op...>; <ha...@ne...>;
Gilberto Dos Santos Alves<gs...@gm...>; buecher<bu...@op...>;
muthu samy<map...@gm...>; <su...@ou...>; Heinrich
Steuber<mr...@gm...>; Reg Pro<reg...@gm...>; Robert
Thomas<rf...@as...>

Subject: Re: [WebERP-developers] Security vulnerabilities

 

Dear All,

 

Thank you all for your contributions to the project, trust me webERP good.

 

Everyone knows how paramount the issue of systems security is, especially
for hosted installations.

 

webERP can really be made better and better, though divisions(among great
contributors) wont make it possible.

 

My humble request is reconciliation, respect, forget the past and set a
fresh ground for cooperation for the good of the webERP project,
Acquisitions wont help.

 

Best Regards

Joe

 

 

On Wed, Mar 12, 2014 at 11:55 AM, Tim Schofield
<tim...@gm...> wrote:

Phil, I tried to bring up a potential security vulnerability with you
privately, and got a nasty bitter abusive message back.

I tried to bring this up on the forum twice and the messages got deleted and
my accounts got blocked.

This could potentially open up the details of a companies customer and sales
base to a rival company. Trying to censor the messenger is not the right way
to deal with potential vulnerabilities. It may be I am wrong, and it is
harmless. If so lets discuss it like intelligent grown ups rather than
behaving like a playground bully and just attacking the person who brings up
a subject you don't like. This is not the right way to run a project.

If there is a different way of highlighting potential vulnerabilities then
please let me and others know.

Denying webERP users access to my help and advice without explaining to them
why is typically dishonest behaviour from you.

 

Tim



-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418 <tel:%2B256%20%280%29%20312%20314%20418> 
M +256 (0) 752 963 325 <tel:%2B256%20%280%29%20752%20963%20325> 
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/ 

 




-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418 <tel:%2B256%20%280%29%20312%20314%20418> 
M +256 (0) 752 963 325 <tel:%2B256%20%280%29%20752%20963%20325> 
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/ 




-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418 <tel:%2B256%20%280%29%20312%20314%20418> 
M +256 (0) 752 963 325 <tel:%2B256%20%280%29%20752%20963%20325> 
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/ 




-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/ 

Re: [WebERP-developers] Reporting Of Issues

[icedlava <ice...@gm...>]

Hi Phil,

Thanks for setting those up. Do you mind if we add something on the 
Problems/Bugs forum description such as:

"Please report potential security issues by email to: 
sec...@we..."

As previously mentioned, the bug tracker might be extra overhead at the 
moment if you are using the forum as well, but perhaps others might like 
to use it. Any thoughts from people?
I can take look at the bug tracker - if it is of some benefit we could 
continue with it. I don't mind taking care of it if it is wanted.

Cheers,


On 13 Mar 2014, at 19:31, Phil Daintree wrote:

> OK we have a new
>
> sec...@we...
>
> address that goes to Jo/Exson and I
>
> If you want to have a go at the bug tracker it is all yours. I am not
> keen to upload some other software though.
>
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890
> http://www.logicworks.co.nz
>
> On 13/03/14 21:51, icedlava wrote:
>>> Yes that's how the thinking went - if we really want feedback on 
>>> bugs
>>> then we need to make it easy to report - so the forum was the place.
>>>
>> hehe - in truth i've never really liked forums as I find them a bit
>> cumbersome for tracking things and having to log in to the web. 
>> Always
>> preferred mailing lists.
>>
>> Having a web based bug tracker is much the same as a forum but has 
>> the
>> benefit that you can track, search, assign, hide, etc each bug as
>> necessarily. i.e. better for management of issues and historical
>> use/looking back for checking.
>>
>> Again, if you do want someone to manage the bug tracker then I'm 
>> happy
>> to do it, along with anyone else that wants to volunteer. I like bug
>> trackers a lot. But i'd recommend you put a link to the bug tracker 
>> in
>> the forum if you do use it.
>>
>> I agree and think the developer list is great for discussion.
>>
>> The reason this came up though is due to the security reporting 
>> process
>> - would only work as intended if we had a place where the report 
>> could
>> be initially out of public view -  developer list is open right?
>>
>> As a simple alternative, setting up email sec...@we... and 
>> having
>> it go to at least 3 people, or some secure non-public mail list would
>> work too to keep the report out of public eye until assessed. Perhaps
>> that's the way to go?
>>
>> Happy to support whatever is agreed.
>>
>> Cheers,
>>
>>
>> On 13 Mar 2014, at 18:40, Phil Daintree wrote:
>>
>>> Yes that's how the thinking went - if we really want feedback on 
>>> bugs
>>> then we need to make it easy to report - so the forum was the place.
>>>
>>> I really do believe if there are issues then the developers list is
>>> where they belong unless we have a full time administrator working 
>>> on
>>> the bug tracker.
>>>
>>> I am thinking of ditching the bug tracker unless anyone has violent
>>> objections or wishes to take it on - not sure how I got talked into
>>> putting it up!
>>>
>>> Phil
>>>
>>> Phil Daintree
>>> Logic Works Ltd - +64 (0)275 567890
>>> http://www.logicworks.co.nz
>>>
>>> On 13/03/14 20:35, icedlava wrote:
>>>> I believe a bug tracker works if all bugs are directed there
>>>> otherwise
>>>> it's just overhead. I do have an account there but as there is a 
>>>> bugs
>>>> forum it seems redundant (and maybe why the tracker is not used 
>>>> more
>>>> -
>>>> doesn't seem to be easy to find the tracker either).
>>>>
>>>>> it is still there is you are keen to pick it up and give it a
>>>>> birthday
>>>> If there is one supported place for tracking bugs and communication
>>>> on
>>>> them, I'd be happy to maintain the bug tracker or lend a hand to
>>>> whoever
>>>> is doing it now (even tho i'm definitely not keen on Mantis). Just
>>>> say
>>>> the word.
>>>>
>>>> My point about a security email address (directing to a private 
>>>> list
>>>> or
>>>> shared mail address) was because sometimes a person just want to
>>>> quickly
>>>> report something and know it's not going public.
>>>>
>>>> I agree with you that the developers mailing list is very useful 
>>>> and
>>>> prefer it to forums. However it's public, and therefore does not 
>>>> fit
>>>> the
>>>> requirements for private reporting of security vulnerabilities. 
>>>> Once
>>>> information is published there it remains public and searchable.
>>>>
>>>> Thanks for the feedback.
>>>>
>>>> cheers
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 13 Mar 2014, at 17:39, Phil Daintree wrote:
>>>>
>>>>> We already have a bug tracker.
>>>>>
>>>>> The snag with it though is that it is unmaintained - I can't
>>>>> remember
>>>>> who put their hand up keen to administer it, but they have not 
>>>>> been
>>>>> able
>>>>> to keep it up. I must say I was sceptical at the time for just 
>>>>> this
>>>>> reason and stated up front that I did not want to maintain it
>>>>> myself.
>>>>> However, it is still there is you are keen to pick it up and give 
>>>>> it
>>>>> a
>>>>> birthday.
>>>>>
>>>>> http://www.weberp.org/bugs
>>>>>
>>>>> What you say is good sense. However, I still feel that this is 
>>>>> what
>>>>> the
>>>>> developers mailing list is for.
>>>>>
>>>>> Phil
>>>>>
>>>>> Phil Daintree
>>>>> Logic Works Ltd - +64 (0)275 567890
>>>>> http://www.logicworks.co.nz
>>>>>
>>>>> On 13/03/14 15:27, icedlava wrote:
>>>>>> Hi Phil,
>>>>>>
>>>>>> Perhaps there could be a security reporting process that attempts
>>>>>> to
>>>>>> keep any vulnerabilities out of public eye until they are 
>>>>>> assessed
>>>>>> and
>>>>>> fixed and patch posted, depending on the severity.
>>>>>>
>>>>>> Some security issues are not as severe as others and would not 
>>>>>> hurt
>>>>>> being publicly posted. Others might need urgent attention and
>>>>>> fixing
>>>>>> prior to publishing any info or hints to it, to ensure websites 
>>>>>> are
>>>>>> not
>>>>>> taken advantage of prior to the fix being applied.
>>>>>>
>>>>>> Example :
>>>>>>
>>>>>> 1. All security vulnerability posts to go to an email
>>>>>> sec...@we... that is received to a closed list, viewable
>>>>>> only
>>>>>> to
>>>>>> a list of developers. There would hopefully be at least one 
>>>>>> person
>>>>>> that
>>>>>> could receive /read it immediately and assess the severity, or
>>>>>> notify
>>>>>> someone who could assess it if they didn't know.
>>>>>> Most bug trackers also have the ability to post directly and not 
>>>>>> be
>>>>>> viewed publicly - e.g. only viewable to a permission enabled list
>>>>>> of
>>>>>> people .
>>>>>>
>>>>>> 2. This email and/or bug tracker link could be publicised on
>>>>>> weberp.org
>>>>>> along with how security issues are handled.
>>>>>>
>>>>>> 3. If it is not a severe vulnerability, it could be publicly
>>>>>> published
>>>>>> to the list/forum/bug tracker for discussion or fixing
>>>>>>
>>>>>> 4. If it is severe and needs discussion, it could be posted to a
>>>>>> 'closed' forum or bug tracker item that is open to all approved
>>>>>> developers. They could address the issue, provide a patch.
>>>>>> Once the patch is provided, it could be published openly.
>>>>>>
>>>>>> 5. Where a report is published openly before it becomes or is 
>>>>>> known
>>>>>> as a
>>>>>> severe security issue (e.g. list or forum), then hopefully before
>>>>>> any
>>>>>> key information is provided about it, discussion can be moved to
>>>>>> the
>>>>>> closed list/bug tracker for processing as in 3. This problem 
>>>>>> could
>>>>>> be
>>>>>> overcome by having a dedicated bug tracker that is always 
>>>>>> promoted
>>>>>> to
>>>>>> be
>>>>>> used for any issue, as the bug could be hidden to the public 
>>>>>> along
>>>>>> with
>>>>>> any existing discussion (in most trackers) as soon as it becomes
>>>>>> evident
>>>>>> it's a security related one.
>>>>>>
>>>>>> Just a rough idea.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 13 Mar 2014, at 9:46, Phil Daintree wrote:
>>>>>>
>>>>>>> There is no secrecy here.
>>>>>>>
>>>>>>> If there is some issue that you are aware of then obviously the
>>>>>>> meat
>>>>>>> of what the issue is about needs to be contained in the message 
>>>>>>> to
>>>>>>> the
>>>>>>> list. It is insufficient to head up a message major 
>>>>>>> vulnerability
>>>>>>> referring to private discussions - which I am unaware of BTW - 
>>>>>>> and
>>>>>>> suggest there is some major problem without any substance in the
>>>>>>> mail
>>>>>>> of what the issue is!  Of course not many people would post such
>>>>>>> FUD
>>>>>>> this way.
>>>>>>>
>>>>>>> I prefer to have any issues completely on the (developers) table
>>>>>>> so
>>>>>>> we
>>>>>>> can discuss them and come up with a solution if necessary 
>>>>>>> quickly
>>>>>>> and
>>>>>>> advise the users ASAP. We are an open source project and well 
>>>>>>> ...
>>>>>>> open. I do however, try to keep these forums/lists free of
>>>>>>> FUD/nonsense.
>>>>>>>
>>>>>>> I am aware of the $AllowAnyone issue which gave access to the GL
>>>>>>> Trial
>>>>>>> balance - which is now fixed and I have published a note to 
>>>>>>> advise
>>>>>>> users.
>>>>>>>
>>>>>>> If there are any incorrect statements in messages to the list or
>>>>>>> the
>>>>>>> forum then I will try to remove them to avoid misleading anyone.
>>>>>>> Although this is not always easy.
>>>>>>>
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> Ph: +64 (0)275 567890
>>>>>>> Skype: daintree
>>>>>>> http://www.logicworks.co.nz
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>>> "Graph Databases" is the definitive new guide to graph databases
>>>>>>> and
>>>>>>> their
>>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>>> this first edition is now available. Download your free book
>>>>>>> today!
>>>>>>> http://p.sf.net/sfu/13534_NeoTech_______________________________________________
>>>>>>> Web-erp-developers mailing list
>>>>>>> Web...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>>>> ------------------------------------------------------------------------------
>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>> "Graph Databases" is the definitive new guide to graph databases
>>>>>> and
>>>>>> their
>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>> this first edition is now available. Download your free book 
>>>>>> today!
>>>>>> http://p.sf.net/sfu/13534_NeoTech
>>>>>> _______________________________________________
>>>>>> Web-erp-developers mailing list
>>>>>> Web...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases 
>>>>> and
>>>>> their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book 
>>>>> today!
>>>>> http://p.sf.net/sfu/13534_NeoTech
>>>>> _______________________________________________
>>>>> Web-erp-developers mailing list
>>>>> Web...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases 
>>>> and
>>>> their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/13534_NeoTech
>>>> _______________________________________________
>>>> Web-erp-developers mailing list
>>>> Web...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Web-erp-developers mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and 
>> their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and 
> their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] Reporting Of Issues

[Phil D. <ph...@lo...>]

OK we have a new

sec...@we...

address that goes to Jo/Exson and I

If you want to have a go at the bug tracker it is all yours. I am not 
keen to upload some other software though.

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 13/03/14 21:51, icedlava wrote:
>> Yes that's how the thinking went - if we really want feedback on bugs
>> then we need to make it easy to report - so the forum was the place.
>>
> hehe - in truth i've never really liked forums as I find them a bit
> cumbersome for tracking things and having to log in to the web. Always
> preferred mailing lists.
>
> Having a web based bug tracker is much the same as a forum but has the
> benefit that you can track, search, assign, hide, etc each bug as
> necessarily. i.e. better for management of issues and historical
> use/looking back for checking.
>
> Again, if you do want someone to manage the bug tracker then I'm happy
> to do it, along with anyone else that wants to volunteer. I like bug
> trackers a lot. But i'd recommend you put a link to the bug tracker in
> the forum if you do use it.
>
> I agree and think the developer list is great for discussion.
>
> The reason this came up though is due to the security reporting process
> - would only work as intended if we had a place where the report could
> be initially out of public view -  developer list is open right?
>
> As a simple alternative, setting up email sec...@we... and having
> it go to at least 3 people, or some secure non-public mail list would
> work too to keep the report out of public eye until assessed. Perhaps
> that's the way to go?
>
> Happy to support whatever is agreed.
>
> Cheers,
>
>
> On 13 Mar 2014, at 18:40, Phil Daintree wrote:
>
>> Yes that's how the thinking went - if we really want feedback on bugs
>> then we need to make it easy to report - so the forum was the place.
>>
>> I really do believe if there are issues then the developers list is
>> where they belong unless we have a full time administrator working on
>> the bug tracker.
>>
>> I am thinking of ditching the bug tracker unless anyone has violent
>> objections or wishes to take it on - not sure how I got talked into
>> putting it up!
>>
>> Phil
>>
>> Phil Daintree
>> Logic Works Ltd - +64 (0)275 567890
>> http://www.logicworks.co.nz
>>
>> On 13/03/14 20:35, icedlava wrote:
>>> I believe a bug tracker works if all bugs are directed there
>>> otherwise
>>> it's just overhead. I do have an account there but as there is a bugs
>>> forum it seems redundant (and maybe why the tracker is not used more
>>> -
>>> doesn't seem to be easy to find the tracker either).
>>>
>>>> it is still there is you are keen to pick it up and give it a
>>>> birthday
>>> If there is one supported place for tracking bugs and communication
>>> on
>>> them, I'd be happy to maintain the bug tracker or lend a hand to
>>> whoever
>>> is doing it now (even tho i'm definitely not keen on Mantis). Just
>>> say
>>> the word.
>>>
>>> My point about a security email address (directing to a private list
>>> or
>>> shared mail address) was because sometimes a person just want to
>>> quickly
>>> report something and know it's not going public.
>>>
>>> I agree with you that the developers mailing list is very useful and
>>> prefer it to forums. However it's public, and therefore does not fit
>>> the
>>> requirements for private reporting of security vulnerabilities. Once
>>> information is published there it remains public and searchable.
>>>
>>> Thanks for the feedback.
>>>
>>> cheers
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 13 Mar 2014, at 17:39, Phil Daintree wrote:
>>>
>>>> We already have a bug tracker.
>>>>
>>>> The snag with it though is that it is unmaintained - I can't
>>>> remember
>>>> who put their hand up keen to administer it, but they have not been
>>>> able
>>>> to keep it up. I must say I was sceptical at the time for just this
>>>> reason and stated up front that I did not want to maintain it
>>>> myself.
>>>> However, it is still there is you are keen to pick it up and give it
>>>> a
>>>> birthday.
>>>>
>>>> http://www.weberp.org/bugs
>>>>
>>>> What you say is good sense. However, I still feel that this is what
>>>> the
>>>> developers mailing list is for.
>>>>
>>>> Phil
>>>>
>>>> Phil Daintree
>>>> Logic Works Ltd - +64 (0)275 567890
>>>> http://www.logicworks.co.nz
>>>>
>>>> On 13/03/14 15:27, icedlava wrote:
>>>>> Hi Phil,
>>>>>
>>>>> Perhaps there could be a security reporting process that attempts
>>>>> to
>>>>> keep any vulnerabilities out of public eye until they are assessed
>>>>> and
>>>>> fixed and patch posted, depending on the severity.
>>>>>
>>>>> Some security issues are not as severe as others and would not hurt
>>>>> being publicly posted. Others might need urgent attention and
>>>>> fixing
>>>>> prior to publishing any info or hints to it, to ensure websites are
>>>>> not
>>>>> taken advantage of prior to the fix being applied.
>>>>>
>>>>> Example :
>>>>>
>>>>> 1. All security vulnerability posts to go to an email
>>>>> sec...@we... that is received to a closed list, viewable
>>>>> only
>>>>> to
>>>>> a list of developers. There would hopefully be at least one person
>>>>> that
>>>>> could receive /read it immediately and assess the severity, or
>>>>> notify
>>>>> someone who could assess it if they didn't know.
>>>>> Most bug trackers also have the ability to post directly and not be
>>>>> viewed publicly - e.g. only viewable to a permission enabled list
>>>>> of
>>>>> people .
>>>>>
>>>>> 2. This email and/or bug tracker link could be publicised on
>>>>> weberp.org
>>>>> along with how security issues are handled.
>>>>>
>>>>> 3. If it is not a severe vulnerability, it could be publicly
>>>>> published
>>>>> to the list/forum/bug tracker for discussion or fixing
>>>>>
>>>>> 4. If it is severe and needs discussion, it could be posted to a
>>>>> 'closed' forum or bug tracker item that is open to all approved
>>>>> developers. They could address the issue, provide a patch.
>>>>> Once the patch is provided, it could be published openly.
>>>>>
>>>>> 5. Where a report is published openly before it becomes or is known
>>>>> as a
>>>>> severe security issue (e.g. list or forum), then hopefully before
>>>>> any
>>>>> key information is provided about it, discussion can be moved to
>>>>> the
>>>>> closed list/bug tracker for processing as in 3. This problem could
>>>>> be
>>>>> overcome by having a dedicated bug tracker that is always promoted
>>>>> to
>>>>> be
>>>>> used for any issue, as the bug could be hidden to the public along
>>>>> with
>>>>> any existing discussion (in most trackers) as soon as it becomes
>>>>> evident
>>>>> it's a security related one.
>>>>>
>>>>> Just a rough idea.
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 13 Mar 2014, at 9:46, Phil Daintree wrote:
>>>>>
>>>>>> There is no secrecy here.
>>>>>>
>>>>>> If there is some issue that you are aware of then obviously the
>>>>>> meat
>>>>>> of what the issue is about needs to be contained in the message to
>>>>>> the
>>>>>> list. It is insufficient to head up a message major vulnerability
>>>>>> referring to private discussions - which I am unaware of BTW - and
>>>>>> suggest there is some major problem without any substance in the
>>>>>> mail
>>>>>> of what the issue is!  Of course not many people would post such
>>>>>> FUD
>>>>>> this way.
>>>>>>
>>>>>> I prefer to have any issues completely on the (developers) table
>>>>>> so
>>>>>> we
>>>>>> can discuss them and come up with a solution if necessary quickly
>>>>>> and
>>>>>> advise the users ASAP. We are an open source project and well ...
>>>>>> open. I do however, try to keep these forums/lists free of
>>>>>> FUD/nonsense.
>>>>>>
>>>>>> I am aware of the $AllowAnyone issue which gave access to the GL
>>>>>> Trial
>>>>>> balance - which is now fixed and I have published a note to advise
>>>>>> users.
>>>>>>
>>>>>> If there are any incorrect statements in messages to the list or
>>>>>> the
>>>>>> forum then I will try to remove them to avoid misleading anyone.
>>>>>> Although this is not always easy.
>>>>>>
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> Ph: +64 (0)275 567890
>>>>>> Skype: daintree
>>>>>> http://www.logicworks.co.nz
>>>>>> ------------------------------------------------------------------------------
>>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>>> "Graph Databases" is the definitive new guide to graph databases
>>>>>> and
>>>>>> their
>>>>>> applications. Written by three acclaimed leaders in the field,
>>>>>> this first edition is now available. Download your free book
>>>>>> today!
>>>>>> http://p.sf.net/sfu/13534_NeoTech_______________________________________________
>>>>>> Web-erp-developers mailing list
>>>>>> Web...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases
>>>>> and
>>>>> their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book today!
>>>>> http://p.sf.net/sfu/13534_NeoTech
>>>>> _______________________________________________
>>>>> Web-erp-developers mailing list
>>>>> Web...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and
>>>> their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/13534_NeoTech
>>>> _______________________________________________
>>>> Web-erp-developers mailing list
>>>> Web...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Web-erp-developers mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and
>> their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [WebERP-developers] Reporting Of Issues

[icedlava <ice...@gm...>]

> Yes that's how the thinking went - if we really want feedback on bugs
> then we need to make it easy to report - so the forum was the place.
>

hehe - in truth i've never really liked forums as I find them a bit 
cumbersome for tracking things and having to log in to the web. Always 
preferred mailing lists.

Having a web based bug tracker is much the same as a forum but has the 
benefit that you can track, search, assign, hide, etc each bug as 
necessarily. i.e. better for management of issues and historical 
use/looking back for checking.

Again, if you do want someone to manage the bug tracker then I'm happy 
to do it, along with anyone else that wants to volunteer. I like bug 
trackers a lot. But i'd recommend you put a link to the bug tracker in 
the forum if you do use it.

I agree and think the developer list is great for discussion.

The reason this came up though is due to the security reporting process 
- would only work as intended if we had a place where the report could 
be initially out of public view -  developer list is open right?

As a simple alternative, setting up email sec...@we... and having 
it go to at least 3 people, or some secure non-public mail list would 
work too to keep the report out of public eye until assessed. Perhaps 
that's the way to go?

Happy to support whatever is agreed.

Cheers,


On 13 Mar 2014, at 18:40, Phil Daintree wrote:

> Yes that's how the thinking went - if we really want feedback on bugs
> then we need to make it easy to report - so the forum was the place.
>
> I really do believe if there are issues then the developers list is
> where they belong unless we have a full time administrator working on
> the bug tracker.
>
> I am thinking of ditching the bug tracker unless anyone has violent
> objections or wishes to take it on - not sure how I got talked into
> putting it up!
>
> Phil
>
> Phil Daintree
> Logic Works Ltd - +64 (0)275 567890
> http://www.logicworks.co.nz
>
> On 13/03/14 20:35, icedlava wrote:
>> I believe a bug tracker works if all bugs are directed there 
>> otherwise
>> it's just overhead. I do have an account there but as there is a bugs
>> forum it seems redundant (and maybe why the tracker is not used more 
>> -
>> doesn't seem to be easy to find the tracker either).
>>
>>> it is still there is you are keen to pick it up and give it a 
>>> birthday
>> If there is one supported place for tracking bugs and communication 
>> on
>> them, I'd be happy to maintain the bug tracker or lend a hand to 
>> whoever
>> is doing it now (even tho i'm definitely not keen on Mantis). Just 
>> say
>> the word.
>>
>> My point about a security email address (directing to a private list 
>> or
>> shared mail address) was because sometimes a person just want to 
>> quickly
>> report something and know it's not going public.
>>
>> I agree with you that the developers mailing list is very useful and
>> prefer it to forums. However it's public, and therefore does not fit 
>> the
>> requirements for private reporting of security vulnerabilities. Once
>> information is published there it remains public and searchable.
>>
>> Thanks for the feedback.
>>
>> cheers
>>
>>
>>
>>
>>
>>
>> On 13 Mar 2014, at 17:39, Phil Daintree wrote:
>>
>>> We already have a bug tracker.
>>>
>>> The snag with it though is that it is unmaintained - I can't 
>>> remember
>>> who put their hand up keen to administer it, but they have not been
>>> able
>>> to keep it up. I must say I was sceptical at the time for just this
>>> reason and stated up front that I did not want to maintain it 
>>> myself.
>>> However, it is still there is you are keen to pick it up and give it 
>>> a
>>> birthday.
>>>
>>> http://www.weberp.org/bugs
>>>
>>> What you say is good sense. However, I still feel that this is what
>>> the
>>> developers mailing list is for.
>>>
>>> Phil
>>>
>>> Phil Daintree
>>> Logic Works Ltd - +64 (0)275 567890
>>> http://www.logicworks.co.nz
>>>
>>> On 13/03/14 15:27, icedlava wrote:
>>>> Hi Phil,
>>>>
>>>> Perhaps there could be a security reporting process that attempts 
>>>> to
>>>> keep any vulnerabilities out of public eye until they are assessed
>>>> and
>>>> fixed and patch posted, depending on the severity.
>>>>
>>>> Some security issues are not as severe as others and would not hurt
>>>> being publicly posted. Others might need urgent attention and 
>>>> fixing
>>>> prior to publishing any info or hints to it, to ensure websites are
>>>> not
>>>> taken advantage of prior to the fix being applied.
>>>>
>>>> Example :
>>>>
>>>> 1. All security vulnerability posts to go to an email
>>>> sec...@we... that is received to a closed list, viewable 
>>>> only
>>>> to
>>>> a list of developers. There would hopefully be at least one person
>>>> that
>>>> could receive /read it immediately and assess the severity, or 
>>>> notify
>>>> someone who could assess it if they didn't know.
>>>> Most bug trackers also have the ability to post directly and not be
>>>> viewed publicly - e.g. only viewable to a permission enabled list 
>>>> of
>>>> people .
>>>>
>>>> 2. This email and/or bug tracker link could be publicised on
>>>> weberp.org
>>>> along with how security issues are handled.
>>>>
>>>> 3. If it is not a severe vulnerability, it could be publicly
>>>> published
>>>> to the list/forum/bug tracker for discussion or fixing
>>>>
>>>> 4. If it is severe and needs discussion, it could be posted to a
>>>> 'closed' forum or bug tracker item that is open to all approved
>>>> developers. They could address the issue, provide a patch.
>>>> Once the patch is provided, it could be published openly.
>>>>
>>>> 5. Where a report is published openly before it becomes or is known
>>>> as a
>>>> severe security issue (e.g. list or forum), then hopefully before 
>>>> any
>>>> key information is provided about it, discussion can be moved to 
>>>> the
>>>> closed list/bug tracker for processing as in 3. This problem could 
>>>> be
>>>> overcome by having a dedicated bug tracker that is always promoted 
>>>> to
>>>> be
>>>> used for any issue, as the bug could be hidden to the public along
>>>> with
>>>> any existing discussion (in most trackers) as soon as it becomes
>>>> evident
>>>> it's a security related one.
>>>>
>>>> Just a rough idea.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>>
>>>> On 13 Mar 2014, at 9:46, Phil Daintree wrote:
>>>>
>>>>> There is no secrecy here.
>>>>>
>>>>> If there is some issue that you are aware of then obviously the 
>>>>> meat
>>>>> of what the issue is about needs to be contained in the message to
>>>>> the
>>>>> list. It is insufficient to head up a message major vulnerability
>>>>> referring to private discussions - which I am unaware of BTW - and
>>>>> suggest there is some major problem without any substance in the
>>>>> mail
>>>>> of what the issue is!  Of course not many people would post such 
>>>>> FUD
>>>>> this way.
>>>>>
>>>>> I prefer to have any issues completely on the (developers) table 
>>>>> so
>>>>> we
>>>>> can discuss them and come up with a solution if necessary quickly
>>>>> and
>>>>> advise the users ASAP. We are an open source project and well ...
>>>>> open. I do however, try to keep these forums/lists free of
>>>>> FUD/nonsense.
>>>>>
>>>>> I am aware of the $AllowAnyone issue which gave access to the GL
>>>>> Trial
>>>>> balance - which is now fixed and I have published a note to advise
>>>>> users.
>>>>>
>>>>> If there are any incorrect statements in messages to the list or 
>>>>> the
>>>>> forum then I will try to remove them to avoid misleading anyone.
>>>>> Although this is not always easy.
>>>>>
>>>>>
>>>>> Phil
>>>>>
>>>>> Ph: +64 (0)275 567890
>>>>> Skype: daintree
>>>>> http://www.logicworks.co.nz
>>>>> ------------------------------------------------------------------------------
>>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>>> "Graph Databases" is the definitive new guide to graph databases 
>>>>> and
>>>>> their
>>>>> applications. Written by three acclaimed leaders in the field,
>>>>> this first edition is now available. Download your free book 
>>>>> today!
>>>>> http://p.sf.net/sfu/13534_NeoTech_______________________________________________
>>>>> Web-erp-developers mailing list
>>>>> Web...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases 
>>>> and
>>>> their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/13534_NeoTech
>>>> _______________________________________________
>>>> Web-erp-developers mailing list
>>>> Web...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Web-erp-developers mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and 
>> their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and 
> their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] Reporting Of Issues

[Phil D. <ph...@lo...>]

Hi Jo,

I think it would be great to formalise the system for reporting security
issues as you outlined. Hopefully this would eliminate any future
misunderstandings like this.

Thanks
Tim

Re: [WebERP-developers] Reporting Of Issues

[Phil D. <ph...@lo...>]

Yes that's how the thinking went - if we really want feedback on bugs 
then we need to make it easy to report - so the forum was the place.

I really do believe if there are issues then the developers list is 
where they belong unless we have a full time administrator working on 
the bug tracker.

I am thinking of ditching the bug tracker unless anyone has violent 
objections or wishes to take it on - not sure how I got talked into 
putting it up!

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 13/03/14 20:35, icedlava wrote:
> I believe a bug tracker works if all bugs are directed there otherwise
> it's just overhead. I do have an account there but as there is a bugs
> forum it seems redundant (and maybe why the tracker is not used more -
> doesn't seem to be easy to find the tracker either).
>
>> it is still there is you are keen to pick it up and give it a birthday
> If there is one supported place for tracking bugs and communication on
> them, I'd be happy to maintain the bug tracker or lend a hand to whoever
> is doing it now (even tho i'm definitely not keen on Mantis). Just say
> the word.
>
> My point about a security email address (directing to a private list or
> shared mail address) was because sometimes a person just want to quickly
> report something and know it's not going public.
>
> I agree with you that the developers mailing list is very useful and
> prefer it to forums. However it's public, and therefore does not fit the
> requirements for private reporting of security vulnerabilities. Once
> information is published there it remains public and searchable.
>
> Thanks for the feedback.
>
> cheers
>
>
>
>
>
>
> On 13 Mar 2014, at 17:39, Phil Daintree wrote:
>
>> We already have a bug tracker.
>>
>> The snag with it though is that it is unmaintained - I can't remember
>> who put their hand up keen to administer it, but they have not been
>> able
>> to keep it up. I must say I was sceptical at the time for just this
>> reason and stated up front that I did not want to maintain it myself.
>> However, it is still there is you are keen to pick it up and give it a
>> birthday.
>>
>> http://www.weberp.org/bugs
>>
>> What you say is good sense. However, I still feel that this is what
>> the
>> developers mailing list is for.
>>
>> Phil
>>
>> Phil Daintree
>> Logic Works Ltd - +64 (0)275 567890
>> http://www.logicworks.co.nz
>>
>> On 13/03/14 15:27, icedlava wrote:
>>> Hi Phil,
>>>
>>> Perhaps there could be a security reporting process that attempts to
>>> keep any vulnerabilities out of public eye until they are assessed
>>> and
>>> fixed and patch posted, depending on the severity.
>>>
>>> Some security issues are not as severe as others and would not hurt
>>> being publicly posted. Others might need urgent attention and fixing
>>> prior to publishing any info or hints to it, to ensure websites are
>>> not
>>> taken advantage of prior to the fix being applied.
>>>
>>> Example :
>>>
>>> 1. All security vulnerability posts to go to an email
>>> sec...@we... that is received to a closed list, viewable only
>>> to
>>> a list of developers. There would hopefully be at least one person
>>> that
>>> could receive /read it immediately and assess the severity, or notify
>>> someone who could assess it if they didn't know.
>>> Most bug trackers also have the ability to post directly and not be
>>> viewed publicly - e.g. only viewable to a permission enabled list of
>>> people .
>>>
>>> 2. This email and/or bug tracker link could be publicised on
>>> weberp.org
>>> along with how security issues are handled.
>>>
>>> 3. If it is not a severe vulnerability, it could be publicly
>>> published
>>> to the list/forum/bug tracker for discussion or fixing
>>>
>>> 4. If it is severe and needs discussion, it could be posted to a
>>> 'closed' forum or bug tracker item that is open to all approved
>>> developers. They could address the issue, provide a patch.
>>> Once the patch is provided, it could be published openly.
>>>
>>> 5. Where a report is published openly before it becomes or is known
>>> as a
>>> severe security issue (e.g. list or forum), then hopefully before any
>>> key information is provided about it, discussion can be moved to the
>>> closed list/bug tracker for processing as in 3. This problem could be
>>> overcome by having a dedicated bug tracker that is always promoted to
>>> be
>>> used for any issue, as the bug could be hidden to the public along
>>> with
>>> any existing discussion (in most trackers) as soon as it becomes
>>> evident
>>> it's a security related one.
>>>
>>> Just a rough idea.
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>> On 13 Mar 2014, at 9:46, Phil Daintree wrote:
>>>
>>>> There is no secrecy here.
>>>>
>>>> If there is some issue that you are aware of then obviously the meat
>>>> of what the issue is about needs to be contained in the message to
>>>> the
>>>> list. It is insufficient to head up a message major vulnerability
>>>> referring to private discussions - which I am unaware of BTW - and
>>>> suggest there is some major problem without any substance in the
>>>> mail
>>>> of what the issue is!  Of course not many people would post such FUD
>>>> this way.
>>>>
>>>> I prefer to have any issues completely on the (developers) table so
>>>> we
>>>> can discuss them and come up with a solution if necessary quickly
>>>> and
>>>> advise the users ASAP. We are an open source project and well ...
>>>> open. I do however, try to keep these forums/lists free of
>>>> FUD/nonsense.
>>>>
>>>> I am aware of the $AllowAnyone issue which gave access to the GL
>>>> Trial
>>>> balance - which is now fixed and I have published a note to advise
>>>> users.
>>>>
>>>> If there are any incorrect statements in messages to the list or the
>>>> forum then I will try to remove them to avoid misleading anyone.
>>>> Although this is not always easy.
>>>>
>>>>
>>>> Phil
>>>>
>>>> Ph: +64 (0)275 567890
>>>> Skype: daintree
>>>> http://www.logicworks.co.nz
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases and
>>>> their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/13534_NeoTech_______________________________________________
>>>> Web-erp-developers mailing list
>>>> Web...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Web-erp-developers mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and
>> their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [WebERP-developers] Reporting Of Issues

[icedlava <ice...@gm...>]

Tim,

What do you think of the ideas for some security reporting process as I 
posted in separate thread?

Any suggestions?

Cheers,



On 13 Mar 2014, at 18:09, Tim Schofield wrote:

> Phil,
>
> I didn't put the details in for the reasons Jo has said,  that it 
> would
> help any malicious person. I did refer you to the email that Exson 
> sent you
> regarding the matter, and that email did provide full details.
>
> If you wanted more information surely the correct thing to do was ask,
> rather than block my forum access?
>
> Tim
>
>
> On 12 March 2014 23:16, Phil Daintree <ph...@lo...> wrote:
>
>> There is no secrecy here.
>>
>> If there is some issue that you are aware of then obviously the meat 
>> of
>> what the issue is about needs to be contained in the message to the 
>> list.
>> It is insufficient to head up a message major vulnerability referring 
>> to
>> private discussions - which I am unaware of BTW - and suggest there 
>> is some
>> major problem without any substance in the mail of what the issue is! 
>>  Of
>> course not many people would post such FUD this way.
>>
>> I prefer to have any issues completely on the (developers) table so 
>> we
>> can discuss them and come up with a solution if necessary quickly and
>> advise the users ASAP. We are an open source project and well ... 
>> open. I
>> do however, try to keep these forums/lists free of FUD/nonsense.
>>
>> I am aware of the $AllowAnyone issue which gave access to the GL 
>> Trial
>> balance - which is now fixed and I have published a note to advise 
>> users.
>>
>> If there are any incorrect statements in messages to the list or the
>> forum then I will try to remove them to avoid misleading anyone. 
>> Although
>> this is not always easy.
>>
>>
>> Phil
>>
>> Ph: +64 (0)275 567890
>> Skype: daintree
>> http://www.logicworks.co.nz
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and 
>> their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>
>
> -- 
> Course View Towers,
> Plot 21 Yusuf Lule Road,
> Kampala
> T   +256 (0) 312 314 418
> M +256 (0) 752 963 325
> www.weberpafrica.com
> Twitter: @TimSchofield2
> Blog: http://weberpafrica.blogspot.co.uk/

Re: [WebERP-developers] Reporting Of Issues

[Tim S. <tim...@gm...>]

Phil,

I didn't put the details in for the reasons Jo has said,  that it would
help any malicious person. I did refer you to the email that Exson sent you
regarding the matter, and that email did provide full details.

If you wanted more information surely the correct thing to do was ask,
rather than block my forum access?

Tim


On 12 March 2014 23:16, Phil Daintree <ph...@lo...> wrote:

>   There is no secrecy here.
>
>  If there is some issue that you are aware of then obviously the meat of
> what the issue is about needs to be contained in the message to the list.
> It is insufficient to head up a message major vulnerability referring to
> private discussions - which I am unaware of BTW - and suggest there is some
> major problem without any substance in the mail of what the issue is!  Of
> course not many people would post such FUD this way.
>
>  I prefer to have any issues completely on the (developers) table so we
> can discuss them and come up with a solution if necessary quickly and
> advise the users ASAP. We are an open source project and well ... open. I
> do however, try to keep these forums/lists free of FUD/nonsense.
>
>  I am aware of the $AllowAnyone issue which gave access to the GL Trial
> balance - which is now fixed and I have published a note to advise users.
>
>  If there are any incorrect statements in messages to the list or the
> forum then I will try to remove them to avoid misleading anyone. Although
> this is not always easy.
>
>
>  Phil
>
> Ph: +64 (0)275 567890
> Skype: daintree
> http://www.logicworks.co.nz
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>


-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/