Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Jul 2014 21:43:08 +0200
From:      Tijl Coosemans <tijl@FreeBSD.org>
To:        Kurt Jaeger <pi@FreeBSD.org>
Cc:        ports@freebsd.org
Subject:   Re: upgrade to security/libgcrypt, shared lib bump, what needs to be done ?
Message-ID:  <20140706214308.7156373d@kalimero.tijl.coosemans.org>
In-Reply-To: <20140706192720.GD73593@f10.opsec.eu>
References:  <20140706111643.GB73593@f10.opsec.eu> <20140706145604.0483ae7f@kalimero.tijl.coosemans.org> <20140706174859.GC73593@f10.opsec.eu> <20140706205203.4176600e@kalimero.tijl.coosemans.org> <20140706205623.2288c2d5@kalimero.tijl.coosemans.org> <20140706192720.GD73593@f10.opsec.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Jul 2014 21:27:20 +0200 Kurt Jaeger wrote:
>> On Sun, 6 Jul 2014 20:52:03 +0200 Tijl Coosemans wrote:
>>> On Sun, 6 Jul 2014 19:48:59 +0200 Kurt Jaeger wrote:
>>>> I prepared a new diff, see
>>>> 
>>>> http://people.freebsd.org/~pi/misc/libgcrypt.svndiff-v2
>>>> 
>>>> Can you have a look at it, before I mess up the whole tree 8-} ?
>>> 
>>> net/samba4/Makefile: PORTREVISION messed up 
>>> net/samba41/Makefile: PORTREVISION messed up
> 
> Ah, thanks, fixed.
> 
>>> security/libgcrypt/Makefile: Keep post-patch silent maybe?
> 
> If possible, I would like to keep those post-patch changes in the open.
> 
>>> Looks good otherwise, so go ahead and commit
>> 
>> There's no major incompatibility with the old version of libgcrypt right?
> 
> In the 1.6.0 release notes at
> 
> http://lists.gnupg.org/pipermail/gcrypt-devel/2013-December/002775.html
> 
> there is a list of changed APIs. Some of them are removed.
> Which might cause issues.
> 
>> Have you tried to compile some of the ports that depend on libgcrypt
>> to see if nothing breaks?
> 
> No, due to number of ports involved (104), list at
> 
> http://people.freebsd.org/~pi/misc/libgcrypt-related-ports
> 
> For this we probably need some exp-run ?
> 
> If one considers this a security-related change, and probably needs
> testing on functionality as well, I think that "commit and fix those few
> that break" looks like a possible short-cut 8-}

It's safer to do an exp-run.  You never know if some important port
breaks.  You can attach your patch to the bug and assign it to portmgr.
Maybe also change the subject to include [exp-run].



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