Hi Juliusz! > You apply the following patch to Debian's polipo:
[skip] > I have thought it over, and I hereby requests that you revert this > patch. There are just too many reasons why you should not have > applied it. > > 1. You did apply a patch relating to security without an explicit ack > From upstream. > > I hope it is clear from the recent OpenSSL debacle why this must not > be done. I'm sorry Juliusz, but I have send you patch with ask to test it. There was 10 days while package was in unstable. And then about 4 monthes. And I think my patch is not the same as OpenSSL patch - they touch very different things. Patch is correct with Debian policy and doesn't have side effects. > 2. You did apply a patch without first trying to get it applied upstream. > > You did send me the patch, but only after you applied it. You should > only ever apply a patch *after* the patch was rejected upstream *and* > you fully understand the reasons why, and believe that these reasons > do not apply to Debian. Ok. > Sorry to beat a dead horse, but taking this approach would have > avoided the recent OpenSSL debacle. > > 3. You changed Polipo's behaviour without documenting it Please see Debian changelog. > The Debian binary of Polipo now behaves differently from the upstream > binary. This will confuse your users and will confuse your friendly > upstream when he tries to help your users with debugging. In commonly way users must contact with package maintainer or by mailing lists, not private. And again, changes are documented in changelog. > What is more, it will create a rather glaring security hole for anyone > who replaces his Debian binary with an upstream binary (which is > something people sometimes do, when they need a more recent version). It is not a Debian way, sorry. If they do that, they must understand what they are doing. > 4. Your patch, while technically correct, will lead to bugs in the future. > > Your patch manipulates the process' *user* mask, which must never be > manipulated by a program. The umask is a global process feature. It's changed only for one, fopen() function, and then changed back. What is wrong? > It will cause a rather glaring security hole if I ever decide to use > threads in Polipo. Yes. But in this case here must be thread locking code. > The proper way to do what you need is to use open(O_CREAT) with the > right permissions (but obeying the umask), then pass the file > descriptor to fdopen. Of course, the permissions should be > configurable by a config variable. Well, this looks some better. Will you apply this in the next version or I may do another patch? > Any one of the above reasons is enough to ask you to revert this > patch. Let's discuss it. At this time I didn't see any security problems except using threads in the feature. -- Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
