Https is started by default with a webroot of /tmp. It's trivial to read any file on the system that the daemon's user has access too (default root). Ex: any user could ln -s /etc/shadow /tmp/shadow, then open a browser to https://<ip> and view the system shadow file.
mkennedy please advise.
I dropped mkennedy an email.
could probably knock this and #159602 out at the same time
mkennedy retired, suggest sending a call for maintainer to -dev ML. :)
Same confusion here.
-dev mailed
masked now. setting severity to enhancement. seems like this was never stable, so we dont need a mask-glsa. this should be completely removed $SOON.
*** Bug 159602 has been marked as a duplicate of this bug. ***
I have a relatively stable, non-vulnerable version (1.68) in my overlay Erlay. The mask masks my version though and I can't seem to do anything about that with a overlay-level package.mask or package.unmask. [OT: Is this a flawed function of portage?] It would be awful nice of you guys if you could mark <=www-servers/yaws-1.64 masked, as klacke the developer of YAWS clarified in bug #159602, even though newer version don't exist in portage. Getting YAWS, and more importantly the mask, out of portage as soon as possible would also make me a very happy overlay maintainer :).
Created attachment 111935 [details] yaws-1.68.ebuild A non-vulnerable version.
Disregard the pleas in comment #9. I've been pointed out a way to unmask packages from overlay (-www-servers/yaws) and then mask just the vulnerable versions. It's all good. Sorry to bother.
Hi Christopher, thank you very much for providing the ebuild, but I found a few issues: a) if the hostname of your machine is "localhost", a wrong /etc/yaws.conf file will be generated (then you have two or three [the error msg says "to" btw] servers with "localhost" and yaws wont start) b) the generated config still has "/tmp" set as docroot, which is the reason why I think that this is not fixed yet. I think that this can be fixed in no time by someone with in-depth knowledge of this package, but i clearly lack this knowledge - so please provide another ebuild or wait until i have more time to check this out. And after all, the ebuild could be just fine and it would be me who is causing the trouble?
Created attachment 112210 [details] yaws.conf_gentoo I've edited the configuration file to remove the issues mentioned in comment #9 and provide information about the privileged port thing. It can be included in ${FILESDIR} and be used in the stead of the config file that the package is distributed with.
Created attachment 112211 [details, diff] patch to yaws-1.68.ebuild to fix configuration
Created attachment 112214 [details, diff] patch to yaws.conf_gentoo to fix configuration Start and stop now work correctly with the example configuration but there are issues with the rest of the init commands (debug, query, reload) don't. They are on my todo list but I don't have any more time today.
I could mail -dev again for a new maintainer, but i think it would be vain. Time has come to take a decision. DerCorny or security or treecleaners please comment.
Someone might be willing to proxy maintain it now that we have an ebuild contributor?
i'd be willing to proxy maintain this. christopher covington: interested in becoming the maintainer of this package?
Created attachment 135643 [details] yaws-1.73.ebuild ebuild for version 1.73
Another half year gone by.. yaws is now removed from portage by treecleaners.
Thanks, we can close this bug then.
Make ebuild for new version(1.77). http://github.com/simonoff/gentoo_erlang/tree/master/www-servers/yaws/yaws-1.77.ebuild
