On Mon, Oct 03, 2005 at 06:37:36PM -0700, Joshua Rodman wrote: > 1) The package does not on install make it clear (at least with my > debian configuration) that replacing the configuration file is > necessary to close the bug. Totally agree - I should've at least "echo" warning in postinst script. Heh heh... that is sad that I'm not a DD yet, so all my uploads have to go through a sponsor, and that delays uploads some times and I don't want to bother him too often.
I will add notification but it I am not sure when new version makes
its way to the Debian repository. At least anyone who uses my local
repository will get it ;-)
> I'm not even sure how this would be done in the debian world, save
> perhaps an email to the system owner?
I think that it is common to just produce a warning message to the
stdout. I need to check, may be dev debian documents or policy has
something regarding such cases
> 2) The regex is not verifiable nor even understandable by me. I
> accept that sophisticated regex has its place, but it is effectively a
> bit of a programming language, and I think configfiles should not
> really contain significant chunks of code, especially ones that are
> moderately opaque.
Indeed... it is a bit cryptic because I am damn pragmatic programmer, so
I hate code duplication. That is why I had such approach to build
regexp as well -- now I don't have 3 or 4 simpler failregex'es with the
common base, which I would need to correct in all of them if I detect a
bug. Rather I have a single regex. Besides that, using full-featured
regexp engine of python provides another advantage of being able to
create complex match patterns if such are necessary.
May be I should place txt2regex among "Suggest:"? That one is quite
nice to help anyone to build a regexp (including for python)
Besides that regular users or sysadmins are not even supposed to "tune"
failregex to have basic functionality to be performed. Me (and the upstream)
author are going to incorporate or at least include in the package more
of the configurations for different servers (imap, smtp, etc).
> Is this a reasonable approach?
> 1) Regex which identifies a false login. This can be as simple as
> before. If someone logs in as "illegal user" to create a false
> positive, so be it.
> 2) Second pattern which simply identifies the IP address component
> of the line.
Well - that is how it was done before, and lead to the security breach.
2nd pattern was a generic pattern for an IP address, and that is why all
substrings containing IP address were matched, including in the
placeholders of the usernames. I don't see sufficiently generic way to
employ in 2) besides scanning the whole line for IP address,
unless I use full regexp as I did.
By employing regexp to match the logged line, I eliminated such
possibility and made it more or less generic, thus I had minimal amount
of real code of fail2ban to change to make it work.
I open for more specific suggestions on how to make it work in a
cleaner way ;-)
> Should I be sending these to the upstream author, or will he/she
> probably see all this anyway.
I will update him as soon as he gets back in touch (he is away at the
moment), so it would be better if you just trust be on that ;-) He might
have some better idea on how to handle this case as well ;-)
> Aside: Many thanks to my debian maintainers. I should buy you all a
> beer.
cyber-beer -- yammy ;-)) Thanx
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
pgpoCZWXxZYVE.pgp
Description: PGP signature
