Bug#802917: do not migrate denyhosts to testing: who will do security support?
Hi All, As an active denyhosts user for a long time now (I guess 3-4 years) I find it way more intuitive and easy to setup than fail2ban, and I hope we can find a way of getting it into a debian release in the future... probably a long way away as stretch has since frozen... I guess buster at this rate? :) The main benefits I've had with it over fail2ban is mainly the ease of syncing multiple bans to a central hub. It's pretty straightforward to setup, especially since I've been toying with Jan's denyhosts-server project. It's pretty cool to be able to visualise when attacks are happening, where they're coming from and the other various metrics and the graphs that come with it. I think with a bit of love from Jan and myself, we can probably get denyhosts up to a polished standard with a majority of tickets resolved. I'm not python expert but I can do what I can to help, and have plenty of infrastructure and automation knowledge to configure systems if needed. Looking through some of the closed tickets mentioned, a number appear to have already been fixed upstream, or patches provided either at the github.com repo, the Sourceforge ticket or in the emails tickets but not followed up on in the package upstream. Thanks Regards
Bug#802917: do not migrate denyhosts to testing: who will do security support?
Hi Jan-Pascal and Helmut, On Mon, Oct 26, 2015 at 09:23:19PM +0100, Jan-Pascal van Best wrote: > Hi Helmut, > > Thanks for showing some care for this package. The main reason for me to > want to support denyhosts was the possibility of the synchronisation > server. I have since written a (AGPL licensed) replacement for the > original, closed source, server, starting from Anne Bezemer's suggestion > in Debian bug#622697. > > I may consider offering to do the security support for denyhosts for at > least the stretch support period, but I'm not sure what that would mean > exactly. Is the main work in following CNEs for the package and fixing > them for Debian (and preferably upstream as well)? > > Another possibility might be to work with fail2ban upstream to also > support my, or another, synchronisation server, but I'm not sure if they > would be willing to accept patches to that effect. > > > * Your upload reintroduces security bug #692229. > You're right. I checked whether all Debian patches had been implemented > upstream, must have missed this one. > > > * Due to the removal of denyhosts from Debian, the following bugs were > >closed by the ftp masters: > > > >#395565 #436417 #497485 #514024 #529089 #546772 #597956 #567209 #611756 > >#622697 #643031 #720130 #729322 #731963 > > > >Please evaluate which of them need to be reopened or failing that > >reopen all of them. > Of course, I was planning to do that. From security team point of view: If all the previously open security bugs get's fixed, and both maintainer (hey! ;-)) and upstream remain active and on track when issues appear I guess we will be fine to have as well denyhosts in stretch. OTOH, there is fail2ban which is actively developped as well, and so I guess much widely used, so it would be possibly better to concentrate the work effort on fail2ban. Helmut is right here, that it's hard to get all the bits right already, so if we can avoid in the end having to maintain both denyhosts and fail2ban that might be preferable. have you spoken/contacted fail2ban upstream to bring your ideas about the synchronisation server? Please only close this bug in case we would be sure that denyhosts should go in stretch and all the items raised by Helmut are addressed. Regards, Salvatore signature.asc Description: PGP signature
Bug#802917: do not migrate denyhosts to testing: who will do security support?
Hi Helmut, Thanks for showing some care for this package. The main reason for me to want to support denyhosts was the possibility of the synchronisation server. I have since written a (AGPL licensed) replacement for the original, closed source, server, starting from Anne Bezemer's suggestion in Debian bug#622697. I may consider offering to do the security support for denyhosts for at least the stretch support period, but I'm not sure what that would mean exactly. Is the main work in following CNEs for the package and fixing them for Debian (and preferably upstream as well)? Another possibility might be to work with fail2ban upstream to also support my, or another, synchronisation server, but I'm not sure if they would be willing to accept patches to that effect. > * Your upload reintroduces security bug #692229. You're right. I checked whether all Debian patches had been implemented upstream, must have missed this one. > * Due to the removal of denyhosts from Debian, the following bugs were >closed by the ftp masters: > >#395565 #436417 #497485 #514024 #529089 #546772 #597956 #567209 #611756 >#622697 #643031 #720130 #729322 #731963 > >Please evaluate which of them need to be reopened or failing that >reopen all of them. Of course, I was planning to do that. Jan-Pascal
Bug#802917: do not migrate denyhosts to testing: who will do security support?
Package: denyhosts Version: 2.10-2 Severity: serious Tags: security Hi Jan-Pascal, thank you for your interest in reviving denyhosts. Unfortunately, there are still unresolved issues with denyhosts that make it unfit for release. This bug is meant as a tracker bug and to prevent testing migration until all sub issues are properly tracked. * The denyhosts package is very similar to fail2ban. In particular, both contain a set of regular expressions for matching log files from daemons. These regular expressions are hard to get right. Thus the Debian security team wants to avoid supporting both tools. This argument is similar to how ffmpeg was blocked from jessie, because it was too similar to libav and had a difficult security profile. So until it is clear who will do the security support for denyhosts, denyhosts should stay out of testing. * Your upload reintroduces security bug #692229. * Due to the removal of denyhosts from Debian, the following bugs were closed by the ftp masters: #395565 #436417 #497485 #514024 #529089 #546772 #597956 #567209 #611756 #622697 #643031 #720130 #729322 #731963 Please evaluate which of them need to be reopened or failing that reopen all of them. Sorry for the bad news, but I believe that reincluding the current denyhosts package is a disservice to our users. Helmut
