security/botan - multiple vulnerabilities
Hello, security/botan in ports is vulnerable to the following advisories: CVE-2016-2194 CVE-2016-2195 CVE-2016-2849 CVE-2015-7827 http://botan.randombit.net/security.html On security.html, 1.10.13 is not mentioned as containing fix for CVE-2016-2849 and CVE-2015-7824 but it is mentioned in release announcement https://lists.randombit.net/pipermail/botan-devel/2016-April/002101.html Regards Sevan
Re: Use arc4random in devel/glib2
> > https://github.com/libressl-portable/portable/tree/master/m4 > > has autoconf checks with an OS whitelist for arc4random. > > It would be nice to keep things similar to these so that > > updates can be merged across from newer versions easily. > > I disagree. > > > libressl is making extremely conservative decisions, to protect > the way that libressl is (1) used and (2) seen. Furthermore, libressl makes that decision to decide if it should provide a *better replacement*. In the library being discussed here it is quite likely that a shitty arc4random() is still better than most other things it has available. Unless the goal is to keep everyone using customized non-standardized /dev/urandom codepaths (if it hits fd-exhaustion, does the library call _exit or abort? Good luck with satisfying people..)
Re: Use arc4random in devel/glib2
> > Anecdocally, libbsd's arc4random is not necessarily secure. IIUC the > > code isn't as glaringly dangerous as g_rand*, but it will seed with only > > the time and PID if other sources fail. I think we should avoid > > conflating BSDs' arc4randoms with libbsd's. > > > > https://github.com/libressl-portable/portable/tree/master/m4 > has autoconf checks with an OS whitelist for arc4random. > It would be nice to keep things similar to these so that > updates can be merged across from newer versions easily. I disagree. libressl is making extremely conservative decisions, to protect the way that libressl is (1) used and (2) seen. The same model is not applicable to everything. If you create an ecosystem where arc4random continues to be treated like a failure (which is not), then you are not creating the conditions for adoption of its, so get ready for more use of RAND_pseudo_bytes() and RAND_status(), more manual use of gettimeofday() seeding. More opening of /dev/urandom with sloppy failure cases. Especially with no handling of out-of-file descriptor conditions. Make sure the failovers you offer to them handle that, ok? Essentially, downstreams are finally in a position to educate upstreams that libc libraries are missing something important, and that it is no longer possible to do the right thing because the fundamentals are missing. POSIX has no way of getting a good random number. If the opportunity to educate is not used at the time when software is being ported downstream, well then you are part of the problem.
Re: Use arc4random in devel/glib2
> Dmitrij D. Czarkoff wrote: > > Stuart Henderson said: > > > glib2 is a pretty clean port patch-wise. This sort of thing would be > > > better done with proper autoconf etc so it can go upstream. > > > > Totally agree. It would be best if upstream would maintain the code. > > They could benefit from arc4random on other BSDs and libbsd-enabled > > platforms as well. > > Makes sense - I'm working on this now. > > Anecdocally, libbsd's arc4random is not necessarily secure. IIUC the > code isn't as glaringly dangerous as g_rand*, but it will seed with only > the time and PID if other sources fail. I think we should avoid > conflating BSDs' arc4randoms with libbsd's. Who cares if libbsd is doing it badly. But that is not our problem. We don't use libbsd. And for those who do? Eventually someone who uses libbsd will get upset and demand that libbsd do the job better, or they will do it themselves by importing a better arc4random, or convincing other libraries to add one. Because what is the alternative solution? Layers of #ifdef? Is that really the only answer to making anything better -- by hard-wiring in choices that will stick until the end of time? You realize that is the story for how OpenSSL-using applications got addicted to EGD? It took almost two years of aggressive user requests to clean up the ecosystem. So why not just stick to arc4random, and hope that eventually everyone accepts that is the only contender for high-availability, chroot-safe, jail-safe, fd-exhaustion-safe, etc? And then, call the job done.
Re: Use arc4random in devel/glib2
On 2016/05/17 18:16, Michael McConville wrote: > Dmitrij D. Czarkoff wrote: > > Stuart Henderson said: > > > glib2 is a pretty clean port patch-wise. This sort of thing would be > > > better done with proper autoconf etc so it can go upstream. > > > > Totally agree. It would be best if upstream would maintain the code. > > They could benefit from arc4random on other BSDs and libbsd-enabled > > platforms as well. > > Makes sense - I'm working on this now. > > Anecdocally, libbsd's arc4random is not necessarily secure. IIUC the > code isn't as glaringly dangerous as g_rand*, but it will seed with only > the time and PID if other sources fail. I think we should avoid > conflating BSDs' arc4randoms with libbsd's. > https://github.com/libressl-portable/portable/tree/master/m4 has autoconf checks with an OS whitelist for arc4random. It would be nice to keep things similar to these so that updates can be merged across from newer versions easily.
Re: Use arc4random in devel/glib2
Dmitrij D. Czarkoff wrote: > Stuart Henderson said: > > glib2 is a pretty clean port patch-wise. This sort of thing would be > > better done with proper autoconf etc so it can go upstream. > > Totally agree. It would be best if upstream would maintain the code. > They could benefit from arc4random on other BSDs and libbsd-enabled > platforms as well. Makes sense - I'm working on this now. Anecdocally, libbsd's arc4random is not necessarily secure. IIUC the code isn't as glaringly dangerous as g_rand*, but it will seed with only the time and PID if other sources fail. I think we should avoid conflating BSDs' arc4randoms with libbsd's.
Re: net/tor: fix example hidden service config
On Tue, 17 May 2016 18:05:50 -0400, Michael McConville wrote: > Michael McConville wrote: > > We patch Tor to use /var/tor instead of /var/lib/tor, but the hidden > > service example in the config hasn't been patched. This causes Tor to > > fail on startup if the example is used: > > > > > Error creating directory /var/lib/tor/hidden_service/: No such file or > > > directory > > > > The below patch fixes this. > > Ping. Is there anything that could be improved with this patch? Sorry, forgot about it. Totally ok (though adjust the REVISION line ofc). > > Index: Makefile > > === > > RCS file: /cvs/ports/net/tor/Makefile,v > > retrieving revision 1.88 > > diff -u -p -u -r1.88 Makefile > > --- Makefile10 Dec 2015 23:35:11 - 1.88 > > +++ Makefile3 May 2016 16:18:58 - > > @@ -3,6 +3,7 @@ > > COMMENT= anonymity service using onion routing > > > > DISTNAME= tor-0.2.7.6 > > +REVISION= 0 > > CATEGORIES=net > > HOMEPAGE= https://www.torproject.org/ > > > > Index: patches/patch-src_config_torrc_sample_in > > === > > RCS file: /cvs/ports/net/tor/patches/patch-src_config_torrc_sample_in,v > > retrieving revision 1.15 > > diff -u -p -u -r1.15 patch-src_config_torrc_sample_in > > --- patches/patch-src_config_torrc_sample_in25 Nov 2015 21:04:07 > > - 1.15 > > +++ patches/patch-src_config_torrc_sample_in3 May 2016 16:18:58 > > - > > @@ -1,6 +1,6 @@ > > $OpenBSD: patch-src_config_torrc_sample_in,v 1.15 2015/11/25 21:04:07 > > pascal Exp $ > > src/config/torrc.sample.in.origFri Nov 13 14:41:38 2015 > > -+++ src/config/torrc.sample.in Fri Nov 20 19:45:16 2015 > > +--- src/config/torrc.sample.in.origFri Nov 13 08:41:38 2015 > > src/config/torrc.sample.in Tue May 3 11:27:08 2016 > > @@ -39,18 +39,18 @@ > > ## Send every possible message to @LOCALSTATEDIR@/log/tor/debug.log > > #Log debug file @LOCALSTATEDIR@/log/tor/debug.log > > @@ -23,6 +23,19 @@ $OpenBSD: patch-src_config_torrc_sample_ > > > > ## The port on which Tor will listen for local connections from Tor > > ## controller applications, as documented in control-spec.txt. > > +@@ -69,10 +69,10 @@ > > + ## HiddenServicePort x y:z says to redirect requests on port x to the > > + ## address y:z. > > + > > +-#HiddenServiceDir @LOCALSTATEDIR@/lib/tor/hidden_service/ > > ++#HiddenServiceDir @LOCALSTATEDIR@/tor/hidden_service/ > > + #HiddenServicePort 80 127.0.0.1:80 > > + > > +-#HiddenServiceDir @LOCALSTATEDIR@/lib/tor/other_hidden_service/ > > ++#HiddenServiceDir @LOCALSTATEDIR@/tor/other_hidden_service/ > > + #HiddenServicePort 80 127.0.0.1:80 > > + #HiddenServicePort 22 127.0.0.1:22 > > + > > @@ -182,6 +182,8 @@ > > ## and any public IPv4 and IPv6 addresses on any interface on the relay. > > ## See the man page entry for ExitPolicyRejectPrivate if you want to allow > >
Re: net/tor: fix example hidden service config
Michael McConville wrote: > We patch Tor to use /var/tor instead of /var/lib/tor, but the hidden > service example in the config hasn't been patched. This causes Tor to > fail on startup if the example is used: > > > Error creating directory /var/lib/tor/hidden_service/: No such file or > > directory > > The below patch fixes this. Ping. Is there anything that could be improved with this patch? > Index: Makefile > === > RCS file: /cvs/ports/net/tor/Makefile,v > retrieving revision 1.88 > diff -u -p -u -r1.88 Makefile > --- Makefile 10 Dec 2015 23:35:11 - 1.88 > +++ Makefile 3 May 2016 16:18:58 - > @@ -3,6 +3,7 @@ > COMMENT= anonymity service using onion routing > > DISTNAME=tor-0.2.7.6 > +REVISION=0 > CATEGORIES= net > HOMEPAGE=https://www.torproject.org/ > > Index: patches/patch-src_config_torrc_sample_in > === > RCS file: /cvs/ports/net/tor/patches/patch-src_config_torrc_sample_in,v > retrieving revision 1.15 > diff -u -p -u -r1.15 patch-src_config_torrc_sample_in > --- patches/patch-src_config_torrc_sample_in 25 Nov 2015 21:04:07 - > 1.15 > +++ patches/patch-src_config_torrc_sample_in 3 May 2016 16:18:58 - > @@ -1,6 +1,6 @@ > $OpenBSD: patch-src_config_torrc_sample_in,v 1.15 2015/11/25 21:04:07 pascal > Exp $ > src/config/torrc.sample.in.orig Fri Nov 13 14:41:38 2015 > -+++ src/config/torrc.sample.in Fri Nov 20 19:45:16 2015 > +--- src/config/torrc.sample.in.orig Fri Nov 13 08:41:38 2015 > src/config/torrc.sample.in Tue May 3 11:27:08 2016 > @@ -39,18 +39,18 @@ > ## Send every possible message to @LOCALSTATEDIR@/log/tor/debug.log > #Log debug file @LOCALSTATEDIR@/log/tor/debug.log > @@ -23,6 +23,19 @@ $OpenBSD: patch-src_config_torrc_sample_ > > ## The port on which Tor will listen for local connections from Tor > ## controller applications, as documented in control-spec.txt. > +@@ -69,10 +69,10 @@ > + ## HiddenServicePort x y:z says to redirect requests on port x to the > + ## address y:z. > + > +-#HiddenServiceDir @LOCALSTATEDIR@/lib/tor/hidden_service/ > ++#HiddenServiceDir @LOCALSTATEDIR@/tor/hidden_service/ > + #HiddenServicePort 80 127.0.0.1:80 > + > +-#HiddenServiceDir @LOCALSTATEDIR@/lib/tor/other_hidden_service/ > ++#HiddenServiceDir @LOCALSTATEDIR@/tor/other_hidden_service/ > + #HiddenServicePort 80 127.0.0.1:80 > + #HiddenServicePort 22 127.0.0.1:22 > + > @@ -182,6 +182,8 @@ > ## and any public IPv4 and IPv6 addresses on any interface on the relay. > ## See the man page entry for ExitPolicyRejectPrivate if you want to allow >
mail/exim SPF ACL
Hello, Wouldn't it be a good idea to make a new flavor for mail/exim with SPF ACL included? Or maybe use the version with SPF ACL as the default one, although that would involve installing libspf2 by default. Regards smime.p7s Description: S/MIME Cryptographic Signature
Re: mail/popa3d broken?
On 2016/05/17 20:29, Stuart Henderson wrote:
> On 2016/05/17 20:13, Andreas Bartelt wrote:
> > Hello,
> >
> > although this ports didn't change since 07/2014, it seems to be broken on
> > current (tested on amd64).
> >
> > Can anybody else reproduce this problem on current?
>
> It will be due to this: http://marc.info/?t=14623987751&r=1&w=2
>
This is probably the diff to fix it, please test and report back.
Index: Makefile
===
RCS file: /cvs/ports/mail/popa3d/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile16 Jul 2014 12:02:30 - 1.1.1.1
+++ Makefile17 May 2016 19:59:39 -
@@ -3,6 +3,7 @@
COMMENT = tiny pop3 daemon
DISTNAME = popa3d-1.0.3
+REVISION = 0
CATEGORIES = mail
Index: patches/patch-auth_passwd_c
===
RCS file: patches/patch-auth_passwd_c
diff -N patches/patch-auth_passwd_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-auth_passwd_c 17 May 2016 19:59:39 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- auth_passwd.c.orig Tue May 17 20:59:12 2016
auth_passwd.c Tue May 17 20:59:19 2016
+@@ -19,7 +19,7 @@ struct passwd *auth_userpass(char *user, char *pass, i
+ {
+ struct passwd *pw, *result;
+
+- *known = (pw = getpwnam(user)) != NULL;
++ *known = (pw = getpwnam_shadow(user)) != NULL;
+ endpwent();
+ result = NULL;
+
Re: mail/popa3d broken?
On 2016/05/17 20:13, Andreas Bartelt wrote: > Hello, > > although this ports didn't change since 07/2014, it seems to be broken on > current (tested on amd64). > > Can anybody else reproduce this problem on current? It will be due to this: http://marc.info/?t=14623987751&r=1&w=2
Re: qt*.port.mk and lrelease
2016-05-17 14:51 GMT+03:00 Jeremie Courreges-Anglas : > Jeremie Courreges-Anglas writes: > >> j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: >> >>> There are a few ports that use lrelease4, but there is no abstraction in >>> the port module. >> >> Please forget this messed up patch, updated version below. >> >>> Comments / ok? > > After feedback from zhuk@, here's a new diff for x11/qt*, for > consistency, and a diff for port-modules(5). okay zhuk@ -- WBR, Vadim Zhukov
mail/popa3d broken?
Hello, although this ports didn't change since 07/2014, it seems to be broken on current (tested on amd64). Can anybody else reproduce this problem on current? Best regards Andreas
Re: json-c patch for arc4random
Kristaps Dzonsons writes: >>> Good question. I figured that if the user has - explicitely - chosen >>> rdrand, then the choice should be respected, even if it's a bit, ahem, >>> stupid. >>> >>> I can change the diff if that's a problem. In the end, this should be >>> discussed with upstream. >> >> Same proposal, diff below for convenience. > > +1 > > I can now pledge my json-c systems. It's in! -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Using gvfsd-fuse with /dev/fuse0
Hey, On 05/17/16 14:32, David Coppa wrote: Only the superuser may mount file systems unless kern.usermount is nonzero (see sysctl(8)), the special device is readable and writeable by the user attempting the mount, and the mount point node is owned by the user attempting the mount. So, besides setting kern.usermount to 1, I think you also need: # chmod g+rw /dev/fuse0 ; ls -al /dev/fuse0 crw-rw 1 root wheel 92, 0 Nov 19 15:18 /dev/fuse0 you are the best. chmod'ing the file plus a restart of the computer helped. Now it mounts the remote directory into ~/.gvfs. Its slow as hell, but it works :) Big thanks and greetings Leo
Re: json-c patch for arc4random
>> Good question. I figured that if the user has - explicitely - chosen >> rdrand, then the choice should be respected, even if it's a bit, ahem, >> stupid. >> >> I can change the diff if that's a problem. In the end, this should be >> discussed with upstream. > > Same proposal, diff below for convenience. +1 I can now pledge my json-c systems. Best, Kristaps
Re: Using gvfsd-fuse with /dev/fuse0
On Tue, May 17, 2016 at 1:23 PM, Leo Unglaub wrote: > Hey, > > On 05/17/16 13:18, Leo Unglaub wrote: >> >> What's the output of: >> >> # ls -al /dev/fuse0 >> >> On your system? > > > the output is as followed. I am on OpenBSD 5.9 (amd64) > >> $ ls -al /dev/fuse0 >> crw--- 1 root wheel 92, 0 May 10 01:51 /dev/fuse0 > > > > My user is also in the wheel group: > >> $ userinfo batman >> login batman >> passwd * >> uid 1000 >> groups batman wheel >> change NEVER >> class staff >> gecos Bruce Wayne >> dir /home/batman >> shell /bin/ksh >> expire NEVER > > > Big thanks and greetings > Leo > The mount(8) manpage says: Only the superuser may mount file systems unless kern.usermount is nonzero (see sysctl(8)), the special device is readable and writeable by the user attempting the mount, and the mount point node is owned by the user attempting the mount. So, besides setting kern.usermount to 1, I think you also need: # chmod g+rw /dev/fuse0 ; ls -al /dev/fuse0 crw-rw 1 root wheel 92, 0 Nov 19 15:18 /dev/fuse0 Ciao! David
Re: qt*.port.mk and lrelease
Jeremie Courreges-Anglas writes:
> j...@wxcvbn.org (Jeremie Courreges-Anglas) writes:
>
>> There are a few ports that use lrelease4, but there is no abstraction in
>> the port module.
>
> Please forget this messed up patch, updated version below.
>
>> Comments / ok?
After feedback from zhuk@, here's a new diff for x11/qt*, for
consistency, and a diff for port-modules(5).
Index: x11/qt3/qt3.port.mk
===
RCS file: /cvs/ports/x11/qt3/qt3.port.mk,v
retrieving revision 1.14
diff -u -p -r1.14 qt3.port.mk
--- x11/qt3/qt3.port.mk 22 Nov 2010 08:37:04 - 1.14
+++ x11/qt3/qt3.port.mk 17 May 2016 11:49:16 -
@@ -35,6 +35,8 @@ MODQT3_UIC = ${LOCALBASE}/bin/uic3-mt
MODQT_UIC ?= ${MODQT3_UIC}
MODQT3_QTDIR = ${LOCALBASE}/lib/qt3
MODQT_QTDIR ?= ${MODQT3_QTDIR}
+MODQT3_LRELEASE = ${LOCALBASE}/bin/lrelease-mt
+MODQT_LRELEASE ?= ${MODQT3_LRELEASE}
MODQT3_PLUGINS =lib/qt3/plugins-33
MODQT_PLUGINS ?=${MODQT3_PLUGINS}
Index: x11/qt4/qt4.port.mk
===
RCS file: /cvs/ports/x11/qt4/qt4.port.mk,v
retrieving revision 1.12
diff -u -p -r1.12 qt4.port.mk
--- x11/qt4/qt4.port.mk 26 Mar 2016 20:37:35 - 1.12
+++ x11/qt4/qt4.port.mk 17 May 2016 11:49:16 -
@@ -30,6 +30,8 @@ MODQT4_QMAKE = ${LOCALBASE}/bin/qmake4
MODQT_QMAKE ?= ${MODQT4_QMAKE}
MODQT4_QTDIR = ${LOCALBASE}/lib/qt4
MODQT_QTDIR ?= ${MODQT4_QTDIR}
+MODQT4_LRELEASE = ${LOCALBASE}/bin/lrelease4
+MODQT_LRELEASE ?= ${MODQT4_LRELEASE}
MODQT4_LIB_DEPENDS = x11/qt4
MODQT_LIB_DEPENDS ?= ${MODQT4_LIB_DEPENDS}
Index: x11/qt5/qt5.port.mk
===
RCS file: /cvs/ports/x11/qt5/qt5.port.mk,v
retrieving revision 1.11
diff -u -p -r1.11 qt5.port.mk
--- x11/qt5/qt5.port.mk 26 Mar 2016 20:37:35 - 1.11
+++ x11/qt5/qt5.port.mk 17 May 2016 11:49:16 -
@@ -28,6 +28,8 @@ MODQT5_QMAKE = ${LOCALBASE}/bin/qmake-qt
MODQT_QMAKE ?= ${MODQT5_QMAKE}
MODQT5_QTDIR = ${LOCALBASE}/lib/qt5
MODQT_QTDIR ?= ${MODQT5_QTDIR}
+MODQT5_LRELEASE = ${LOCALBASE}/bin/lrelease-qt5
+MODQT_LRELEASE ?= ${MODQT5_LRELEASE}
_MODQT5_CMAKE_PKGS = \
Qt5 \
Index: port-modules.5
===
RCS file: /cvs/src/share/man/man5/port-modules.5,v
retrieving revision 1.205
diff -u -p -r1.205 port-modules.5
--- port-modules.5 26 Apr 2016 16:25:09 - 1.205
+++ port-modules.5 17 May 2016 11:51:04 -
@@ -1852,11 +1852,13 @@ as the global qt directory location,
as standard GNU configure-style parameters to locate the include and libraries.
.Pp
The location of qt specific tools
+.Nm lrelease ,
.Nm moc ,
.Nm qmake
and
.Nm uic
is available through
+.Ev MODQT*_LRELEASE ,
.Ev MODQT*_MOC ,
.Ev MODQT*_QMAKE
and
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Using gvfsd-fuse with /dev/fuse0
On Tue, May 17, 2016 at 1:18 PM, Leo Unglaub wrote: > Hey friends, > i am trying to get gvfsd-fuse to work with the OpenBSD fuse implementation > /dev/fuse0. > > My goal is to get gvfsd-fuse to mount remote filesystems in ~/.gvfs so that > pure posix applications can access the files from remote systems. The > general workflow should be as followed: > > 1: Browse a remote server with my file browser (Xfce4 Thunar) > 2: Opening a file > 3: gvfsd-fuse mounts that location in ~/.gvfs/ so that my editor (Geany) can > open it > > > I did the following things in order to try to get it to work: > > * Allowed user mounts (kern.usermount to 1) > * Started dbus (/etc/rc.d/messagebus) > > This is the workflow i know from an old Linux Distribution i once used but > sadly i am unable to get this to work on OpenBSD. I hope someone of you can > point out the me what i have to do in order to get this to work. > > Big thanks > Leo > What's the output of: # ls -al /dev/fuse0 On your system? -- David
Re: Using gvfsd-fuse with /dev/fuse0
Hey, On 05/17/16 13:18, Leo Unglaub wrote: What's the output of: # ls -al /dev/fuse0 On your system? the output is as followed. I am on OpenBSD 5.9 (amd64) $ ls -al /dev/fuse0 crw--- 1 root wheel 92, 0 May 10 01:51 /dev/fuse0 My user is also in the wheel group: $ userinfo batman login batman passwd * uid 1000 groups batman wheel change NEVER class staff gecos Bruce Wayne dir /home/batman shell /bin/ksh expire NEVER Big thanks and greetings Leo
Using gvfsd-fuse with /dev/fuse0
Hey friends, i am trying to get gvfsd-fuse to work with the OpenBSD fuse implementation /dev/fuse0. My goal is to get gvfsd-fuse to mount remote filesystems in ~/.gvfs so that pure posix applications can access the files from remote systems. The general workflow should be as followed: 1: Browse a remote server with my file browser (Xfce4 Thunar) 2: Opening a file 3: gvfsd-fuse mounts that location in ~/.gvfs/ so that my editor (Geany) can open it I did the following things in order to try to get it to work: * Allowed user mounts (kern.usermount to 1) * Started dbus (/etc/rc.d/messagebus) This is the workflow i know from an old Linux Distribution i once used but sadly i am unable to get this to work on OpenBSD. I hope someone of you can point out the me what i have to do in order to get this to work. Big thanks Leo
Re: update the_silver_searcher (uses pledge upstream)
On Tue, May 17, 2016 at 08:54:41AM +0100, Stuart Henderson wrote: > Update and switch to upstream's standard install target. It now uses > pledge, so add a marker to the Makefile. Ok? > Ok by me. I have also been running the pledge patch without any issues for a few months now.
Re: update the_silver_searcher (uses pledge upstream)
On Tue, May 17, 2016 at 08:54:41AM +0100, Stuart Henderson wrote: > Update and switch to upstream's standard install target. It now uses > pledge, so add a marker to the Makefile. Ok? I've been running ag with the pledge patches since they were posted back in February, so these should be fine. Port looks good, the modifications and simplifications make sense to me. Unless Florian objects, ok tb@
Re: security/wpa_supplicant - multiple vulnerabilities
On Tue, May 17, 2016 at 4:01 AM, Sevan Janiyan wrote: > Hello, > The version of security/wpa_supplicant in ports is vulnerable to the > following CVEs > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4476 > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4477 I've applied upstream fixes from http://w1.fi/security/2016-1/ Thanks for the heads up! David
Re: NEW: sysutils/u-boot
On Mon, May 16, 2016 at 11:01:00PM +1000, Jonathan Gray wrote:
> On Mon, May 16, 2016 at 12:57:19PM +0100, Stuart Henderson wrote:
> > On 2016/05/16 21:18, Jonathan Gray wrote:
> > > On Sun, May 15, 2016 at 04:53:40PM +0200, Jeremie Courreges-Anglas wrote:
> > > >
> > > > Hi,
> > > >
> > > > Please reorder the Makefile to follow
> > > > infrastructure/templates/Makefile.template, same thing for
> > > > sysutils/dtb.
> > > >
> > > > Since you're replicating much of the default build target, it would also
> > > > make sense to use ${SETENV} instead of env -i.
> > > >
> > > > I think PKG_ARCH-data should be PKG_ARCH. Should sysutils/dtb also use
> > > > PKG_ARCH=* ?
> > >
> > > Thanks, updated with the above suggestions.
> >
> > This is missing a build dep on devel/dtc. Also could you flesh out
> > DESCR a bit please? Something like this maybe,
> >
> > "U-Boot is a boot loader for embedded boards based on PowerPC, ARM, MIPS and
> > several other processors, which can be installed in a boot ROM and used to
> > initialize and test the hardware or to download and run application code.
> >
> > This package provides U-Boot for various boards using ARM processors."
> >
> > Otherwise OK.
> >
>
> Updated with the build dep and the below DESCR:
>
> U-Boot is a firmware for embedded boards based on PowerPC, ARM, MIPS and
> several other processors, which can be installed in a boot ROM and used to
> initialize and test the hardware or to download and run application code.
>
> As ARM systems often do not come with firmware it must be supplied on
> an SD card or MMC device to have a bootable system.
>
> This package provides U-Boot for various boards using ARM processors.
And another update for the final version of 2016.05 with some additional
targets added.
u-boot.tgz
Description: application/tar-gz
update the_silver_searcher (uses pledge upstream)
Update and switch to upstream's standard install target. It now uses
pledge, so add a marker to the Makefile. Ok?
Index: Makefile
===
RCS file: /cvs/ports/textproc/the_silver_searcher/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile9 Oct 2015 12:48:22 - 1.19
+++ Makefile17 May 2016 07:51:20 -
@@ -2,7 +2,7 @@
COMMENT = code searching tool, with a focus on speed (ag)
-DISTNAME = the_silver_searcher-0.31.0
+DISTNAME = the_silver_searcher-0.32.0
CATEGORIES = textproc
HOMEPAGE = https://github.com/ggreer/the_silver_searcher
@@ -11,6 +11,7 @@ MAINTAINER = Florian Stinglmayr http://geoff.greer.fm/ag/releases/
@@ -19,18 +20,11 @@ LIB_DEPENDS = archivers/xz \
devel/pcre
CONFIGURE_STYLE = gnu
+SEPARATE_BUILD = Yes
CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include"
+FAKE_FLAGS = bashcompdir=${PREFIX}/share/bash-completion/completions
-# referenced in Makefile, but apparently included in distfile
+# not included in distfile, only in repository. requires cram.
NO_TEST = YES
-
-pre-configure:
- sed -i "s,-O2,,g" ${WRKSRC}/configure
-
-do-install:
- ${INSTALL_PROGRAM} ${WRKSRC}/ag ${PREFIX}/bin/ag
- ${INSTALL_MAN} ${WRKSRC}/doc/ag.1 ${PREFIX}/man/man1
- ${INSTALL_DATA_DIR} ${PREFIX}/share/bash-completion/completions
- ${INSTALL_DATA} ${WRKSRC}/ag.bashcomp.sh
${PREFIX}/share/bash-completion/completions/ag
.include
Index: distinfo
===
RCS file: /cvs/ports/textproc/the_silver_searcher/distinfo,v
retrieving revision 1.17
diff -u -p -r1.17 distinfo
--- distinfo18 Sep 2015 14:54:15 - 1.17
+++ distinfo17 May 2016 07:51:20 -
@@ -1,2 +1,2 @@
-SHA256 (the_silver_searcher-0.31.0.tar.gz) =
K1VtYacC0E4mOFMqugi8zxeFI7ajhGSiUwVWNYGCMnE=
-SIZE (the_silver_searcher-0.31.0.tar.gz) = 177903
+SHA256 (the_silver_searcher-0.32.0.tar.gz) =
lEynfkmPNEsr+9jfbV2N97vBx+CAtQwLqz0amlUVG2A=
+SIZE (the_silver_searcher-0.32.0.tar.gz) = 179724
Index: pkg/PLIST
===
RCS file: /cvs/ports/textproc/the_silver_searcher/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 20 Sep 2013 14:40:09 - 1.2
+++ pkg/PLIST 17 May 2016 07:51:20 -
@@ -3,4 +3,4 @@
@man man/man1/ag.1
share/bash-completion/
share/bash-completion/completions/
-share/bash-completion/completions/ag
+share/bash-completion/completions/ag.bashcomp.sh
