Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)

2009-01-25 Thread Ambroz Bizjak
On Sunday 25 January 2009 12:39:22 Dmitry Timoshkov wrote: Guillaume SH gsh.debianli...@gmail.com wrote: As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from

Re: running msys under wine

2009-01-10 Thread Ambroz Bizjak
On Saturday 10 January 2009 01:05:07 David Laight wrote: On Fri, Jan 09, 2009 at 06:39:27PM +, Luke Kenneth Casson Leighton wrote: further up the strace files, i'm looking at the biggest offender and it looks like it's reading files one byte at a time. Certainly a normal unix shell has

Re: [1/4] winemenubuilder: move path normalization to Process_Link and Process_URL

2008-12-01 Thread Ambroz Bizjak
On Monday 01 December 2008, Francois Gouget wrote: On Sun, 30 Nov 2008, Ambroz Bizjak wrote: [...] To allow that, I've modified winemenubuilder to record created shortcuts to registry, and my service will obtain and maintain the list of .lnk/url files from there. The general idea

Re: Patchwatcher security improvements

2008-09-10 Thread Ambroz Bizjak
Francois Gouget wrote: This seems like an almost perfect task for a virtual machine: * set up you virtual machine to taste * take a snapshot * to test a patch, fire up the virtual machine * have it test the patch * after the test or when it times out, revert it to the snapshot * rinse

Re: Patchwatcher security improvements

2008-09-10 Thread Ambroz Bizjak
Dan Kegel wrote: So the slave can be in another real machine, another virtual machine, or running as another user; anything as long as it can get read/write access to its subdirectory of the shared directory. The problem with your design right now is that you want to run the slave in some

Patchwatcher security improvements

2008-09-08 Thread Ambroz Bizjak
Hi, I've abandoned my chroot aproach to improving security in patchwatcher. Instead I've implemented the ability to run untrusted code as a user different than the one running patchwatcher. This is because creating a chroot where Wine could be compiled and tested proved to be too difficult and

re: Patchwatcher security improvements

2008-09-08 Thread Ambroz Bizjak
Interesting.One of my goals is to support Solaris and BSD; have you tried your stuff there? Not yet, but that stuff is pretty generic, so it shouldn't be hard to get it to work. I'm surprised you had to give up on the chroot... I was planning on trying to run just wine-slave.sh in a

Re: Patchwatcher security improvements

2008-09-08 Thread Ambroz Bizjak
Also, it's possible some of your changes won't be needed after the refactoring... I plan to run wine-slave as a different user anyway... That doesn't solve much; although in may look clean, it is not secure. The user should have a limited amount of resources to work with. Your way, for

Re: Patch checking robot coming

2008-08-05 Thread Ambroz Bizjak
I've written some code for the chroot, though it has proven to be harder than I taught it would, especially because of all the development tools and libraries that need to be copied into the chroot. Right now it will only work on Gentoo, other distributions will require some fine-tuning of paths,

Re: Patch checking robot coming

2008-08-03 Thread Ambroz Bizjak
Dan Kegel wrote: Sounds great. Want to implement that and send it my way? It'll take me a while to get the kinks worked out of the script, it'd be nice to have a hand with the chroot. - Dan OK, I'll try it. I have a lot of experience with the OS's architecture so it should be ready soon.

Re: Patch checking robot coming

2008-08-02 Thread Ambroz Bizjak
Dan Kegel wrote: What I have so far is a script that watches wine-patches and applies each patch to current git, then builds, Just where are you going to run that? To me, a script that builds just every patch is a serious security flaw; I suppose it wouldn't be very hard for someone to send a