Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Apr 2016 10:15:27 +0200 (CEST)
From:      =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no>
To:        Warren Block <wblock@wonkity.com>
Cc:        Kurt Lidl <lidl@FreeBSD.org>, freebsd-hackers@freebsd.org
Subject:   Re: Importing NetBSD's blacklist project into FreeBSD
Message-ID:  <alpine.BSF.2.20.1604141006370.14591@mail.fig.ol.no>
In-Reply-To: <alpine.BSF.2.20.1604132044270.41766@wonkity.com>
References:  <570EF8DF.3020408@FreeBSD.org> <alpine.BSF.2.20.1604132044270.41766@wonkity.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Apr 2016 20:47-0600, Warren Block wrote:

> On Wed, 13 Apr 2016, Kurt Lidl wrote:
> 
> > Greetings all -
> > 
> > This is just a quick note to alert the FreeBSD development community
> > that I've posted a review for the import of the NetBSD "blacklist"
> > project into FreeBSD.
> > 
> > The reviews for the basic import and hookup of the blacklist system
> > into the build process are here:
> > 
> > 	https://reviews.freebsd.org/D5912
> > 	https://reviews.freebsd.org/D5913
> > 
> > The rational behind the system is given in the first referenced
> > review, which is Christos Zoulas' presentation at vBSDcon 2015.
> 
> The first review has a link to the video:
> https://youtu.be/fuuf8G28mjs
> 
> > I think the system is a very reasonable framework to allow for
> > real-time notification of attacks, feeding to a single daemon
> > process, which maintains a persistent on-disk database. The daemon
> > can then invoke a helper script to affect packet filtering changes
> > as needed. It's driven from a text configuration file, and it is
> > pretty easy to add support to more programs in the future.
> > 
> > Thanks for your interest, and I look forward to any discussion
> > about the merits of the system and the patches to implement it
> > in FreeBSD.
> 
> After seeing that review yesterday and thinking it sounded interesting, I
> watched the video.  After looking at today's maillog, I have gone from just
> being interested to really wanting it.  And a patch for sendmail to use it.
> 
> Thank you for working on this!

+1

security/denyhosts is a fairly good substitute for handling sshd 
abuse, but denyhosts chokes on certain hostnames and adds the same 
hostname over and over to /etc/hosts.deniedssh, leaving me with the 
burden of cleaning up the mess.

I hope blacklistd is better than denyhosts as the former integrates 
with the daemon internals.

Speaking of denyhosts, any chance blacklistd could distribute the 
blacklisted IP adresses between multiple hosts? The blacklistd-helper 
control program could be a candidate.

-- 
+-------------------------------+------------------------------------+
| Vennlig hilsen,               | Best regards,                      |
| Trond Endrestøl,              | Trond Endrestøl,                   |
| IT-ansvarlig,                 | System administrator,              |
| Fagskolen Innlandet,          | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,       | Cellular...: +47 952 62 567,       |
| sentralbord 61 14 54 00.      | Switchboard: +47 61 14 54 00.      |
+-------------------------------+------------------------------------+
From owner-freebsd-hackers@freebsd.org  Thu Apr 14 08:35:12 2016
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3ECA6B0F588
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Thu, 14 Apr 2016 08:35:12 +0000 (UTC)
 (envelope-from killing@multiplay.co.uk)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com
 [IPv6:2a00:1450:400c:c09::22c])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id EA61511CF
 for <freebsd-hackers@freebsd.org>; Thu, 14 Apr 2016 08:35:11 +0000 (UTC)
 (envelope-from killing@multiplay.co.uk)
Received: by mail-wm0-x22c.google.com with SMTP id n3so114797735wmn.0
 for <freebsd-hackers@freebsd.org>; Thu, 14 Apr 2016 01:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623;
 h=subject:to:references:from:message-id:date:user-agent:mime-version
 :in-reply-to:content-transfer-encoding;
 bh=Fj47UCoGy4s4R2on46ffBDZxzoG2Doy67NvAVdyHwNo=;
 b=pLcIG8hWM7wD5OYZqbqOnhArwPeMc6Z1rhiOfOE5cLxuDR1hfnByAx2lJhhST/T6D5
 evtAp1rH0jJfXN3CyxixIWoAgppAdOod3nfGAlrrg5QhFc1U6E8atbWheJn0BkcwZbTL
 QoxVHt1miZB39cJ5SmyxVA4OkC7HK4gjIoJG4q9+/2+gE3PSgBfse4pZmN1wQuzfmLl3
 w2KFOp6u8m9NnbqO5Am9bOSmtEGgS6py66vYimAj2FU0Jf9MGsqIKCX4bMldo9QIlx4L
 tDfumzka/InF9ubJkZ9xz6569KlFlVMcpf5T60hlMmb3bQnRSDU/li7T6W+6OBwspLQN
 Mq3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:subject:to:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-transfer-encoding;
 bh=Fj47UCoGy4s4R2on46ffBDZxzoG2Doy67NvAVdyHwNo=;
 b=V0Tow3I9ALZYRDFFiGTitX7JrwsDYa2dh4+fqYTV6hsaRKoAiVteX1D9+4ntvemBOT
 KGrT7pS4p0h7W8VnU/WiOIhLhMS0rifp05wXlnQgcg/33Do5z1tvMQ58Ey+u/RIiAN/C
 l/CPdKLEtxh0DQou99pFSwWMOHOUzHSyuhLQPULin0BE8+9Bb4UwbNhUvf6mPZTpHPHv
 7qBNCAJx6e+YBh/j1IgcOeJr510nTpe98gHMyAa4XeajmUPL6dhfhXHYfPq5bYP9fdTa
 pMY79MyN3AxqStxpS2F8ybqLZpVv5QKbLveH5+af2aka7uV32Sju2sjFSVTNtiUmJo8H
 Lq7w==
X-Gm-Message-State: AD7BkJJaUzrpNHGReWIRPGcrbSMuaSkdc2I/JxGypDvcnRbUJ7j+3ApppUQ+BpGitO6bkBzF
X-Received: by 10.28.98.137 with SMTP id w131mr36027774wmb.30.1460622910008;
 Thu, 14 Apr 2016 01:35:10 -0700 (PDT)
Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171])
 by smtp.gmail.com with ESMTPSA id k139sm5288995wmg.24.2016.04.14.01.35.08
 for <freebsd-hackers@freebsd.org> (version=TLSv1/SSLv3 cipher=OTHER);
 Thu, 14 Apr 2016 01:35:08 -0700 (PDT)
Subject: Re: Improving commit logs
To: freebsd-hackers@freebsd.org
References: <56FF6534-276E-4E52-871F-5567BD9D6EC7@dons.net.au>
 <CAGHfRMAwZ-A7BspzCqAEniyQOcy1fmL85V4wjzG0gDBq6gbjtw@mail.gmail.com>
 <FBAA087E-DCF3-4FB7-922D-A333AD237A23@dons.net.au>
 <20160414032801.GP18163@FreeBSD.org>
 <1DDB0BFB-545F-4293-9BFB-020DAFD7A5C4@dons.net.au>
 <20160414034320.GQ18163@FreeBSD.org>
 <2FD1641C-DF99-4464-BA34-A05430D663C4@dons.net.au>
 <20160414034805.GR18163@FreeBSD.org>
 <9FD838FE-E1DF-487D-82BF-77EEA2C51156@dons.net.au>
From: Steven Hartland <killing@multiplay.co.uk>
Message-ID: <570F5644.3010206@multiplay.co.uk>
Date: Thu, 14 Apr 2016 09:35:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <9FD838FE-E1DF-487D-82BF-77EEA2C51156@dons.net.au>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>;
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2016 08:35:12 -0000

On 14/04/2016 04:52, O'Connor, Daniel wrote:
>> On 14 Apr 2016, at 13:18, Glen Barber <gjb@FreeBSD.org> wrote:
>>
>> On Thu, Apr 14, 2016 at 01:14:46PM +0930, O'Connor, Daniel wrote:
>>>> On 14 Apr 2016, at 13:13, Glen Barber <gjb@FreeBSD.org> wrote:
>>>> I absolutely agree with you that a guide on this will be beneficial.
>>>> Sorry if my reply was taken any other way.
>>>>
>>>> If I had a genie in a bottle, my three wishes would be:
>>>>
>>>> 1) Better commit messages that address the "what";
>>>> 2) Better explanation on the "why";
>>> Huh interesting, I definitely would pick 2 before 1 but I can see
>>> what you mean for a lot of commits (especially to 30 year old cruft
>>> filled esoterica)
>> When writing release notes, for example, the "what" is generally more
>> useful than the "why."  In other words, the end user does not generally
>> care *why* something changed, but they want to know *what* changed.
> That's a good point, my original version was written more in the mind of someone who understands the code already but as you (and ngie) point out there are other consumers of the code.
>
> ===== SNIP =====
> This section contains some suggestions and traditions for how commit logs are formatted and what they should contain.
>
> A commit log should explain *why* a commit has taken place, *what* was changed and to a lesser degree *how*.
>
> The why of a commit message is absolutely critical to allow other people (including your future self) to understand the reason a change was made.
>
> The how can be skipped if it is obvious - it's left as an exercise to the reader to determine what obvious is. You should try and step into the mind set of someone who is familiar with FreeBSD but not focussed on the particular area you have committed to. What is obvious now can be obtuse in a few months when you or someone else is reviewing the code to track down issues. The commit logs are used by more people that just other developers - they are used to develop tests and release notes as well.
>
> Generally speaking *how* is obvious due to the diff itself assuming you have used enough comments, but clever tricks should probably be explained (or commented in the code).
>
> Due to the use of git and use of svn blame it is highly desirable to have a 1 line summary of the commit, however do not think this means you only need a 1 line summary. Write the full log first, then summarise it if possible. If you aren't sure, err on the side of a longer rather than shorter commit message.
>
> As well as including an informative message with each commit you may need to include some additional information.
>
> ===== SNIP =====
I definitely agree!

I've found myself on a number of occasions sending emails across to 
people asking for clarification on why things have been changed in order 
to better understand areas I'm less familiar with. Providing official 
guidance is always good IMO :)

     Regards
     Steve



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1604141006370.14591>