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
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
Mark Kettenis wrote:
> Theo pointed out the NOBTCFI reversal here. Now the reason that we
> still see SIGILL despite fixes to the assembly code is because the
> -mbranch-protection=pac-ret option added by the configure script
> actually downgrades our default of enabling both BTI and PAC to just
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Sat, 22 Jun 2024 06:16:03 -0600
> >
> > Mark Kettenis wrote:
> >
> > > Theo pointed out the NOBTCFI reversal here. Now the reason that we
> > > still see SIGILL despit
Stuart Henderson wrote:
> This change won't work directly as the following lines currently need
> blocking until dhcp has fetched an address but I don't think it's worth it.
Right.
We have entered a world where dynamic address negotiation is async.
But then, it always was.
This is not right.
Only a maximum number of unveil's are allowed, before it starts returning
E2BIG. That amount is not a public #define, to discourage what you are
doing.
You are trying to shove an unbounded number of them into the kernel, based
upon getenv and argv.
When you run out, and will
at g2k23 we talked about this issue for a bit. The make(1) manual
page can be confusing because it says:
-j max_processes
Specify the maximum number of processes that make may have
running at any one time.
Nope, that's wrong. It can create vast number of processes
Christian Weisgerber wrote:
> The remaining build failures are:
>
> lang/crystal
> lang/dmd
> lang/gprolog
> lang/ldc
> lang/mono
> lang/ocaml
> lang/racket-minimal
Have the upstreams been told that IBT/BTI instructions are going to
be required in all software (sometime in the future).
Brian Callahan wrote:
> Pushed a nobtcfi fix for DMD.
nobtcfi should never be considered a "fix". It is a workaround we make
available to allow laggard software to continue running -- nothing more.
Brian Callahan wrote:
> On 7/10/2023 9:33 AM, Theo de Raadt wrote:
> > Brian Callahan wrote:
> >
> >> Pushed a nobtcfi fix for DMD.
> >
> > nobtcfi should never be considered a "fix". It is a workaround we make
> > available to allow
Christian Weisgerber wrote:
> (Let's call it "IBT" because this is on amd64.)
>
> The remaining build failures in lang/* are:
>
> lang/crystal
> lang/gprolog
> lang/ldc
> lang/ocaml
> lang/racket-minimal
>
> Is anybody doing full package bulk builds on hardware that enforces
> IBT? I could gi
Morgan Aldridge wrote:
> Since Ian mentioned devel/zeal for a USE_NOBTCFI update in -current, I
> figured I'd give it a try. Unfortunately, under OpenBSD
> amd64/6.3-stable, I get the following error when attempting to execute
> it:
>
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tm
Christian Weisgerber wrote:
> Mark Kettenis:
>
> > This port has some infrastructure to use an optimized function that
> > uses a function pointer. Not sure why for arm64 it actually uses that
> > infrastructure, since the only alternative is the generic C
> > implementation. But adding a BTI
Mark Kettenis wrote:
> I'm not sure to what extent this makes IBT less effective. Can the
> retpolines be used as gadgets to bypass IBT? Should we stop enabling
> retpolines by default?
>
> What *is* obvious is that retpolines are incompatible wuth shadow
> stacks. Is there an alternative tha
> yes, -current has it enabled now. But in order to catch those problems
> you'll need a CPU that supports it, too ... on amd64 that would be
> Tiger Lake(?) and later. I think.
it is any "laptop / desktop" cpu from gen11 onwards, which is most things
in the last 3 years
If you use unveil() without pledge(), you do not get the
special-case-file-exposures-for-libc behaviours that pledge() brings.
You are then responsible for all path exposure.
Morgan Aldridge wrote:
> On Mon, Aug 7, 2023 at 3:57 AM Landry Breuil wrote:
>
> > Le Sat, Aug 05, 2023 at 07:41:12PM
I do not think this should be enabled.
Our stacks work differently.
We don't put shit near the bottom of the main stack, because we
reserve the space.
For pthread stacks, we allocate them randomly also so you cannot
determistically trash a specific object.
This change also make very small stacks (m
Mark Kettenis wrote:
> > From: Theo de Raadt
> > Date: Thu, 14 Sep 2023 01:02:14 -0600 (MDT)
> >
> > I do not think this should be enabled.
> > Our stacks work differently.
> > We don't put shit near the bottom of the main stack, because we
> >
> On Mon, Dec 1, 2008 at 12:21 PM, Marc Balmer <[EMAIL PROTECTED]> wrote:
> > * Ian Darwin wrote:
>
> >> Gypsy was designed to fix "the numerous design flaws found in GPSD".
> >> These are compiled at http://gypsy.freedesktop.org/why-not-gpsd.html.
> >
> > So how does this compare to gpsd for real
> > > > So how does this compare to gpsd for real applications? I am asking
> > > > since the main gpsd developer is also an OpenBSD developer, and maybe
> > > > there are ways to fix the problems in gpsd?
> > > >
> > > > Oh, and I find this rude.
> > >
> > > DBUS is more crap I don't need or wan
> .It Fl M
> Show the install-message file (if any) for each package.
> +If any step not documented in the manual must be taken before a package
> +can be used, this file will often mention it.
That is an attempt to entirely push the problem under the table.
The default message should be releva
Another way to solve this is a rewrite of pod2man .. which will then
generate mandoc instead.
That also benefits the other manual page project.
> Actually, this is more complex than it looks, because recent pod converters
> make a lot of use of
> .ie n
> .el
> constructions, and that throws makew
> On Sun, Mar 22, 2009 at 12:47:28AM -0600, Theo de Raadt wrote:
> > Another way to solve this is a rewrite of pod2man .. which will then
> > generate mandoc instead.
> >
> > That also benefits the other manual page project.
>
> hum... so let's trade 10 line
> On Thu, Mar 26, 2009 at 01:36:00PM +0100, Daniel Hartmeier wrote:
> > On Thu, Mar 26, 2009 at 01:11:49PM +0100, Markus Lude wrote:
> >
> > > Hello,
> > > after updating to the recent snapshot from march 24th I now get errors
> > > when running pfstat:
> > >
> > > ioctl: DIOCIGETIFACES: Operatio
> The $PACKAGE_REPOSITORY directory, typically /usr/ports/packages/, will
> normally contain subdirectories for arch, as well as, further
> subdirectories for desired\allowed redistribution (cdrom, ftp, ...).
No, we don't do that.
> /usr/ports/packages/i386/
> /usr/ports/packages/i386
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
> Is there a timeline for the sudo->doas transition? The sudo port could
> be imported early, I'd say.
I think we should create the gap, first.
I am not positive if doas is exactly the right path replacement. I
still wish there was some sort of privsep for the parsing. And about
whether this s
> On my old, circa 2005 systems, writing out a ~1.5 GB core file probabaly
> takes about 30-120 seconds to complete (I never actually timed it, but it
> certainly takes long enough to notice), by which time upon rejoining the
> game most people have already left. By doing:
>
> % rm game.
> On 2015/07/17 20:24, Ted Unangst wrote:
> > Jeremy Evans wrote:
> > > As an aside, crypt("passwd", "$2") returns ":" instead of NULL. I'm not
> > > sure if that's a security issue, but I think it is and we should fix it.
> > > I'll see if I can get a patch for that and send it to tech@.
> >
> >
>On Sep 21 22:37:11, st...@openbsd.org wrote:
>> On 2015/09/21 21:31, Jan Stary wrote:
>> > On Sep 17 07:30:23, st...@cvs.openbsd.org wrote:
>> > > update to libmagic (file) 5.25
>> >
>> > What is the relation of OpenBSD's own new file(1) to devel/libmagic?
>>
>> No code relation. libmagic is a p
> > > Ports is a thankless job. I guess there are way more (most probably paid?)
> > > volunteers in Linux who maintain nagios.
> >
> Not necessarily - the codebase is exactly the same - compiling on 5.7
> throws the errors previously mentioned, .. building on a 32-bit Debian
> kernel [4-byte time
> > > Not saying he is, .. the question is why the codebase complies just fine
> > > on both 64 & 32 bit Linux systems, but not OBSD. If there were a way to
> > > divine that secret sauce, would it not help others?
> >
> > Yes. So go divine it, get going at it already.
> >
> Well, ... guess you re
> > Apparently your expertise is begging for help on open source
> > mailing lists, and then insulting us when we say no, we won't
> > help do your job for you.
> >
> Ahh, .. I wasn't begging, better check your sources. I was trying to help
> - if you don't want help, go farm cotton.
>
> > Get los
FYI sluug,
Lee has been on our mailing lists arguing with people who don't
want to do his work for him.
Such discourse from a member of your community towards open source
groups is not acceptable.
Lee, you tell me when I should stop being a 'lunatic', ok?
> > Apparently your expertise is beggin
> On Fri, 2 Oct 2015, Theo de Raadt wrote:
>
> > When you pick a fight with one open source project, it may lead
> > people to believe you have other bad business practices.
> >
> Sorry, .. you picked the fight, not me - better get your story straight.
>
> >
> On Fri, 2 Oct 2015, Stuart Henderson wrote:
>
> > AFAIK, Linux uses 'long' for time_t, like we used to. This is
> > 32 bits on 32-bit platforms and 64 bits on 64-bit platforms and
> > matches the %lu format strings.
> >
> > Background etc. in http://www.openbsd.org/papers/eurobsdcon_2013_time_t/
> Do you want to give back the money we have contributed? Refund the cost of
> the CDs we have on the shelf since, what, 3.1?
Even if that is the case, it gives you NO RIGHT to keep pushing for
developers to fix shit for you.
None of your mails have arrived with a patch. Why is that?
http://www
> Do you want to give back the money we have contributed? Refund the cost of
> the CDs we have on the shelf since, what, 3.1?
Are you being serious here?
I give you some money, and you'll leave?
Are there really user community members like you -- who are so
freeloading -- that if push comes to
> > > Do you want to give back the money we have contributed? Refund the cost of
> > > the CDs we have on the shelf since, what, 3.1?
> >
> > Are you being serious here?
> >
> > I give you some money, and you'll leave?
> >
> Well, .. that's what you were proposing, ..
I didn't propose anything abo
Lee said:
> > > Do you want to give back the money we have contributed? Refund the cost of
> > > the CDs we have on the shelf since, what, 3.1?
Theo said
> > Are you being serious here?
> >
> > I give you some money, and you'll leave?
Lee said:
> Well, .. that's what you were proposing, ..
Lee
> Any thoughts about doing this? Regression tests are all OK, I'm about
> to start a ports build with it in (but I don't expect any problems).
>
> For bzip2 the call is right at the start of main().
>
> For xz it's a bit lower - below hardware_init(), which uses sysctls
> to find the amount of me
> So, the only downside seems to be performance related.
>
> See: https://bugzilla.mozilla.org/show_bug.cgi?id=1215479
>
> < not
> enabled elsewhere because it's a performance hit (we should remeasure how much
> though). This is because we have to toggle pages from executable to writable
> and ba
I already had that queued, in the diff I sent out 9 hours ago.
I've commited it.
>I just spent 30 minutes playing with easy-rsa which is shipped broken on
>5.8 until I realized what was going on. I see that sthen has already
>reverted easy-rsa to OpenSSL run dependency per comment
>
>switch easy-rsa to using openssl to unbreak; libressl doesn't allow
>$ENV:: in config files and
> While on the subject, cert generation steps in the isakmpd(8) manual are
> also broken by this. It's absolutely right IMHO that the library should not
> honour these variables, but can anyone comment on how difficult/desirable
> it would be for the openssl(1) tool to handle these internally?
The
> On Thu, Nov 12, 2015 at 02:02:50AM +0100, J??r??mie Courr??ges-Anglas wrote:
>
> > Back to your concern: I don't think it's a reasonable approach to ask
> > for tests on all architectures before introducing a change in a port.
> > If we did that, the ports tree would be ridiculously small and la
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
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
that file being there, hints this is a directory which must be
visited early to install the header file.
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
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
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
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 :)
> >
>
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
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
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
>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
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
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
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
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
> In the latest snapshots, I've noticed something a little strange. In both
> firefox and chrome, every once in a while a line of text will be a
> little darker than usual. Like all the gray pixels that make up the smooth
> antialiased edges are black. It kind of looks like bold text would look,
>
> Do all of our stacks grow down?
Of course not.
>So here's a second attempt, this time with 3.0-324. Works for me with
>AfriNIC, APNIC, LACNIC and RIPE. I tried squinting at the tshirt photo
>for ARIN's trust anchor but couldn't quite make it out.
what?? the ports tree doesn't have a scanning program for that?
I hope fixing these ports is easy and fast.
LOOK, let me be clear.
At the very last minute, the sysctl can be changed to return success
But if you guys aren't even going to try to cope with change, that's
coming off a little lame.
There are bad side effects from the past behaviour as well.
Je
Alexander Bluhm wrote:
> On Tue, Oct 23, 2018 at 03:21:23AM +1100, Joel Sing wrote:
> > P.S. There is more functionality that could be enabled for LibreSSL, which
> > is currently being explicitly disabled...
>
> When a new Net::SSLeay is released, I disable things that are not
> supported by cu
Alexander Bluhm wrote:
> On Mon, Oct 22, 2018 at 11:10:49AM -0600, Theo de Raadt wrote:
> > I understand the difficulty pointed out by the first questions. What
> > bothers me is the last question. It indicates a desire to support many
> > generations of software. Any at
Christian Weisgerber wrote:
> * editors/emacs21 segfault
> Maybe it's time to take that old horse out behind the barn?
BTW, I don't use it anymore.
Theo de Raadt wrote:
> Christian Weisgerber wrote:
>
> > * editors/emacs21 segfault
> > Maybe it's time to take that old horse out behind the barn?
>
> BTW, I don't use it anymore.
And the reason is, it is the last program using brk which we
>> On Nov 5, 2018, at 8:30 AM, Marc Espie wrote:
>>
>> Or we could just finally remove brk and sbrk from the libc ?
>>
>>
>
>you won???t get very far. they are still needed in base (gcc, clang, mkhybrid).
The goal isn't to remove it.
Rather, we want to neuter one semantic component, such that
Peter Hessler wrote:
> On 2018 Dec 13 (Thu) at 11:20:37 +0100 (+0100), Sebastian Benoit wrote:
> :I'm cleaning up things on a system, and deleting quite a few packages.
> :
> :For example cups. Because its no longer needed.
> :
> :--- -cups-2.2.8p1 ---
> :You should also run rm -r
Edward Lopez-Acosta wrote:
> What is the logic in not updating this for -stable too?
There are no magic fairies building -stable packages on a constant
basis.
> Because they constantly update for security issues and this is not convenient?
Yes. Also it isn't just a matter of building using ro
The proposed diff contains many problems, and demonstrate that pledge and
unveil are not well understood.
In particular, specific pledges open up various system files, so those do not
need to be opened via unveil. Thos unveil calls are misguided. This is a
pretty
strange misunderstanding.
The
Well, someone screwed up.
This program does a "dns" lookup, when it hasn't been coded to enable
dns lookups in pledge. It is as simple as that.
I am always amazed people who run into these issues don't immediately
use ktrace + repeat the problem, then kdump, and then determine what
usage pattern
Christian Weisgerber wrote:
> George Koehler:
>
> > - unsigned char* c = (unsigned char*) &col; return c[i];
> > + unsigned char* c = (unsigned char*) &col;
> > +#ifdef __BIG_ENDIAN__
> > + return c[sizeof(col) - i];
> > +#else
> > + return c[i];
> > +#endif
> >}
>
> Off by one:
> ret
The hiding of PAGE_SIZE is intentional.
The code should be using getpagesize() or some API which asks the
kernel.
The reason is that PAGE_SIZE is not a standardized symbol, and on some
of our architectures it changes between different processor models.
>sysutils/ntfs-3g fails to build on loongso
>On Wed, Jan 15, 2014 at 09:31, Antoine Jacoutot wrote:
>> On Tue, Jan 14, 2014 at 11:06:40PM -0500, Ted Unangst wrote:
>>> I ran pkg_add -u and it printed a warning about @endfake being
>>> obsolete. It may have been in the xvidcore package, or not; it was
>>> hard to tell which package the warnin
> On Fri, Mar 07, 2014 at 10:51:50AM +0100, Landry Breuil wrote:
> > [...]
> > To everyone experiencing this issue, can you try with this diff:
> > [...]
>
> Seems to work. I get consistent ~60 FPS with glxgears during
> suspend/resume cycles where before I'd get ~60 until the first suspend
> and
> Yes. Allthough the inteldrm code wasn't quite as bad in this respect
> as the radeondrm code.
No kidding.
> My hopethesis about what's causing the problem here is that during the
> DVACT_WAKEUP phase, some drivers actually sleep and that userland
> processes actually get to run.
Yes, that is
> DVACT_WAKEUP does finish its job. It's just that it is doing so while
> kernel threads and userland processes are running as well. Drivers
> need to be aware of this, and I'm not sure they all are.
Well the only thing which could stop that X process from playing with
stuff, is the driver it be
I don't see the point.
1) Collisions happen in other places.
2) Noone who runs into this will have read the note before they run
into the situation.
> Is this worth committing?
>
> Thanks
>
>
> Index: current.html
> ===
> RCS
> To summarize, if you are interested in improving OpenBSD regression
> tests, i'd suggest working on *actual tests*, not bloated frameworks.
> One could look at the existing tests, clean them up such that they
> actually run through, do not generate bogus errors, improve the style
> in some places
> On 2014/03/13 17:09, Brian Callahan wrote:
> >
> > On 03/13/14 16:02, Juan Francisco Cantero Hurtado wrote:
> > >On Wed, Mar 12, 2014 at 07:39:29PM +0100, Pascal Schmid wrote:
> > >>port of the DOS shoot-em-up Tyrian
> > >>
> > >>Tested on amd64 and macppc (both -current)
> > >>
> > >I attached
> On Mon, Mar 31, 2014 at 20:19, Stuart Henderson wrote:
> > On 2014/03/31 20:58, Christian Weisgerber wrote:
> >> security/samhain has been broken since the removal of sum(1).
> >>
> >> The problem is the c_random.sh script, which returns a 16-bit random
> >> number in decimal. Unless I'm missin
> > I wondered about just doing $((RANDOM+RANDOM)) but don't know the
> > pros and cons of that approach - it's not exactly arc4random_uniform..
>
> I wanted to stay in the spirit of portability. RANDOM is a ksh
> extension and difficult to check for reliably.
Well...
openssl is an extension.
>> > I recently posted a new CPAN module to ports@ which wraps pledge and
>> > unveil. There was a bit of a balls up because as a sysadmin I'm not
>> > really used to group development and what I've done has usually been in
>> > a corporate environment but in the end a complete tarball was posted.
It is such an amazing business-friendly but risk-ignorant pattern to
simply restart software that has failed.
It's like you keep flying a plane that falls out of the sky twice,
rather than cease operation, figure out what is wrong, and fix it before
continuing.
Edd Barrett wrote:
> Hi all,
>
>
Edd Barrett wrote:
> On Thu, May 30, 2019 at 10:00:12AM -0600, Theo de Raadt wrote:
> > It is such an amazing business-friendly but risk-ignorant pattern to
> > simply restart software that has failed.
>
> It's all configurable, so if that isn't the desired beha
Thomas Frohwein wrote:
> The ideal future state would be removing W|X from those remaining
> ports.
That is seriously idealistic.
The upstream software teams must decide to do that.
After that, the "port" has no work to do.
It is generally impossible for a "port" to solve this problem.
It's l
Bryan Steele wrote:
> In addition to what Stuart said, irssi is using libperl here for perl
> scripts, which means the irssi unveil will be applied to them. There
> are many uses for perl scripts, and many involve reading arbitrary files
> and there's no way to know that upfront.
Keep in mind un
Solene Rapenne wrote:
> On Tue, Jun 11, 2019 at 11:55:29AM -0600, Theo de Raadt wrote:
> > Bryan Steele wrote:
> >
> > > In addition to what Stuart said, irssi is using libperl here for perl
> > > scripts, which means the irssi unveil will be applied to them. T
Alexander Bluhm wrote:
> On Thu, Jun 27, 2019 at 10:08:37PM +0100, Stuart Henderson wrote:
> > #0 0x082eefff in botan_sha160_x86_32_compress () from
> > /usr/local/lib/libbotan-1.10.so.1.1
>
> This code is at a page boundary, so it traps into the kernel. There
> it is detected that the esp re
Alexander Bluhm wrote:
> On Sun, Jun 23, 2019 at 04:18:29PM +0100, David CARLIER wrote:
> > Here the changeling
> > https://botan.randombit.net/news.html#version-2-10-0-2019-03-30
>
> The problem with this update is that they added pledge(2) in a wrong
> way. So I hesitated to update the port.
mazoc...@disroot.org wrote:
> Hi!
>
> We all know that bugs don't get fixed without backtraces.
>
> After few years of using OpenBSD I am annoyed to get mocked for not
> sending backtraces, but why I don't send them? The answer is: OpenBSD
> doesn't provide software packages with debugging symbo
Please leave the list.
Leonid Bobrov wrote:
> > It is definately not a friendly place for people with a tone like yours.
>
> Theo, your excuse that OpenBSD is not more popular than Linux because AT&T
> sued BSD in 90's is ridiculous, that's your own fault for being so
> terrible in technical
Stuart Henderson wrote:
> On 2019/08/12 14:12, adr wrote:
> > > It's not clear to me that assembly code is the culprit here.
> >
> > No, I bet it is their memory managment functions.
> >
> > > I agree with Stuart's statement. It may be terse but I don't find it
> > > pedantic.
> >
> > And I a
adr wrote:
> > And disabling asm is unappealing on an arch which needs as much
> > help with speed as it can get.
>
> Even worst if you have to play video without hw acc.
>
> I thought that the decision of using --no_unaligned_access was a
> security one, but it seems from the thread that is mo
Christian Weisgerber wrote:
> Jeremie Courreges-Anglas:
>
> > > The below diff allows to build flac on macppc, where tests are passing
> > > [1]. I've not bumped revision, the change impacts powerpc where it has
> > > never been built.
> >
> > Good enough for ports, ok jca@
>
> ok naddy@
>
>
Jan Stary wrote:
> On Aug 15 18:30:20, j...@wxcvbn.org wrote:
> > Committed, thanks!
>
> So now, with openrsync in base (thank you Kristaps),
> rsync can finaly go.
Sadly, that is very far from true. openrsync is still missing a large
pile of important elements.
1 - 100 of 483 matches
Mail list logo
