* Martin Schulze [EMAIL PROTECTED]:
Florian Weimer wrote:
(Note that I have yet to test Lorenzo's new package.)
Are you in a position to do so?
Sure, but the question is if you want to rely on the results. You
don't seem to trust my judgement on this matter, for reasons I don't
Lorenzo Martignoni wrote:
If you can, please build an updated package, based on the version in
sarge and woody if that's needed as well, and place them on a .debian.org
host.
I already have a fixed package. I only need to add the CVE ID.
On which host of .debian.org should I upload it?
Florian Weimer wrote:
(Note that I have yet to test Lorenzo's new package.)
Are you in a position to do so?
Sure, but the question is if you want to rely on the results. You
don't seem to trust my judgement on this matter, for reasons I don't
know.
I simply did not understand the
* Lorenzo Martignoni:
The patch has been tested by me and by Paul Gear but further tests will
be better, so your feedback will be very precious.
Apart from the lack of CVE entry in the changelog, the package seems
to be fine. Both problems are fixed.
There is a surprising reduction of the
* Florian Weimer [EMAIL PROTECTED]:
* Lorenzo Martignoni:
The patch has been tested by me and by Paul Gear but further tests will
be better, so your feedback will be very precious.
Apart from the lack of CVE entry in the changelog, the package seems
to be fine. Both problems are
* Martin Schulze:
What was the behaviour pre-sarge?
What is the behaviour post-sarge (or rather in sarge)?
Do you mean before and after the upstream security update? The
terms pre-sarge/post-sarge do not make much sense to me in this
context, I'm afraid.
Ok, so when did the behaviour
* Florian Weimer [EMAIL PROTECTED]:
* Martin Schulze:
What was the behaviour pre-sarge?
What is the behaviour post-sarge (or rather in sarge)?
Do you mean before and after the upstream security update? The
terms pre-sarge/post-sarge do not make much sense to me in this
context,
As far as I understand it, from the perspective of the security team,
it is not clear if the upstream change breaks existing user
configurations. Users might rely on the current behavior and use it
to deliberately weaken the filter policy. This is a reasonable
question because the existing
Florian Weimer wrote:
As far as I understand it, from the perspective of the security team,
it is not clear if the upstream change breaks existing user
configurations. Users might rely on the current behavior and use it
to deliberately weaken the filter policy. This is a reasonable
question
* Martin Schulze:
So a summary would be to leave the package as it is in sarge, right?
Based on the facts, I reach the opposite conclusion. The upstream
changes should be merged. However, since easy workarounds are
possible, we might get away without code changes, if issuing the
update
Florian Weimer wrote:
* Martin Schulze:
So a summary would be to leave the package as it is in sarge, right?
Based on the facts, I reach the opposite conclusion. The upstream
changes should be merged. However, since easy workarounds are
possible, we might get away without code changes,
* Florian Weimer [EMAIL PROTECTED]:
* Martin Schulze:
What was the behaviour pre-sarge?
What is the behaviour post-sarge (or rather in sarge)?
Do you mean before and after the upstream security update? The
terms pre-sarge/post-sarge do not make much sense to me in this
context, I'm
Florian Weimer wrote:
* Martin Schulze:
What was the behaviour pre-sarge?
What is the behaviour post-sarge (or rather in sarge)?
Do you mean before and after the upstream security update? The
terms pre-sarge/post-sarge do not make much sense to me in this
context, I'm afraid.
Ok, so
13 matches
Mail list logo
