When the COMELEC apologists can not discuss the merits of a case, they throw MUD at the party that brings the case to the Supreme Court. This is what the article and the comment has effectively done. I've been a member of PLUG since it was established in the middle 1990s. A good number of PLUG members know me, and you would not agree to make me the first PLUG president if you thought that I was a bad person, which the comment to the article is trying to suggest.
The person who made the comment: > Now this, another petition before the Supreme Court by the > same group of people who cleverly disguised themselves as > different and independent. made wild accusations without verifying his facts. The first (losing) case was brought to the Supreme Court by Atty Harry Roque together with the Concerned Citizens Movement and the OES organizers. In his pleading, Harry Roque cited a PCIJ article in which I was quoted as stating that "the the entity (Smartmatic in this case) that possesses all the private RSA keys has the capability to control the results of the election", which is truly what I said in the PCIJ interview. From that time of the pleading, the COMELEC apologists have already associated me with Harry Roque and Gus Lagman. Before that Supreme Court hearing, I've never even heard of Harry Roque, and it is unfair to the state that CenPEG is "the same group of people who cleverly disguised themselves as different and independent". The only link between Harry Roque and CenPEG is that Harry Roque cited a PCIJ interview of me, and I am a volunteer CenPEG IT consultant, and Harry Roque did not even ask my permission to use that interview! A certain "Paolo" (who turned out to be Paolo Falcone) actually made a second comment about the article which Mike Mondragon conveniently omits in his citation here. This is Paolo's comment: "You've been watching too many conspiracy theories from G2 chairborne commandos my friend. First and foremost, on what grounds do you level your accusations against Dr. Manalastas et.al? Have you done any due diligence before casting any doubts? Fact of the matter is, Section 12 of RA-9369 allows any interested party to do its own source code review independent of any review or testing that COMELEC itself might want to do. COMELEC decided this already in an en-banc resolution last June 2009, but till now adamantly refuses to actually implement it. Read the complaint letter and the law first and digest it well before spewing garbage." Thank you Mr. Paolo Falcone for clarifying some of the issues here. ~Pablo Manalastas~ --- On Wed, 10/14/09, Michael Mondragon <[email protected]> wrote: > While I am reading some section of the RA provisions, I > stumbled on this comment. > > Src: > http://philippinecommentary.blogspot.com/2009/10/war-over-source-code.html > -- > It is quite ironic that CenPeg continuously accuses Comelec > of delaying tactics when in fact they are part of the group > that is actually causing the delay. First, the Harry Roque > et al case, already setback some of the salient but > important aspects of the contract such as the scheduled > payments to the winning bidder. Comelec in deference and > respect to the Supreme Court, withheld payments to the > contractor. Comelec did not have to do this because the SC > did not issue a TRO on payment but out of respect and > propriety, they withheld payment. Without payment, certain > deliverables will also be delayed. It's still a business > transaction, isn't it? > > Now this, another petition before the Supreme Court by the > same group of people who cleverly disguised themselves as > different and independent. I am beginning to suspect that > this is part of the earth scorching tactics being deployed > by the people behind the OES system. If this new petition is > not handled properly by the Supreme Court, it will > definitely cause another delay. Maybe this is part of the > strategy by these obstructionist cabal to purposely cause > delay in order to eventually kill the project. > > The very insistence of Dr. Manalastas to have the source > code available to his group NOW for review raises some very > interesting suspicions. Does he want to get a peek at the > source code to review its integrity or to copy its code > technology and give it to the OES people? It is quite > arrogant for Dr. Manalastas to demand NOW the source code > from Comelec when it had already given its reasons for not > having it available NOW. > > Even if Comelec approved CenPeg's request to review the > source code, CenPeg is still subject to the same ethical > standards as that of the members of the Advisory Council and > Technical Evaluation Committee, meaning they have to prove > that they are non-partisan, independent and does not have > any vested interest, business or otherwise. > > Now if we can only prove that Dr. Manalastas and Gus Lagman > are cut from the same grain, then we will know their true > motivations! If they can't get in the action, then no one > can...scorch the earth, tsk, tsk! > -- > > Hereby, accusing (indirectly some of us folks - pls correct > me) of delaying. I wonder why this user is aware of what's > really happenning. > > Oscar, I am getting your point here (they made a law > without following it), though what you've posted here is not > implicitly stating about the source code review, but in > section 14 it does. Correct my if my understanding is not > enough. > > -- > SEC. 12. Section 10 of Republic Act No. 8436 is hereby > amended to read as follows: > "SEC.14. Examination and Testing of Equipment or Device of > the AES and Opening of the Source Code for Review. - The > Commission shall allow the political parties and candidates > or their representatives, citizens' arm or their > representatives to examine and test. > -- > > However, the problem I am seeing is that, since payment has > been delayed, there's a problem now in getting the source > code to be delivered to Comelec which in fact its clear that > during procurement - this have been handed over (I'm not > sure if some of the source codes has been delivered modules > or the other way around). So if there are no source code > at all, then why and what do we need to review then? > > Do you think guys, the delay will be the cause (class suit, > etc.) of not implementing the Automated Election in 2010? > Will there be another case of un-utilized computers, etc. > where millions has been wasted already? I hope not. > > > Thanks, > Mike > > > > ----- Original Message ---- > From: Oscar Plameras <[email protected]> > To: Philippine Linux Users' Group (PLUG) Technical > Discussion List <[email protected]> > Sent: Wed, October 14, 2009 11:13:30 AM > Subject: Re: [plug] COMELEC SUED (Was: The Death of > Election 2010SourceCodeReview) > > In RA 9369, source code review is part of Section 9, It's > only one of > the sections out of 47 sections > > In that Section 9, again source code review provision is > only one of > the many other provisions amongst the many, and Souce Code > Review is > not even prominent. And I list as follows, > > "Sec 9, ........ > > ............... > .............. > etc. > > 1. Recommend the most appropriate, secure, applicable and > cost-effective technology to be applied in the AES, in > whole or in > part, at that specific form in time. > 2. Participate as nonvoting members of the Bids and Awards > Committee > in the conduct of the bidding process for the AES. Members > of the > Advisory Council representing the ICT Professionals > organizations are > hereby excluded from participating in any manner in the > Bids and > Awards Committee. > > 3. Participate as nonvoting members of the steering > committee tasked > with the implementation of the AES, Members of the Advisory > Council > representing the ICT professional organization are hereby > excluded > from participating in any manner in the steering > committee. > > 4. Provide advice and assistance in the review of the > systems > planning, inception, development, testing, > operationalization, and > evaluation stages. > > 5. Provided advice and/or assistance in the identification, > assessment > and resolution of systems problems or inadequacies as may > surface or > resurface in the course of the bidding, acquisition, > testing, > operationalization, re-use, storage or disposition of the > AES > equipment and/or resources as the case may be. > > 6. Provided advice and/or assistance in the risk management > of the AES > especially when a contingency or disaster situation > arises. > > 7. Prepare and submit a written report, which shall be > submitted > within six months from the date of the election to the > oversight > committee, evaluating the use of the AES.." > > So, by examining RA 9369, there are so many other > considerations > included there to assure the integrity and security of the > AES. > > I am sure the SC will hear all arguments and examine all > evidence and > make their judgments. > > Of course, what's at stake are the Integrity of the > Election results > as well as other practical considerations like, what's the > implication > of annulling the AES for the May 2010 election in terms of > cost, the > common interest, and the Constitution. > > The onus is on the Source Code proponents to convince the > SC that > Source Code Review is the only ( which is not) way to > ensure the > Integrity and Security of the AES system. > > The way it appears to me and others, the Source Code Review > proponents > have their work cut out for them. > > On Wed, Oct 14, 2009 at 1:10 PM, Robert Locke <[email protected]> > wrote: > > > > Even if Mr. Plameras was right (which he's not), it's > irrelevant. The > > source code review is required by law according to Mr. > Manalastas, so > > what's there to argue? This is a legal issue, not a > technical one. > > > > > > > > > > > > On 10 14, 09, at 9:57 AM, Paolo Alexis Falcone wrote: > > > >> Sure we know the dictionary definition, done that > in practice, coded > >> measures to prevent such. > >> > >> A buffer overrun need not terminate the system. > The C and C++ > >> standards mention that handling of such is > undefined. It may crash > >> the system, or be exploited once certain input has > been placed. > >> > >> While it is possible that you can craft a test > that will do buffer > >> overruns over certain inputs, you will have to > craft multiple tests > >> (therefore consuming time and resources) to know > all possible > >> combinations (as the buffer overrun may not be in > your code, but > >> together with a current bug in one of the > libraries, and together an > >> exploit can occur) while a simple source code > check will get there > >> faster. > >> > >> Given undefined behavior, your program may have > the semblance of > >> working properly (which satisfies the tests), but > over the course of > >> time make a sudden crash (had this at work just > last weekend), or at > >> this time be exploited (seen this happen a couple > of times). You > >> cannot simply test against what you dont expect, > since software > >> testing demands that you know your expectations in > order to have a > >> successful UAT. > >> > >> I do understand the tests are measured against a > thousand samples > >> (as you can only fit so much inside a voting > precinct), but your > >> concept of tests being sufficient is already murky > given the > >> arguments and how we poked a hole in your testing > methodology re > >> buffer overruns. > >> > >> A source code review + very good and extensive > tests will be most > >> beneficial and the fastest way to find exploitable > code and fix > >> them. It makes testing easier as you have the > expectations (the > >> source + the tests) absolutely in front of you - > if there are still > >> exploits those are already either in the libraries > used. > >> > >> > >> Sent from my Nokia phone > >> -----Original Message----- > >> From: Oscar Plameras > >> Sent: 2009-10-14 09:23:45 > >> Subject: Re: [plug] COMELEC SUED (Was: The Death > of Election > >> 2010SourceCodeReview) > >> > >> For the benefit of everybody so we know what we > >> are talking about, I will quote this short > article > >> about buffer overruns, > >> > >> "Buffer overrun is s an anomaly where a process > >> stores data in a buffer outside the memory the > >> programmer set aside for it. In computer security > >> and programming, a buffer overflow, or buffer > overrun, > >> is an anomaly where a process stores data in a > buffer > >> outside the memory the programmer set aside for > it. > >> The extra data overwrites adjacent memory, which > >> may contain other data, including program > variables > >> and program flow control data. This may result in > erratic > >> program behavior, including memory access errors, > >> incorrect results, program termination (a crash), > or a > >> breach of system security. > >> > >> Buffer overflows can be triggered by inputs that > are > >> designed to execute code, or alter the way the > program > >> operates. They are thus the basis of many > software > >> vulnerabilities and can be maliciously exploited. > >> Bounds checking can prevent buffer overflows. > >> > >> Programming languages commonly associated > >> with buffer overflows include C and C++, which > provide > >> no built-in protection against accessing or > overwriting > >> data in any part of memory and do not > automatically > >> check that data written to an array (the built-in > buffer > >> type) is within the boundaries of that array." as > quoted > >> from http://en.wikipedia.org/wiki/Buffer_overflow > >> > >> We are interested in, > >> > >> 1. "This may result in erratic program behavior, > >> including memory access errors..." in which case > the > >> program will abruptly terminate. This will be > caught by > >> the Outcome test. > >> > >> 2. "incorrect results..", This will be caught also > by the > >> Outcome test > >> > >> 3. Program termination (a crash),..", which will > be caught > >> by the Outcome test because the program crashes. > >> > >> 4. " or a breach of system security" meaning > absurd or > >> corrupt results will be generated. The Outcome > test > >> will again check the Actual Outputs against the > Expected > >> Outputs. And since the two do not agree the system > is > >> rejected.. > >> > >> > >> > >> > >> On Wed, Oct 14, 2009 at 11:47 AM, Gideon Guillen > >> <[email protected]> > wrote: > >>> On Wed, Oct 14, 2009 at 7:38 AM, Oscar > Plameras <[email protected] > >>> > wrote: > >>>> I'm as bored as you are with arguments > going around in > >>>> circles. It's like watching dogs chasing > their tails. > >>> > >>> You still haven't addressed the issue about > your output based method > >>> not addressing security issues. Remember the > part of the thread > >>> wherein actual voting machines used in a major > industrialized country > >>> shipping with real and exploitable buffer > overrun security > >>> vulnerabilities. And, contrary to you last > post about it, you don't > >>> need to overload a system to exploit it. Just > one seemingly valid > >>> malformed input is all it takes to explot it. > You can use > >>> vulnerabilities to make the machine do things > outside the scope of > >>> your output based testing, such as inserting > and executing > >>> "dagdag-bawas" code. > >>> > >>>> As a matter of interest there was a > previous court decision > >>>> on a similar matter which was ruled by SC > in favor of the > >>>> Comelec. > >>> > >>> The previous ruling has nothing to do with the > source code auditing, > >>> though. It has to do with the validity of the > bid. > >>> > _________________________________________________ > >>> Philippine Linux Users' Group (PLUG) Mailing > List > >>> http://lists.linux.org.ph/mailman/listinfo/plug > >>> Searchable Archives: http://archives.free.net.ph > >>> > >> _________________________________________________ > >> Philippine Linux Users' Group (PLUG) Mailing List > >> http://lists.linux..org.ph/mailman/listinfo/plug > >> Searchable Archives: http://archives.free.net.ph > >> > >> _________________________________________________ > >> Philippine Linux Users' Group (PLUG) Mailing List > >> http://lists.linux.org.ph/mailman/listinfo/plug > >> Searchable Archives: http://archives.free.net.ph > > > > _________________________________________________ > > Philippine Linux Users' Group (PLUG) Mailing List > > http://lists.linux.org.ph/mailman/listinfo/plug > > Searchable Archives: http://archives.free.net.ph > > > _________________________________________________ > Philippine Linux Users' Group (PLUG) Mailing List > http://lists.linux.org.ph/mailman/listinfo/plug > Searchable Archives: http://archives.free.net.ph > > > > > > _________________________________________________ > Philippine Linux Users' Group (PLUG) Mailing List > http://lists.linux.org.ph/mailman/listinfo/plug > Searchable Archives: http://archives.free.net.ph > _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
