I've made a start with the audit of NTOSKRNL. The page
http://www.reactos.org/wiki/index.php/Ntoskrnl_audit contains a list of all
the public (either exported or syscall) routines of our ntoskrnl.exe, with a
template to fill in the audit metrics which were proposed. I already checked
the documentation status of all routines.
GvG
Hey all,
I have finished my security audit of one of the pieces of code in the
new svn repository! (/base/services/tcpsvcs/)
In my audit notes I have listed the problems by simple filename:line,
flaw, description. They are also dated. Is this the same sort of
documentation you would like in svn and bugzilla too?
On that note, what is happening with bugzilla? I seem to remember
someone mentioning that someone was going to go through all the bug
reports and close any that affected non-audited code. Is this
correct? Should I submit my bug report anyway? I'll write something
noticeable in the summary field so it is obvious it is to do with the
security audit.
Are we going to implement something like Peters /documentation/ patch?
If so I will put my security auditing notes in there too.
Cheers,
Martin
Index: documentation/README
===================================================================
--- documentation/README (revision 0)
+++ documentation/README (revision 0)
@@ -0,0 +1,11 @@
+This is the documentation directory for the ReactOS project.
+
+
+Directory Layout:
+
+api\ : Documentation for various APIs.
+articles\ : Howto's, Articles and related documentation.
+audit\ : Documentation about and gathered by the audit.
+reverse.engineering\ : Clean-Room effort documentation.
+ : _Only_ human language and pseudo-code documentation is allowed here.
+
Just an idea to kick around--
With the recent issues of reverse engineering, and our
new-- extra stern-- IP policy, it appears that
"cleanroom implementation" (US style) is going to be
very strictly adhered to. This raises a few concernes
to me, even though I dont develop code.
1) The developers that decide they will become(Stay)
reverse-engineers are going to have a great deal on
their plate allready. Not only will they have to
decompile proprietary binaries, but they will also
have to make documentation about the functions within
those binaries. Asking them to manage the collective
work of both themselves and other reverse engineers is
asking too much.
2) Implementors are not allowed to have direct
communication with reverse engineers, under US style
CleanRoom implementation practices.
So, I propose a new group classification, with the
purposes of
1) Organizing, catalogueing, and possibly correcting
(For spelling, and other grammaticals) the whitepaper
documentation produced by the reverse engineers.
2) Offering the functional service of communicating
with the reverse engineers any objections, or concerns
the implementors might have. (EG, "XXXX XXXX does XXX
XXX by YYYYY" is not sufficent to explain what is
going on, can I get a better description?", the
documentation manager group would contact the reverse
engineer in question, and ask them to make an adendum
to their documentation to address this issue, and
would then contact the implementor after such
addendum(s) have been completed, and filed.)
This group would thus have responsibilities simmilar
to "Editor", "Librarian", and "Secretary", which is
why I propose the generic name "Documentation
Manager(s)."
If there is allready such a position/group, I withdraw
the proposal. Otherwise, I dont see how we could
really hope to pull this off without dedicated
individuals on this task.
(PS, having "non-Coders" on this taskforce would
probably alleviate any allegations of contamination
between reverse engineers and Implemntors, in that it
is unlikely that the secretary in question would
understand a very technical request to begin with, and
thus be unable to pass on any such complicated
requests in their duties as secretary. It would also
give some really strong enthusiasts something to do--
All you need are clerical and communication skills.)
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Has anyone checked out the Samba 4.0 Tech Preview? I think the NTVFS
folder includes code that allows another FS to act like NTFS. But
take a look and tell me if integration to ReactOS would be a good idea.
Please ignore my last diff; this is an improved version.
This diff sets up a directory (ntdocs) where documention and test cases
and be put.
I sugest that the tree for this dir should mirror the actual code base
for ease of use.
Thanks.
Index: ntdocs/readme.txt
===================================================================
--- ntdocs/readme.txt (revision 0)
+++ ntdocs/readme.txt (revision 0)
@@ -0,0 +1,6 @@
+This directory contains the documentation for Reactos (test cases and the like). Please do NOT put actual code here.
+Just enough to implement it. Only human lanuage and puedo-code is allowed here. If you reversed engeneered, it please keep the policy and DO NOT implement it.
+
+The tree layout for the docs should mirror that of the actual code tree for ease of use.
+
+Thanks.
\ No newline at end of file
I think we need to be more organized in this endeavor.
We need to decided who will look at chuck of code, so that the process
goes faster.
I suggest that we pair up into two person teems whose responsibility is
to decide if a certain group of code it dirty or not. These teems will
then look at their area of code systematicly, deciding if part or alll
of the code they come across is dirty. All the clean code will then be
put into the audited trunk, then the stripped stub of the functions that
were dirty.
> From: chorns(a)svn.reactos.org
>
> Document rbuild
> Property changes on: trunk/reactos/tools/rbuild
> Name: svn:doc
It seems your brain is pre-wired to type "svn:..." after "propset" :-)
GvG
