Ros-dev

ros-dev@reactos.org

5788 discussions

by Colin Finck

Hi folks, As proposed in our urgent meeting in February, we are going to have regular meetings at 20:00 UTC on the last Thursday of every month. Next Thursday will be the first time to hold such a meeting. While I was preparing the technical side (we're going to have a dedicated IRC server with voting capabilities this time), Amine and Victor have come up with a meeting agenda. We have agreed on the following points in this order: - ReactOS member definition. Proposal is not to establish a fixed definition, but decide upon always keeping a list of people and just giving hints on how you can get on this list - Current ReactOS work. Developers saying what they are working on - Status of our GSoC participation, in particular students and mentors - Upcoming LinuxTag event on 11th to 14th May - Sum up of previous events, ideas for next ones - Website revamp. Current status, who is working, who is willing to help You see that the list is more about inquiring and getting information than doing vital decisions this time. The agenda is also prioritized so that people may leave if they don't want to participate in website discussions for example. If nobody else volunteers, Amine would be in the minute taker position again and I would take the meeting leader role. My current list of ReactOS members is as follows. Only these people will be able to participate in the discussions and votings, so please tell me if I have forgotten anybody or if you want to be added to this list: - Giannis Adamopoulos (smiley1_) - Johannes Anderwald (janderwald) - Javier Agustìn Fernàndez Arroyo (elhoir) - Maciej Bialas (niski) - Aleksey Bragin (abragin) - Colin Finck (Colin_Finck) - Danny Götte (dangerground) - Cameron Gutman (aicom) - Ziliang Guo (ZWabbit) - Rafal Harabien (rafalh) - Kamil Hornicek (Pigglesworth) - Amine Khaldi (AmineKhaldi) - Timo Kreuzer (tkreuzer) - Matthias Kupfer (Collibri) - Michael Martin (mjmartin) - Victor Martinez (vicmarcal) - Roel Messiant (Mephisto) - Andrew Munger (WaxDragon) - Ged Murphy (GedMurphy) - Sylvain Petreolle (Usurp) - Hervé Poussineau (hpoussin) - Daniel Reimer (dreimer) - Pierre Schweitzer (HeisSpiter) - Samuel Serapion (encoded) - Olaf Siejka (Caemyr) - James Tabor (jimtabor) - Art Yerkes (arty) Everybody may join the meeting channel as a non-participating observer though. I'll hand you all connection details when we're ready. With best regards, Colin

13 years, 5 months

Re: [ros-dev] [ros-diffs] [gadamopoulos] 51115: [ntoskrnl] - Implement calling OkayToCloseProcedure callouts to win32k for desktop and window station objects - Fix a bug that caused ObpCloseHandle to return success even whe...

by Alex Ionescu

It's hilarious how this new code has the exact same Windows security bug I gave a talk about at BlackHat 2-3 years ago (which Microsoft fixed in Vista). It's sad how this code ignores the exported PsSetProcessWindowStation API and relevant EPROCESS field. It's awesome how nothing changes whenever I prop up to see the "progress". -- Best regards, Alex Ionescu On 2011-03-22, at 5:19 AM, gadamopoulos(a)svn.reactos.org wrote: > Author: gadamopoulos > Date: Tue Mar 22 09:19:26 2011 > New Revision: 51115 > > URL: http://svn.reactos.org/svn/reactos?rev=51115&view=rev > Log: > [ntoskrnl] > - Implement calling OkayToCloseProcedure callouts to win32k for desktop and window station objects > - Fix a bug that caused ObpCloseHandle to return success even when OkayToCloseProcedure failed > > [win32k] > - Rewrite SetProcessWindowStation to actually set the current window station and close the previous one > - Implement OkayToCloseProcedure callouts from the kernel to prevent closing the current desktop or window station > > Modified: > trunk/reactos/ntoskrnl/ex/win32k.c > trunk/reactos/ntoskrnl/ob/obhandle.c > trunk/reactos/ntoskrnl/ps/win32.c > trunk/reactos/subsystems/win32/win32k/include/desktop.h > trunk/reactos/subsystems/win32/win32k/include/win32.h > trunk/reactos/subsystems/win32/win32k/include/winsta.h > trunk/reactos/subsystems/win32/win32k/main/dllmain.c > trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c > trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c > > Modified: trunk/reactos/ntoskrnl/ex/win32k.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/win32k.c?rev=5… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/win32k.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/win32k.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -37,9 +37,45 @@ > > PKWIN32_PARSEMETHOD_CALLOUT ExpWindowStationObjectParse = NULL; > PKWIN32_DELETEMETHOD_CALLOUT ExpWindowStationObjectDelete = NULL; > +PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpWindowStationObjectOkToClose = NULL; > +PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpDesktopObjectOkToClose = NULL; > PKWIN32_DELETEMETHOD_CALLOUT ExpDesktopObjectDelete = NULL; > > /* FUNCTIONS ****************************************************************/ > + > +NTSTATUS > +NTAPI > +ExpDesktopOkToClose( IN PEPROCESS Process OPTIONAL, > + IN PVOID Object, > + IN HANDLE Handle, > + IN KPROCESSOR_MODE AccessMode) > +{ > + WIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters; > + > + Parameters.Process = Process; > + Parameters.Object = Object; > + Parameters.Handle = Handle; > + Parameters.PreviousMode = AccessMode; > + > + return ExpDesktopObjectOkToClose(&Parameters); > +} > + > +NTSTATUS > +NTAPI > +ExpWindowStationOkToClose( IN PEPROCESS Process OPTIONAL, > + IN PVOID Object, > + IN HANDLE Handle, > + IN KPROCESSOR_MODE AccessMode) > +{ > + WIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters; > + > + Parameters.Process = Process; > + Parameters.Object = Object; > + Parameters.Handle = Handle; > + Parameters.PreviousMode = AccessMode; > + > + return ExpWindowStationObjectOkToClose(&Parameters); > +} > > VOID > NTAPI > @@ -114,6 +150,7 @@ > ObjectTypeInitializer.PoolType = NonPagedPool; > ObjectTypeInitializer.DeleteProcedure = ExpWinStaObjectDelete; > ObjectTypeInitializer.ParseProcedure = ExpWinStaObjectParse; > + ObjectTypeInitializer.OkayToCloseProcedure = ExpWindowStationOkToClose; > ObCreateObjectType(&Name, > &ObjectTypeInitializer, > NULL, > @@ -124,6 +161,7 @@ > ObjectTypeInitializer.GenericMapping = ExpDesktopMapping; > ObjectTypeInitializer.DeleteProcedure = ExpDesktopDelete; > ObjectTypeInitializer.ParseProcedure = NULL; > + ObjectTypeInitializer.OkayToCloseProcedure = ExpDesktopOkToClose; > ObCreateObjectType(&Name, > &ObjectTypeInitializer, > NULL, > > Modified: trunk/reactos/ntoskrnl/ob/obhandle.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ob/obhandle.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ob/obhandle.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ob/obhandle.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -1752,7 +1752,6 @@ > > /* Detach and return success */ > if (AttachedToProcess) KeUnstackDetachProcess(&ApcState); > - Status = STATUS_SUCCESS; > } > else > { > > Modified: trunk/reactos/ntoskrnl/ps/win32.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/win32.c?rev=51… > ============================================================================== > --- trunk/reactos/ntoskrnl/ps/win32.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/win32.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -20,6 +20,8 @@ > PGDI_BATCHFLUSH_ROUTINE KeGdiFlushUserBatch = NULL; > extern PKWIN32_PARSEMETHOD_CALLOUT ExpWindowStationObjectParse; > extern PKWIN32_DELETEMETHOD_CALLOUT ExpWindowStationObjectDelete; > +extern PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpWindowStationObjectOkToClose; > +extern PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpDesktopObjectOkToClose; > extern PKWIN32_DELETEMETHOD_CALLOUT ExpDesktopObjectDelete; > extern PKWIN32_POWEREVENT_CALLOUT PopEventCallout; > > @@ -116,6 +118,8 @@ > PspW32ThreadCallout = CalloutData->ThreadCallout; > ExpWindowStationObjectParse = CalloutData->WindowStationParseProcedure; > ExpWindowStationObjectDelete = CalloutData->WindowStationDeleteProcedure; > + ExpWindowStationObjectOkToClose = CalloutData->WindowStationOkToCloseProcedure; > + ExpDesktopObjectOkToClose = CalloutData->DesktopOkToCloseProcedure; > ExpDesktopObjectDelete = CalloutData->DesktopDeleteProcedure; > PopEventCallout = CalloutData->PowerEventCallout; > KeGdiFlushUserBatch = CalloutData->BatchFlushRoutine; > > Modified: trunk/reactos/subsystems/win32/win32k/include/desktop.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/desktop.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/desktop.h [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -69,6 +69,9 @@ > VOID APIENTRY > IntDesktopObjectDelete(PWIN32_DELETEMETHOD_PARAMETERS Parameters); > > +NTSTATUS NTAPI > +IntDesktopOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters); > + > LRESULT CALLBACK > IntDesktopWindowProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam); > > > Modified: trunk/reactos/subsystems/win32/win32k/include/win32.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/win32.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/win32.h [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -166,6 +166,7 @@ > PCLS pclsPrivateList; > PCLS pclsPublicList; > INT cThreads; > + HDESK hdeskStartup; > DWORD dwhmodLibLoadedMask; > HANDLE ahmodLibLoaded[CLIBS]; > struct _WINSTATION_OBJECT *prpwinsta; > > Modified: trunk/reactos/subsystems/win32/win32k/include/winsta.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/winsta.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/winsta.h [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -82,6 +82,9 @@ > APIENTRY > IntWinStaObjectParse(PWIN32_PARSEMETHOD_PARAMETERS Parameters); > > +NTSTATUS NTAPI > +IntWinstaOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters); > + > NTSTATUS FASTCALL > IntValidateWindowStationHandle( > HWINSTA WindowStation, > @@ -106,4 +109,7 @@ > > PWINSTATION_OBJECT FASTCALL IntGetWinStaObj(VOID); > > +BOOL FASTCALL > +UserSetProcessWindowStation(HWINSTA hWindowStation); > + > /* EOF */ > > Modified: trunk/reactos/subsystems/win32/win32k/main/dllmain.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ma… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -119,6 +119,7 @@ > { > DPRINT("Destroying W32 process PID:%d at IRQ level: %lu\n", Process->UniqueProcessId, KeGetCurrentIrql()); > Win32Process->W32PF_flags |= W32PF_TERMINATED; > + > if (Win32Process->InputIdleEvent) > { > EngFreeMem((PVOID)Win32Process->InputIdleEvent); > @@ -144,6 +145,9 @@ > { > LogonProcess = NULL; > } > + > + UserSetProcessWindowStation(NULL); > + > } > > RETURN( STATUS_SUCCESS); > @@ -220,25 +224,14 @@ > { > if(hWinSta != NULL) > { > - if(Process != CsrProcess) > + if(!UserSetProcessWindowStation(hWinSta)) > { > - HWINSTA hProcessWinSta = (HWINSTA)InterlockedCompareExchangePointer((PVOID)&Process->Win32WindowStation, (PVOID)hWinSta, NULL); > - if(hProcessWinSta != NULL) > - { > - /* our process is already assigned to a different window station, we don't need the handle anymore */ > - NtClose(hWinSta); > - } > - } > - else > - { > - NtClose(hWinSta); > + DPRINT1("Failed to set process window station\n"); > } > } > > if (hDesk != NULL) > { > - Win32Thread->rpdesk = NULL; > - Win32Thread->hdesk = NULL; > if (!IntSetThreadDesktop(hDesk, FALSE)) > { > DPRINT1("Unable to set thread desktop\n"); > @@ -441,6 +434,8 @@ > CalloutData.ProcessCallout = Win32kProcessCallback; > CalloutData.ThreadCallout = Win32kThreadCallback; > CalloutData.BatchFlushRoutine = NtGdiFlushUserBatch; > + CalloutData.DesktopOkToCloseProcedure = IntDesktopOkToClose; > + CalloutData.WindowStationOkToCloseProcedure = IntWinstaOkToClose; > > /* Register our per-process and per-thread structures. */ > PsEstablishWin32Callouts((PWIN32_CALLOUTS_FPNS)&CalloutData); > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -166,6 +166,29 @@ > RemoveEntryList(&Desktop->ListEntry); > > IntFreeDesktopHeap(Desktop); > +} > + > +NTSTATUS NTAPI > +IntDesktopOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters) > +{ > + PTHREADINFO pti; > + > + pti = PsGetCurrentThreadWin32Thread(); > + > + if( pti == NULL) > + { > + /* This happens when we leak desktop handles */ > + return TRUE; > + } > + > + /* Do not allow the current desktop or the initial desktop to be closed */ > + if( Parameters->Handle == pti->ppi->hdeskStartup || > + Parameters->Handle == pti->hdesk) > + { > + return FALSE; > + } > + > + return TRUE; > } > > /* PRIVATE FUNCTIONS **********************************************************/ > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -187,6 +187,21 @@ > return STATUS_OBJECT_TYPE_MISMATCH; > } > > +NTSTATUS NTAPI > +IntWinstaOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters) > +{ > + PPROCESSINFO ppi; > + > + ppi = PsGetCurrentProcessWin32Process(); > + > + if(Parameters->Handle == ppi->hwinsta) > + { > + return FALSE; > + } > + > + return TRUE; > +} > + > /* PRIVATE FUNCTIONS **********************************************************/ > > /* > @@ -915,6 +930,57 @@ > return WinStaObj; > } > > +BOOL FASTCALL > +UserSetProcessWindowStation(HWINSTA hWindowStation) > +{ > + PPROCESSINFO ppi; > + NTSTATUS Status; > + HWINSTA hwinstaOld; > + PWINSTATION_OBJECT NewWinSta = NULL, OldWinSta; > + > + ppi = PsGetCurrentProcessWin32Process(); > + > + if(hWindowStation !=NULL) > + { > + Status = IntValidateWindowStationHandle( hWindowStation, > + KernelMode, > + 0, > + &NewWinSta); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT("Validation of window station handle (0x%X) failed\n", > + hWindowStation); > + SetLastNtError(Status); > + return FALSE; > + } > + } > + > + OldWinSta = ppi->prpwinsta; > + hwinstaOld = ppi->hwinsta; > + > + /* > + * FIXME - don't allow changing the window station if there are threads that are attached to desktops and own gui objects > + */ > + > + InterlockedExchangePointer(&PsGetCurrentProcess()->Win32WindowStation, hWindowStation); > + > + ppi->prpwinsta = NewWinSta; > + ppi->hwinsta = hWindowStation; > + > + > + if(OldWinSta != NULL) > + { > + ObDereferenceObject(OldWinSta); > + } > + > + if(hwinstaOld != NULL) > + { > + ZwClose(hwinstaOld); > + } > + > + return TRUE; > +} > + > /* > * NtUserSetProcessWindowStation > * > @@ -934,44 +1000,15 @@ > BOOL APIENTRY > NtUserSetProcessWindowStation(HWINSTA hWindowStation) > { > - PWINSTATION_OBJECT NewWinSta; > - NTSTATUS Status; > - > - DPRINT("About to set process window station with handle (0x%X)\n", > - hWindowStation); > - > - if(PsGetCurrentProcess() == CsrProcess) > - { > - DPRINT1("CSRSS is not allowed to change it's window station!!!\n"); > - EngSetLastError(ERROR_ACCESS_DENIED); > - return FALSE; > - } > - > - Status = IntValidateWindowStationHandle( > - hWindowStation, > - KernelMode, > - 0, > - &NewWinSta); > - > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("Validation of window station handle (0x%X) failed\n", > - hWindowStation); > - SetLastNtError(Status); > - return FALSE; > - } > - > - /* > - * FIXME - don't allow changing the window station if there are threads that are attached to desktops and own gui objects > - */ > - > - /* FIXME - dereference the old window station, etc... */ > - InterlockedExchangePointer(&PsGetCurrentProcess()->Win32WindowStation, hWindowStation); > - > - DPRINT("PsGetCurrentProcess()->Win32WindowStation 0x%X\n", > - PsGetCurrentProcess()->Win32WindowStation); > - > - return TRUE; > + BOOL ret; > + > + UserEnterExclusive(); > + > + ret = UserSetProcessWindowStation(hWindowStation); > + > + UserLeave(); > + > + return ret; > } > > /* > >

13 years, 5 months

GSoC 2011 idea

by Ilie Halip

Hi! My name is Ilie Halip, and I'm a student at the Faculty of Computer Science, in Iasi, Romania. I'd like to take part in this year's Google Summer of Code, and I was browsing the ideas page earlier. What caught my eye was the Management Console, but after some discussions on IRC, I got very excited about another thing not listed on the wiki page for GSoC. It's about implementing support for Windows Error Reporting. It's listed at http://reactos.org/wiki/Missing_ReactOS_Functionality. I think it's doable in less than 3 months, and might prove to be helpful too (the wiki page sais that :P). I'm not sure if you would accept this kind of proposal, so I'm here to ask about that. Also, I would need a mentor to help me with this project - so... would anyone be willing to mentor me, if this project would be accepted? I was also looking at WMI, but I know it's huge, and I'm not sure how much of it would be required to consider such a project successful. Also, another thing I should mention. I do have a full time job right now. That's a reason I didn't dive into anything bigger listed on the ideas page. Even though I do have some experience writing Windows drivers (I wrote a file system filter driver 2 years back), I don't think I'd be able to write an Intel HDA driver in less than 3 months. But I talked to my superiors, and they are willing to let me work part-time during GSoC, so I should be able to work for my would-be project about 30 hours/week. Do you think that's enough? Regards, Ilie.

13 years, 5 months

Re: [ros-dev] [NTDLL/LDR] - Fix a few bugs (wrong variable usage, wrong variable initialization) which led to incorrect snapping of import address table.

by Minas Abrahamyan

Hi Alexey, Since you are still working on these LdrXXX functions then you maybe find possibility to add there some code to prevent them trapping into infinite cycle (bug 5881: http://www.reactos.org/bugzilla/show_bug.cgi?id=5881 ) While booted up with RAM 25 or 24 MB ROS kernel falls into infinite cycle there, but being booted up with 15 Mbs ROS stalls and and hangs up. To test it is enough to run it on any VM with 24Mb of RAM. What occurs there is infinite recursive calls, in form of LdrpLoadModule ->calls LdrFixupImports -> LdrpGetOrLoadModule -> LdrpLoadModule and so forth. (detailed bt is in bug 5881 description). Maybe ROS kernel doesn't check memory availability, something like XXXMalloc returning NULL or so. Thanks! -M.A. On Wed, Mar 23, 2011 at 4:25 PM, <fireball(a)svn.reactos.org> wrote: > Author: fireball > Date: Wed Mar 23 12:25:53 2011 > New Revision: 51123 > > URL: http://svn.reactos.org/svn/reactos?rev=51123&view=rev > Log: > [NTDLL/LDR] > - Fix a few bugs (wrong variable usage, wrong variable initialization) which led to incorrect snapping of import address table. > - Wrap LdrpSnapThunk() invocations into SEH. > > Modified: > trunk/reactos/dll/ntdll/ldr/ldrpe.c > > Modified: trunk/reactos/dll/ntdll/ldr/ldrpe.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ldr/ldrpe.c?rev=…

13 years, 5 months

SSPI and Interactive logon GSOC Proposal

by Samuel serapion

Hello fellow ReactOS developers and users, Most of you might know me from IRC as encoded. I am a Computer Science student at the Polytechnic University of Puerto Rico. Although at times not the best IRC citizen, I've always had the best intentions for ReactOS at heart. The following is my proposal/plan outline for Implementing SSPI and secure authentication mechanisms for ReactOS, including Interactive Logon. First, some definitions: Security Support Provider Interface (SSPI) allows applications to use various security models available on a computer or network without changing the interface to the security system. SSPI does not establish logon credentials because that is generally a privileged operation handled by the operating system(LSA). Windows Challenge/Response (NTLM) is the authentication protocol used on systems running Windows. NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire(in case there is a wire). Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials. Secure Channel, also known as Schannel, is a security support provider (SSP) that contains a set of security protocols that provide identity authentication and secure, private communication through encryption. Mainly SSL and TLS, with a variety of cipher options. Primary goals: - Utilize wine secur32 as starting point for implementing SSPI. - NTLM Security Support Provider (SSP) -- Authentication -- feature flags -- SignMessage -- VerifyMessage -- EncryptMessage -- DecryptMessage - Small, low footprint, maintainable code - Implement create credentials/logon/authentication in LSA -- LogonUser -- LsaConnectUntrusted -- others, as necessary. - Separate secur32 and schannel(wine has them unified) Secondary goals: - implement SSL/TLS/ptc SSP (using 3rd party libs) -- GnuTLS, OpenSSL are huge and have many dependencies -- secur32 is (theoretically) loaded and used by many system dlls, would be very bad if it is a performance/memory hog. -- Need to severely trim them down or use alternatives. - run extensive tests/fix other system code paths that have been dormant/stubs why wine secur32 is bad: - Wine is a *nix program so its ok for them to use dlopen(gnutls.so)... and use the system native library but we cant. - Uses fork() to call a program in winbind(samba extra) package! - if we want to use gnutls and such in reactos the following problems occur: -- too many dependencies -- problems running in native mode(lsa) -- big footprint -- too much code/hard to maintain - Wine's implementation of schannel loads GnuTLS, and is barely functional. - wine winhttp and wininet don't use schannel, and instead use OpenSSL directly to implement SSL and TLS. This can lead to confusing differences in certificate verification between applications. Ideally, schannel would use crypt32 for certificate chain verification, and winhttp and wininet would use schannel. (fixme later) -- good news is, wine crypt32 is relatively good and feature complete (at least seems that way).

13 years, 5 months

GSoC: Kernel-Mode Test Suite

by Thomas Faber

Hi, I guess I don't have to introduce myself all that much anymore ;) Please see [1] if you disagree. I plan to submit a GSoC project proposal concerning the kernel-mode test suite, and would like to discuss a few key points to better shape the project idea and its timeline. Because of the broadness of the subject, I'm posting here to reach as many ears (er... eyes) as possible, hoping for feedback from people working on several different areas of ROS. My "state of mind" is currently the following regarding the project: Basic key points (I hope everyone agrees; please tell me if I'm wrong :p) - follow Winetest "feeling" - syntax for writing tests should be almost identical; like current kmtests demonstrate - tests should be startable individually from a command line launcher and follow Winetest behavior in that regard, so that an integration with Testman is made easy - code should be CMake and MSVC/WDK compatible from the beginning Ideas I deem useful (would appreciate any comments) - include buffer overrun checks, much like DPH (DPH can't be used for this though, can it?), using e.g. a guard/noaccess page behind each buffer. See [2] for a userland example; I'm working on a kernel-mode one - inspired by Winetest's broken(), one could make tests Windows-version specific. Something like [but better thought-out in syntax] ok(win2k3sp1(ret == 0) | win7x64sp1(ret == 1), ...) This would help compare different versions of Windows and much facilitate future kernel-target switching Questions - as there are ... many... kernel-mode functions, it is unfeasible to write tests for all during the project. My idea would be to create some very thorough sample tests, then focus on the most critical functions. "If there's time", thinly covering a more broad area might also be very useful (as extending existing tests is probably deemed easier than creating new ones by people later on). I have no doubt there's enough to do, ;) but would be interested to hear if you agree with the general strategy and what you think those "critical" areas might be. So what do you guys think? Excited for your input. Thanks. :) Regards, Tom [1] Hi! I'm Thomas, 23, from Germany, currently studying Computer Engineering in Berlin. I've been hanging out on IRC as ThFabba for some time now and submitted some hopefully-not-totally-useless patches ;) I'm interested in.... oh well, pretty much all parts of ROS. *g* Nice to meet you! [2] http://www.reactos.org/paste/index.php/8697/

13 years, 5 months

Request for apply to GSoC 2011

by Fabio Cristini

Good day to all, my name is Fabio Cristini. I work as a software designer and developer in Italy, I'm a student in Software Engineering and I would like to apply for a React OS project proposal. I especially like the idea of implementing an SSH Service for Windows, and I hope I can do it for you (I like to develop an OpenSSH clone). Please let me know if you may be intrested. Fabio Cristini Italian, English +1 UTC fcristini(a)gmail.com (not registered yet) if you can contact me in private, I can give you more details and my full contact informations. Many thanks Time Commitment I can work at this project about 20 hours a week Optional (But Suggested) SSH Service for Windows http://www.reactos.org/wiki/Google_Summer_of_Code_2011_Ideas#SSH_Service Legal Requirements Students are required to affirm that the following is true. I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel.

13 years, 5 months

INTRODUCING MYSELF TO THE ROS COMMUNITY.

by Armaan

Hello friends, I am Syed Armani, i am a 3rd year computer science student at DCE ,NCR, INDIA Email: dce3062(a)gmail.com IRC: #armaan Jabber: syedarmani(a)jabber.org *ABOUT ME:* I have experience of - c/c++ - GUI development with c++. - python - java - lua - NETWORK PROTOCOLS - NETWORK PROGRAMMING - xhtml/css/javascript - Assembly (mid level 8085 n 8086) - BASH scripting. - VIRTUALIZATION, WORKING OF HYPERVISORS AND LIBVERT. - PHP - MYSQL - DEEP LEVEL LINUX OS - BASH SCRIPTING - LAMP/WAMP - WEB 2.0 - Android apps development I have a personality of a creative explorer and i always seek knowledge. I consider experience as a very very important thing. My wish is to take part in the development process of react os. Regards Syed Armani

13 years, 5 months

Re: [ros-dev] unanswered gsoc mails

by Ged Murphy

Thanks for that guys, it's really helpful.... From: Ged Murphy [mailto:gedmurphy@gmail.com] Sent: 29 March 2011 11:22 To: 'ReactOS Development List' Subject: unanswered gsoc mails I've noticed there are quite a few emails to ros-dev regarding GSoC participation with no replies. Can someone reply to these in my absence, I won't be around for a few more days yet. As usual, I'm contactable by email and msn. Ged.

13 years, 5 months

unanswered gsoc mails

by Gerard Murphy

I've noticed there are quite a few emails to ros-dev regarding GSoC participation with no replies. Can someone reply to these in my absence, I won't be around for a few more days yet. As usual, I'm contactable by email and msn. Ged.

13 years, 5 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev