Hi people, i want to forward that mail because i wish we'll get the point about current lxdm development status that seems to lack some quality. I am NOT a good coder, so i cannot say a thing about that, BUT i know that in openSUSE we have good developers that really wish to contribute. I believe they have good points, but for some reasons (that i think would be nice to share with everyone) they are ignored. Some of them are even suggesting to remove lxdm from officially supported repo for several reasons. I am just forwarding one of the mail i received to you, so all the developers can give a look, and because i know lxde (and lxdm) are opensource and are a community effort, maybe some of you can apply patches and perform changes even if the main developer (dgod) is not available at the moment.
Best Regards Andrea -------- Messaggio originale -------- Oggetto: LXDM rant Hello, as promised here is my rant about the current state of LXDM, I have rebased and partially rewritten all patches we had before as the upstream code has changed quite a bit. First, signal handling has changed, the signal handling code seems now async-safe, however it is still broken since rcxdm stop leaves the X server alive. Restarting lxdm the exposes another bug as it gets in an indefinite loop trying to start an X server while the old one is still running. So far I wasn't able to motivate myself to look into this code once again. There is also still another small flaw related to signal handling, any file operations after setting up signal handlers need to be protected against non-fatal signal handling, i.e. errno needs to be checked for EINTR and the operation if necessary repeated. I've pointed this out to the upstream author to no avail. I've also sent him our patches for logging (which make use of glib's logging facilities and redirect stdout and stderr to the logfile rather than spewing everything on the console) and for setting some environment variables needed by the login/logout scripts. Unfortunately, he has chosen to ignore them and to make some half-baked changes which do not solve the issues. Specificlly, the lxdm code implements its own logging functions ignoring superior facilities offered by glib. The debug mode is worthless since it can only be activated at compile-time option rather than though a command line switch (my logging patch currently fixes this as well). The upstream fix for providing an appropriate environment for scripts consists of a few setenv's before calling Pre/Postlogin and Xsession, which is not only plain ugly (why not put the environment into the session context as I have done in my patch?) but it also not help us at all since it does not take care of PostLogout. More generally the code looks just awful, and I don't mean a different coding style in every function but the lack of function prototypes and the ignorance towards superior and/or portable functionality offered by glib which is partly duplicated by half-baked reinventions (e.g. see the logging or command line option handling). Finally, the GTK/GDK-greeter runs as root which poses an unnecessary risk violating the principle of least privilege. For all these reasons I personally would consider it best to remove lxdm, not for animosity towards lxdm's author and the code but simply out of responsibility for our users, the perspective that the upstream author is simply not up to the task of writing a secure login manager, and cosiderations of the workload that lxdm updates impose on us. The other option I see is to audit the current codebase, to review every upstream commit for security issues (such as the world-writable socket in /tmp) and to maintain a rather invasive set of patches. I also find that endorsing LXDM as the login manager of LXDE does shed a bad light on the LXDE project management, is there noone caring for some minimum quality standards? Anyway, let me know what you think about all of this. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
