...
I assume SVN is starting from Scratch?
On 1/27/06, chorns(a)svn.reactos.org <chorns(a)svn.reactos.org> wrote:
> Standard repository layout
>
>
> Added files:
> branches/
> tags/
> trunk/
> vendor/
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
>
--
"I had a handle on life, but then it broke"
Hello,
There has been a lot of talk about possible tainted code in ReactOS
and or developers that had access to leaked Microsoft source code.
This has caused a lot of speculation about the future of the ReactOS
Project. I'm going to try to put those fears to rest and explain what
has been going on and where we are going to go from here.
There was one issue that started this discussion and it related to
clean-room reverse engineering of certain code in ReactOS. Due to the
fact we have developers in many different countries the term reverse
engineering can mean many things to many different people. For us in
the US when you speak of clean-room reverse engineering it means that
one person tears apart the implementation of a device, writes
documentation and another reads that documentation and implements.
Other countries do not require this invisible great wall of
development and allow the same person that disassembles the interface
to also write the replacement implementation.
Because of the confusion this has caused and the possible legal issues
this could lead to we have decided to do the following.
1) Amend our Intellectual Property Policy Statement to reflect
clean-room reverse engineering as meaning the US standard method for
reverse engineering and make that the project requirement
2) Audit the entire source tree and rewrite all code found to have
been implemented not using the US method for reverse Engineering
3) Require all developers contributing major code to accept the terms
of our IP Policy Document via signature.
Now as for the issue of leaked source code, I want to try to put all
fears to rest. We don't know what the legal ramifications are for
someone downloading and having leaked code, as the party that
maintains copyright ownership of that code might still try to claim
Trade Secrecy on information contained in the sources in a court of
law. It is our point of view that the source code leaks of Windows
have been spread to a broad enough audience that it would be
impossible to claim the product is still under Trade Secrecy. Because
of this we are not banning any developer who might have had access to
leaked sources from contributing to ReactOS, however they are being
limited as to what area they can contribute. Copyright law still
applies to all leaked Windows sources and no one in ReactOS may copy
code from a Windows source leak and try to apply it to code in the
ReactOS tree.
We know of four developers who have had access to leaked sources prior
to working on ReactOS and while they no longer have copies of the
source code in question, each of the developers have told us in
private which sections of the sources they were exposed to. As such
the project has amending the IP document as a fourth step of
protection
4) any developer that had access to leaked sources is baned from
contributing code to the project for any of the modules that are the
same as leaked sources they examined.
So to clarify that, lets say someone saw some of the leaked Windows
source code in version.dll, then they would be unable to contribute
code to the ReactOS project for that dll.
It is our hope that a court case will arise and declare Microsoft's
Windows code is no longer under Trade Secret protection so these
developers who did have access to some of the leaked sources will be
free to contribute again to all sections of the project.
One final note, this audit of the code is going to take a long time.
It could take years, but it will happen, this project will come out
better than it was before. I don't believe anything anyone has done
while working on this project was really wrong. Every decision has
three possibilities, being moral, ethical and or legal. Sometimes the
law in itself is unethical and immoral. If people made mistakes and
there was a violation of the law, I question the justice of the law
and or anyone that would try to prosecute any of the developers who
just want the freedom to learn and create a more free system.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello,
Sorry for this general email. I have gotten many personal emails about
the current situation and cannot reply to all of them. In short here
is the deal:
There have been allegations about possible copyright and trade secret
violations in the ReactOS Project. Pending a discussion with legal
council, those members with SVN access who were part of private
discussion and online on IRC on Tuesday Jan 24th 2006 decided by
majority vote to suspend operations of public SVN, forum, discussion
and email archive. Anyone with SVN write access who might have missed
any of the discussion is asked to try to be on IRC today at 3PM EST
(-5GMT). We are going to discuss the matter further and decide how to
proceed.
What started out as a question about development methods mushroomed in
to a much larger issue. The question the looms before us is a simple
one. If one or more developers had at any leaked source code in the
past, does it taint us and the entire project in the future? It is my
point of view based on the AT&T Unix case that it does not however
IANAL. It is my hope the matter can be solved via a simple set of
changes in our IP Policy as well as sworn affidavits by major
contributors stating they do not have access to leaked sources and if
they ever did, no longer possess them.
Rest assured that the project will live on. Every developer I have
spoken with wants the project to survive and be a success. In the
meantime we are filtering email discussion on this matter because we
do not want rumor and hearsay to be spread. When the time comes and we
have proper legal advice we will move forward. No one is trying to
hide the truth, but law regarding Copyright, Trade Secret, Patent, etc
differ from one country to another and we are currently exploring what
US law says regarding the situation.
One final note, no one is denying that mistakes could have been made
and or trying to hide it forever and pretend there is nothing going
on. We just simply do not want people to be accused of breaking the
law if they really did not. There is clearly some violation of our
current IP policy, however depending on what the legal council
suggests we will see how we move forward. Many of the core developers
at some point have either violated small sections of it by mistake or
prior to its ratification.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
IANAL but from what I understand, there are 2 issues with using the leaked
source code.
The first is that it is (C) Microsoft. This can be handled like any other
copyrighted material.
The second is that it could be considered a trade secret. I dont know that
much about trade secret law but AFAIK once something is widely distributed
(like the MS 2000 & NT4 source leaks are), it cant be considered a trade
secret anymore. I think that what the ReactOS team needs need is for a
lawyer skilled in the area of trade secret law to answer the question as to
whether the leaked MS source code is still a trade secret or not. (although
unless an actual lawsuit happens that provides a usable precedent either
with the leaked MS source code or a similar leak elsewhere, getting clear
usable advice one way or the other might not be possible)
If it is not, there is no problem with people who have seen it contributing
to any part of ReactOS (as long as there is no copyright violation). If it
is, then there is need to be more careful about people who have seen it
contributing.
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
Hey devs,
I hope the new rules we established will prevent something similar in
the future and I really hope this project will one day succeed. It's not
going to be an easy task, but it can be done. I wish you all best luck
to succeed.
However, the amount of effort more or less wasted, and personal reasons
made me decide that it's better for me to step back for now until
ReactOS some day reaches this point of maturity again. I basically don't
have the resources and energy to devote so much time, again.
Re-inventing the wheel already is controversial, but I personally can't
do it yet another time.
I've met many very talented people ever since I joined almost three
years ago, so it's very sad for me to leave most of this behind. Even
though there were disagreements occasionally, it was great fun for me to
collaborate and create something unique and outstanding. However, I'm
going to try to stay in touch at least.
I encourage everyone to stay if somehow possible and rebuild ReactOS!
Thanks for everything that was done for me and the countless hours of
fun I had with this project.
Best Regards,
Thomas
I was wondering if NTVFS from the Samba 4.0TP would be able to be
integrated with ReactOS? This might add some support for NTFS over
Fat32 or like file systems...
Inproved the implimentation of NdisWriteConfiguration(), by Crashfourit.
Index: drivers/net/ndis/ndis/config.c
===================================================================
--- drivers/net/ndis/ndis/config.c (revision 21005)
+++ drivers/net/ndis/ndis/config.c (working copy)
@@ -66,6 +66,18 @@
ULONG ParameterType = ParameterValue->ParameterType;
ULONG DataSize;
PVOID Data;
+
+ /*
+ The next few lines of code before teh first if statement are used when
+ ParameterType equals NdisParameterHexInteger or NdisParameterInteger.
+ This is done so that Buff can be used beyond the switch statement.
+ */
+ UNICODE_STRING buff;
+ WCHAR str[25];
+
+ Buff->Length=0;
+ Buff->MaximumLength = sizeof(str) / sizeof(str[0]);
+ Buff->Buffer=str;
if(ParameterType != NdisParameterInteger &&
ParameterType != NdisParameterHexInteger &&
@@ -81,12 +93,29 @@
/* reset parameter type to standard reg types */
switch(ParameterType)
{
- /* TODO: figure out what do do with these; are they different? */
+ /*
+ TODO: figure out what do do with these; are they different?
+ Done by Crashfourit
+ */
case NdisParameterHexInteger:
- case NdisParameterInteger:
- ParameterType = REG_SZ;
- Data = &ParameterValue->ParameterData.IntegerData;
- DataSize = sizeof(ULONG);
+ case NdisParameterInteger:
+ {
+ if (!NT_SUCCESS(RtlIntegerToUnicodeString(
+ ParameterValue->ParameterData.IntegerData,
+ ( ParameterType == NdisParameterHexInteger ) ? 16 : 10,
+ &buff))
+ )
+ {
+ *Status = NDIS_STATUS_FAILURE;
+ return;
+ }
+ else
+ {
+ ParameterType = REG_SZ;
+ Data = &Buff->Buffer;
+ DataSize = Buff->Length;
+ }
+ }
break;
case NdisParameterString:
Hey all,
As my exams are now over I will hopefully be having more free time
available to put into ReactOS security. I would like to perform a
security audit of the code base. I've jotted down a few thoughts and
suggestions of mine below and would appreciate feedback on them.
Methodology
I hope to work on the kernel mode code first, working up through the
layers up to application API level code. I feel this is the best
method because, as it has been mentioned before to me on IRC / email ,
some functions canot check the parameters that are passed down to
lower functions.
I understand the following code to run in kernel mode:
/lib/rtl/
/lib/string/
/lib/kjs/
/lib/freetype/
/lib/pseh/
/hal/
/drivers/
/subsys/win32k/
/ntoskrnl/
If you know of any more please let me know.
I was thinking of checking out an entire svn revision and updating
only after I had checked an entire library. What do other people
think on this?
I will predominatly be working just from the code source, but after
playing around with Doxygen I have found it to be incredibly useful
for quick referencing typedefs and function parameter calls.
What am I looking for?
I am only a single person, so code auditing will be a slow process at
the moment. I wish to check for the following vulnerabilities:
Incorrect null termination.
Buffer overflows.
Premature termination.
Lack of input validation.
Bad calculations.
Off by one / few.
Personally I feel this list of six common vulnerability types should
be enough to thwart the most common of attacks, but if anyone else
feels some other class of vulnerability is missing from the list
please let me know. Obviously if I find any other bugs then they will
be reported as well.
Reporting of errors?
How should I go about reporting the errors? I was previously told to
report all occasions of the incorrect uses of the RtlAllocateHeap
function under the same bug number (no 1110, some still unfixed). Is
this the preferred method for my code auditing results? I would like
to submit the bugs as quickly as possible, so I can keep my working
tree as close to possible to head, but this may mean submitting
multiple bug reports for the same problem. I think that the best
option is to submit similar bugs in the same module under the same
report, but open a new bug if the same vulnerability occurs in another
module. Thoughts?
These are just some of my ideas that are floating around in my head at
the moment. I would welcome all feedback on this matter and I think I
may create a wiki page with the same information on. Again, thoughts
on this would be nice as I haven't really used wiki's before.
Cheers,
Martin
I noticed that the implimentation of NdisReadConfiguration() is slightly
off, so I fixed it. The reason why this was so is located in the diff as
a comment.
Thanks.
Index: drivers/net/ndis/ndis/config.c
===================================================================
--- drivers/net/ndis/ndis/config.c (revision 20999)
+++ drivers/net/ndis/ndis/config.c (working copy)
@@ -493,8 +493,17 @@
str.Buffer = (PWCHAR)KeyInformation->Data;
(*ParameterValue)->ParameterType = ParameterType;
- *Status = RtlUnicodeStringToInteger(&str, 16, &(*ParameterValue)->ParameterData.IntegerData);
+
+ /*
+ If ParameterType is NdisParameterInteger then the base of str is decimal.
+ If ParameterType is NdisParameterHexInteger then the base of str is hexadecimal.
+ */
+ if (ParameterType == NdisParameterInteger)
+ *Status = RtlUnicodeStringToInteger(&str, 10, &(*ParameterValue)->ParameterData.IntegerData);
+ else if (ParameterType == NdisParameterHexInteger)
+ *Status = RtlUnicodeStringToInteger(&str, 16, &(*ParameterValue)->ParameterData.IntegerData);
ExFreePool(KeyInformation);
if(*Status != STATUS_SUCCESS)
Hi folks,
> Delete libjpeg because sedwards and greatlord thought we should wait
with jpeg support until the patent expired. If someone got a different
opinion please take the issue to ros-dev.
>
>
> Deleted files:
> vendor/libjpeg/
I hereby "take the issue to ros-dev", because I have a different
opinion. ReactOS is filled with patented (to more and lesser extent,
ranging from SEH to scrollbars, I kid you not) features, and I believe
it is hypocritical to simply remove one of them. I don't know the
details on the libjpeg patent, but I do know that linux distributions
use libjpeg as well, and I haven't seen them remove it yet. I officially
request a vote to revert this commit.
Thanks for reading,
mf.
Does this mean the ROS is going to die a violent death?
No hope for a real alternative to M$ Windoze?
I am really looking forward to Version # 1.0.0 of ROS in both x86 and PPC.
People we (you devs) need to stick togather. Become a team! People are
counting on YOU!
ROS-PPC + Open Workstation Computing platform. = Power to the People!
If you have to become 90% WinOS compatable then so be it! 90% is better than
0%
XP apps can be ported to ROS.
Maybe GvG and WD will come back if ROS went in this direction.
Port Linux GNU code if you have to. Lets get a new GUI and a Integrated
sound system.
Use a open file system not FAT. Write a translator for FAT.
--
David Johnson
Voice Talent
http://www.davefilms.us
DaveFilms Digital Media - Audio [TM]
Producer , Writer,
Production Director/ Designer
The solution is quite easy, is Harmut believes the
code could have implemented another way, unrelated to
the microsoft way, i propouse that Alex gives him the
documentation and Harmut does write the code.
Either if Harmut manages to make a quite diferent code
for that piece of reactos, or is proved that there is
no other way of writing the code Reactos developers
can be safe about that particular code.
And just an advice, it seems you MUST meet each other
face to face, to know each other (a few beers would
help) and get a working relationship.I believe there
is no need of theatral posts and the such,
disagreements is habitual when there is more that one
person, but flaming, bashing or threatening is not the
solution. Talking is.
Take it easy,
Lucio Diaz.
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
Gentlemen,
I'd never thought I'd take part in such a debate. Let me comment from a
position of someone who's been folowing this project with great
anticipation and high hopes.
First of all I must say Alex's work and commitment to the project is
outstanding. Maybe it is that he somehow makes his work most visible (I'm
not trying to diminish the great work that all contributors have done).
However the discussion here is about something else. I do not think the
discussion should be going along the lines if things can be done any other
way or not. Also I wouldn't think that what someone called 'intent' is the
most important thing (it maybe would be if it saved lives of people). The
thing here is not about whether Alex understands the code he put into SVN
(extensively) commented.
Let me provide an example here on a bit different level: suppose I like
what a commercial(!) Java (or any other decompilable language) program does
and decide to implement an open-source implementation. Would it be
acceptable if I used decompiler to produce a readable code, study it,
understand it, copy and paste those decompiled sources into my project and
comment it extensively? I do not think so. The argument of understanding
the code is irrelevant in this case as it is irrelevant in ReactOS's case.
Is there so much difference between decompiled Java source code and
disassembled binary (especially when the source has been assembly
probably)?
The issue here is about the method and I believe (and that makes me sad)
the method Alex used was against the law and no good intent can change
that. I think copy-and-paste is illegal under any circumstances (I am
strong oponnent of American patent law). I wish very much that Alex and
Hartmut as well continue to work on this project and we see a day when it
becomes an alternative to Windows. But this case puts the project into big
danger in my opinion.
Just my 2cents.
Best regards
Radovan Skolnik
Recent developments have been quite heated recently, and I would just
like to add in some of my own opinions. If code was directly copied
from Windows then it should be removed. Period. This is against the
aims and charter of this project. If Windows was only disassembled to
gain information on how it works then I think this falls under fair
use. Whether a spec should have been written and another person
implement the spec is a topic which I'm sure will be discussed for a
while to come. This is my point of view on the matter and I will not
discuss it further.
It is unfortunate that WaxDragon is also leaving the project, I'm sure
he will be missed. But people do have lives to lead as well. I'm
sure that in the future I will have to leave the ReactOS project too,
and probably for the same reasons, such as family and work. Ideally I
would like all developers / testers and other contributers to stay
with the project, but I understand that this isn't feasible and I
respect them for what they have contributed during their lifetime with
the project.
I devote some of my spare time to the ReactOS project for two main
reasons:
1. I wish to learn more about operating system development.
2. I wanted to practice my code auditing and security skills on a
project that was of a size that was not too large and mature
(e.g. Linux), while not being so small to be insignificant (various
other home-brew OSs).
Number one is coming along nicely as I'm learning about various topics
such as memory management and how drivers work. Number two is coming
along as well, although much slowly as code auditing a fast moving
project such as this is very time consuming and I have been very busy
lately.
I currently see ReactOS at the same stage of Linux in the mid
nineties. People run it, play with it and contribute to it. The size
of this group of people is not large, but they are usually technically
minded and their number is sufficient for the project to grow and
continue. Development is happening at a fast pace and keeping up can
be time consuming at the moment. Lets not try and loose our drive and
ambition here. You have implemented a fairly significant amount of
the Windows operating system in a relatively short amount of time.
You have contributed code to other projects such as WINE. You have a
large number of applications that can already run on the system. You
have achieved a lot, don't stop now.
I think that ReactOS is at a critical stage in development and once is
becomes a little more stable we will see a large increase in the
number of users beta testing and trying it out. I wish the ReactOS
project to succeed and it is something that I think will occur
eventually.
To all of ReactOS' developers, testers and supporters: You are doing a
great job, don't stop now.
Cheers,
Martin
I hereby resign from the position of Testing Coordinator. Casper,
could you please disable my svn account?
I am leaving for a variety of reasons. First of all, I wish to spend
more of my precious free time with my family. Second, work has become
more demanding of my time. There are many other reasons, including
the way major project issues are handled, and the fact I have not been
able to keep up with the testing and improvements I wished to
implement. This decision has been a long time coming.
It's been great getting to know the ReactOS developers and community,
and have learned a great deal from many of you. I will still stop in
IRC occasionally, and will continue to follow the project.
I think the Testing Coordinator position is a very important position,
and it needs to be filled. I feel that I was able to make a direct
impact on the quality of ReactOS, even though I am not a real
developer. I am willing to provide assistance and information to
anyone who wishes to step up to the position.
KEEP FILING BUGS!
Andrew Munger (WaxDragon)
Hi folks:
I was trying to update mi local mirror and fuond that the SVN server is no
longer the same. Wich is the new Address.
Thanks in advance
Regards
Waldo Alvarez
On 1/16/06, Richard <eek2121(a)comcast.net> wrote:
>
> I think it's time for me to hit up bugzilla, anyways, Firefox setup from
> mozilla.com no longer works, it just dies, and the 'get firefox' link
> results in an access denied in the middle of FF setup.
>
> Every 3rd or 4th boot ROS also does not have a mouse pointer. It may be
> frozen, i can't tell.
>
> Regressions...Regressions...Regressions...
> Richard
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
Hi,
many people mailed to me directly.
Sorry, If I didn't answered all of them.
Sorry if I only answer in the evening (EU). I've a day-job and my WAF
doesn't like ReactOS really.
- Hartmut