CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2019/09/24 18:33:55 Modified files: mail/claws-mail: Makefile distinfo mail/claws-mail/patches: patch-configure_ac Log message: Update to claws-mail-3.17.4 Drop maintainer. Help from sthen@, "please proceed" solene@
Re: Adding binary renaming facility to python.port.mk
> I think that ship has already sailed. 6.6-beta was tagged weeks ago and the > release is not far away. There was no "tagging". What happened was the mid-cycle switch in name from N.M-something to N.M+1-something, so that the late arrival of N.M+1 numbering doesn't cause late surprises. actual tagging happens later. But you are right, the time schedules are a little tight. It is definately to select "comfortable positions", and ship those.
Re: LAMP/LEMP equivalent bundle?
> On Sep 21, 2019, at 2:05 AM, Martijn van Duren > wrote: > > On 9/20/19 8:57 PM, Implausibility wrote: >> Hi. >> >> I'm trying to move a few system off of Linux, and onto OpenBSD... I'm >> trying to get it "right" the first time. >> > That fully depends on the application you want to run and what that > application requires. Note that there's a difference between what > an application requires and what they document on how to set things > up. > > If you are going to write it yourself just use what you're > comfortable with. Just keep sane coding practises in mind. > I'm currently running WordPress & Mediawiki... But those servers are outdated (PHP5.6.x) so I'm looking for a bundle/meta-package that has the latest versions of the stack, mostly configured to interoperate. I'm agnostic when it comes to the web server or database itself. I've been looking through OpenPorts.se, and I see there are some meta packages, but none for a web environment.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > > I'm suggesting that ignoring the technical, and focusing on the > > political, being expedient at "reduction of patches", and bending over > > backwards to please Mozilla people who don't understand unveil/pledge, > > has caused harm here. It is turning a serious attempt at security > > feature into security theater. > > Feel free to correct my mistakes there then, or find someone to do so. > I'm done working on those diffs. I attempted to correct a mistake, by explaining how the decision to store the unveil/pledge configuration in userspace was pushing jcs's strong security design into a security theater. But you said Mozilla demanded it, and said you won't act against them. So once again, I attempted to correct the mistake, as I have interpreted that Mozilla's guidance in that direction is due to YOUR misguiding Mozilla people in that direction, ignoring the technical! And your reaction to that is "I'm done"? And all through this you say you don't care about the technical? Very strange.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Tue, Sep 24, 2019 at 12:57:57PM -0600, Theo de Raadt wrote: > Landry Breuil wrote: > > > On Tue, Sep 24, 2019 at 11:13:38AM -0600, Theo de Raadt wrote: > > > Landry Breuil wrote: > > > > > > > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > > > > joshua stein wrote: > > > > > > > > > > > I don't like the pledge and unveil settings being in preferences > > > > > > for > > > > > > these and other reasons, but it's currently what Mozilla people are > > > > > > asking for in order to get reviewed/upstreamed and is how their own > > > > > > sandboxing on other platforms is controlled > > > > > > (security.sandbox.content.level can be changed on Linux for > > > > > > example). > > > > > > > > > > > > In the end, this task of upstreaming these patches may be too > > > > > > difficult or insecure and I'll go back to reading from root-owned > > > > > > files in /etc/firefox like our Chromium port does, having to carry > > > > > > our own patches for each release. I'm not sure what the plan is > > > > > > yet. > > > > > > > > > > > > > > > I'm still very surprised. Their proposed model completely lacks any > > > > > security, as it ignores obvious escalation techniques. > > > > > > > > > > The unveil/pledge/sandbox variables in question establish a > > > > > process-containment. Let's say the attacker is aware of a browser bug > > > > > which can achieve code-execution, well he will change those variables > > > > > to > > > > > request less (or no) containment, for FUTURE BROWSER RESTARTS. At > > > > > that > > > > > point he can crash the browser, which the user will restart WITHOUT > > > > > CONTAINMENT, and the browser's default will revisit the same attacker > > > > > pages permitting a continuation of the attack without sandbox > > > > > constraints. > > > > > > > > > > If a program can disable it's own security policy, well then it isn't > > > > > a > > > > > security policy. > > > > > > > > > > I suggest doing as they ask to get it integrated, and then maintain a > > > > > few lines of patch that causes root-owned-files to override the > > > > > fragile > > > > > user-selected options. > > > > > > > > All good ideas need to be discussed with upstream at > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1580271. I spent months > > > > upstreaming tons of patches, and i'm not carrying more of them.. > > > > > > Glad to se you've ignored the technical discussion and maintain the > > > opinion it must be upstream. > > > > I'm 'ignoring' the technical discussion because i dont feel qualified to > > have an opinion about it, nor do i have the time/energy to work on it. > > > > At that point, my best advice is to work with upstream because qualified > > people there might have a valuable technical opinion. Even if you doubt > > it. > > And I'm saying I don't believe it, to me it looks like the opening > comment leads the entire thread away form jcs's technically correct > solution. > > I believe those comments have led later Mozilla people who don't fully > understand pledge/unveil to echo your approach without understanding that > it totally nueters the security. Then please enlighten them. > And as you said here, you "dont feel qualified". Yet you felt qualified > enough to break jcs's diffs. > > I'm suggesting that ignoring the technical, and focusing on the > political, being expedient at "reduction of patches", and bending over > backwards to please Mozilla people who don't understand unveil/pledge, > has caused harm here. It is turning a serious attempt at security > feature into security theater. Feel free to correct my mistakes there then, or find someone to do so. I'm done working on those diffs.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > On Tue, Sep 24, 2019 at 11:13:38AM -0600, Theo de Raadt wrote: > > Landry Breuil wrote: > > > > > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > > > joshua stein wrote: > > > > > > > > > I don't like the pledge and unveil settings being in preferences for > > > > > these and other reasons, but it's currently what Mozilla people are > > > > > asking for in order to get reviewed/upstreamed and is how their own > > > > > sandboxing on other platforms is controlled > > > > > (security.sandbox.content.level can be changed on Linux for > > > > > example). > > > > > > > > > > In the end, this task of upstreaming these patches may be too > > > > > difficult or insecure and I'll go back to reading from root-owned > > > > > files in /etc/firefox like our Chromium port does, having to carry > > > > > our own patches for each release. I'm not sure what the plan is > > > > > yet. > > > > > > > > > > > > I'm still very surprised. Their proposed model completely lacks any > > > > security, as it ignores obvious escalation techniques. > > > > > > > > The unveil/pledge/sandbox variables in question establish a > > > > process-containment. Let's say the attacker is aware of a browser bug > > > > which can achieve code-execution, well he will change those variables to > > > > request less (or no) containment, for FUTURE BROWSER RESTARTS. At that > > > > point he can crash the browser, which the user will restart WITHOUT > > > > CONTAINMENT, and the browser's default will revisit the same attacker > > > > pages permitting a continuation of the attack without sandbox > > > > constraints. > > > > > > > > If a program can disable it's own security policy, well then it isn't a > > > > security policy. > > > > > > > > I suggest doing as they ask to get it integrated, and then maintain a > > > > few lines of patch that causes root-owned-files to override the fragile > > > > user-selected options. > > > > > > All good ideas need to be discussed with upstream at > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1580271. I spent months > > > upstreaming tons of patches, and i'm not carrying more of them.. > > > > Glad to se you've ignored the technical discussion and maintain the > > opinion it must be upstream. > > I'm 'ignoring' the technical discussion because i dont feel qualified to > have an opinion about it, nor do i have the time/energy to work on it. > > At that point, my best advice is to work with upstream because qualified > people there might have a valuable technical opinion. Even if you doubt > it. And I'm saying I don't believe it, to me it looks like the opening comment leads the entire thread away form jcs's technically correct solution. I believe those comments have led later Mozilla people who don't fully understand pledge/unveil to echo your approach without understanding that it totally nueters the security. And as you said here, you "dont feel qualified". Yet you felt qualified enough to break jcs's diffs. I'm suggesting that ignoring the technical, and focusing on the political, being expedient at "reduction of patches", and bending over backwards to please Mozilla people who don't understand unveil/pledge, has caused harm here. It is turning a serious attempt at security feature into security theater. > Sorry, in ports land we've always been told to work with upstream .. > https://www.openbsd.org/faq/ports/guide.html#PortsComplex as of now even > says 'Make sure the software authors are aware of your tweaks to make > it run on OpenBSD. You must endeavor to get OpenBSD patches into the > next release of the software. Otherwise, you can be prepared to rewrite > most of your patches from scratch every release.'. That page does not say "ignore the technical". Nor does it say "convince the upstream to incorporate useless diffs". It does not say "water down improvements".
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Tue, Sep 24, 2019 at 11:13:38AM -0600, Theo de Raadt wrote: > Landry Breuil wrote: > > > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > > joshua stein wrote: > > > > > > > I don't like the pledge and unveil settings being in preferences for > > > > these and other reasons, but it's currently what Mozilla people are > > > > asking for in order to get reviewed/upstreamed and is how their own > > > > sandboxing on other platforms is controlled > > > > (security.sandbox.content.level can be changed on Linux for > > > > example). > > > > > > > > In the end, this task of upstreaming these patches may be too > > > > difficult or insecure and I'll go back to reading from root-owned > > > > files in /etc/firefox like our Chromium port does, having to carry > > > > our own patches for each release. I'm not sure what the plan is > > > > yet. > > > > > > > > > I'm still very surprised. Their proposed model completely lacks any > > > security, as it ignores obvious escalation techniques. > > > > > > The unveil/pledge/sandbox variables in question establish a > > > process-containment. Let's say the attacker is aware of a browser bug > > > which can achieve code-execution, well he will change those variables to > > > request less (or no) containment, for FUTURE BROWSER RESTARTS. At that > > > point he can crash the browser, which the user will restart WITHOUT > > > CONTAINMENT, and the browser's default will revisit the same attacker > > > pages permitting a continuation of the attack without sandbox constraints. > > > > > > If a program can disable it's own security policy, well then it isn't a > > > security policy. > > > > > > I suggest doing as they ask to get it integrated, and then maintain a > > > few lines of patch that causes root-owned-files to override the fragile > > > user-selected options. > > > > All good ideas need to be discussed with upstream at > > https://bugzilla.mozilla.org/show_bug.cgi?id=1580271. I spent months > > upstreaming tons of patches, and i'm not carrying more of them.. > > Glad to se you've ignored the technical discussion and maintain the > opinion it must be upstream. I'm 'ignoring' the technical discussion because i dont feel qualified to have an opinion about it, nor do i have the time/energy to work on it. At that point, my best advice is to work with upstream because qualified people there might have a valuable technical opinion. Even if you doubt it. You're of course free to disagree with me, and find someone else to do my work if you dont like the way i do it. > My personal opinion on this. I've contributed a technical point and > look at the result, I'm told to shut up and talk to some people I don't > care to talk to. Count me out, I will not run this trash fire. Sorry, in ports land we've always been told to work with upstream .. https://www.openbsd.org/faq/ports/guide.html#PortsComplex as of now even says 'Make sure the software authors are aware of your tweaks to make it run on OpenBSD. You must endeavor to get OpenBSD patches into the next release of the software. Otherwise, you can be prepared to rewrite most of your patches from scratch every release.'. Landry
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/09/24 12:10:06 Modified files: geo/qgis : Makefile distinfo geo/qgis/patches: patch-src_core_CMakeLists_txt geo/qgis/pkg : PLIST Log message: Update to QGIS 3.8.3
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > joshua stein wrote: > > > > > I don't like the pledge and unveil settings being in preferences for > > > these and other reasons, but it's currently what Mozilla people are > > > asking for in order to get reviewed/upstreamed and is how their own > > > sandboxing on other platforms is controlled > > > (security.sandbox.content.level can be changed on Linux for > > > example). > > > > > > In the end, this task of upstreaming these patches may be too > > > difficult or insecure and I'll go back to reading from root-owned > > > files in /etc/firefox like our Chromium port does, having to carry > > > our own patches for each release. I'm not sure what the plan is > > > yet. > > > > > > I'm still very surprised. Their proposed model completely lacks any > > security, as it ignores obvious escalation techniques. > > > > The unveil/pledge/sandbox variables in question establish a > > process-containment. Let's say the attacker is aware of a browser bug > > which can achieve code-execution, well he will change those variables to > > request less (or no) containment, for FUTURE BROWSER RESTARTS. At that > > point he can crash the browser, which the user will restart WITHOUT > > CONTAINMENT, and the browser's default will revisit the same attacker > > pages permitting a continuation of the attack without sandbox constraints. > > > > If a program can disable it's own security policy, well then it isn't a > > security policy. > > > > I suggest doing as they ask to get it integrated, and then maintain a > > few lines of patch that causes root-owned-files to override the fragile > > user-selected options. > > All good ideas need to be discussed with upstream at > https://bugzilla.mozilla.org/show_bug.cgi?id=1580271. I spent months > upstreaming tons of patches, and i'm not carrying more of them.. I've just explained how all this unveil/pledge effort is complete and utter security theater because the browser can undo the security, and you tell me to shut up and go to a bugzilla?
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > joshua stein wrote: > > > > > I don't like the pledge and unveil settings being in preferences for > > > these and other reasons, but it's currently what Mozilla people are > > > asking for in order to get reviewed/upstreamed and is how their own > > > sandboxing on other platforms is controlled > > > (security.sandbox.content.level can be changed on Linux for > > > example). > > > > > > In the end, this task of upstreaming these patches may be too > > > difficult or insecure and I'll go back to reading from root-owned > > > files in /etc/firefox like our Chromium port does, having to carry > > > our own patches for each release. I'm not sure what the plan is > > > yet. > > > > > > I'm still very surprised. Their proposed model completely lacks any > > security, as it ignores obvious escalation techniques. > > > > The unveil/pledge/sandbox variables in question establish a > > process-containment. Let's say the attacker is aware of a browser bug > > which can achieve code-execution, well he will change those variables to > > request less (or no) containment, for FUTURE BROWSER RESTARTS. At that > > point he can crash the browser, which the user will restart WITHOUT > > CONTAINMENT, and the browser's default will revisit the same attacker > > pages permitting a continuation of the attack without sandbox constraints. > > > > If a program can disable it's own security policy, well then it isn't a > > security policy. > > > > I suggest doing as they ask to get it integrated, and then maintain a > > few lines of patch that causes root-owned-files to override the fragile > > user-selected options. > > All good ideas need to be discussed with upstream at > https://bugzilla.mozilla.org/show_bug.cgi?id=1580271. I spent months > upstreaming tons of patches, and i'm not carrying more of them.. >From what ticket, it looks like the idea of not making the options root-only comes from YOU in the introduction of the ticket chain: "I doubt hardcoding /etc/firefox/unveil.main in the source code will be accepted as is, since etc/firefox doesnt exist. That directory was a jcs proposal, but there is nothing which said it had to be that specific directory, and your entire approach leads away from root-owned placement: :gcp, what would be the preferred way to add a (potentially user-customizable) config file listing paths and corresponding perms ? Right now, filesystem isolation is configured this way in our chromium port but i'm not comfortable with adding /etc/firefox. A default file under browser/defaults/preferences/, overridable by the user ? for pledge we use about:config strings for that wont work for unveil paths lists." >From my quick read, it seems you are the one who led the firefox team to requiring unveil/pledge choices be inside the program rather than in root-only files. then you mention that Linux and MacOS do it hardcoded and safe way, but: "I know for linux & macos iirc the list is hardcoded in the source code but that doesnt leave a way for the user to add paths." And again, you are the one who leads the development towards the exactly the insecurity mentioned in my post. Because only YOU suggested that users must have a way to "add paths". In the chrome paths, users cannot add paths, BECAUSE THAT WOULD BE INSECURE. >From my read, Mozilla didn't say this had to be user configurable on their own. You did. And in chrome, robert didn't. The root-owned files were added in Slovenia years ago simply for fast-prototyping method so that chrome didn't need to be recompiled to adjust the modes, they are effectively hardcoded and once in a while I prod Robert asking if it is time to remove those files and hardcode the pledges in the binary. I'll say it again: I think this security problem I described comes from you.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > joshua stein wrote: > > > > > I don't like the pledge and unveil settings being in preferences for > > > these and other reasons, but it's currently what Mozilla people are > > > asking for in order to get reviewed/upstreamed and is how their own > > > sandboxing on other platforms is controlled > > > (security.sandbox.content.level can be changed on Linux for > > > example). > > > > > > In the end, this task of upstreaming these patches may be too > > > difficult or insecure and I'll go back to reading from root-owned > > > files in /etc/firefox like our Chromium port does, having to carry > > > our own patches for each release. I'm not sure what the plan is > > > yet. > > > > > > I'm still very surprised. Their proposed model completely lacks any > > security, as it ignores obvious escalation techniques. > > > > The unveil/pledge/sandbox variables in question establish a > > process-containment. Let's say the attacker is aware of a browser bug > > which can achieve code-execution, well he will change those variables to > > request less (or no) containment, for FUTURE BROWSER RESTARTS. At that > > point he can crash the browser, which the user will restart WITHOUT > > CONTAINMENT, and the browser's default will revisit the same attacker > > pages permitting a continuation of the attack without sandbox constraints. > > > > If a program can disable it's own security policy, well then it isn't a > > security policy. > > > > I suggest doing as they ask to get it integrated, and then maintain a > > few lines of patch that causes root-owned-files to override the fragile > > user-selected options. > > All good ideas need to be discussed with upstream at > https://bugzilla.mozilla.org/show_bug.cgi?id=1580271. I spent months > upstreaming tons of patches, and i'm not carrying more of them.. Glad to se you've ignored the technical discussion and maintain the opinion it must be upstream. My personal opinion on this. I've contributed a technical point and look at the result, I'm told to shut up and talk to some people I don't care to talk to. Count me out, I will not run this trash fire.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > joshua stein wrote: > > > I don't like the pledge and unveil settings being in preferences for > > these and other reasons, but it's currently what Mozilla people are > > asking for in order to get reviewed/upstreamed and is how their own > > sandboxing on other platforms is controlled > > (security.sandbox.content.level can be changed on Linux for > > example). > > > > In the end, this task of upstreaming these patches may be too > > difficult or insecure and I'll go back to reading from root-owned > > files in /etc/firefox like our Chromium port does, having to carry > > our own patches for each release. I'm not sure what the plan is > > yet. > > > I'm still very surprised. Their proposed model completely lacks any > security, as it ignores obvious escalation techniques. > > The unveil/pledge/sandbox variables in question establish a > process-containment. Let's say the attacker is aware of a browser bug > which can achieve code-execution, well he will change those variables to > request less (or no) containment, for FUTURE BROWSER RESTARTS. At that > point he can crash the browser, which the user will restart WITHOUT > CONTAINMENT, and the browser's default will revisit the same attacker > pages permitting a continuation of the attack without sandbox constraints. > > If a program can disable it's own security policy, well then it isn't a > security policy. > > I suggest doing as they ask to get it integrated, and then maintain a > few lines of patch that causes root-owned-files to override the fragile > user-selected options. All good ideas need to be discussed with upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=1580271. I spent months upstreaming tons of patches, and i'm not carrying more of them..
Re: New devel/py-base58
On Mon, Sep 23, 2019 at 11:06:39PM +0100, Stuart Henderson wrote: > The script conflicts between py- and py3-. Hi Stuart, Sorry, could you please give me some more details, I am not sure to understand this properly. I've re-done everything [1] for both FLAVORS, all distinctions in between py* and py3* naming were correct on my system using the version attached. Including the associated dependencies (py-hamcrest, py-test, py-setuptools). So I am not sure to understand what you meant by "script conflicts". [1] fetch, checksum, extract, patch, configure, build, test, fake, port-lib-depends-check, package, install, deinstall Cheers, -- clematis (0x7e96fd2400fe7b59) converters_py-base58.tar.gz Description: application/tar-gz
Re: Default PHP version for the next OpenBSD release
I know that nextcloud and nfsen work fine on 7.3.
On Tue, Sep 24, 2019 at 04:29:32PM +0100, Stuart Henderson wrote:
> https://www.php.net/supported-versions.php
>
> PHP 7.1 will soon be end of life (no more security updates) so we need
> to move the ports default version (i.e. the version used as a dependency for
> most other PHP ports) to either 7.2 or 7.3.
>
> 7.2 is soon going to "security fixes only" mode with EoL due Nov 2020.
>
> 7.3 is still in "active support" mode but it's a bigger change.
>
> I'm pretty sure that some ports using PHP won't like 7.3 (and it's
> not really possibly to identify these in advance) and will need to
> be restricted to 7.2 but I think it would be better to do this on a
> case-by-case basis and have the default set to the newer version.
>
> Any major opposition to this?
>
> Does anyone know of particular PHP ports in the tree that are already
> known to fail with 7.3?
>
> Unfortunately we can't set ports to depend on "either 7.2 or 7.3".
> ports/pkg_add allow "A or B" type choice, but don't allow "A+A1 or
> B+B1 but not A+B1@ type choices which would be needed for correct
> dependencies with this, and there's a further problem as the path
> to the PHP interpreter (MODPHP_BIN) needs to point at a particular
> version. So I think we're stuck with making a specific decision
> for each port ("force X version or use the default").
--
Tracey Emery
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/09/24 09:37:34 Modified files: sysutils/ncdu : Makefile distinfo Log message: Update ncdu to 1.14.1. OK solene@, bket@
Default PHP version for the next OpenBSD release
https://www.php.net/supported-versions.php
PHP 7.1 will soon be end of life (no more security updates) so we need
to move the ports default version (i.e. the version used as a dependency for
most other PHP ports) to either 7.2 or 7.3.
7.2 is soon going to "security fixes only" mode with EoL due Nov 2020.
7.3 is still in "active support" mode but it's a bigger change.
I'm pretty sure that some ports using PHP won't like 7.3 (and it's
not really possibly to identify these in advance) and will need to
be restricted to 7.2 but I think it would be better to do this on a
case-by-case basis and have the default set to the newer version.
Any major opposition to this?
Does anyone know of particular PHP ports in the tree that are already
known to fail with 7.3?
Unfortunately we can't set ports to depend on "either 7.2 or 7.3".
ports/pkg_add allow "A or B" type choice, but don't allow "A+A1 or
B+B1 but not A+B1@ type choices which would be needed for correct
dependencies with this, and there's a further problem as the path
to the PHP interpreter (MODPHP_BIN) needs to point at a particular
version. So I think we're stuck with making a specific decision
for each port ("force X version or use the default").
UPDATE devel/git-cola 3.5
Enclosed diff brings git-cola to 3.5, which is a bugfix release. Release
notes can be found at
https://github.com/git-cola/git-cola/blob/v3.5/share/doc/git-cola/relnotes.rst
'make test' fails one test (IconTestCase.test_from_filename_unicode).
I'm not sure, but it look to me that the test itself is at fault. I have
opened an issue upstream.
Run tested OK on amd64.
Comments/OK?
Index: Makefile
===
RCS file: /cvs/ports/devel/git-cola/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- Makefile12 Jul 2019 20:44:09 - 1.30
+++ Makefile24 Sep 2019 14:37:04 -
@@ -2,7 +2,7 @@
COMMENT = python powered git gui
-MODPY_EGG_VERSION= 3.4
+MODPY_EGG_VERSION= 3.5
DISTNAME = ${GH_PROJECT}-${MODPY_EGG_VERSION}
GH_ACCOUNT = git-cola
Index: distinfo
===
RCS file: /cvs/ports/devel/git-cola/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo18 Jun 2019 04:13:54 - 1.12
+++ distinfo24 Sep 2019 14:37:04 -
@@ -1,2 +1,2 @@
-SHA256 (git-cola-3.4.tar.gz) = dj44LYsyQnU5WF0X7G/pICbAc/bTGoZKWBbr4izyRbw=
-SIZE (git-cola-3.4.tar.gz) = 963393
+SHA256 (git-cola-3.5.tar.gz) = f9z8QyazXjhLl71LshibTLXPJYlINSdZwwLmMrQbsuI=
+SIZE (git-cola-3.5.tar.gz) = 970155
Re: [UPDATE] sysutils/ncdu to 1.14.1
On Tue 24/09/2019 15:02, Frederic Cambus wrote: > On Tue, Sep 17, 2019 at 09:54:56AM +0200, Frederic Cambus wrote: > > > Here is a diff to update ncdu to 1.14.1. > > > > Comments? OK? > > Ping. Anyone willing to OK this? Works for me. OK bket@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2019/09/24 08:11:07 Modified files: www/chromium/patches: patch-build_gn_run_binary_py patch-tools_protoc_wrapper_protoc_wrapper_py patch-v8_tools_run_py Log message: fixup patches where WRKSRC was substituted
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/09/24 07:15:19 Modified files: graphics/openbsd-backgrounds: Makefile distinfo graphics/openbsd-backgrounds/pkg: PLIST Log message: a few more pics, mostly from norway
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/09/24 07:05:22 Modified files: lang/clojure : Makefile Added files: lang/clojure/patches: patch-clojure Log message: Add back javaPathHelper support for running clojure. okay jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/09/24 07:03:41 ports/lang/clojure/patches Update of /cvs/ports/lang/clojure/patches In directory cvs.openbsd.org:/tmp/cvs-serv37428/patches Log Message: Directory /cvs/ports/lang/clojure/patches added to the repository
Re: [UPDATE] sysutils/ncdu to 1.14.1
On Tue, Sep 17, 2019 at 09:54:56AM +0200, Frederic Cambus wrote: > Here is a diff to update ncdu to 1.14.1. > > Comments? OK? Ping. Anyone willing to OK this?
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
joshua stein wrote: > I don't like the pledge and unveil settings being in preferences for > these and other reasons, but it's currently what Mozilla people are > asking for in order to get reviewed/upstreamed and is how their own > sandboxing on other platforms is controlled > (security.sandbox.content.level can be changed on Linux for > example). > > In the end, this task of upstreaming these patches may be too > difficult or insecure and I'll go back to reading from root-owned > files in /etc/firefox like our Chromium port does, having to carry > our own patches for each release. I'm not sure what the plan is > yet. I'm still very surprised. Their proposed model completely lacks any security, as it ignores obvious escalation techniques. The unveil/pledge/sandbox variables in question establish a process-containment. Let's say the attacker is aware of a browser bug which can achieve code-execution, well he will change those variables to request less (or no) containment, for FUTURE BROWSER RESTARTS. At that point he can crash the browser, which the user will restart WITHOUT CONTAINMENT, and the browser's default will revisit the same attacker pages permitting a continuation of the attack without sandbox constraints. If a program can disable it's own security policy, well then it isn't a security policy. I suggest doing as they ask to get it integrated, and then maintain a few lines of patch that causes root-owned-files to override the fragile user-selected options.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/09/24 06:23:57 Modified files: fonts/spleen : Makefile distinfo Log message: Update spleen to 1.4.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/09/24 05:47:54 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: register java-tanukiwrapper removal
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/09/24 05:47:41 Modified files: java : Makefile Removed files: java/tanukiwrapper: Makefile distinfo java/tanukiwrapper/files: Makefile-openbsd-x86-32.gmake Makefile-openbsd-x86-64.gmake java/tanukiwrapper/patches: patch-build-tests_xml patch-build_xml patch-src_c_logger_c patch-src_c_property_c patch-src_c_wrapper_c patch-src_c_wrapper_h patch-src_c_wrapper_unix_c java/tanukiwrapper/pkg: DESCR PLIST Log message: remove java-tanukiwrapper, it was never used and the original software that required it never made it into the tree. ok kurt@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/09/24 05:20:21 Modified files: www/webkitgtk4 : Makefile distinfo Log message: Update to webkitgtk4-2.26.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/09/24 05:19:59 Modified files: devel/glib2mm : Makefile distinfo Log message: Update to glib2mm-2.60.1.
Re: ghc 8.6.4 upgrade Sep 15
On Mon, Sep 23, 2019 at 11:39:51PM +0200, Matthias Kilian wrote:
> Still to clarify / fix:
>
> - architecture-dependent directories in hs-ports.
Which can be "fixed" by this one (a better fix would be to patch ghc-pkg
and/or cabal to use libdir/libsubdir for shared libraries the same way
as for static libraries and to drop the $arch-$os-$compiler patterns):
Index: ghc.port.mk
===
RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.43
diff -u -p -r1.43 ghc.port.mk
--- ghc.port.mk 10 Sep 2019 13:51:21 - 1.43
+++ ghc.port.mk 24 Sep 2019 09:34:24 -
@@ -64,13 +64,15 @@ MODGHC_SETUP_CONF_ENV ?=
MODGHC_SETUP_CONF_ARGS += --datasubdir=hs-\$$pkgid
MODGHC_SETUP_CONF_ARGS += --docdir=\$$datadir/doc/hs-\$$pkgid
MODGHC_SETUP_CONF_ARGS += --libsubdir=ghc/\$$pkgid
+MODGHC_SETUP_CONF_ARGS += --dynlibdir=${PREFIX}/lib/ghc/\$$pkgid
MODGHC_SETUP_CONF_ARGS += --enable-library-profiling
. else
# Override Cabal defaults, which are $arch-$os-$compiler/$pkgid for
-# datasubdir and libsubdir and $datadir/doc/$arch-$os-$compiler/$pkgid
-# for docdir.
+# datasubdir and libsubdir, $datadir/doc/$arch-$os-$compiler/$pkgid
+# for docdir and ${PREFIX}/lib/$arch-$os-$compiler/$pkgid for dynlibdir.
MODGHC_SETUP_CONF_ARGS += --datasubdir=\$$pkgid
MODGHC_SETUP_CONF_ARGS += --libsubdir=\$$pkgid
+MODGHC_SETUP_CONF_ARGS += --dynlibdir=${PREFIX}/lib/ghc/\$$pkgid
MODGHC_SETUP_CONF_ARGS += --docdir=\$$datadir/doc/\$$pkgid
. endif
> - the libffi shared library built from the bundled ffi; not sure wether
> this is a problem or not, but it looks a little bit scary.
And indeed. After a few iterations of fixing plists of hs-ports (after
the dynlibdir patch above), with pkg_delete -a in between, I ran into
build errors like this one:
===> Configuring for hs-vector-0.12.0.3
ld.so: ghc: can't load library 'libffi.so.1.2'
Killed
The ghc binary was linked against our system libffi (from devel/libffi),
and after the pkg_delete -a and a restart of dpb, this was missing. So
I'll now try to build ghc using our libffi instead of the bundled one.
Ciao,
Kili
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2019/09/24 03:17:09 Modified files: www/webkitgtk4/patches: patch-Source_cmake_OptionsCommon_cmake Log message: make sure that the internal library path is first in the list so that linking does not fail when there is a webkitgtk4 package installed already ok aja@
Re: New security/py-pysha3
> On Mon, Sep 23, 2019 at 11:05:09PM +0100, Stuart Henderson wrote:
> > On 2019/09/23 16:17, Kurt Mosiejczuk wrote:
> > > Did we really want to name it py-pysha3? I figure py-sha3 is what we would
> > > usually do in that case. (See pytest -> py-test, pydot -> py-dot, others)
>
> > We have it both ways, personally I prefer it this way (portgen does
> > this also) but I don't mind much either way.
I did notice we weren't necessarily always consistent with the naming.
I chose this way for a couple of reasons. (I am not saying this is the
right way).
1/ Be consistent with other platform and faciliate the search. The
module name is 'pydot'. People wondering if it's available in ports
will search for 'pydot'.
You will not find it, not with pkg_info -Q, not with make search
key=pydot, not on openports.se (Package Name). (But you will find
'pygal' for example). Potentially you would have noticed some py-* so
will search for py-pydot, or py-pygal. But will again find only the second
one.
2/ Prevent collision. To come back to this pysha3 ports, a 'sha3' [1]
module does exist. What would be his package name? py-sha3.
Would be a problem if we name 'pysha3' this way.
I understand this could feel awkward for the modules py-py*
But long story short, PKGNAME = py-${DISTNAME} makes more sense to me than
PKGNAME= ${DISTNAME:S/py/py-/}.
But this is just my opinion. If there's another approach I would be
happy to stick with it in the future and stay consistent.
[1] https://pypi.org/project/sha3/
--
clematis (0x7e96fd2400fe7b59)
[Update] graphics/p5-Imager : Update to 1.011
Hi, ports@: Here is a simple patch for graphics/p5-Imager to update to 1.011. It build well and passed all tests on amd64-head system. Two ports depends on it: www/p5-Mojolicious-Plugin-Thumbnail graphics/p5-Imager-QRCode Both build well and passed all tests with this patch on amd64-head system. Comments? OK? wen Index: Makefile === RCS file: /cvs/ports/graphics/p5-Imager/Makefile,v retrieving revision 1.44 diff -u -p -r1.44 Makefile --- Makefile12 Jul 2019 20:47:07 - 1.44 +++ Makefile24 Sep 2019 08:04:41 - @@ -2,10 +2,9 @@ COMMENT= generate and manipulate images -DISTNAME = Imager-1.009 +DISTNAME = Imager-1.011 CATEGORIES=graphics MODULES= cpan -REVISION = 1 # Perl PERMIT_PACKAGE=Yes Index: distinfo === RCS file: /cvs/ports/graphics/p5-Imager/distinfo,v retrieving revision 1.10 diff -u -p -r1.10 distinfo --- distinfo25 Jan 2019 13:18:50 - 1.10 +++ distinfo24 Sep 2019 08:04:41 - @@ -1,2 +1,2 @@ -SHA256 (Imager-1.009.tar.gz) = F3BAOYDEVK3+m7pOWLLHraIRhiOGhtk7V0sQUXUcuIU= -SIZE (Imager-1.009.tar.gz) = 1236563 +SHA256 (Imager-1.011.tar.gz) = o66i8MFywsCUuuztSjvaqfVOPoXJfuouX4+ZS6K+7fw= +SIZE (Imager-1.011.tar.gz) = 1239305
[Update] devel/liblouis : Update to 3.11.0
Hi, ports@:
Here is a patch for devel/liblouis:
i) Update to 3.11.0
ii) Remove patches/patch-liblouis_compileTranslationTable_c, which
had been included into upstream.
It build well and passed all tests on amd64-head system.
One port(x11/gnome/orca) depends on it, it build well with this patch too.
Comments? OK?
wen
Index: Makefile
===
RCS file: /cvs/ports/devel/liblouis/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile12 Jul 2019 20:44:39 - 1.29
+++ Makefile24 Sep 2019 07:27:45 -
@@ -2,10 +2,10 @@
COMMENT= braille translator, back-translator and formatter
-V= 3.9.0
+V= 3.11.0
DISTNAME= liblouis-${V}
-SHARED_LIBS += louis8.0 # 17.1
+SHARED_LIBS += louis8.0 # 19.0
CATEGORIES=devel
Index: distinfo
===
RCS file: /cvs/ports/devel/liblouis/distinfo,v
retrieving revision 1.14
diff -u -p -r1.14 distinfo
--- distinfo13 May 2019 22:14:01 - 1.14
+++ distinfo24 Sep 2019 07:27:45 -
@@ -1,2 +1,2 @@
-SHA256 (liblouis-3.9.0.tar.gz) = 5K4jNzdRADxuRLzaZTzzs94e/wuFD5NJCRrqfkoMuHg=
-SIZE (liblouis-3.9.0.tar.gz) = 13923857
+SHA256 (liblouis-3.11.0.tar.gz) = uAKroL/0ljaQfKdIIl4hxW7PPz68FD1YJDADbU2fYlk=
+SIZE (liblouis-3.11.0.tar.gz) = 14105376
Index: patches/patch-liblouis_compileTranslationTable_c
===
RCS file: patches/patch-liblouis_compileTranslationTable_c
diff -N patches/patch-liblouis_compileTranslationTable_c
--- patches/patch-liblouis_compileTranslationTable_c19 Aug 2018 07:54:04
- 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,23 +0,0 @@
-$OpenBSD: patch-liblouis_compileTranslationTable_c,v 1.1 2018/08/19 07:54:04
ajacoutot Exp $
-
-From dbfa58bb128cae86729578ac596056b3385817ef Mon Sep 17 00:00:00 2001
-From: Christian Egli
-Date: Wed, 6 Jun 2018 16:41:53 +0200
-Subject: [PATCH] Check index before writing to result->chars
-
-Index: liblouis/compileTranslationTable.c
liblouis/compileTranslationTable.c.orig
-+++ liblouis/compileTranslationTable.c
-@@ -1127,11 +1127,11 @@ parseChars(FileInfo *nested, CharsString *result, Char
- }
- in++;
- }
-- result->chars[out++] = (widechar)ch;
- if (out >= MAXSTRING) {
- result->length = out;
- return 1;
- }
-+ result->chars[out++] = (widechar)ch;
- continue;
- }
- lastOutSize = out;
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/liblouis/pkg/PLIST,v
retrieving revision 1.15
diff -u -p -r1.15 PLIST
--- pkg/PLIST 13 May 2019 22:14:01 - 1.15
+++ pkg/PLIST 24 Sep 2019 07:27:45 -
@@ -21,7 +21,6 @@ bin/lou_maketable.d/wrap_patgen.sh
@bin bin/lou_trace
@bin bin/lou_translate
include/liblouis/
-include/liblouis/internal.h
include/liblouis/liblouis.h
lib/liblouis.a
lib/liblouis.la
@@ -29,7 +28,7 @@ lib/liblouis.la
lib/pkgconfig/liblouis.pc
lib/python${MODPY_VERSION}/site-packages/louis/
lib/python${MODPY_VERSION}/site-packages/louis/__init__.py
-lib/python${MODPY_VERSION}/site-packages/louis/${MODPY_PYCACHE}/
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/louis/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/louis/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
@man man/man1/lou_allround.1
@man man/man1/lou_checkhyphens.1
@@ -48,6 +47,7 @@ share/liblouis/tables/Lv-Lv-g1.utb
share/liblouis/tables/Pl-Pl-g1.utb
share/liblouis/tables/Se-Se-g1.utb
share/liblouis/tables/afr-za-g1.ctb
+share/liblouis/tables/afr-za-g2.ctb
share/liblouis/tables/ar-ar-comp8.utb
share/liblouis/tables/ar-ar-g1.utb
share/liblouis/tables/ar-ar-g2.ctb
@@ -72,7 +72,6 @@ share/liblouis/tables/braille-patterns.c
share/liblouis/tables/ca-chardefs.cti
share/liblouis/tables/ca-g1.ctb
share/liblouis/tables/ca.tbl
-share/liblouis/tables/chardefs.cti
share/liblouis/tables/chr-us-g1.ctb
share/liblouis/tables/ckb-chardefs.cti
share/liblouis/tables/ckb-g1.ctb
@@ -129,12 +128,13 @@ share/liblouis/tables/digits8Dots.uti
share/liblouis/tables/dra.ctb
share/liblouis/tables/dra.tbl
share/liblouis/tables/el.ctb
-share/liblouis/tables/el.tbl
share/liblouis/tables/en-GB-g2.ctb
+share/liblouis/tables/en-chardefs.cti
share/liblouis/tables/en-chess.ctb
share/liblouis/tables/en-gb-comp8.ctb
share/liblouis/tables/en-gb-g1.utb
share/liblouis/tables/en-in-g1.ctb
+share/liblouis/tables/en-nabcc.utb
share/liblouis/tables/en-ueb-chardefs.uti
share/liblouis/tables/en-ueb-g1.ctb
share/liblouis/tables/en-ueb-g2.ctb
@@ -143,7 +143,7 @@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/09/24 00:56:44 Modified files: www/webkitgtk4 : Makefile distinfo www/webkitgtk4/patches: patch-CMakeLists_txt patch-Source_JavaScriptCore_assembler_ARM64Assembler_h patch-Source_JavaScriptCore_assembler_ARMv7Assembler_h patch-Source_JavaScriptCore_jit_ExecutableAllocator_cpp patch-Source_JavaScriptCore_offlineasm_arm64_rb patch-Source_WTF_wtf_PlatformRegisters_h patch-Source_WTF_wtf_Platform_h patch-Source_WebKit_Shared_Plugins_unix_PluginSearchPath_cpp patch-Source_cmake_OptionsCommon_cmake patch-Source_cmake_WebKitCompilerFlags_cmake patch-Source_cmake_WebKitFeatures_cmake www/webkitgtk4/pkg: PLIST Removed files: www/webkitgtk4/patches: patch-Source_WebCore_Modules_indexeddb_server_SQLiteIDBBackingStore_cpp patch-Source_WebCore_contentextensions_DFACombiner_cpp patch-Source_WebCore_contentextensions_NFAToDFA_cpp Log message: Update to webkitgtk4-2.26.0.
