597 undo_size = gimp_get_physical_memory_size ();
Any software which does this is written by stupid people.
I have tried to push back against this, but it keeps happening.
The only way the ports community will ever fix this general problem
which keeps being repeated, is by finding a way to be
Stuart Henderson wrote:
> On 2022/09/20 14:07, Marc Espie wrote:
> > Note that gimp itself has some control over memory used
> > under various circumstances in its Preferences.
> >
> > I haven't seen any indication that authors in this thread
> > are even aware those parameters exist.
>
> Proba
Yifei Zhan wrote:
> > WASM is not required on the open internet. Not required Today. Hopefully
> > never.
>
> I think we unfortunately now already live in such a world, both
> BigBlueButton and jitsi make use of WASM, and BigBlueButton won't let
> me join a meeting without having WASM enabl
My take on this is that WASM is quite simply just new attack surface.
Hear me out.
Imagine tomorrow someone invents WebX86. One website uses it. Support
arrives for browsers, now 10 websites use it. So it gets added.
And next year, someone inventest webARM64thingy. One website uses it. Supp
> You mean to tell us that nmap is currently segfaulting for an industry
No, it is not segfaulting, and it is not exploitable.
Our libc contains a feature to detect backwards memcpy, in that case
it logs and KILLS THE PROCESS dead. There is no way to consider this
a risk.
The problem here is th
Stuart Henderson wrote:
> On 2022/05/22 08:58, Theo de Raadt wrote:
> > The existing code uses mlock. It appears to be using mlock for a
> > privacy reason. But mlock has no privacy reason.
> > The mlock page does not make any privacy or security promises at all.
>
&
Stuart Henderson wrote:
> On 2022/05/22 13:49, Caspar Schutijser wrote:
> > I haven't tested this but shouldn't this be HAVE_CALLOC_CONCEAL?
I really don't understand the approach being taken here.
The existing code uses mlock. It appears to be using mlock for a
privacy reason. But mlock has
Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2022/05/19 08:54, Theo de Raadt wrote:
> > > I have argued in the past that mlock() in our kernel should probably be
> > > a NOOP, return success all the time, and doing nothing.
> >
> > Woul
Stuart Henderson wrote:
> On 2022/05/19 08:54, Theo de Raadt wrote:
> > I have argued in the past that mlock() in our kernel should probably be
> > a NOOP, return success all the time, and doing nothing.
>
> Would it make any sense to do that rather than abort if pledg
Klemens Nanni wrote:
> Otherwise it gets killed due to mlock(2) whenever I click on the login
> button that causes the PIN prompt to appear:
>
> firefox[71624]: pledge "", syscall 203
>
>
> mlock(2) is not covered in any pledge(2) promise.
>
> Does such use case fall under "just disable
> Should we continue to distribute that file is it's broken due to tar
> limitations?
Yes, we should. People can extract the tar, then update on top of it, and
at minimum this is much faster. At maximum, the small amounts of damage
people find in the tar file are not going to hurt the majority.
> - create a "gnome" login class and add users to it (recommended, see below)
I think this a really sad approach.
Suddenly a user who is in that group, has all the ridiculous limits for all
their processes.
Daniel Jakots wrote:
> On Sat, 16 Apr 2022 20:59:08 -0400, Kurt Mosiejczuk
> wrote:
>
> > I'd like to lose that whole section since most of it is many many
> > years old and seems more of historical interest rather than practical
> > advice at this point.
> >
> > ok?
>
> ok danj@
I don't wor
> It would be good to have Go 1.18 make release - if we're not able
> to do that, then we should update to 1.17.8.
Be very careful, the user testing time for such large software is becoming
exceedingly short, and quickly.
Christian Weisgerber wrote:
> Mark Kettenis:
>
> > There is a scenario where this goes wrong. If a shared library lacks
> > a DT_SONAME entry, the library filename is used to generate the
> > DT_NEEDED entries. But I would consider such a shared library broken
> > and we fixed base a lng t
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Mon, 14 Feb 2022 00:34:53 -0700
> >
> > > The solution would be to add symlinks like all the other OSes do. But
> > > Theo doesn't like that.
> >
> > No, the problem is you
Mark Kettenis wrote:
> > From: Philip Guenther
> > Date: Sun, 13 Feb 2022 23:29:06 -0800
> >
> > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis
> > wrote:
> >
> > > From: Greg Steuck
> > > Date: Sun, 13 Feb 2022 22:37:13 -0800
> > >
> > > To give a sense of the kind of change required t
Philip Guenther wrote:
> On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis
> wrote:
>
> > > From: Greg Steuck
> > > Date: Sun, 13 Feb 2022 22:37:13 -0800
> > >
> > > To give a sense of the kind of change required to get the feature I
> > > want, see the patch at the end. The change in DriverUtils
Philip Guenther wrote:
> Those of long memory will recall a hackathon where dependencies on libc
> were put in place, the libm vs libc deps were changed as functions were
> moved from libm to libc, and base builds completely broke. My recall is
> that the diffs had to basically be unrolled to re
> The solution would be to add symlinks like all the other OSes do. But
> Theo doesn't like that.
No, the problem is you add symbolic links, how long before software
ecosystems in ports choose the short names in linkage -- "because it
also works"? If they do so, all the transition benefits we ha
Alexander Bluhm wrote:
> > and those experts can stop running fw_update and do it by hand.
>
> I was testing new firmware package that is not released yet. That's
> an expert job. Now I know what to do.
The ability to go back-and-forth was part of pkg_add
We can't do that with the new firmw
Andrew Hewus Fresh wrote:
> On Thu, Feb 10, 2022 at 12:40:43PM +0100, Alexander Bluhm wrote:
> > Does the new fw_update not check the version number of the file? Does
> > it always overwrite with the tgz from firmware.openbsd.org?
>
> It only checks whether the versions match, one of the caveat
Stuart Henderson wrote:
> On 2022/01/24 22:17, Jonathan Matthew wrote:
> > The proposed update to lang/node makes this irrelevant, but I thought I'd
> > send
> > it anyway since it may come up elsewhere too.
> >
> > I noticed that on one system, 'npm install less' would abort, logging
> > 'node
Stefan Hagen wrote:
> Crystal Kolipe wrote:
> > On Sat, Jan 08, 2022 at 08:15:43PM +0100, Stefan Hagen wrote:
> > > Start X via xenodm and not via startx. Then it runs through
> > > /etc/X11/xenodm/GiveConsole, which contains:
> > >
> > > if [ -c /dev/dri/card0 ]; then
> > > chown $USER /de
Chris Bennett wrote:
> Except that others are requesting this be ported into OpenBSD for years.
> This is accounting software. It needs to be thoroughly tested or
> companies may fail. SMB stands for small to medium sized businesses.
The "No warranty" clauses on so much open source software isn'
Jeremie Courreges-Anglas wrote:
> cc'ing maintainer,
>
> On Tue, Dec 07 2021, Timo Myyrä wrote:
> > Hi,
> >
> > The upcoming emacs 28 has native compilation feature which allows it to
> > use gcc to compile emacs lisp files to loadable libraries by using the
> > libgccjit library. This library
- long width;
+ int width;
and then:
- width = strtol(argv[pos++], NULL, 10);
+ width = (int)strtol(argv[pos++], NULL, 10);
This is not right.
You need to leave the type as long, and then range check it. I understand
you are uncomfortable
Wind R wrote:
> 1. OpenBSD doesn't have a syscall that returns the current path to the
> executable file of the process, which adb and fastboot both use.
This system call is impossible. It is not possible to convert an inode
to a path cheaply. A variety of systems have this, and it either (ve
Stuart Henderson wrote:
> On 2021/09/20 13:09, Renaud Allard wrote:
> >
> >
> > On 9/20/21 11:32 AM, Stuart Henderson wrote:
> > > On 2021/09/20 10:29, Stuart Henderson wrote:
> > > > Some of these are pretty hairy and it's a moving codebase. Since they
> > > > are applying compiler "printf-lik
Joerg Jung wrote:
> > On 20. Sep 2021, at 01:42, Theo de Raadt wrote:
> > Christian Weisgerber wrote:
> >
> >> This includes the list of remaining ports with %n warnings:
> >>
> >> editors/cooledit
> >> mail/exim
> >> misc/br
Stuart Henderson wrote:
> On 2021/09/20 13:09, Renaud Allard wrote:
> >
> >
> > On 9/20/21 11:32 AM, Stuart Henderson wrote:
> > > On 2021/09/20 10:29, Stuart Henderson wrote:
> > > > Some of these are pretty hairy and it's a moving codebase. Since they
> > > > are applying compiler "printf-lik
Christian Weisgerber wrote:
> This includes the list of remaining ports with %n warnings:
>
> editors/cooledit
> mail/exim
> misc/brltty
> net/climm
climm s_sprintf() is a work of art, like an ochre cave painting of a stick
animal with a stick poking through it.
probably predates the better as
Christian Weisgerber wrote:
> This includes the list of remaining ports with %n warnings:
>
> mail/exim
> net/climm
two left.
here is my brutish attempt to deal with exim, which has a set of
*printf-like functions which return pointer, and but discard the
length
in a few cases, %n is at the e
> Note that the port is very low quality in general.
This is the ports tree: you sound like a broken record.
Christian Weisgerber wrote:
> This includes the list of remaining ports with %n warnings:
>
> editors/cooledit
> mail/exim
> misc/brltty
> net/climm
> security/gnupg
> sysutils/cdrtools
> x11/fvwm2
I don't want to do ports development, but I am the one making %n walk the
plank, so I should lift
Renaud Allard wrote:
> On 9/8/21 6:59 PM, Jeremie Courreges-Anglas wrote:
> > On Wed, Sep 08 2021, Renaud Allard wrote:
> > [...]
> > If you're worried that the %n uses in acl.c might trigger abort(3)
> > calls
> > in libc, please check and confirm that this debug_printf_something call
> > actua
Christian Weisgerber wrote:
> We also need to finish the %n cleanup. It looks like Theo wants
> to ship 7.0 with %n triggering abort(3). Without testing, we will
> not find all application uses.
It can miss release if it needs to.
But I urge users to install new ports, and test, and not defer
Similar comments here:
> Hi,
>
> Another attempt to be helpful. This removes %n from brltty.
> Compiles, but untested due to I don't have a braille device.
>
> +@@ -87,8 +87,9 @@ describeCommand (int command, char *buffer, int size)
> + candidate->name, number, candidate->descripti
I do not like your style of adjusting the counter with -=
the character counting approach looks fragile.
I suspect some of these refactorings are better if MULTIPLE *printf calls
are used, instead of one call.
Cut the call into two at the %n
Stefan Hagen wrote:
> Hi,
>
> Another %n fix.
>
>
This change is really weird.
%n in a scanning string isn't the same as %n in a format string.
Is clang mistakenly flagging %n in scanning strings? That might be a
mistake. clang should only be inspecting *printf style format strings.
The change to libc has no impact on scanning strings. scann
Stuart Henderson wrote:
> On 2021/09/09 16:45, Kevin Lo wrote:
> > On Thu, Sep 09, 2021 at 07:05:26AM +, Yifei Zhan wrote:
> > >
> > > On 21/09/09 02:35PM, Kevin Lo wrote:
> > > >
> > > > This has been discussed before:
> > > > https://marc.info/?t=15781134382&r=1&w=2
> > >
> > > Is the
Jeremie Courreges-Anglas wrote:
> On Wed, Sep 08 2021, Renaud Allard wrote:
>
> [...]
>
> > I discussed with exim guys and it seems they are quiet reluctant at
> > modifying "correct C code".
>
> Even sprintf uses can be correct, it doesn't mean that people should use it.
the exim people tal
Stuart Henderson wrote:
> On 2021/09/07 21:24, Christian Weisgerber wrote:
> > Earlier today, semarie@ committed a change that will now cause base
> > clang to warn when the %n specifier appears in a format string for
> > the printf(3) family of functions:
> >
> > warning: '%n' format specifier
Jeremie Courreges-Anglas wrote:
> On Fri, Sep 03 2021, Renaud Allard wrote:
> > On 9/2/21 11:38 PM, Jeremie Courreges-Anglas wrote:
> >> On Thu, Sep 02 2021, Jeremie Courreges-Anglas wrote:
> >>> On Thu, Sep 02 2021, "Theo de Raadt" wrote
Jeremie Courreges-Anglas wrote:
>
>
> exim apparently uses printf("%n"), which is currently forbidden (libc
> calls abort(3)).
>
> I don't want us to fix all the %n uses in the ports tree, but instead
> wait for user reports. Though for some software like exim it makes
> sense to help users a
Stefan Hagen wrote:
> Hi,
>
> This fixes:
> Aug 31 23:37:50 x230 luakit: *printf used %n: %s:%d%n
>
> It can be tested:
> 1. start luakit
> 2. type: ":lua foobar()"
>
> An error text with a Traceback occurs. The text + alignment is created
> with the fixed function.
>
> OK?
>
> Best regards,
Christian Weisgerber wrote:
> Jeremie Courreges-Anglas:
>
> > Ports may suffer from this at build time *and* runtime. Regarding
> > issues at build time we can ease the debugging with the diff below.
>
> I've been running with this for months, but nobody asked me for
> results and I didn't pus
Jeremie Courreges-Anglas wrote:
> (cc'ing ports bulk builds herders)
>
> Hi folks,
>
> On Mon, Aug 30 2021, Theo de Raadt wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: dera...@cvs.openbsd.org 2021/08/30 05:16:49
> >
%n abuse is always so crazy, it is like some developer saw a weird
thing on the shelf and just had to use it.
I am so happy we managed to change the support onto a hard failure.
Jeremie Courreges-Anglas wrote:
> On Mon, Aug 23 2021, George Koehler wrote:
> > Hi,
> >
> > When emacs-27.2p1-gtk3
Ingo Schwarze wrote:
> Theo de Raadt wrote on Tue, Jul 27, 2021 at 09:12:58AM -0600:
> > Ian Darwin wrote:
> >> On Tue, Jul 27, 2021 at 04:47:46PM +0200, Ingo Schwarze wrote:
>
> >>>> Changes by: st...@cvs.openbsd.org 2021/07/27 05:55:36
> >&g
Ian Darwin wrote:
> On Tue, Jul 27, 2021 at 04:47:46PM +0200, Ingo Schwarze wrote:
> > > Changes by: st...@cvs.openbsd.org 2021/07/27 05:55:36
> > >
> > > Modified files:
> > > sysutils/bat : Makefile
> > >
> > > Log message:
> > > set sysutils/bat to ONLY_FOR_ARCHS=${LP64_ARCHS},
The rust ecosystem working hard to make an impression.
Rafael Sadowski wrote:
> On Sat Jun 19, 2021 at 08:17:43AM +0200, Rafael Sadowski wrote:
> > On Thu Jan 16, 2020 at 03:29:42PM +0100, Landry Breuil wrote:
> > > Hi,
> > >
> > > sent this last year but it wasnt imported due to lack of interes
Stuart Henderson wrote:
> On 2021/06/09 09:56, Jonathan Gray wrote:
> > update intel microcode to 20210608
>
> Fine with me. Wondering about -stable for microcode, should we push it
> there after a couple of weeks of no reported problems in -current?
Yes.
> (Though I'm not sure how much covera
Use a mix of ktrace -di and ltrace(1) , and try to find the callpaths
that are trying to something like
close(fd);
fd = -1;
...
close(fd);
though it will likely be in very different places...
Stephan Mending wrote:
> Hello *,
>
> I've been noticing a large number of error
Stephane Guedon wrote:
> Le lundi 24 mai 2021, 16:59:15 CEST Stuart Henderson a écrit :
> > On 2021/05/24 15:25, Stephane Guedon wrote:
> > > Hello
> > >
> > > I am beginning to write a peertube port, just as a way to better
> > > manage my instance. I don't know if it will succeed.
> > >
> > >
It is a both-compilers architecture.
Kurt Mosiejczuk wrote:
> On Sat, May 15, 2021 at 11:57:03PM -0400, Kurt Miller wrote:
> > On May 15, 2021, at 11:34 PM, Kurt Mosiejczuk wrote:
>
> > > benchmarks/fio needs at least ports-gcc to compile on sparc64
>
> > > This fixes the build on sparc64
>
Stuart Henderson wrote:
> > In fact, I scanned the code looking for calls, so this should be ready for
> > general use. I could have restricted it way more for my own use only.
> > Though, I agree, this only protects from a very limited subset like route,
> > settime, pf, audio, video.
>
> Even
Stuart Henderson wrote:
> On 2021/03/16 09:28, Theo de Raadt wrote:
> > >
> > > Yes, I know, it's a "better than nothing" solution. I tried to make it
> > > run for all use cases, which is quite wide as you said.
> >
> > Hang on -- it i
Renaud Allard wrote:
> On 3/16/21 4:11 PM, Theo de Raadt wrote:
> > Renaud Allard wrote:
> >
> >> This is a small patch to try to add a basic pledge() to exim. It also
> >> avoids exim from calling some "inappropriate" ioctls.
> >> This seem
Renaud Allard wrote:
> This is a small patch to try to add a basic pledge() to exim. It also
> avoids exim from calling some "inappropriate" ioctls.
> This seems to run fine on my server, but I would like a wider testing
> and bug reporting if possible.
I'll step in and say I am really sceptical
Sebastien Marie wrote:
I take no position on what lands in ports, but want to make a public
comment. I doubt you wrote the following sentence:
> Zig is a general-purpose programming language and toolchain for
> maintaining robust, optimal, and reusable software.
I am sure both csh and php aspi
Bjorn Ketelaars wrote:
> On Sat 27/02/2021 18:18, Christian Weisgerber wrote:
> > Bjorn Ketelaars:
> >
> > > +--- src/parser-cw.c.orig
> > > src/parser-cw.c
> > > +@@ -32,8 +32,8 @@
> > > + #include "program-cw.h"
> > > + #include "options.h"
> > > +
> > > +- int current_line;
> > > +-
We'll need to carry both nodes for a while.
Another problem is there will be people who don't upgrade, and must
run MAKEDEV manually for the new nodes.
Much later on, we want the old nodes to be deleted. I think the
scripts can be adjusted later. We need to choose the right order of
completing
Stuart Henderson wrote:
> On 2021/02/02 21:18, Greg Steuck wrote:
> > Added a patch from upstream to work around a case of
> > "all-world-is-Linux"ism.
>
> That's not really true; pretty much every OS other than OpenBSD has a
> way to determine the path that the current executable was started f
> Instead of allowing wpath and catching it again with unveil, wouldn't
> it be worth thinking about a pledge promise that allows X font cache
> updates?
That is ridiculous.
Everyone can see you have an agenda.
Please stop being so rude.
max porter wrote:
> If it doesn't represent policy then change the name of the section otherwise
> it just seems to read as "rules for thee and not for me". This implication
> also is reinforced by the behavior of developers an
I thought you said you were leaving.
You really should do what you said you were going to do. I'm going
to ask for you to be evicted from the list.
wrote:
> "Tracey Emery" wrote:
> > On Wed, Oct 28, 2020 at 04:06:43PM +0100, zeurk...@volny.cz wrote:
> >> "Stuart Henderson" wrote:
> >> > On
kettenis and I have spent some time trying to track this down.
There is an obscure MP-unsafe / thread-unsafe in the W^X
line-in-the-sand mechanism, which is done using GDT CS manipulation.
It is related to sleeps in the trap function.
On PAE NX systems, the GDT CS manipulation is not neccessary,
Stuart Henderson wrote:
> > I don't think we'll be able to make it default, Theo will object.
> > If you want it, you have to convince *him*, not me.
I've encountered a few situations with _mostly offline machines_ where
the rsync package is need, and thus, 1 file can be copied over for
pkg_add.
Stuart Henderson wrote:
> On 2020/08/04 12:30, Todd C. Miller wrote:
> > On Tue, 04 Aug 2020 12:19:49 -0600, "Theo de Raadt" wrote:
> >
> > > This is totally ridiculous.
> > >
> > > Who is served by all these extra features? Didn't i
Todd C. Miller wrote:
> On Tue, 04 Aug 2020 12:19:49 -0600, "Theo de Raadt" wrote:
>
> > This is totally ridiculous.
> >
> > Who is served by all these extra features? Didn't it work before?
> > Is it suddenly MANDATORY to have all these fea
This is totally ridiculous.
Who is served by all these extra features? Didn't it work before?
Is it suddenly MANDATORY to have all these features?
Christian Weisgerber wrote:
> On 2020-07-30, Klemens Nanni wrote:
>
> > Any OKs for this diff which updates and brings in all the support?
>
>
Remember that srandom() + random() will do arc4random() internally,
unless srandom_determinisitic() is called.
But I guess the idiocy is the code ahead of srandom...
Christian Weisgerber wrote:
> telephony/resiprocate fails to build on non-x86 architectures.
>
> The reason is amazing:
> error:
Sebastien Marie wrote:
> The diff switchs the function sc_mem_secure_alloc() to uses mmap(2) with
> MAP_CONCEAL as we do for secrets (it excludes this chunk of memory from core
> dumps), and to not uses mlock(2). And changes sc_mem_secure_free() too.
Why.
They tried to keep it out of swap, whic
Landry Breuil wrote:
> Maybe opensc upstream have valid reasons for calling mlock() or not, i'm
> not in a position to judge that.
>
> Anyway, the corresponding code is probably there:
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc.c#L895
>
> Which was added 2 years ago in this
> firefox[50499]: pledge "", syscall 203
This is mlock.
It is not suitable in a privsep + pledge program.
pledge challenges programs to be narrower and more careful in their
system call use for two reasons: upon error they can cause less damage
within the filesystem, and upon control fewer ke
Martijn van Duren wrote:
> tl;dr: should we disable alloca in gettext and what's the best way to
> do this if so?
>
> So msgfmt crashes an insane amount of times on alpha (rough guess is 75%
> of the time) which is a pain when building other packages.
> I managed to trace the issue to gettet-run
+The key must be specified as the GOOGLE_API_KEY environment variable.
Wow, the process environment is going to get real full soon with all
these NSA_API_KEY, CSE_API_KEY, and SAFEWAY_API_KEY environment
variables.
Dystopia ahead.
Antoine Jacoutot wrote:
> On Mon, Apr 13, 2020 at 08:13:50PM -0400, Brad Smith wrote:
> > On 4/13/2020 5:26 PM, Antoine Jacoutot wrote:
> >
> > > On Mon, Apr 13, 2020 at 12:47:47PM -0400, Kurt Mosiejczuk wrote:
> > > > Two things cause the build to fail on sparc64: "-Werror" and the need
> > > >
Caspar Schutijser wrote:
> p.s. This makes me wonder whether there are other features that don't
> work on OpenBSD.. I'm planning to look into that at some point. In the
> meantime, should we warn users about this?
Warn the software comes without a warranty? Or any actual claim that it
actually
It upsets me that there is a way to disable it, and it also upsets me
that it is flawed and people need to disable it.
Solene Rapenne wrote:
> This will be helpful for people upgrading to 6.7 who had disabled pledge
> in firefox, and also to tell people about unveil addition to firefox and
> tha
Landry Breuil wrote:
> On Thu, Jan 16, 2020 at 09:18:50AM -0700, Theo de Raadt wrote:
> > Stuart Henderson wrote:
> >
> > > On 2020/01/16 15:29, Landry Breuil wrote:
> > > > Hi,
> > > >
> > > > sent this last year but it wasnt im
Stuart Henderson wrote:
> On 2020/01/16 15:29, Landry Breuil wrote:
> > Hi,
> >
> > sent this last year but it wasnt imported due to lack of interest, maybe
> > more luck this time... yes, its a rust thing.
>
> portswise OK if you really think it's worth the build time (20 minutes on
> a 3.2GHz
Annother approach would be to unify all the input method pathnames, so that
there is only one pathname. That might require a lot of ports surgery,
I don't know how much.
But consider the benefit of such a plan. If there is only one pathname,
containing only input mechanism, then it can be unveil
>The latest vim update appears to have changed the default colorscheme to
>reallyfreakingawful. The previous default seems to be called peachpuff. hth.
does mailing ports@ help?
much more likely, did upstream not make the decision? why not engage
them and express your outrage?
if it is not a por
Should be able to spot the reverse overlap.
The memcpy vs memmove difference is pretty simple, and has not
false positived once.
Claudio Jeker wrote:
> On Mon, Dec 30, 2019 at 10:31:30AM +0100, Denis Fondras wrote:
> > On Sun, Dec 29, 2019 at 11:56:57PM +0100, Theo Buehler wrote:
> > > > That's
that small libc tweak keeps delivering results!
Theo Buehler wrote:
> > That's a problem on my side, I will sort it and retry.
>
> This diff fixes it:
>
> Index: libvips/iofuncs/init.c
> --- libvips/iofuncs/init.c.orig
> +++ libvips/iofuncs/init.c
> @@ -858,7 +858,7 @@ extract_prefix( const ch
Stuart Henderson wrote:
> On 2019/12/19 18:35, Reyk Floeter wrote:
> > On Thu, Dec 19, 2019 at 12:18:28PM -0600, Lucas Raab wrote:
> > > Hello,
> > >
> > > Updated py-fido2 below and has been tested with a Yubikey 4 and
> > > security/yubico/yubikey-manager. Note, either chmod the USB devices o
Landry Breuil wrote:
> On Tue, Dec 10, 2019 at 10:18:37AM -0700, Theo de Raadt wrote:
> > Landry Breuil wrote:
> >
> > > Well, i managed to have a 'video' pledge class, so you can probably get
> > > an 'uhidioctl' class :)
> >
>
Landry Breuil wrote:
> On Tue, Dec 10, 2019 at 10:18:37AM -0700, Theo de Raadt wrote:
> > Landry Breuil wrote:
> >
> > > Well, i managed to have a 'video' pledge class, so you can probably get
> > > an 'uhidioctl' class :)
> >
>
Landry Breuil wrote:
> Well, i managed to have a 'video' pledge class, so you can probably get
> an 'uhidioctl' class :)
I still feel the addition of 'video' pledge was an abuse of the concept.
firefox has done a pretty weak version of privsep that requires a
'master process' to have nearly all
Just make sure your processes call setresuid() or setresgid() to change
(or change to the same...) their uid or gid or gidset, which locks out
ptrace from related processes. That also kills inadvertent coredump drops.
Beyond that, you are dependent on the code not having take-over bugs which
atte
Sadly, it is hard to add incremental improvements to architectures,
and then assume the old ones are gone...
Stuart Henderson wrote:
> On 2019/11/15 03:02, Ted Unangst wrote:
> > Stuart Henderson wrote:
> > > This runs OK on an i386 with more CPU features; most likely it wants
> > > SSE or simil
that file being there, hints this is a directory which must be
visited early to install the header file.
I'll add my voice to this.
The powerful vendors writing new languages must expand their breath,
or face the consequences that some software is not going to get written
in their languages. Better is very much muted by unportable.
> Hello Joerg,
>
> No objections from me portswise (although I'm n
Landry Breuil wrote:
> I have to admit that now that we move towards unveil, dlopen() feels awkward,
> especially with the version number hardcoded. I dont want to hardcode
> libsndio.so.7.0 in the unveil config... and i dunno if having
> /usr/lib/libsndio.so would work.
Yes, it should make you
Landry Breuil wrote:
> On Thu, Nov 07, 2019 at 06:25:33PM +, Stéphane HUC - PengouinBSD wrote:
> > On 2019-11-07 17:17, Landry Breuil wrote:
> > > On Thu, Nov 07, 2019 at 06:06:35PM +0100, Stéphane HUC wrote:
> > > > Hi,
> > > >
> > > > In 2019/09/08, about Firefox and DoH by default, Otto M
This problem was just fixed by matthieu in X:
CVSROOT:/cvs
Module name:xenocara
Changes by: matth...@cvs.openbsd.org2019/10/28 13:38:47
Modified files:
dist/fontconfig/src: fccompat.c fccache.c
Log message:
Stop calling chmod() in cache update code.
These calls ar
Stuart Henderson wrote:
> On 2019/10/28 14:09, joshua stein wrote:
> > On Mon, 28 Oct 2019 at 20:04:06 +0100, Sebastien Marie wrote:
> > > On Mon, Oct 28, 2019 at 09:26:09AM +0100, Klemens Nanni wrote:
> > > > On Sun, Oct 27, 2019 at 12:56:40PM -0500, joshua stein wrote:
> > > > > As a workaround
joshua stein wrote:
> On Mon, 28 Oct 2019 at 20:04:06 +0100, Sebastien Marie wrote:
> > On Mon, Oct 28, 2019 at 09:26:09AM +0100, Klemens Nanni wrote:
> > > On Sun, Oct 27, 2019 at 12:56:40PM -0500, joshua stein wrote:
> > > > As a workaround, you can add this to
> > > > /usr/local/lib/thunderbi
101 - 200 of 487 matches
Mail list logo
