Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Mon, 14 Nov 2022 10:02:40 -0700
> >
> > An OpenBSD machine only has one OpenBSD install.
>
> I have to disagree here. Not everyone has a pile of test machines
> lying around.
Are you goi
Stuart Henderson wrote:
> > Index: app/xenodm//config/Xsession.in
> > ===
> > RCS file: /cvs/xenocara/app/xenodm/config/Xsession.in,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 Xsession.in
> > --- app/xenodm//config/Xsession.in
14, 2022 at 07:49:11AM -0700, Theo de Raadt wrote:
> > Klemens Nanni wrote:
> >
> > > This is because the installer always considers the first root disk it
> > > finds as the one to upgrade, which is certainly not what I intend or
> > > expect when booting/up
> sd1-3 are softraid chunks hosting a separate installation for testing.
> Booting into this
I think this is where you went wrong. Expecting this to work is going
to result in 20-40 diffs bloating all the media for a configuration which
less than than 1 in a thousand people need.
Klemens Nanni wrote:
> This is because the installer always considers the first root disk it
> finds as the one to upgrade, which is certainly not what I intend or
> expect when booting/upgrading the softraid installation on sd1-3.
What does
first root disk
Mean?
There is only one root d
Klemens Nanni wrote:
> I'd like to get on with this, can also add sysctl.2 bits to document
> those before sending diffs using them.
I want you to prove the use case first.
> Mark asked whether CTLTYPE_QUAD would be more suited, but I still don't
> understand how that is supposed to work and th
Mark Kettenis wrote:
> > > The installer considers a disk a root disk if 'a' is FFS and contains
> > > expected files.
> > >
> > > Furthermore, unattended upgrades will always install to the first root
> > > disk that is found.
> > >
> > > This works fine on machines with only one root disk, bu
Claudio Jeker wrote:
> On Wed, Nov 09, 2022 at 07:37:50AM +, Stuart Henderson wrote:
> > Seems some hosting providers have annoying "out of prefix"
> > default gateways whuch are painful to configure
> > (https://marc.info/?t=16678224225&r=1&w=2), should
> > we give a pointer in route(8)?
Stuart Henderson wrote:
> > But I am not sure people need to see this detail. It just takes a bit
> > of time. How does knowing what steps are being taken help...
>
> Sometimes it's a bit of time, sometimes it's a _lot_ of time until
> people get a new computer or raid battery or something and
Klemens Nanni wrote:
> On Tue, Nov 08, 2022 at 10:23:23AM +, Stuart Henderson wrote:
> > On 2022/11/07 23:54, Theo de Raadt wrote:
> > > Klemens Nanni wrote:
> > >
> > > > > I know this makes rc(8) a bit noisier but it really does improve my
&
Klemens Nanni wrote:
> > I know this makes rc(8) a bit noisier but it really does improve my
> > (for want of a better term) "user experience" as I wait for my machine
> > to boot.
>
> I like this and it doesn't add more **lines** to the boot log, but maybe
> print library names without versions
> I'm a bit torn on this one since it is pretty niche, but since this
> actually helps you, I am ok with the diff.
I worry about unexpected results, which might even be dangerous.
The bsd.re-config file is written by people to perform against a GENERIC
or GENERIC.MP kernel.
It is not written to
Should we have a small window where the key is generated, but not yet
the default?
Or should we use the snapshot period to create some pain, and see which
clouds react (we will allow them to self-publish their hate for the choices
of their customers), but then when release time comes, we can make
i...@tutanota.com wrote:
> Nov 6, 2022, 21:14 by dera...@openbsd.org:
>
> > I suspect your company forces children to make shoes, and your bosses
> > kick dogs and cats. Can you provide evidence that is not true?
> >
> > that is what your messages come off like.
> >
> > Grow up.
> >
> I am
i...@tutanota.com wrote:
> Nov 6, 2022, 21:00 by dera...@openbsd.org:
>
> > Everything is provided with no warranty and you cannot insist on us
> > telling you what our processes are.
> >
> > You are out of line.
> >
> I am not insisting on anything, I am simply asking.
>
> We have supported th
i...@tutanota.com wrote:
> Nov 6, 2022, 20:16 by dera...@openbsd.org:
>
> > Mr iio7,
> >
> > Your persistant questions as to our processes are pointless.
> >
> > You are asking these questions in this way to interfere.
> >
> > That is a dickhead move.
> >
> > Everyone can see it.
> >
> Well, then
Yeah sure why not.
Klemens Nanni wrote:
> Upgrades are noiser on macppc (and loongson and octeon) than on other
> architectures because boot firmware changes and/or tips to complete an
> OpenBSD installation are always printed, even though they are not needed
> after an upgrade:
>
> INSTA
i...@tutanota.com wrote:
> >>> That is not your responsibility. It is mine.
> >>>
> >>> You can stop asking.
>
> I replied of list (by mistake by pressing reply rather than reply to all):
>
> >> Why do you keep wasting your precious time with these completely
> >> useless comments?
>
> To which
+ if (mergesort(learning, ASR_MAXNS, sizeof(learning[0]), cmp) == -1)
+ lerr(1, "mergesort");
So at runtime if mergesort() fails to allocate memory, the program will
simply exit?
That is not your responsibility. It is mine.
You can stop asking.
>I am trying to understand how the code review process is conducted in
>OpenBSD. I can see all the OK's in the commit log, but not every commit
>has the OK.
>
>On FreeBSD there where a serious problem with a developer who was hire
If you do not sort the, you cannot remove duplicates.
David Gwynne wrote:
> usbdevs has "?" in the optstring is passes to getopt, but doesn't handle
> it specially. this is unnecessarily different to everything else in the
> tree, so i want to remove it. ok?
>
> Index: usbdevs.c
> ===
Todd C. Miller wrote:
> On Fri, 21 Oct 2022 22:55:57 +0200, Mark Kettenis wrote:
>
> > Be careful. By moving more stuff into .rodata, you may overflow the
> > .text/.rodata block. Make sure you build and test the kernels and
> > also test an actual bsd.rd.
>
> Do we know exactly what these li
Mark Kettenis wrote:
> Be careful. By moving more stuff into .rodata, you may overflow the
> .text/.rodata block. Make sure you build and test the kernels and
> also test an actual bsd.rd.
Unless it fits, just barely, and then a commit three weeks later breaks it.
Or three months. Or two year
Mark Kettenis wrote:
> > I tend to agree that the complexity of this is out of scope for
> > man pages. Understanding this properly requires reading books
> > about computer architecture first.
>
> So I would phrase this as something like "device that the OpenBSD
> kernel considers removable".
Stefan Sperling wrote:
> And perhaps the entire USB bus will be powered down when
> the host controller goes to sleep, and all connected devices
> will lose power.
but oh ... the situation is even more
complicated:
There are situations where a machine won't suspend because a bus has
power-draw
Jason McIntyre wrote:
> > It is extremely complicated, there is no way to accurately explain
> > in user-speak what devices detach and what devices don't detach.
> >
>
> pluggable?
Sorry, that is completely untrue.
What kind of plug?
A USB plug?
A MMC plug?
A PCI plug?
A MINI-PCIE plug?
A doc
Solène Rapenne wrote:
> I agree my sentence isn't good enough or is too much, but I think ZZZ
> explanations isn't enough in its current form
Maybe it is lacking. But your previous diff didn't help anyone.
> from your reply I got
> information such as external devices that wasn't described in
I disagree with this sentence.
The machine is unhiberated in the same way that an unsuspend happens.
EVERYTHING is as it was before, except for one thing: Devices which are
not known to be part of the machine, will have become detached, and
if/when they reattach, configuration of them will be mis
Mikolaj Kucharski wrote:
> Hi,
>
> Kind reminder. Diff re-attached at the end and on MARC:
>
> https://marc.info/?l=openbsd-tech&m=166219807307308&w=2
I don't understand what your complaint is, because:
-P Attempt to overwrite regular writable files before deleting them.
Martijn van Duren wrote:
> This one got overlooked when all the metrics moved to snmpd_metrics.
>
> OK?
>
> martijn@
>
> Index: Makefile
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/Makefile,v
> retrieving revision 1.21
> diff -u -p
YASUOKA Masahiko wrote:
> Currently the value on VMware may be truncated silently. It's simply
> broken. I think we should fix it by having a way to know if the value
> is reached the limit.
>
> Also I think we should be able to pass larger size of data. Since at
> least on VMware, people is
It's been explained a few times that being up-to-date is not an error.
It's a good thing, and no action is neccessary when up-to-date.
Any non-zero value indicates an error, that would include 2. You are
marking this as an error, when it isn't.
You think this will help your scripting. Do you no
I'm not worried until it gets exposed to userland.
Mark Kettenis wrote:
> Here is a diff that implements EFI runtime services support on amd64
> in much the same way as we already do on arm64. This will be used in
> the future to implement support for EFI variables.
>
> Some initial testing am
I think if we make all the escape options in all the programs changable
via an option -- there will be only one person using it: Klemens Nanni.
This is 2022. This is not a new problem, multi-layer escape with various
characters have been in ssh, cu, tmux, and other things for basicallyt forever.
Marc Espie wrote:
> On Wed, Oct 05, 2022 at 07:54:41AM -0600, Theo de Raadt wrote:
> > Marc Espie wrote:
> >
> > > On Tue, Oct 04, 2022 at 10:15:51AM -0600, Theo de Raadt wrote:
> > > > A note on why this chance is coming.
> > > >
> >
Marc Espie wrote:
> On Tue, Oct 04, 2022 at 10:15:51AM -0600, Theo de Raadt wrote:
> > A note on why this chance is coming.
> >
> > malloc.c (as it is today), does mprotects back and forth between RW and
> > R, to protect an internal object. This object is in bss, i
Masato Asou wrote:
> As you pointed out, it is not a good idea to allocate large spaces
> in kernel.
>
> Would it be better to keep the current fixed length?
>
> Prepare a variable like kern.maxpvbus and default it to
> 4096. Futhermore, how about free() after copyout() to user space?
Sorry I
Looking at these pieces:
+ sc->sc_rpc_buf = malloc(sc->sc_rpc_buflen, M_DEVBUF, M_NOWAIT);
...
+vm_rpc_buf_realloc(struct vmt_softc *sc, size_t len)
+{
+ free(sc->sc_rpc_buf, M_DEVBUF, sc->sc_rpc_buflen);
+
+ sc->sc_rpc_buflen = len / VMT_RPC_BUFLEN * VMT_RPC_BUFLEN;
+ sc->
I think the idea was to do the unveil+pledge before kvm_openfiles, but
I ran into some other difficulty. I wonder if issues remain. It means
someone must play with dead kernels...
Theo Buehler wrote:
> kvm_openfiles() happens before unveil. It opens these files (or falls
> back to defaults), s
If it is empty at the beginning, the operation is free.
Today it is a narrow check for mfs. Tomorrow someone will want to
add tmpfs to this. And next month, some other crazy configuration.
So I do not see the point of this diff, at all.
The find operation is free. The echo doesn't stab you in
A note on why this chance is coming.
malloc.c (as it is today), does mprotects back and forth between RW and
R, to protect an internal object. This object is in bss, it is not
allocated with mmap. With the upcoming mimmutable change, the bss will
become immutable by default, at program load time
David Gwynne wrote:
> On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
> > diskless(8) just needs tftpd(8) to deliver files, none of the possibly
> > untrusted clients are supposed to ever write anything.
> >
> > Either way, even when run without -c, a single file writable by _tftp
Klemens Nanni wrote:
> rarpd(8) is small enough where my impression is that refining it a
> little would be good, but it quickly comes down to personal taste.
And I continue to disagree.
Another example of the same pattern is ifconfig. Here you will see it
is not documented that [-a] is incomp
ok, let's give it a shot then.
And watch for behaviour changes...
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Sat, 01 Oct 2022 09:37:01 -0600
> >
> > Mark Kettenis wrote:
> >
> > > Armv8.4 introduced a feature that prov
The getopt language is imprecise, and attempts to be precise with it
usually go poorly.
For example,
SYNOPSIS
ls [-1AaCcdFfgHhikLlmnopqRrSsTtux] [file ...]
% ls -1AaCcdFfgHhikLlmnopqRrSsTtux
The result may seem surprising. I claim the result is not surprising.
It is unsurprising because
Mark Kettenis wrote:
> Armv8.4 introduced a feature that provides data independent timing for
> data processing instructions. This feature is obviously introduced to
> mitigate timing side-channel attacks. Presumably enabling the feature
> has some impact on performance as it would disable cert
Todd C. Miller wrote:
> On Thu, 29 Sep 2022 23:30:54 -0400, Daniel Dickman wrote:
>
> > > On Sep 29, 2022, at 8:24 PM, Joerg Sonnenberger wrote:
> > >
> > > On Thu, Sep 29, 2022 at 08:39:16PM +1000, Jonathan Gray wrote:
> > >> wc counts items in files. Finding the longest item indeed sounds
Theo de Raadt wrote:
> Theo de Raadt wrote:
>
> > > Yet another version of the diff as I incrementally get it working better.
> > > Call it version 22..
>
> This is around version 30.
New version.
uvm_unmap_remove() now avoids doing entry splits as it scan
Right.
This is called "idiomatic programming".
Sometimes it looks a bit idiotic (haha), but as the years go by, we've
learned that stylistic reminders that a rarely used function's parameter
is a variadic format string, helps us avoid introduction of new mistakes
during future development.
Stuar
This is not helping.
Please send Scott private replies regarding his diff.
Masato Asou wrote:
> Hi,
>
> I have new AMD laptop. The dmesg is posted below:
>
> OpenBSD 7.2 (GENERIC.MP) #2: Mon Sep 26 09:09:17 JST 2022
> a...@hp-obsd.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> re
Scott Cheloha wrote:
> > And it is the wrong time in the release cycle for this.
>
> This doesn't need to make release, I'm just gauging interest and
> testing code.
But you didn't say that in your email.
But Worse, you didn't think that you need to say it.
> And it is the wrong time in the release cycle for this.
No kidding.
As this makes absolutely no difference for any existing code in 7.2,
except the strong hazard of accidentally breaking a machine.
This change fixes another wart in unveil/pledge which wasn't resolved in
the original design. pledge allows bypass-reading of
/usr/share/zoneinfo/ files for TZ=zone but absolute path support
remained a wart.
Once again, we have to remove a rarely used behavior of libc.
During pledge and unveil
Florian Obser wrote:
> On 2022-09-19 22:27 +02, Hrvoje Popovski wrote:
> > Hi all,
> >
> > when doing sysupgrade few minutes ago on multiple machines i'm getting
> > error in subject
> >
> > smc24# sysupgrade -s
> > Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/
> > SHA256.si
Paul Janzen wrote:
> My issues with the time system are (a) it has to "just work", so it flees
> to UTC the instant something goes wrong, but never makes available any
> status as to whether the asked-for time zone is the one returned, except
> for (b) my program aborts if I'm pledged and I go do
Paul Janzen wrote:
> Yeah, I know with pledge() you can't do testing like
> TZ=:/home/pjanzen/dev/usr/share/zoneinfo/testing/2022/America/Kentucky/Monticello
> any more, even though that's a perfectly cromulent and functional TZ on my
> system otherwise. So for the time being, probably any TZ tha
> thing inside !SMALL_KERNEL
Is that neccessary?
Because arm64 has no limitation on bsd.rd size
Theo de Raadt wrote:
> > Yet another version of the diff as I incrementally get it working better.
> > Call it version 22..
This is around version 30.
There is still a subtle problem with RELRO, but it is masked with a hack.
arm64 also works correctly, and I'm onto the
Theo de Raadt wrote:
> Theo de Raadt wrote:
>
> > Theo de Raadt wrote:
> >
> > > In this version of the diff, the kernel manages to mark immutable most of
> > > the main binary, and in the shared-binary case, also most of ld.so. But
> > >
Theo de Raadt wrote:
> Theo de Raadt wrote:
>
> > In this version of the diff, the kernel manages to mark immutable most of
> > the main binary, and in the shared-binary case, also most of ld.so. But it
> > cannot mark all of the ELF mapping -- because of two remain
Theo de Raadt wrote:
> In this version of the diff, the kernel manages to mark immutable most of
> the main binary, and in the shared-binary case, also most of ld.so. But it
> cannot mark all of the ELF mapping -- because of two remaining problems (RELRO
> in .data, and the m
Florian Obser wrote:
> On 2022-09-01 09:55 -06, "Theo de Raadt" wrote:
> > Job Snijders wrote:
> >
> >> On Thu, Sep 01, 2022 at 03:14:40PM +0200, Martin Schröder wrote:
> >> > Am Do., 1. Sept. 2022 um 05:38 Uhr schrieb Job Snijders
> >&
Job Snijders wrote:
> On Thu, Sep 01, 2022 at 03:14:40PM +0200, Martin Schröder wrote:
> > Am Do., 1. Sept. 2022 um 05:38 Uhr schrieb Job Snijders :
> > > Some ps(1) implementations have an '-d' ('descendancy') option. Through
> > > ASCII art parent/child process relationships are grouped and di
In the last few years, I have been improving the strictness of userland
memory layout.
An example is the recent addition of MAP_STACK and msyscall(). The first one
marks pages that are stack, so that upon entry to the kernel we can check if
the stack-pointer is pointing in the stack range. If it
Sure.
Klemens Nanni wrote:
> Noticed by mistake (wanted `-l'):
>
> # vnconfig l
> vnd0
> vnconfig: VNDIOCSET: No such file or directory
>
> Same happens if you try to load a bogus file:
>
> # vnconfig ./empty
> vnd0
> vnconfig: VNDIOCSET: Input/output
I would really prefer if this did not need floating point.
>From owner-tech+m90...@openbsd.org Mon Aug 29 03:52:24 2022
>Delivered-To: dera...@cvs.openbsd.org
>Date: Mon, 29 Aug 2022 11:47:16 +0200
>From: =?utf-8?B?0L3QsNCx?=
>To: Stuart Henderson
>Cc: tech@openbsd.org
>Subject: Re: [PATCH] Corr
Jonathan Gray wrote:
> On Fri, Aug 26, 2022 at 10:21:32PM -0500, Scott Cheloha wrote:
> > I noticed that on non-LAPIC systems we program channel 0 in periodic
> > mode with an initial count of 11932 to effect a 100hz clock interrupt.
> > And then we also use that same channel to count time, but b
Jonathan Gray wrote:
>> What difference does it make? We don't use counter 1.
>
> The PCH datasheets from 100 series and later only document counter 0
> and counter 2.
>
> 9 series and earlier datasheet has
> "The PCH contains three counters that have fixed uses."
> 100 series and later
> "The
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Fri, 26 Aug 2022 09:53:35 -0600
> >
> > Klemens Nanni wrote:
> >
> > > On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > > > On 2022/08/26 09:49, Kle
Klemens Nanni wrote:
> On Fri, Aug 26, 2022 at 04:15:43PM +0100, Stuart Henderson wrote:
> > On 2022/08/26 09:49, Klemens Nanni wrote:
> > > grep and CVS agree that this is a switch(4) left-over.
> > >
> > > OK?
> >
> > This is exported to userland isn't it?
>
> No, everything is under _KERNEL
Klemens Nanni wrote:
> On Thu, Aug 25, 2022 at 07:07:27PM +, Miod Vallat wrote:
> > > Well, something tells me the inclusion of the manual pages for fdisk
> > > and disklabel is deliberate. Makes some sense as these are complex
> > > utilities and their interactive use is documented in those
Wow you have it so backwards.
So we will have embedded manuals for the case we don't need need the
embedded manual because you have manuals installed (type ^Z and run man)
but in the systems where you don't have manual pages, you won't have
the embedded manuals.
Very logical to forget why this wa
I think you have this wrong.
If someone is operating in the install media, and manually adjusting
their disk, and they don't know the commands they need, where are they
going to find the instructions?
In 1997, we added the embedded manual pages to fdisk (inside the
'manual' command) and disklabe
Klemens Nanni wrote:
> Dynamic installboot would be nice but I don't have strong opinoins about
> it, so best drop the diff and retain the chance to repair your system.
These are the static binaries:
./libexec/ld.so/ldconfig
obvious why
./sbin/dhcpleased
./sbin/iked
./sbin/isakmpd
./sb
This binary being static has nothing to do with "installer testing".
You've got that completely wrong. It has nothing to do with reacharounds
either, since instbin takes care of all that.
It has to do with people who may want to use it when their systems are
broken in some way, to repair their sy
Theo Buehler wrote:
> > > + if (pemmode) {
> > > + if (pledge("stdio rpath", NULL) == -1)
> > > + err(1, "pledge");
> > > +
> > > + if (argc > 1)
> > > + goto usage;
> >
> > This should be argc > 0 to match your synopsis.
>
> Ugh. I confused mysel
argv += optind;
argc -= optind;
+ if (pemmode) {
+ if (pledge("stdio rpath", NULL) == -1)
+ err(1, "pledge");
+
rpki-client is starting to develop quite a number of run-time "modes".
I think it is time to add some checks (right around ar
Josuah Demangeon wrote:
> Jonathan Gray wrote:
> > Index: usbdevs
> > ===
> > RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> > retrieving revision 1.747
> > diff -u -p -r1.747 usbdevs
> > --- usbdevs 23 Jun 2022 00:31:37 - 1.74
Jonathan Gray wrote:
> Index: usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.747
> diff -u -p -r1.747 usbdevs
> --- usbdevs 23 Jun 2022 00:31:37 - 1.747
> +++ usbdevs 23 Aug 2022 14:39:2
Jonathan Gray wrote:
> >
> > I could recompile and see the device listed as ugen(4):
> >
> > $ dmesg | grep pico-debug
> > ugen1 at uhub4 port 2 "pico-debug CMSIS-DAP" rev 1.10/10.05 addr 2
>
> "Peter Lawrence CMSIS-DAP Dapper Miser" is a rather large string
> especially as the device alre
Stuart Henderson wrote:
> > > .Nm
> > > will hash the nwid along with the passphrase to create the key.
> > > +If a passphrase contains one or more whitespaces, it can be surrounded
> > > +by double quotes.
>
> The same applies for nwid, pppoekey, descr, pass (carp).
>
> The place this is nee
Hi,
Do you recommend we do the same in the cat manual page, regarding filenames?
Or for that matter, in hundreds of other manual pages.
Unix does whitespace-seperated tokenization, nearly everywhere, so I
do not think this needs to be documented.
Florian Viehweger wrote:
> Hi,
>
> this is a
Miod Vallat wrote:
> Come to think further about it, I think it is better for diskmap to
> always trust disk drivers to either :
> - not have any label (dk_label == NULL, or points to zeroed memory)
> or
> - have a valid label (duid is not zeroes).
What is the result if root runs disklabel, and
Because there is a hope someone will fix it.
Solène Rapenne wrote:
> hi
>
> is there a reason to keep mount_tmpfs available while it's deactived in
> the kernel?
>
> Index: sbin/Makefile
> ===
> RCS file: /cvs/src/sbin/Makefile,v
Scott Cheloha wrote:
> On Wed, Aug 10, 2022 at 12:26:17PM -0600, Theo de Raadt wrote:
> > Scott Cheloha wrote:
> >
> > > We're sorta-kinda circling around adding the missing (?) stdio error
> > > checking to other utilities in bin/ and usr.bin/, no? I wan
Scott Cheloha wrote:
> We're sorta-kinda circling around adding the missing (?) stdio error
> checking to other utilities in bin/ and usr.bin/, no? I want to be
> sure I understand how to do the next patch, because if we do that it
> will probably be a bunch of programs all at once.
This speci
There have to be some strict-aligned architectures which don't emulate
unaligned access, because there will always be architectures which have
a high emulation cost, and I'm ok with alpha joining that group.
Miod Vallat wrote:
> The alpha part contains code in the kernel to handle unaligned mem
Klemens Nanni wrote:
> On Fri, Aug 05, 2022 at 05:08:14PM +0200, Claudio Jeker wrote:
> > We added the inline functions for these typecasts to add a minimal level
> > of error protection. Now where do we hit const problems? I have not seen
> > such issues and I wonder if those just come from ove
Todd C. Miller wrote:
> On Sat, 06 Aug 2022 02:19:31 +0200, Jeremie Courreges-Anglas wrote:
>
> > This seems fair, but maybe we should just zap the type from sys/types.h and
> > define it only in sys/blist.h, as done in DragonflyBSD?
>
> Fine with me. It is a non-standard type not used by base
Alexander Bluhm wrote:
> On Fri, Aug 05, 2022 at 09:03:03AM -0600, Theo de Raadt wrote:
> > But I also disagree with the idea of wrapping a trivial piece of C into
> > a function located in another header file
>
> I added many of them a few years ago. We have them for all
Klemens Nanni wrote:
> satosin(), sin6tosa(), etc. are convenient helpers to avoid manually
> casting all over the place.
>
> struct sockaddr aka. sa, struct sockaddr_in6 aka. sin6, etc. are well
> known abbreviations in networking code.
Your diff does not touch satosin.
You are mentioning the
Andre Stoebe wrote:
> So I added unveil and removed the limitation on forward slashes as well
> as symbolic links when using the -d option. I believe (please correct me
> if I'm wrong) these limitations were added to prevent breaking out of
> the directory while keeping the code simple. With unve
I struggle to see any value of this concept: If you put a cast in-line
in the code, as a coder you can know what it means. But if you abstract
the typecast to some function in a header file, how do you remember
that it only does a typecast, and doesn't do something else? I think this
is a foolis
Bryan Steele wrote:
> On Fri, Aug 05, 2022 at 03:37:41AM +0200, Theo Buehler wrote:
> > On Fri, Aug 05, 2022 at 03:34:57AM +0200, Theo Buehler wrote:
> > > If you want games, opt into it. They are very old, full of bugs and not
> > > really maintained. It's very easy to get a PATH containing game
Bryan Steele wrote:
> On Fri, Aug 05, 2022 at 03:37:41AM +0200, Theo Buehler wrote:
> > On Fri, Aug 05, 2022 at 03:34:57AM +0200, Theo Buehler wrote:
> > > If you want games, opt into it. They are very old, full of bugs and not
> > > really maintained. It's very easy to get a PATH containing game
Theo Buehler wrote:
> On Thu, Aug 04, 2022 at 07:11:40PM -0600, Theo de Raadt wrote:
> > And anyways, this directory is not in $PATH by default, so there is no
> > risk.
>
> Unless you create a user during install in which case /etc/skel will
> give you a $PATH c
luci...@bronze.ctrl-c.club wrote:
> t...@theobuehler.org wrote:
> >I have no strong opinion. I'm fine with either approach. It's such a
> >silly program...
> >
> >As an aside, random -e has been completely broken (it's non-uniform)
> >since forever. To fix -e, we should clamp denom to an integer
luci...@bronze.ctrl-c.club wrote:
> Another way to solve this problem would be to trim the numbers with
> something like this: if (denom > UINT32_MAX) denom = UINT32_MAX.
And then document that the program returns incorrect results?
> >However, using drand48() will mean using a floating point mo
I think you intend for that to be two seperate diffs, not merged into one.
For connect < 15 seconds, I think that is a bit strict.
For IO stalling 15 seconds, I suspect such IO stalls happen more than we
know, and will do harm to RPKI processing results.
I don't see any way this can be tested in
201 - 300 of 1277 matches
Mail list logo
