Re: qt4-qmake-4.8.4 upgrading stops for input. Which file to patch?
2013-08-15 17:27, Raphael Kubo da Costa skrev: Leslie Jensen les...@eskk.nu writes: All qt4-qmake-4.8.4 (1/1) === Cleaning for qt4-qmake-4.8.4_1 === qt4-qmake-4.8.4_1 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by qt4-qmake-4.8.4_1 for building === Extracting for qt4-qmake-4.8.4_1 = SHA256 Checksum OK for KDE/qt-everywhere-opensource-src-4.8.4.tar.gz. === Patching for qt4-qmake-4.8.4_1 === Applying FreeBSD patches for qt4-qmake-4.8.4_1 File to patch: Fixed in r324772. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org Thanks :-) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Searching the port tree with portmaster?
On Fri, Aug 16, 2013 at 7:35 AM, Sergey V. Dyatko
sergey.dya...@gmail.com wrote:
2 aliases from my .cshrc:
alias search_namemake -C /usr/ports/
search name='\!*' display=name,path,info
alias search_keymake -C /usr/ports/ search key='\!*'
display=name,path,info
search_[name|key] smthng
And a sh script solution, in case it is of use to someone:
tingo@kg-core1$ pinfo
pinfo - find a given port in /usr/ports
Use with 'pinfo xxx', where xxx is the name of the port.
It looks like this:
tingo@kg-core1$ more `which pinfo`
#!/bin/sh
# @(#)port 1.0 10-nov-2001 T. Ingolfsen / KG4, Norway
#
# Just a quick hack to get any easier way to search for ports
#
NAME=`basename ${0}`
PORTNAME=${1}
PORTSDIR=/usr/ports
if [ $1 = ]; then
echo ${NAME} - find a given port in /usr/ports
echo Use with '${NAME} xxx', where xxx is the name of the port.
else
if [ ! -d ${PORTSDIR} ]; then
echo ERROR: ${PORTSDIR} doesn't exist!
exit 0
fi
cd ${PORTSDIR}
make search name=${PORTNAME}
fi
(yes, it was originally called port, but at some point in time it
conflicted with a port I installed, thus I renamed it pinfo)
HTH
--
Regards,
Torfinn Ingolfsen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
openldap-client conflicts with openldap-sasl-client
While updating the ports following ports/UPDATING entry 20130731 I got this error: === Updating dependent ports gconf2-2.32.0_3 net/openldap24-client (27/59) === Cleaning for openldap-client-2.4.35 === openldap-client-2.4.35 conflicts with installed package(s): openldap-sasl-client-2.4.35 Have I missed something? Thanks Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [patch] various pkg audit issues
Any feedback / ideas on this? On Mon, 29 Jul 2013 21:01:22 +0200 Michael Gmelin free...@grem.de wrote: Hi, periodic/410.pkg-audit produces inconsistent output depending on if the database has been fetched or not. Since the default db expiry is two days this produces alternating output, e.g.: Day 1: Checking for packages with security vulnerabilities: subversion-1.7.10 Day 2: Checking for packages with security vulnerabilities: Database fetched: Sun Jul 28 03:02:06 UTC 2013 subversion-1.7.10 is vulnerable: subversion -- remotely triggerable Assertion failed DoS vulnerability or read overflow. WWW: http://portaudit.FreeBSD.org/2ae24334-f2e6-11e2-8346-001e8c75030d.html 1 problem(s) in your installed packages found. Day 3: Checking for packages with security vulnerabilities: subversion-1.7.10 And so on. The attached patch (also available at [1]) fixes this by running pkg audit a second time in case a vulnerability has been found on the first (fetching) run. This is merely a workaround, IMHO it would be best to provide a fetch only option to pkg audit and do fetching and checking in two separate invocations. The default of two days for daily_status_security_pkgaudit_expiry seems not a good choice, I would suggest to change it to one day, so that the periodic job always uses the latest version of the audit database (you don't want to loose an extra day learning about that remote exploitable vulnerability - anything one day should be the exception and not the rule at this point). I seems like pkg audit doesn't validate the signature of auditfile after fetching it. I originally introduced this signature to portaudit to mitigate a remote command execution vulnerability (see [2]). The potential for remote code execution is lower compared to ports-mgmt/portaudit, since auditfile is not processed by shell scripts directly - even though its output might be processed by users, not that uncommon. Regardless, checking the signature would be reasonable to ensure that auditfile has not been tampered with, especially since it's fetched using plain http and could get faked quite easily (e.g. DNS spoofing or transparent proxying). It also seems like pkg audit doesn't check the CREATED header of auditfile, therefore it won't complain in case an outdated auditfile is used. This could be used in a malicious way or simply happen by accident in setups where machines, which are not directly connected to the internet, access a copy on the local network that might have stopped receiving updates. By implementing both features, signature and creation timestamp checking, pkg audit would ensure that always a recent and authoritative vulnerability database is used. Michael [1]http://blog.grem.de/0001-Ensure-pkg-audit-periodic-output-consistency.patch [2]http://vuxml.freebsd.org/freebsd/6d329b64-6bbb-11e1-9166-001e4f0fb9b1.html -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [patch] various pkg audit issues
On 16/08/2013 13:24, Michael Gmelin wrote: Any feedback / ideas on this? On Mon, 29 Jul 2013 21:01:22 +0200 Michael Gmelin free...@grem.de wrote: Hi, periodic/410.pkg-audit produces inconsistent output depending on if the database has been fetched or not. Since the default db expiry is two days this produces alternating output, e.g.: Day 1: Checking for packages with security vulnerabilities: subversion-1.7.10 Day 2: Checking for packages with security vulnerabilities: Database fetched: Sun Jul 28 03:02:06 UTC 2013 subversion-1.7.10 is vulnerable: subversion -- remotely triggerable Assertion failed DoS vulnerability or read overflow. WWW: http://portaudit.FreeBSD.org/2ae24334-f2e6-11e2-8346-001e8c75030d.html 1 problem(s) in your installed packages found. Day 3: Checking for packages with security vulnerabilities: subversion-1.7.10 And so on. The attached patch (also available at [1]) fixes this by running pkg audit a second time in case a vulnerability has been found on the first (fetching) run. This is merely a workaround, IMHO it would be best to provide a fetch only option to pkg audit and do fetching and checking in two separate invocations. The default of two days for daily_status_security_pkgaudit_expiry seems not a good choice, I would suggest to change it to one day, so that the periodic job always uses the latest version of the audit database (you don't want to loose an extra day learning about that remote exploitable vulnerability - anything one day should be the exception and not the rule at this point). I seems like pkg audit doesn't validate the signature of auditfile after fetching it. I originally introduced this signature to portaudit to mitigate a remote command execution vulnerability (see [2]). The potential for remote code execution is lower compared to ports-mgmt/portaudit, since auditfile is not processed by shell scripts directly - even though its output might be processed by users, not that uncommon. Regardless, checking the signature would be reasonable to ensure that auditfile has not been tampered with, especially since it's fetched using plain http and could get faked quite easily (e.g. DNS spoofing or transparent proxying). It also seems like pkg audit doesn't check the CREATED header of auditfile, therefore it won't complain in case an outdated auditfile is used. This could be used in a malicious way or simply happen by accident in setups where machines, which are not directly connected to the internet, access a copy on the local network that might have stopped receiving updates. By implementing both features, signature and creation timestamp checking, pkg audit would ensure that always a recent and authoritative vulnerability database is used. Michael [1]http://blog.grem.de/0001-Ensure-pkg-audit-periodic-output-consistency.patch [2]http://vuxml.freebsd.org/freebsd/6d329b64-6bbb-11e1-9166-001e4f0fb9b1.html Thanks for the patch. I'll have a look at this over the weekend. I agree that next day alert to any new vulnerabilities are desirable nowadays. And your comments about checking the CREATED header are valid too. Cheers, Matthew PS. While we are happy to receive feedback by any channel, opening an issue on GitHub is our preferred mechanism: we can't miss that, and it won't get accidentally forgotten. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[QAT] r324818: 4x leftovers
Update 804.030 -- 804.031 This fixes build under perl5.18. Reviewed by:perl@ mailing list - Build ID: 20130816223800-16571 Job owner: c...@freebsd.org Buildtime: 8 minutes Enddate: Fri, 16 Aug 2013 22:46:24 GMT Revision: r324818 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=324818 - Port:x11-toolkits/p5-Tk 804.031 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~c...@freebsd.org/20130816223800-16571-170484/p5-Tk-804.031.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~c...@freebsd.org/20130816223800-16571-170485/p5-Tk-804.031.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~c...@freebsd.org/20130816223800-16571-170486/p5-Tk-804.031.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~c...@freebsd.org/20130816223800-16571-170487/p5-Tk-804.031.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20130816223800-16571 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: openldap-client conflicts with openldap-sasl-client
On 16/08/2013 19:39, Anton Shterenlikht wrote: While updating the ports following ports/UPDATING entry 20130731 I got this error: === Updating dependent ports gconf2-2.32.0_3 net/openldap24-client (27/59) === Cleaning for openldap-client-2.4.35 === openldap-client-2.4.35 conflicts with installed package(s): openldap-sasl-client-2.4.35 Have I missed something? portmaster can't tell that the two ldap client ports are variants of the same port. To prevent this happening you need to make sure that the one you want is installed properly first, so that the dependency tests pass and portmaster doesn't hit this snag. I'm guessing that some bits of your openldap-sasl-client have gone missing, causing the tests in bsd.ldap.mk to fail, and resulting in attempted installation of net/openldap24-client. I suggest you reinstall openldap-sasl-client-2.4.35 by itself and then try again. -- John Marshall signature.asc Description: OpenPGP digital signature
portsdb + rrdmerge = *hiccup*
Hey guys, Since databases/rrdmerge showed up in ports, portupgrade seems to have gotten a bit unhappy with INDEX: [Updating the portsdb format:bdb_btree [...] /usr/ports/INDEX-8:19441:rrdmerge-0.0_b05d69bfac64: 0.0_b05d69bfac64: Not in due form: 'version[_revision][,epoch]'. (whether the version is itself malformed, or portsdb is being overly retentive, I leave as an exercise to the readers ;) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
