From owner-freebsd-hackers@freebsd.org Thu Apr 14 08:15:37 2016 Return-Path: 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 6C22BB10E1A for ; Thu, 14 Apr 2016 08:15:37 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 154171687; Thu, 14 Apr 2016 08:15:36 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id u3E8FRej068812 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Apr 2016 10:15:27 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id u3E8FRDm068809; Thu, 14 Apr 2016 10:15:27 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 14 Apr 2016 10:15:27 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Warren Block cc: Kurt Lidl , freebsd-hackers@freebsd.org Subject: Re: Importing NetBSD's blacklist project into FreeBSD In-Reply-To: Message-ID: References: <570EF8DF.3020408@FreeBSD.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, AWL autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 08:15:37 -0000 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: 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 ; 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 ; 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 ; 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 (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> <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >> >> On Thu, Apr 14, 2016 at 01:14:46PM +0930, O'Connor, Daniel wrote: >>>> On 14 Apr 2016, at 13:13, Glen Barber 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