Opera vulnerability, marked forbidden instead of update?
Hello, I've noticed that www/opera was marked FORBIDDEN because of a security hole: http://www.freebsd.org/cgi/getmsg.cgi?fetch=614275+0+current/svn-ports-head The opera software compagny advisory indeed mark this bug as high severity, and mention that there is an update to fix it. I am not familiar with the security process in ports, but would not it be better to update the version? Marking it FORBIDDEN do not do much for the userbase that does already have it installed. I've bumped the versions in the Makefile OPERA_VER?= 12.11 OPERA_BUILD?= 1661 and made a `make makesum reinstall`, there was no apparent problem. Regards, -- Matthieu Volat ma...@alkumuna.eu ___ 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
Self-Maintained ports Makefile for cloned git
Hi. I want to add a new port to my locally maintained collection. Source files will be cloned using git into a folder on the system (and not a tar.gz file) and I will manually update the git, I do not want the Makefile to run git fetch. So I have several questions about this: 1. How do I set MASTER_SITES in the port's Makefile to a local folder path? Something like this? MASTER_SITES=file//path/to/folder - is there another variable I am overlooking? 2. Is there any way version information on the git clone can be automatically passed to the Makefile? Can DISTNAME= be of help here? 3. In the Makefile do I have to define tools that the source needs for building (like cmake / bison / lua)? Or is the process smart enough to know where to look - sometimes source builds break because they are unable to locate a tool which is already installed on the system. Thank You. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Self-Maintained-ports-Makefile-for-cloned-git-tp5763428.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ 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: Opera vulnerability, marked forbidden instead of update?
On 23/11/2012 08:26, Matthieu Volat wrote: I've noticed that www/opera was marked FORBIDDEN because of a security hole: http://www.freebsd.org/cgi/getmsg.cgi?fetch=614275+0+current/svn-ports-head The opera software compagny advisory indeed mark this bug as high severity, and mention that there is an update to fix it. I am not familiar with the security process in ports, but would not it be better to update the version? Marking it FORBIDDEN do not do much for the userbase that does already have it installed. I've bumped the versions in the Makefile OPERA_VER?= 12.11 OPERA_BUILD?= 1661 and made a `make makesum reinstall`, there was no apparent problem. Marking a port 'FORBIDDEN' is a quick response measure that can be done without having to worry about time consuming testing the of port and so forth. It's an interim measure taken to ensure that users do not unwittingly install software with known vulnerabilities. Yes, updating the port to a non-vulnerable version is the ideal response, but that may not be possible to do straight away. You've sketched out the first couple of steps a port maintainer would take, but that 'there was no apparent problem' statement would need to be backed up by some more rigorous testing before a maintainer would feel confident in committing the update. Cheers, Matthew ___ 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
gnome-keyring error prevents Firefox build
I have been getting this error for some time when compiling firefox: args: ['/usr/obj/asp/ports/www/firefox/work/mozilla-release/obj-x86_64-unknown-freebsd9.1/dist/firefox/firefox-bin', '-no-remote', '-profile', '/usr/obj/asp/ports/www/firefox/work/mozilla-release/obj-x86_64-unknown-freebsd9.1/_profile/pgo/pgoprofile/', 'http://127.0.0.1:/index.html'] INFO | automation.py | Application pid: 50174 Error: cannot open display: localhost:1001 TEST-UNEXPECTED-FAIL | automation.py | Exited with code 1 during test run INFO | automation.py | Application ran for: 0:00:01.560881 INFO | automation.py | Reading PID log: /tmp/tmpHpNy8cpidlog gmake: *** [profiledbuild] Error 1 *** [do-build] Error code 1 My work-around was to logout from gnome, login to the awesome desktop environment and continue the build from there. The latest port updates now prevent me from doing that and I now get the error in awesome as well. The gnome-keyring error is: * gnome-keyring-daemon[1028]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk * polkitd(authority=local): Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.30 [/usr/local/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) * dbus[665]: [system] Rejected send message, 2 matched rules; type=method_call, sender=:1.36 (uid=1001 pid=1042 comm=nautilus ) interface=org.freedesktop.DBus.Properties member=GetAll error name=(unset) requested_reply=0 destination=:1.1 (uid=0 pid=686 comm=/usr/local/sbin/console-kit-daemon --no-daemon ) -- View this message in context: http://freebsd.1045724.n5.nabble.com/gnome-keyring-error-prevents-Firefox-build-tp5763435.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ 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: fixing missing launch icons
I corrected the other error and installed textproc/goldendict. when I run $ update-desktop-database, I get error: Could not parse file /usr/local/share/applications/emma.desktop: Key file does not start with a group I cannot find any reference to the error or to group in the *.desktop standard. -- View this message in context: http://freebsd.1045724.n5.nabble.com/fixing-missing-launch-icons-tp5759494p5763467.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ 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: Opera vulnerability, marked forbidden instead of update?
On Friday 23 November 2012 03:00:59 Matthew Seaman wrote: On 23/11/2012 08:26, Matthieu Volat wrote: I've noticed that www/opera was marked FORBIDDEN because of a security hole: http://www.freebsd.org/cgi/getmsg.cgi?fetch=614275+0+current/svn-ports-h ead The opera software compagny advisory indeed mark this bug as high severity, and mention that there is an update to fix it. I am not familiar with the security process in ports, but would not it be better to update the version? Marking it FORBIDDEN do not do much for the userbase that does already have it installed. I've bumped the versions in the Makefile OPERA_VER?= 12.11 OPERA_BUILD?= 1661 and made a `make makesum reinstall`, there was no apparent problem. Marking a port 'FORBIDDEN' is a quick response measure that can be done without having to worry about time consuming testing the of port and so forth. It's an interim measure taken to ensure that users do not unwittingly install software with known vulnerabilities. Yes, updating the port to a non-vulnerable version is the ideal response, but that may not be possible to do straight away. You've sketched out the first couple of steps a port maintainer would take, but that 'there was no apparent problem' statement would need to be backed up by some more rigorous testing before a maintainer would feel confident in committing the update. Cheers, Matthew I did the same and I don't have problems... Mitja http://www.redbubble.com/people/lumiwa ___ 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: blue griffon
I will post later if it is successfully.
I ran into the same error as stated here:
https://groups.google.com/forum/?fromgroups=#!topic/bluegriffon/W-EjIGzTFEE
mozilla/src/dom/base/nsFocusManager.cpp: In member function 'nsresult
nsFocusManager::DetermineElementToMoveFocus(nsPIDOMWindow*, nsIContent*,
int32_t, bool, nsIContent**)':
mozilla/src/dom/base/nsFocusManager.cpp:2672:1: error: a
function-definition is not allowed here before '{' token
mozilla/src/dom/base/nsFocusManager.cpp:3406:1: error: expected '}' at
end of input
mozilla/src/dom/base/nsFocusManager.cpp:3406:1: error: control reaches
end of non-void function [-Werror=return-type]
nsDOMClassInfo.cpp
cc1plus: some warnings being treated as errors
Unfortunately I got no clue how to resolve this at the moment.
I'm using gcc46, BG svn checkout 1.5.2 and trunk from mozilla-central.
Anybody seens this error when compiling mozilla from source?
Greetings Peter
___
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: Opera vulnerability, marked forbidden instead of update?
On Fri, 23 Nov 2012 09:00:59 + Matthew Seaman matt...@freebsd.org wrote: On 23/11/2012 08:26, Matthieu Volat wrote: I've noticed that www/opera was marked FORBIDDEN because of a security hole: http://www.freebsd.org/cgi/getmsg.cgi?fetch=614275+0+current/svn-ports-head The opera software compagny advisory indeed mark this bug as high severity, and mention that there is an update to fix it. I am not familiar with the security process in ports, but would not it be better to update the version? Marking it FORBIDDEN do not do much for the userbase that does already have it installed. I've bumped the versions in the Makefile OPERA_VER?= 12.11 OPERA_BUILD?= 1661 and made a `make makesum reinstall`, there was no apparent problem. Marking a port 'FORBIDDEN' is a quick response measure that can be done without having to worry about time consuming testing the of port and so forth. It's an interim measure taken to ensure that users do not unwittingly install software with known vulnerabilities. Yes, updating the port to a non-vulnerable version is the ideal response, but that may not be possible to do straight away. You've sketched out the first couple of steps a port maintainer would take, but that 'there was no apparent problem' statement would need to be backed up by some more rigorous testing before a maintainer would feel confident in committing the update. Cheers, Matthew ___ 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 Hello and thanks for the explanation, Cheers, -- Matthieu Volat ma...@alkumuna.eu ___ 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
[security/sshguard] Are default intervals toggled?
Hi All, there are two valuse at the port's RC script: - # sshguard_pardon_min_interval (int): # Minimum pardon interval. Set to 1200 # by default. # sshguard_prescribe_interval (int): # Prescribe interval. Set to 420 by # default. - This seems to contradict with the man and sources: - /* default: minimum seconds after which unblocking a blocked IP. Max is (min*3/2) */ #define DEFAULT_PARDON_THRESHOLD(7 * 60) /* default seconds after which forgiving a cracker candidate */ #define DEFAULT_STALE_THRESHOLD (20 * 60) - The man page: - -p secs release a blocked address no sooner than secs seconds after being blocked for the first time. sshguard will release the address between X and 3/2 * X seconds after blocking it. (Default: 7*60) -s secs forget about an address after secs seconds. If host A issues one attack every this many seconds, it will never be blocked. (Default: 20*60) - If I'm not mistaken those two values should be toggled at the RC script. Or am I lost with those therms/variable names? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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
graphics/OpenEXR: patch for gcc46+
--- exrenvmap/blurImage.cpp.orig2012-11-23 23:23:48.714449156 +0200 +++ exrenvmap/blurImage.cpp 2012-11-23 23:24:09.765447850 +0200 @@ -45,6 +45,7 @@ #include Iex.h #include iostream #include algorithm +#include cstring using namespace std; using namespace Imf; This patch is required because memcpy(3) is used in the file. -- Andriy Gapon ___ 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
graphics/ilmbase: gcc46+ patch
--- Imath/ImathMatrix.h.orig2012-11-23 23:29:16.401450990 +0200 +++ Imath/ImathMatrix.h 2012-11-23 23:29:37.622449298 +0200 @@ -51,6 +51,7 @@ #include iostream #include iomanip +#include cstring #if (defined _WIN32 || defined _WIN64) defined _MSC_VER // suppress exception specification warnings This patch is required because memset and memcpy are used in this file. -- Andriy Gapon ___ 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
