Bug#692734: unblock: ettercap/0.7.5-4
Hi, 365 files changed, 23718 insertions(+), 14033 deletions(-) This isn't something that can be reviewed, especially with the large number of unrelated changes to (for example build system switch!) the package. The options remaining are: * Backport specific fixes for the version in testing * Remove the package Could you please indicate if you wish to do the first or the second. Thanks, Neil On Tue, Jan 08, 2013 at 11:03:59PM +, Barak A. Pearlmutter wrote: That is a matter of release policy. I believe I've made clear my own recommended action, listed the alternative possibilities I consider realistic, and given supporting reasoning. After that, this becomes a matter for the release team to decide. They can take my recommendation, or do something else, as they wish. It is ridiculous process-over-sense to say that the release team should ask me, via your sending me your interpretation of their policy document, to ask them to do something which you think they've already decided to do. (Especially when I don't think what you seem to think they've already decided to do is the best option.) After all, if they have decided to do something, they can just do it. We're trying to produce a good operating system here, not an improv parody of paralyzing procedure-heavy bureaucratic inertia. It's a bit frustrating to see that the release gets delayed because of situations like these. Ettercap is a minor leaf package. This issue is not a release delayer. --Barak. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871udvs2e8@cs.nuim.ie -- signature.asc Description: Digital signature
Bug#692734: unblock: ettercap/0.7.5-4
As I've stated previously, I don't believe that backporting fixes is really feasible. There are too many, they are mixed with non-security-related modifications, there would be enormous opportunity for error, and ongoing security maintenance would be quite difficult. Some background: upstream development stalled, and a new team has (with the blessing of the retired old team) taken over. The new team is willing to do security updates on their versions, but it is not realistic to expect them to be able to do security patches for an ancient version full of backported patches. On the other hand, I personally don't see any disadvantage to letting 0.7.5* in and pulling it if there is a problem, instead of just pulling it preemptively in case there is a problem. So that is my recommendation. The choice, however, is with the release team. --Barak. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwwixvvq@cs.nuim.ie
Bug#692734: unblock: ettercap/0.7.5-4
On Wed, Jan 09, 2013 at 02:40:25PM +, Barak A. Pearlmutter wrote: As I've stated previously, I don't believe that backporting fixes is really feasible. There are too many, they are mixed with non-security-related modifications, there would be enormous opportunity for error, and ongoing security maintenance would be quite difficult. Do you have CVE numbers, BTS references or any further detail? These very changes make it not suitable for update when we've been frozen for over 6 months. Some background: upstream development stalled, and a new team has (with the blessing of the retired old team) taken over. The new team is willing to do security updates on their versions, but it is not realistic to expect them to be able to do security patches for an ancient version full of backported patches. No, that's what we expect *you* to do as the maintainer. If you feel you cannot support software for the length of the stable release, then it's simple: find help or let's not have it in a stable release. On the other hand, I personally don't see any disadvantage to letting 0.7.5* in and pulling it if there is a problem, instead of just pulling it preemptively in case there is a problem. Because by that stage a number of people will have already installed it and we have provided a commitment to have it in the release. So that is my recommendation. The choice, however, is with the release team. That's not going to happen. So, can you please let me know if you're going to backport the fixes, or if I should remove it from wheezy. Neil -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130109152458.gn6...@halon.org.uk
Bug#692734: unblock: ettercap/0.7.5-4
Do you have CVE numbers, BTS references or any further detail? No, I don't believe any such processes were engaged. But examination of the actual changes shows many potentially security-relevant deltas. The tool is most commonly used in friendly networks to look for vulnerabilities, so this does not render it useless. But I would be surprised if it were not possible to create hostile traffic that would at the very least crash the tool, and likely subvert it. So, can you please let me know if you're going to backport the fixes, or if I should remove it from wheezy. As I've already said repeatedly, I don't think backporting all and only the security-relevant patches is a realistic option. I could go back to the old build system while keeping the updated C sources. This would dramatically reduce the delta count, but seems silly. --Barak. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehhuxr92@cs.nuim.ie
Bug#692734: unblock: ettercap/0.7.5-4
On Wed, Jan 09, 2013 at 03:24:58PM +, Neil McGovern wrote: On Wed, Jan 09, 2013 at 02:40:25PM +, Barak A. Pearlmutter wrote: As I've stated previously, I don't believe that backporting fixes is really feasible. There are too many, they are mixed with non-security-related modifications, there would be enormous opportunity for error, and ongoing security maintenance would be quite difficult. Do you have CVE numbers, BTS references or any further detail? These very changes make it not suitable for update when we've been frozen for over 6 months. I'm not aware of any security issues in Ettercap and the release announcement of 0.7.5 doesn't mention them either. The 0.7.4 release mentions several buffer overflows, but this version is already in testing. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130109183800.ga15...@inutil.org
Bug#692734: unblock: ettercap/0.7.5-4
I'm not aware of any security issues in Ettercap and the release announcement of 0.7.5 doesn't mention them either. The 0.7.4 release mentions several buffer overflows, but this version is already in testing. Well, that depends on *which* 0.7.4 you mean, NG-0.7.4 vs v0.7.4, but in any case, even just peeking at the very tip of the 0.7.5 tree in git we immediately see something highly suspicious: $ cd ettercap $ git log --pretty=oneline --deco --graph v0.7.5| head -5 * 9e82ea656a5cbecc79823143907564cd4b446573 (tag: v0.7.5) Merge branch 'ettercap_rc' |\ | * 302152524ccd09ac4252d5f33c617cc6e9ed9545 Merge pull request #29 from kholia/o5logon-fixes | |\ | | * b510c1520a64372fffd04449413bb0255598d149 Fix crash with Nmap generated packets, catch login failures ...^ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uduxe7y@cs.nuim.ie
Bug#692734: unblock: ettercap/0.7.5-4
That is a matter of release policy. I believe I've made clear my own recommended action, listed the alternative possibilities I consider realistic, and given supporting reasoning. After that, this becomes a matter for the release team to decide. They can take my recommendation, or do something else, as they wish. It is ridiculous process-over-sense to say that the release team should ask me, via your sending me your interpretation of their policy document, to ask them to do something which you think they've already decided to do. (Especially when I don't think what you seem to think they've already decided to do is the best option.) After all, if they have decided to do something, they can just do it. We're trying to produce a good operating system here, not an improv parody of paralyzing procedure-heavy bureaucratic inertia. It's a bit frustrating to see that the release gets delayed because of situations like these. Ettercap is a minor leaf package. This issue is not a release delayer. --Barak. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871udvs2e8@cs.nuim.ie
Bug#692734: unblock: ettercap/0.7.5-4
Hi, A new upstream version 0.7.5 of ettercap (a network sniff/attack tool) fixes a variety of security issues. It does not seem practical to me to backport the fixes, because many of them are made on top of non-security-related changes, and teasing them apart etc would be a great deal of work and also quite error-prone. The upstream team is very eager to get the new version in place, and I find their reasoning compelling. Well, as a Debian Developer you should know that during a freeze, no new upstream releases are allowed into testing. You should therefore either cherrypick the fixes or request a removal of the package from testing. I am pretty sure that the new upstream release has little to no chances to get into testing, so I would like to ask you to take one of the two aforementioned actions. It's a bit frustrating to see that the release gets delayed because of situations like these. The relase policy has been known for a long time and you should adhere to it. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121223154504.ga27...@physik.fu-berlin.de
Bug#692734: unblock: ettercap/0.7.5-4
On Thu, Nov 8, 2012 at 11:46:33 +, Barak A. Pearlmutter wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello release team, please unblock package ettercap. A new upstream version 0.7.5 of ettercap (a network sniff/attack tool) fixes a variety of security issues. It does not seem practical to me to backport the fixes, because many of them are made on top of non-security-related changes, and teasing them apart etc would be a great deal of work and also quite error-prone. I think it's too late to get a new upstream, with an entirely rewritten build system, into wheezy. Cheers, Julien signature.asc Description: Digital signature
Bug#692734: unblock: ettercap/0.7.5-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello release team, please unblock package ettercap. A new upstream version 0.7.5 of ettercap (a network sniff/attack tool) fixes a variety of security issues. It does not seem practical to me to backport the fixes, because many of them are made on top of non-security-related changes, and teasing them apart etc would be a great deal of work and also quite error-prone. The upstream team is very eager to get the new version in place, and I find their reasoning compelling. This is briefly alluded to in BTS 691465. Note that ettercap is a leaf package (nothing depends on it) so there is no real down-side to allowing 0.7.5 to progress to testing and then having a show-stopping problem pop up. In that case it would likely be pulled ... which I think we'd have to do anyway if 0.7.5 is not allowed into testing, since in that case we'll have known latent security issues. On the other hand, with 0.7.5 we have an active (quite pro-active in fact) and highly responsive upstream team eager to fix any issues that we might bring to their attention. --Barak. -- Barak A. Pearlmutter Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/E1TWQZ7-0003h9-9x@port-kdr.hamilton.local
