I disagree.
"dstsize" is conceptually easier for readers to understand.
Secondly, there is nothing which says the library code has to match the
manual page. Implementation does not need to match documentation.
Emil Engler wrote:
> Hello tech@,
> currently the man-page for strlcpy(3) and strl
Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.29 15:34:15 +0200:
> > Like for rsync repos files in the RRDP repos should be delayed until after
> > the validation finished. As with anything RPKI related there is little
> > trust in the repositories and their abiliti
> I failed to find a case where to use SYSCTL_INT_UNBOUNDED. We always
> find better "common sense" limits than completely unconstrained.
I agree. There must always be a bound.
Claudio Jeker wrote:
> > So, that would suggest some sort of lockout against running multiple
> > rpki-client with the correct termination strategy. I don't believe we
> > have such a thing right now. We have the timeout, to ensure rpki-client
> > doesn't run too long which may prevent simultan
Christian Weisgerber wrote:
> Marc Espie:
>
> > I would also actually be fairly happy if we changed drastically the way
> > sh(1) and ksh(1) look. To me, sh(1) should be the (more or less) standard
> > shell documentation, AND ksh(1) should contain the differences/extensions.
>
> I think that i
Edgar Pettijohn wrote:
> slight wording change. it doesn't return these values it sets errno to
> these values...
.Fn recv
and
.Fn recvfrom
-may return the following error:
+may fail if:
.Bl -tag -width Er
.It Bq Er EINVAL
.Fa len
I think it is more accurate the way it is, rather than cop
Luigi30 wrote:
> I noticed that timezone paths in the installer step that sets the system
> timezone are case-sensitive to match the paths in /usr/share/zoneinfo.
> (Specifically, it's set_timezone() in /usr/src/distrib/miniroot/install.sub.)
>
> It seems like the behavior should be more like:
>
Isn't a majority of this already in the manual page?
Or alternatively, does your attempt to create a FAQ entry indicate that
the manual page is weak or unsuitable?
> There has been a lot of interest in WireGuard on the OpenBSD subreddit. So
> here
> is a patch that provides a few basic example
;
> Section of manpage:
> EXAMPLES
> Create two wg interfaces in separate rdomain(4)s, which is of no
> practical use but demonstrates two interfaces on the same machine:
>
> On Sun, May 02, 2021 at 09:25:21AM -0600, Theo de Raadt wrote:
> > Isn't a ma
Showing the symbolic name is not doing anywhere else in the tree.
Most likely they should be
err(1, "unveil: %s", path);
Ashton Fagg wrote:
> Ashton Fagg writes:
>
> > Hi all,
> >
> > I saw a discussion on here a while ago about the use of patterns like:
> >
> > if (unveil(some_p
Florian Obser wrote:
> In this hunk alone you have three out of five and you log them all
> differently. I think this should be unified as
> fatal("unveil(\"%s\", \"%s\")", _PATH_RESCONF, "wc");
> fatal("unveil(\"%s\", \"%s\")", /etc/resolv.conf.tail, "r");
> fatal("unveil(\"%s\
Theo de Raadt wrote:
> Florian Obser wrote:
>
> > In this hunk alone you have three out of five and you log them all
> > differently. I think this should be unified as
> > fatal("unveil(\"%s\", \"%s\")", _PATH_RESCONF, "wc"
Job Snijders wrote:
> AS38971,178.57.71.0/24,24,ripe,2021-05-04T05:39:30Z
This time format is human readable, but these files are largely part
of the machinery. And now they need expensive parsing when used.
Are you sure this shouldn't be an integer since the epoch?
Ashton Fagg wrote:
> On Mon, 3 May 2021 at 10:17, Theo de Raadt wrote:
> > So if the messages were just 'unveil %s: error' or 'unveil: %s: error'
> > I would be thrilled, as this allows users to realize why the program is
> > not working right.
>
Job Snijders wrote:
> @@ -24,15 +24,16 @@ output_csv(FILE *out, struct vrp_tree *v
...
> +
> + if (fprintf(out, "AS%u,%s,%u,%s,%lld\n", v->asid, buf,
> + v->maxlength, v->tal, v->until) < 0)
> return -1;
This needs a cast from time_t to long long
Stuart Henderson wrote:
> Every new entry in this file reduces the range available for dynamic
> port selection, so it would seem a good idea to cull a few if we're
> adding some. Here are some likely candidates;
Precisely.
And one day there will be no reserved ports left, and then what?
Makes sense to me.
Job Snijders wrote:
> I'd like to modify our JSON format, many people in the community have
> voiced complaints that transforming the string to an integer is
> annoying.
>
> This won't break existing deployments coupled with GoRTR.
>
> OK?
>
> Index: output-json.c
> ==
I would like a further justification for removing these ports from
the very limited dynamic reserved space used by bindresvport.
(but not by rresvport, which appears still stomp over them)
For tcp, 32 of the 512 are locked out.
For udp, 19.
What software is actually using these ports?
Is that s
Jan Klemkow wrote:
> On Wed, May 05, 2021 at 12:18:43PM -0600, Theo de Raadt wrote:
> > I would like a further justification for removing these ports from
> > the very limited dynamic reserved space used by bindresvport.
> >
> > (but not by rresvport, which ap
I'm confused.
Who has a free() that clobbers errno?
Claudio Jeker wrote:
> Noticed while looking at the same version in rsync. free() may clobber
> errno so better save the value before calling free().
> Also update the comment, remove all those arguments I removed :)
>
> --
> :wq Claudio
>
Jan Klemkow wrote:
> > > > I'm working on a diff to bring ftps with libtls into our ftpd(8). There
> > > > is a "getaddrinfo(NULL, "ftps", &hints, &res0)" call, which uses this
> > > > port. Thus, I made this change.
> > >
> > > Hang on -- does the world want ftps support?
>
> I don't know, w
Ashton Fagg wrote:
> The committed diff fixes my original problem. However, I've now
> encountered another one. On one of my machines (far slower than the
> first one), the devices themselves are much slower to attach - this
> leads to the same race condition as before, as "iscsictl reload" is on
Ashton Fagg wrote:
> On May 11, 2021, at 22:53, Theo de Raadt wrote:
> > This is because the design of hotplug is completely broken.
>
> Thank you, Theo, for the comprehensive reply. This was just the sort of
> feedback I’d hoped to get.
>
> Ok so we have established
Nicer than the garble...
It would be nice if we could see all the panics. Could we also have a
per-cpu panic buffer, and then adapt ddb to show them all?
Scott Cheloha wrote:
> In a separate mail thread, bluhm@ mentioned that panic(9) does not
> cleanly handle multiple CPUs entering it simulta
I guess this diff would skip sending the early events. You don't show how
it is used, in which drivers it is used, nor how they are modified to send
replacements for the skipped messages.
And then you would modify specific drivers to not send the early events,
and instead use an additional API fo
+ if (pledge("stdio rpath inet recvfd sendfd "
+ "wpath cpath proc tty getpw", NULL) == -1)
Please change the order:
stdio rpath wpath cpath inet recvfd sendfd proc tty getpw
(It remains extremely permissive).
Claudio Jeker wrote:
> I don't think httpd should handle rdomain in its config but instead you
> should run multiple httpd processes one for each rdomain.
> Not every daemon needs to support running in multiple rdomains at once.
I agree with you Claudio.
This in particular is what lost me:
> >
Stuart Henderson wrote:
> System calls are not a stable interface in OpenBSD.
system calls are stable API.
The syscall numbers are not stable ABI.
The parameters of syscall() are very much not stable, syscall() is not
API access, it is an interface noone should use, as can be witnessed by
our
Why would anyone care about that stupid decision?
This function is never going to be deleted from the namespace because
it is critical, and the alternatives offered will continue to be less
portable beyond the lifespan of the people who made that irrelevant
and uneducated decision.
But more to th
Without proof it is required, no.
Raf Czlonka wrote:
> Hello,
>
> Pretty self-explanatory - add "SHARKOON Technologies GmbH" vendor ID.
>
> Regards,
>
> Raf
>
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/u
But does it matter?
It adds sizeof pointer + 28 bytes to every OpenBSD kernel.
I have seriously considered deleting usbdevs device-naming support,
because the cost keeps growing without bound.
Raf Czlonka wrote:
> On Mon, May 24, 2021 at 04:00:20PM BST, Theo de Raadt wrote:
> > With
Raf Czlonka wrote:
> On Mon, May 24, 2021 at 04:10:00PM BST, Theo de Raadt wrote:
> > But does it matter?
>
> Did this[0] matter?
If you aren't curious enough to read the Makefile, devlist2h.awk,
usbdevs.h, and usbdevs_data.h to recognize the full production
of your chang
Scott Cheloha wrote:
> On Sat, May 22, 2021 at 01:35:53AM +0200, Alexander Bluhm wrote:
> > On Fri, May 21, 2021 at 02:00:54PM -0500, Scott Cheloha wrote:
> > > Given all of this, would it be better if secondary CPUs spin in
> > > panic(9) instead of trying to print anything?
> >
> > The panic c
Scott Cheloha wrote:
> On Mon, May 24, 2021 at 10:12:53PM -0500, Scott Cheloha wrote:
> > On Sat, May 22, 2021 at 01:35:53AM +0200, Alexander Bluhm wrote:
> > > On Fri, May 21, 2021 at 02:00:54PM -0500, Scott Cheloha wrote:
> > > > Given all of this, would it be better if secondary CPUs spin in
>
Scott Cheloha wrote:
> > If the 2nd cpu to enter panic actually has a more relevant panic, now
> > it will be missed.
>
> I said we could keep the printing. I even
> kept the printing in my latest patch. So I
> don't know what you're arguing against
> here.
You start spinning cpus inside panic
Alexander Bluhm wrote:
> On Tue, May 25, 2021 at 04:15:26PM +0200, Mark Kettenis wrote:
> > Wouldn't be too hard. But unless you're on a serial console, that
> > will probably be more than a screenful of information, so not terribly
> > useful.
>
> The most important things must fit on the firs
gwes wrote:
> On 5/25/21 10:26 AM, Theo de Raadt wrote:
> > Alexander Bluhm wrote:
> >
> >> On Tue, May 25, 2021 at 04:15:26PM +0200, Mark Kettenis wrote:
> >>> Wouldn't be too hard. But unless you're on a serial console, that
> >>> wil
Why does anyone require this functionality?
(minus the irony the additional feature is coming from a "slimmed" clone)
Paul Spooren wrote:
> To know the fingerprint used for a sec/pub/sig the option `-F` is added
> which works in combination with `-s`, `-p` or `-x`. It will load the
> file and a
Frederic Cambus wrote:
> Does this look reasonable?
>
> If it does and if we want to go this way, I can try to build a release
> and check if MINIROOTSIZE must be bumped on RAMDISK_CD. Then we could do
> the same for i386, armv7 and arm64.
We need to see these results first.
I am satisfied.
That is one architecture. I suggest checking which others can use
the same treatment.
Frederic Cambus wrote:
> On Mon, May 31, 2021 at 12:57:47PM +0200, Mark Kettenis wrote:
>
> > > +option FONT_SPLEEN8x16
> > > +option FONT_SPLEEN12x24
> > > +option
> This is also because communication with the device uses ASN.1-like
> structures, and that complexity should maybe not be part of the kernel.
I actually think this should all be in the driver. I think the wrong
decision was made of turning this into a /dev/ interface.
In the end, the object par
Josh Rickmar wrote:
> I figure that the manpage is probably the more consulted reference,
> and the order that is preferred, so the patch below reorders the
> promise names in pledge.h to match.
The current array was value-sorted (by the bit value) to allow binary
search. However no code is act
I would argue for deleting that code.
A flag for el_set which *allows it* might work for me, but I anticipate
this is a crazy feature that programs using the library would not expect,
and the risks of abuse are clear.
Leon Fischer wrote:
> The editline(7) library has a little known feature: vi-
Leon Fischer wrote:
> On the other hand, users could also bind it themselves in ~/.editrc and
> trigger pledge(2) violations in programs not designed for it. It won't
> be obvious to them why their shiny feature wouldn't work.
Let me explain the future.
Pledge is now almost 6 years old, and it
I think we should go with Josh's original diff, without the commentary.
I'll commit.
As for the entries not documented in the manual page, the process goes
like this:
1. grep the tree for the programs that use it
2. read kern_pledge.c or lower-level code to find out what operations
are permitt
Regarding the vmm chunk -- as I said in my other reply, these
explanations are too precise. They risk becoming outdated as things
change. Furthermore, some of those ioctl may work in one way, but not
another way. Which would be too complicated to describe also. I urge
simple messaging:
.It Va
Dave Voutila wrote:
> Theo de Raadt writes:
>
> > Regarding the vmm chunk -- as I said in my other reply, these
> > explanations are too precise. They risk becoming outdated as things
> > change. Furthermore, some of those ioctl may work in one way, but not
> >
dz...@disroot.org wrote:
> Currently, if an unveiled process execs another program, it doesn't
> inherit the unveil paths. This means that if the unveiled process
> hasn't pledged itself out of the exec syscall and it has a suitable
> binary inside of its paths, it can trivially bypass unveil. Her
dz...@disroot.org wrote:
> If there isn't - what about changing the kernel so unveiled paths persist
> between execs? That would allow very easy container-like sandboxing.
This last sentence bothers me a lot, I am extremely jaded having heard the
same ideas over and over and over.
"very easy" is
dz...@disroot.org wrote:
> > "Theo de Raadt" wrote:
> > If it is a shared executable, you would need to encode access to ld.so
> > and all the library environment, and additional strange things used
> > during libc initialization for various subsystems.
> &g
The expected uses of unveil and pledge aren't some weird fiction
of "oh look I can use them wrong".
The interesting cases are when pledge and unveil are used correctly,
which means they reduce control or access to objects.
This is expecially true around pledge "proc exec".
Say you have program1
dz...@disroot.org wrote:
> > If you use "exec", you have intentionally and visibly opened an escape
> > hatch to run other programs, which are EXPECTED to self-protect against
> > their own misbehaviour.
> Yet, the documentation doesn't warn about it. It's an easy mistake to make.
> Let's say that
dz...@disroot.org wrote:
> June 15, 2021 2:51 PM, "Theo de Raadt" wrote:
> > "attacker"?
> Isn't the purpose of pledge() and unveil() to prevent a person with
> a code execution bug from damaging the system?
No, the purpose is to declare the bounds of
Having fewer versions of software is not neccessarily a plus.
It is easily considered a negative.
enh wrote:
> it's perhaps worth mentioning in the "pros" column that toybox (a
> 0BSD-licensed busybox which provides most of /bin on Android, which i
> maintain) and busybox both use Gavin's bc/d
enh wrote:
> heh. while i know what Theo means -- and his is also a valid philosophical
> standpoint -- this kind of thing is one reason why i personally prefer
> fewer implementations of things and more shared code between them :-)
>
> at least it leads to more consistency, and to having fewer
Scott Cheloha wrote:
> I want to improve the alarm(3) manpage. Here's a first attempt:
>
> - Correct the initial behavior description. alarm(3) does not "wait".
> It schedules signal delivery at a point in the future.
you are right about this.
> The
> .Fn alarm
> +function causes the async
Scott Cheloha wrote:
> On Fri, Jun 18, 2021 at 09:15:31AM -0600, Todd C. Miller wrote:
> > On Tue, 15 Jun 2021 20:22:53 -0500, Scott Cheloha wrote:
> >
> > > After that is committed, I'm unclear whether alarm(3) can fail anymore
> > > on OpenBSD. The only remaining plausible failure case I can
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 12:13:54 -0600, "Theo de Raadt" wrote:
>
> > I don't understand what you are solving.
> >
> > The way I look at it... you want to convert one kind of bug into a
> > different kind of bug?
> >
&g
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 12:02:18 -0600, "Theo de Raadt" wrote:
>
> > But I dislike this text since it doesn't speak to the underlying
> > mechanism.
> >
> > The
> > .Fn alarm
> > function configures the process
> &
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 16:02:20 -0500, Scott Cheloha wrote:
>
> > If we're going to just return an arbitrary value shouldn't we keep
> > returning UINT_MAX as we always have? This would preserve compat with
> > the other BSD libc implementations, too.
>
> I think that a re
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 15:05:52 -0600, "Theo de Raadt" wrote:
>
> > Without considering the cases where an incorrect value is passed in...
> >
> > How many pieces of code have you found that inspect the return value?
>
> Very fe
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 15:17:47 -0600, "Theo de Raadt" wrote:
>
> > OK. How any pieces of code were found which do that?
> >
> > I mean, code search for ' = alarm('
>
> In our tree? Just ksh.
>
> static void
&
Please don't turn current.html into a series of essays.
At most, the chunks in this page should highlight that something has changed.
What has changed? Keep it simple. People should be taught to re-read the
updated manual page. Thus the manual pages should be accurate.
Using current.html as a
Jason McIntyre wrote:
> hi.
>
> diff to reduce verbosity in flex/lex usage. before:
This seems better. Rather than telling people to run --help, which is
now usage(), just run usage(). Also usage() does not need to exit(),
since all calls to usage() are followed by FLEX_EXIT().
[This is a cr
Alexander Bluhm wrote:
> On Wed, Jun 23, 2021 at 11:40:18AM +0200, Martin Pieuchot wrote:
> > Our previous attempt [0] to replace the current select(2) implementation
> > has been reverted due to non-acceptable latency increase on sockets [1].
>
> I have measured the performance difference.
>
>
Visa Hankala wrote:
> On Thu, Jun 24, 2021 at 07:02:11PM +, Mickael Torres wrote:
> > Hello,
> >
> > On the risc-v SiFive Unmatched the internal cad0 ethernet interface stops
> > working randomly after some packets are sent/received. It looks like it's
> > because the bus_dmamap used isn't
Mark Kettenis wrote:
> > I am surprised that this has not been raised before. I also wonder if
> > riscv64's DMA constraints are fully sane.
>
> There is no DMA constraint on riscv64 yet. We try to avoid having
> such a constraint on platforms that don't have a long history, hoping
> those plat
> But i think editline(3) code quality is insufficent for use in a
> shell. It's all quite messy and hastily and sloppily written.
I also mistrust it. It may be tempting to use a library, but the shell
is quite standalone code, and benefits from internal purpose-built code.
>Uh, oh, to my naive ears (naive with respect to matters of time-related
>functions), this sounds like a typical case where we likely want one
>manual page documenting both alarm(3) and ualarm(3), not two pages.
>
>Basically, the rule of thumb is: if two functions have a very similar
>purpose, shar
Todd C. Miller wrote:
> > I think it would be ideal for the manual page text to state
> > which values can be used in a *portable* way. If, for some reason,
> > that is not desirable, then the main text should say which values
> > can be used on OpenBSD, and STANDARDS should say that using value
Todd C. Miller wrote:
> On Thu, 01 Jul 2021 00:14:12 +0200, Ingo Schwarze wrote:
>
> > Can the current wording below CAVEATS, "confusing behavior", be made
> > more precise, explaining what actually happens rather than merely
> > calling it "confusing"? For example, saying that they all overrid
Scott Cheloha wrote:
> FWIW, the manpage has literally always led with this bolded
> implementation detail. From January of 1986:
>
> https://svnweb.freebsd.org/csrg/lib/libc/gen/ualarm.3?revision=25789&view=markup
I'm just saying it is uninformative and distracting.
> ... specifically, setit
Scott Cheloha wrote:
> > +Exceedingly large timing arguments are succeptable to truncation.
> >
> > Rough warning feels like it is enough.
>
> Do you mean truncation or overflow?
Maybe, once again, accurately explain the problem.
Exceedingly large timing arguments will perform incorrectly due
Calling more than one of the interfaces setitimer(2), alarm(3),
and ualarm(3) in the same program results in unspecified behaviour.
I don't think it is unspecified. It will behave precisely as
expected...
I disagree with this change. I don't see that specific indent as
prevailing. But more importantly, the specification is overly
proscriptive.
Developers type a variety of things in their variable declaration
blocks, some of this is due to editor assist, and being exceedingly
strict about a few sp
Claudio Jeker wrote:
> I know that golang has its definition of uvmexp and so if you change the
> ABI then you would break at least that. struct uvmexp is used more often
> than we would like.
It is a huge ABI change. If we are going to change the size of the subunits,
we have to get it right
Alexander Bluhm wrote:
> pledge(2) and so_state SS_DNS are special. There is no real risk
> of a race and the flag is set only at socket creation.
Yes, this looks safe to me. ps_flags PS_PLEDGE and ps_pledge are only
set inside locked pledge(), which makes the pledge_socket() SS_DNS check
non-
> This diff is an attempt to make identifying audio devices easier by
> giving each device a human-readable description that can be read from
> userspace (and without scraping dmesg).
But why does anyone want that?
Isn't everyone served best when there is a public portable interface,
and all the
Job Snijders wrote:
> A use case could be running rpki-client more frequently than once an
> hour:
I want to say I think running rpki-client so often is misguided for
these rpki-processing-on-the-router configurations.
rpki-processing-on-the-router seems like more a technology demonstration
tha
Theo de Raadt wrote:
> It will do 5 minutes of compute, 15 minutes of pause, and do it all
> again.
A recent rpki-client took longer:
# Processing time 989 seconds (199 seconds user, 155 seconds system)
So that would be 6 minutes cpu, over 16 minutes elapsed.
Followed by a 15 minute
stolen data wrote:
> After reading the man pages of the replacements for dhclient(8) it looks
> like it will no longer be possible to prevent DNS entries in a DHCP offer
> from ending up in the resolv.conf - as is practically always the case with
> a residential Internet connection with DHCP. I d
I think this is excessively verbose for such a simple function, especially
the addition of examples.
There are many APIs which are hundreds of times more complicated which
don't have this level of detailing, and I would argue such manual pages
have the correct tone and complexity.
It stops feeli
> [EFAULT] foo points outside the process's allocated address space.
>
> But i don't really i like that. The word "allocated" makes me wonder
> because it sounds too much like malloc(3) for my taste.
> Usually, pointers to automatic and to static objects are acceptable,
> too, and are those "all
Scott Cheloha wrote:
> I'm not wed to keeping all the examples. What if we merge examples 1
> and 2 and dumb the result down a bit?
Are you teaching people how to fill a structure, how to perform a loop,
or that they need to check errno?
I don't see the point of having any example.
Do we need
If you delete this, people's ntpd will fail to start.
getopt will fail to match, drop into usage, and fail.
It is way too early to cause that problem. Couple more years I think.
Klemens Nanni wrote:
> On Mon, Jul 12, 2021 at 09:08:59PM +, Klemens Nanni wrote:
> > deraadt neutered these
This is a lot of fuss.
How many bugs have you found relating to this issue?
Let me guess: zero?
Scott Cheloha wrote:
> On Sun, Jul 25, 2021 at 08:15:34AM +0100, Jason McIntyre wrote:
> > On Sat, Jul 24, 2021 at 10:39:49PM -0500, Scott Cheloha wrote:
> > > Okay, the nanosleep.2 changes are
Scott Cheloha wrote:
> On Sun, Jul 25, 2021 at 01:35:19PM -0600, Theo de Raadt wrote:
> > This is a lot of fuss.
> >
> > How many bugs have you found relating to this issue?
> >
> > Let me guess: zero?
>
> Right, that's why I'm asking if we n
Scott Cheloha wrote:
> Given this, I want to tell the reader, roughly:
>
> "hey! it's plausible there is a SIGALRM-based sleep() implementation
>using still floating around out there in the wild. If you find one,
>you'll want to avoid using it because there are unfixable
Klemens Nanni wrote:
> With the current wording, I'd either expect usage error when passing
> `-o output' or more wording explaining the behaviour when fetching
> multiple files.
>
> Usage error seems wrong since our synopsis explicitly allows it, but
> writing the contents behind multiple URLs
Todd C. Miller wrote:
> I really don't like "get or set the UTC time" in the NAME section.
> It's not like we have a "get or set the local time" function.
> I would prefer if you left the UTC information for the DESCRIPTION.
I agree.
Excessive obvious detail detracts from simple points.
Stuart Henderson wrote:
> On 2021/08/01 12:57, Gregory Edigarov wrote:
> > Hello Everybody,
> >
> > The very minimal change to make it work correctly:
>
> Running configuration twice on all interfaces is not 'very minimal' and
> could easily cause more problems than it solves.
No kidding.
>
Joerg Sonnenberger wrote:
> On Tue, Aug 03, 2021 at 01:12:54AM +0300, Vitaliy Makkoveev wrote:
> > Index: sbin/iked/types.h
> > ===
> > RCS file: /cvs/src/sbin/iked/types.h,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 types.h
Vitaliy Makkoveev wrote:
> > ssh_packet_need_rekeying() appears to have some nice decisions. The
> > idea is to rekey based upon time, primarily.
>
> It does the same: the two limits and rekying starts when you exceeded
> any of them. But in the ssh case we have no massive traffic load, so we
>
Theo Buehler wrote:
> > hmac-md5 might not be vulnerable, but snmp doesn't use pure hmac-*; in
> > the case of md5 and sha1 it strips the result back to 12 bytes (for
> > sha256 it's 24 bytes). I'm not saying that is insecure because of it; I
> > haven't seen any research on the truncation of HMA
Martijn van Duren wrote:
> What about something like the phrasing below? It puts a heavy emphasis
> on not relying on the defaults (currently the auth and enc keyword
> aren't marked as optional in the syntax anyway), but keeps the current
> defaults as a strong hint on what is adviced. I also do
Patrick Wildt wrote:
> On Fri, Aug 06, 2021 at 11:05:53AM +0200, Patrick Wildt wrote:
> > Am Thu, Aug 05, 2021 at 02:33:01PM +0200 schrieb Jan Klemkow:
> > > Hi,
> > >
> > > The following diff removes useless code from the driver. As discussed
> > > here [1] and committed there [2], the hypervi
OK deraadt
Ingo Schwarze wrote:
> Hi,
>
> after quite some head-scratching, i consider the following bug report
> legitimate:
>
> user wrote on Thu, Aug 05, 2021 at 12:43:21AM -0500:
> > On Thu, Aug 05, 2021 at 12:37:00AM -0500, user wrote:
> >> On Fri, Jul 23, 2021 at 11:15:59AM -0500, user w
Damien Miller wrote:
> On Fri, 6 Aug 2021, Christian Weisgerber wrote:
>
> > Damien Miller:
> >
> > > Just a head-up: snaps currently contain a set of changes[1] to
> > > make scp(1) use the SFTP protocol by default.
> >
> > > Please report any incompatibilities or bugs that you encounter here
Martijn van Duren wrote:
> Maybe, but it also made it clear that relying on the defaults for a
> protocol (USM) that doesn't allow to be negotiated will make users
> cry.
You have selected defaults that noone will naturally use in their existing
*OR NEW* environment, and they could spend a lots
Ingo Schwarze wrote:
> as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C.
> Fixing that without longjmp(3) requires making editline(3) better
> behaved.
If a library interface encourages use longjmp(), that library should be
thrown into the dustbin of history. Our src tree has
501 - 600 of 2939 matches
Mail list logo
