There are also a few issues in general with command-lines & windows that I did not mention before - command-line arguments won't propagate if you are in a cluster and program fails. You will be stuck using a batch command file that sets service parameters. I have got to believe this violates numerous best-practices for windows. (and for all I know, it might be a deal-killer for MSFT certification)
- Unless you write a completely different executable that spawns shttpd with appropriate parameters, then you won't be able to insure appropriate path environment is passed; you won't be able to use an icon; you will have to do extra work to digitally sign the executable. (If you are in active directory environment, then is common practice for sysadmin to set group policy that prevents non-signed programs -- including batch files from running on any PC in the enterprise. - If you are running Vista or Win2008, then you must digitally sign as it is a requirement to get around the UAC warnings. You won't be able to get around this by using a .bat file, especially if you want an autostart/autorun on removable media. (You can sign a .VBS script but not a .BAT script) - Of course there are work-arounds for everything .. but bottom line, I can't imagine that this product could be used in a windows environment for any embedded application unless the developer writes a front-end program that parses a configuration file, then launches shttpd as a thread. We'll have to go down our own paths adding logic to get this to work. I can't emphasize security enough. A configuration file can easily be protected by developer using native unix/windows crypto library calls, and this insures that nothing can be mucked with. Parameters are decoded in RAM and safe from prying eyes, and they can't be mucked with unless the hacker is really, really good. Take the config file away, and you force security-conscious developers to re-invent the wheel you already invented. Ignore all arguments related to windows-centric anomalies, and just consider security risk alone with runtime parms. It is easy for hackers to create buffer overflows in command-line programs. Unless program is statically linked with libraries that are patched to protect such exploits then there is risk. This program has potential to kill any host running any IP port (web server, ftp server, mail). I for one will not be able to deploy this program at any end-user site unless I can protect and control what port(s) it uses. Convinced ? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Sent: Tuesday, February 12, 2008 11:57 AM To: Sergey Lyubka Cc: shttpd-general Subject: Re: [shttpd-general] [1.38 Win] How to encrypt .htpasswd? At 14:09 12/02/2008 +0000, Sergey Lyubka wrote: >and then call shttpd like this: "shttpd `cat my_config.txt`" I also prefer to use a configuration file. Having to call shttpd.exe from a batch file, and finding a way not to display a DOS box under Windows... is just not worth it. I think shttpd is OK as is. One thing that could be changed in shttp.conf, is being able to use a relative path instead of an absolute path: I didn't have time to look into how to build an installer and have it write this information on the fly, so had to ask the user to manually edit this line so that it would point to C:\shttpd\php\php-cgi.exe since .\php\php-cgi.exe wouldn't work. Thanks. ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ shttpd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shttpd-general ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ shttpd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shttpd-general
