[PATCH] Extend OAEP support
Provide methods: EVP_PKEY_CTX_{g,s}et_rsa_oaep_md,
EVP_PKEY_CTX_{g,s}et0_rsa_oaep_label.
Based on Stephen Henson's patches for OpenSSL 1.1.0:
https://github.com/openssl/openssl/commit/271fef0ef39a1c0cb5233a5adf3ff8733abb375e
https://github.com/openssl/openssl/commit/211a14f6279f127f7a5a59948819bd939131b0b6
---
src/lib/libcrypto/rsa/rsa.h | 31
src/lib/libcrypto/rsa/rsa_err.c | 1 +
src/lib/libcrypto/rsa/rsa_oaep.c | 117 +
src/lib/libcrypto/rsa/rsa_pmeth.c | 121 --
4 files changed, 218 insertions(+), 52 deletions(-)
diff --git a/src/lib/libcrypto/rsa/rsa.h b/src/lib/libcrypto/rsa/rsa.h
index 2aa472f50..afa995e5d 100644
--- a/src/lib/libcrypto/rsa/rsa.h
+++ b/src/lib/libcrypto/rsa/rsa.h
@@ -230,6 +230,22 @@ struct rsa_st {
EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_RSA, EVP_PKEY_OP_TYPE_SIG, \
EVP_PKEY_CTRL_GET_RSA_MGF1_MD, 0, (void *)pmd)
+#define EVP_PKEY_CTX_set_rsa_oaep_md(ctx, md) \
+ EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_RSA, EVP_PKEY_OP_TYPE_CRYPT, \
+ EVP_PKEY_CTRL_RSA_OAEP_MD, 0, (void *)(md))
+
+#define EVP_PKEY_CTX_get_rsa_oaep_md(ctx, pmd) \
+ EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_RSA, EVP_PKEY_OP_TYPE_CRYPT, \
+ EVP_PKEY_CTRL_GET_RSA_OAEP_MD, 0, (void *)(pmd))
+
+#define EVP_PKEY_CTX_set0_rsa_oaep_label(ctx, l, llen) \
+ EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_RSA, EVP_PKEY_OP_TYPE_CRYPT, \
+ EVP_PKEY_CTRL_RSA_OAEP_LABEL, llen, (void *)(l))
+
+#define EVP_PKEY_CTX_get0_rsa_oaep_label(ctx, l) \
+ EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_RSA, EVP_PKEY_OP_TYPE_CRYPT, \
+ EVP_PKEY_CTRL_GET_RSA_OAEP_LABEL, 0, (void *)(l))
+
#define EVP_PKEY_CTRL_RSA_PADDING (EVP_PKEY_ALG_CTRL + 1)
#define EVP_PKEY_CTRL_RSA_PSS_SALTLEN (EVP_PKEY_ALG_CTRL + 2)
@@ -241,6 +257,12 @@ struct rsa_st {
#define EVP_PKEY_CTRL_GET_RSA_PSS_SALTLEN (EVP_PKEY_ALG_CTRL + 7)
#define EVP_PKEY_CTRL_GET_RSA_MGF1_MD (EVP_PKEY_ALG_CTRL + 8)
+#define EVP_PKEY_CTRL_RSA_OAEP_MD (EVP_PKEY_ALG_CTRL + 9)
+#define EVP_PKEY_CTRL_RSA_OAEP_LABEL (EVP_PKEY_ALG_CTRL + 10)
+
+#define EVP_PKEY_CTRL_GET_RSA_OAEP_MD (EVP_PKEY_ALG_CTRL + 11)
+#define EVP_PKEY_CTRL_GET_RSA_OAEP_LABEL (EVP_PKEY_ALG_CTRL + 12)
+
#define RSA_PKCS1_PADDING 1
#define RSA_SSLV23_PADDING 2
#define RSA_NO_PADDING 3
@@ -368,6 +390,14 @@ int RSA_padding_add_PKCS1_OAEP(unsigned char *to, int tlen,
int RSA_padding_check_PKCS1_OAEP(unsigned char *to, int tlen,
const unsigned char *f, int fl, int rsa_len,
const unsigned char *p, int pl);
+int RSA_padding_add_PKCS1_OAEP_mgf1(unsigned char *to, int tlen,
+const unsigned char *from, int flen,
+const unsigned char *param, int plen,
+const EVP_MD *md, const EVP_MD *mgf1md);
+int RSA_padding_check_PKCS1_OAEP_mgf1(unsigned char *to, int tlen,
+const unsigned char *from, int flen, int num,
+const unsigned char *param, int plen,
+const EVP_MD *md, const EVP_MD *mgf1md);
int RSA_padding_add_none(unsigned char *to, int tlen,
const unsigned char *f, int fl);
int RSA_padding_check_none(unsigned char *to, int tlen,
@@ -574,6 +604,7 @@ void ERR_load_RSA_strings(void);
#define RSA_R_D_E_NOT_CONGRUENT_TO_1123
#define RSA_R_FIRST_OCTET_INVALID 133
#define RSA_R_ILLEGAL_OR_UNSUPPORTED_PADDING_MODE 144
+#define RSA_R_INVALID_DIGEST157
#define RSA_R_INVALID_DIGEST_LENGTH 143
#define RSA_R_INVALID_HEADER137
#define RSA_R_INVALID_KEYBITS 145
diff --git a/src/lib/libcrypto/rsa/rsa_err.c b/src/lib/libcrypto/rsa/rsa_err.c
index c2b197c58..c7e7470f3 100644
--- a/src/lib/libcrypto/rsa/rsa_err.c
+++ b/src/lib/libcrypto/rsa/rsa_err.c
@@ -96,6 +96,7 @@ static ERR_STRING_DATA RSA_str_reasons[] = {
{ERR_REASON(RSA_R_D_E_NOT_CONGRUENT_TO_1), "d e not congruent to 1"},
{ERR_REASON(RSA_R_FIRST_OCTET_INVALID) , "first octet invalid"},
{ERR_REASON(RSA_R_ILLEGAL_OR_UNSUPPORTED_PADDING_MODE), "illegal or
unsupported padding mode"},
+ {ERR_REASON(RSA_R_INVALID_DIGEST), "invalid digest"},
{ERR_REASON(RSA_R_INVALID_DIGEST_LENGTH) , "invalid digest length"},
{ERR_REASON(RSA_R_INVALID_HEADER), "invalid header"},
{ERR_REASON(RSA_R_INVALID_KEYBITS) , "invalid keybits"},
diff --git a/src/lib/libcrypto/rsa/rsa_oaep.c b/src/lib/libcrypto/rsa/rsa_oaep.c
index c463a885d..30e8353d7 100644
--- a/src/lib/libcrypto/rsa/rsa_oaep.c
+++ b/src/lib/libcrypto/rsa/rsa_oaep.c
@@ -32,63 +32,75 @@
#include
#include
-static int MGF1(unsigned char *mask, long len, const unsigned char *seed,
-long seedlen);
-
int
RSA_padding_add_PKCS1_OAEP(unsigned char *to, int tlen,
const unsigned char *from, int flen, const unsigned char *para
Re: audio: fix block size calculation
On Tue, Sep 03, 2019 at 02:03:52PM -0300, Martin Pieuchot wrote: > On 18/08/19(Sun) 08:02, Alexandre Ratchov wrote: > > Currently the block size calculations are broken by design: the driver > > provides a round_blocksize() function which must retrun a valid block > > size in *bytes*. Unfortunately, since the driver doesn't know if it's > > called for the play or for the record block size, it's mathematically > > impossible to calculate the block size in all cases if play and record > > number of channels are different. As a consequence, there are > > half-working and weired hacks to find a usable block sizes. > > > > The diff below addresses this by adding two new driver functions, > > which are very simple to use: > > > > set_blksz() - calculate and set the block size in *frames*, it's > > necessarily common to play and recording directions no matter > > the number of channels, > > > > set_nblks() - calculate the number of blocks per buffer for the given > > direction. > > > > the diff below shows how to properly calculate the block size in > > azalia and uaudio. The plan is to convert all drivers from > > round_blocksize() to the new functions and to delete > > round_blocksize(). > > > > Why is this important? besides for removing ugly (and risky) hacks, we > > want all our drivers to support common block sizes in the 5ms-50ms > > range. This would allow to implement switching between audio devices: > > for instance, start playback on a USB device, unplug the cable and > > continue on azalia. > > While the cleanup in itself makes sense to me. I'm unsure if continuing > to play on a secondary audio device is what we want. Nowadays phones > seems to stop music players if an audio device is disconnected. > > Let's assume I'm in a hackathon hearing music via a USB device, if I > unplug it, accidentally or not, I'd find more logical that the player > stop instead of forcing the whole room to listen my music. I totally agree, making this the default would be a mistake as it's against the "least surprise" principle. It seems practical in few specific cases though: for instance I use it to temporarilly connect a usb headset in order to answer a phone call in firefox without the need to restart sndiod and firefox and then call back the other person. > > OK? > > Diff is ok with me, if you think it makes sense to do this change anyway > :) > Sure, the change is very useful.
Re: once again: iwm(4) multi-frame rx + monitor mode
On 30.08., Stefan Sperling wrote: > I would like to try this again: In iwm(4), process more than one frame > per Rx interrupt, and enable monitor mode. > > Monitor mode triggers "unhandled fimware response" errors without multi-Rx > support. We have seen these infamous errors in other contexts as well. > It is possible that the firmware decides to use multi-Rx in such cases > which would of course confuse our driver. > > The fact is that Linux has not used single-Rx mode for years. One of their > developers told me that Intel has stopped testing it entirely. The current > code isn't future-proof and is likely to break with newer versions of > firmware and/or hardware. > > These changes were attempted and reverted twice already. > Last time because they were causing throughput issues (and I now see why). > I have rebased my old diff and tweaked it slightly to avoid an unneeded > mbuf copy and reworked all the offset/length calculations once again. > > Works fine here against several APs with no observable drop in throughput. > > Please test this on as many iwm devices as possible. Thanks! > Your diff is working on my Intel Dual Band Wireless AC 3165 for three days now. I haven't encounter any problems so far. Please tell me if you need specific tests or more information about my setup. Cheers, Bruno
Re: audio: fix block size calculation
On 18/08/19(Sun) 08:02, Alexandre Ratchov wrote:
> Currently the block size calculations are broken by design: the driver
> provides a round_blocksize() function which must retrun a valid block
> size in *bytes*. Unfortunately, since the driver doesn't know if it's
> called for the play or for the record block size, it's mathematically
> impossible to calculate the block size in all cases if play and record
> number of channels are different. As a consequence, there are
> half-working and weired hacks to find a usable block sizes.
>
> The diff below addresses this by adding two new driver functions,
> which are very simple to use:
>
> set_blksz() - calculate and set the block size in *frames*, it's
> necessarily common to play and recording directions no matter
> the number of channels,
>
> set_nblks() - calculate the number of blocks per buffer for the given
> direction.
>
> the diff below shows how to properly calculate the block size in
> azalia and uaudio. The plan is to convert all drivers from
> round_blocksize() to the new functions and to delete
> round_blocksize().
>
> Why is this important? besides for removing ugly (and risky) hacks, we
> want all our drivers to support common block sizes in the 5ms-50ms
> range. This would allow to implement switching between audio devices:
> for instance, start playback on a USB device, unplug the cable and
> continue on azalia.
While the cleanup in itself makes sense to me. I'm unsure if continuing
to play on a secondary audio device is what we want. Nowadays phones
seems to stop music players if an audio device is disconnected.
Let's assume I'm in a hackathon hearing music via a USB device, if I
unplug it, accidentally or not, I'd find more logical that the player
stop instead of forcing the whole room to listen my music.
When gilles@ and/or jcs@ will be ready with their Bluetooth code, we
could do the same there :o)
> OK?
Diff is ok with me, if you think it makes sense to do this change anyway
:)
>
> Index: share/man/man9/audio.9
> ===
> RCS file: /cvs/src/share/man/man9/audio.9,v
> retrieving revision 1.27
> diff -u -p -r1.27 audio.9
> --- share/man/man9/audio.912 Mar 2019 08:18:34 - 1.27
> +++ share/man/man9/audio.918 Aug 2019 05:28:35 -
> @@ -82,6 +82,10 @@ struct audio_hw_if {
> void (*)(void *), void *, struct audio_params *);
> void(*copy_output)(void *hdl, size_t bytes);
> void(*underrun)(void *hdl);
> + int (*set_blksz)(void *, int,
> + struct audio_params *, struct audio_params *, int);
> + int (*set_nblks)(void *, int, int,
> + struct audio_params *, int);
> };
>
> struct audio_params {
> @@ -417,6 +421,56 @@ Drivers using bounce buffers for transfe
> ring buffer and the device must implement this method to skip
> one block from the audio ring buffer and transfer the
> corresponding amount of silence to the device.
> +.It Fn "int (*set_blksz)" "void *hdl" "int mode" \
> +"struct audio_params *play" "struct audio_params *rec" "int blksz"
> +This function is called to set the audio block size.
> +.Fa mode
> +is a combination of the
> +.Dv AUMODE_RECORD
> +and
> +.Dv AUMODE_PLAY
> +flags indicating the current mode set with the
> +.Fn open
> +function.
> +The
> +.Fa play
> +and
> +.Fa rec
> +structures contain the current encoding set with the
> +.Fn set_params
> +function.
> +.Fa blksz
> +is the desired block size in frames.
> +It may be adjusted to match hardware constraints.
> +This function returns the adjusted block size.
> +.It Fn "int (*set_nblks)" "void *hdl" "int dir" "int blksz" \
> +"struct audio_params *params" "int nblks"
> +This function is called to set the number of audio blocks in
> +the ring buffer.
> +.Fa dir
> +is either the
> +.Dv AUMODE_RECORD
> +or the
> +.Dv AUMODE_PLAY
> +flag, indicating which ring buffer size is set.
> +The
> +.Fa params
> +structure contains the encoding parameters set by the
> +.Fn set_params
> +method.
> +.Fa blksz
> +is the current block size in frames set with the
> +.Fa set_params
> +function.
> +The
> +.Fa params
> +structure is the current encoding parameters, set with the
> +.Fn set_params
> +function.
> +.Fa nblks
> +is the desired number of blocks in the ring buffer.
> +It may be lowered to at least two, to match hardware constraints.
> +This function returns the adjusted number of blocks.
> .El
> .Pp
> If the audio hardware is capable of input from more
> Index: sys/dev/audio.c
> ===
> RCS file: /cvs/src/sys/dev/audio.c,v
> retrieving revision 1.180
> diff -u -p -r1.180 audio.c
> --- sys/dev/audio.c 17 Aug 2019 05:04:56 - 1.180
> +++ sys/dev/audio.c 18 Aug 2019 05:28:36 -
> @@ -193,6 +193,31 @@ audio_gcd(unsigned int a, unsigned int b
> return a;
> }
>
> +/*
> + * Calculate the least block size (in
Re: smtpd: change PATH for filters
On Tue, 03 Sep 2019 17:11:22 +0200, Martijn van Duren wrote: > I choose this value because I hit the maximum command length of the > shell before. This way I'm somewhat confident that the shell doesn't > do something weird with my command if we ever overflow it's internal > buffer. So I based it on the shell, not the kernel. > > Also, I deem it extremely unlikely that any configuration ever > has a filter command which reaches over _POSIX_ARG_MAX. OK, that's fine. We can revisit this later if system(3) is removed from the equation. - todd
Re: Questions about syspatch(8) mtree(8) behaviour
On Tue, Sep 03, 2019 at 08:51:09AM +0200, Antoine Jacoutot wrote:
> On Mon, Sep 02, 2019 at 08:58:01PM +0200, Hiltjo Posthuma wrote:
> > On Mon, Sep 02, 2019 at 12:07:59PM -0600, Theo de Raadt wrote:
> > > Hiltjo Posthuma wrote:
> > >
> > > > Hi,
> > > >
> > > > I have three questions regarding a behaviour of syspatch(8) with
> > > > mtree(8).
> > > >
> > > > 1. I noticed when applying patches it resets some permissions of new,
> > > > but also of
> > > > existing directories on the system using mtree(8).
> > > >
> > > > In the shellscript syspatch(8) there is a function:
> > > >
> > > > trap_handler():
> > > > # in case a patch added a new directory (install -D)
> > > > if [[ -n ${_PATCHES} ]]; then
> > > > mtree -qdef /etc/mtree/4.4BSD.dist -p / -U >/dev/null
> > > > [[ -f /var/sysmerge/xetc.tgz ]] &&
> > > > mtree -qdef /etc/mtree/BSD.x11.dist -p / -U
> > > > >/dev/null
> > > > fi
> > > >
> > > > Here the comment says: "in case a patch added a new directory (install
> > > > -D)".
> > > > This is true, but it also applies to existing directories and resets
> > > > permissions, ownership, etc.
> > > >
> > > > A real-world example: on my system after applying syspatch this changed
> > > > permissions of an existing directory and a daemon (mysqld) failed to
> > > > start,
> > > > because it could not access a UNIX domain socket file in the www chroot.
> > >
> > > A very long mail without being 100% PRECISE.
> > >
> > > > Is this intended? If so should this behaviour perhaps get documented in
> > > > the man
> > > > page? I can write a patch if so.
> > >
> > > Intentional. As a general rule if you change a system component, you own
> > > all the pieces.
> > >
> > > But I guess you did chmod a+wrxt / or something, right? I have to assume
> > > so, because your mail is not PRECISE.
> > >
> >
> > In this particular case it was the directory /var/www/run. The default
> > permissions are as specified in /etc/mtree/4.4BSD.dist:
> >
> > run type=dir uname=root gname=daemon mode=755
> >
> > I changed it from 755 to 775 (still root:daemon) so both mysqld and PHP
> > could
> > access the UNIX domain socket in the www chroot (/var/www).
>
> Why don't you do what the mariadb readme advises?
>
> chrooted daemons and MariaDB socket
> ===
>
> For external program running under a chroot(8) to be able to access the
> MariaDB server without using a network connection, the socket must be
> placed inside the chroot.
>
> e.g. httpd(8) or nginx(8): connecting to MariaDB from PHP
> -
> Create a directory for the MariaDB socket:
>
> # install -d -m 0711 -o _mysql -g _mysql /var/www/var/run/mysql
>
> Adjust ${SYSCONFDIR}/my.cnf to use the socket in the chroot - this
> applies to both client and server processes:
>
> [client-server]
> socket = /var/www/var/run/mysql/mysql.sock
>
>
> --
> Antoine
>
Thanks, I think I understand the ideas behind it now and will keep it in mind.
--
Kind regards,
Hiltjo
Re: armv7: remove gcc support from kernel Makefile
Mark Kettenis: > > This drops support for building the armv7 kernel with gcc and reduces > > the difference to arm64. > > If we're keeping the gcc bits on other architectures, it makes sense > to keep it here as well. Helps with diffability and someone might > want to run the same tools for armv7 at some point. Well, arm64 does not have any gcc bits there and this diff (which I already committed, oops) reduces the difference between Makefile.armv7 and Makefile.arm64. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: armv7: remove gcc support from kernel Makefile
Mark Kettenis wrote: > > Date: Mon, 2 Sep 2019 17:32:04 +0200 > > From: Christian Weisgerber > > > > This drops support for building the armv7 kernel with gcc and reduces > > the difference to arm64. > > > > I can't test this. > > > > OK? Or it can be rolled into somebody else's larger "remove gcc > > from armv7" diff. > > If we're keeping the gcc bits on other architectures, it makes sense > to keep it here as well. Helps with diffability and someone might > want to run the same tools for armv7 at some point. Perhaps, perhaps. It is fragile. These stanzas will break. When they do, someone has to tweak them to get gcc to build the kernel. But at least they have a starting point, so that's not terribly bad. So yeah, maybe let's keep that around. I also consider it very important that we try to keep the Makefile.* files on all the architectures "maximally diffable". Another aspect where we don't need surprises.
Re: smtpd: change PATH for filters
On 9/3/19 4:30 PM, Todd C. Miller wrote:
> On Mon, 02 Sep 2019 21:15:23 +0200, Martijn van Duren wrote:
>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
>> {_POSIX_ARG_MAX}
>> Maximum length of argument to the exec functions including environment da
>> ta.
>> Value: 4 096
>
> Note that this is the minimum value POSIX requires, implementations
> are allowed to have larger values. The _actual_ value on OpenBSD
> is ARG_MAX which is much higher, 256 * 1024.
>
> Personally, I'd just use asprintf() here. The actual limit is going
> to be closer to ARG_MAX - (strlen("sh) + strlen("-c") so I don't
> think you are likely to get it exactly. The kernel should enforce
> that limit, not smtpd.
>
> - todd
>
I choose this value because I hit the maximum command length of the
shell before. This way I'm somewhat confident that the shell doesn't
do something weird with my command if we ever overflow it's internal
buffer. So I based it on the shell, not the kernel.
Also, I deem it extremely unlikely that any configuration ever
has a filter command which reaches over _POSIX_ARG_MAX.
If you feel strongly about changing it asprintf I'll prepare a diff,
I just want my reasoning out there first.
Re: armv7: remove gcc support from kernel Makefile
> Date: Mon, 2 Sep 2019 17:32:04 +0200
> From: Christian Weisgerber
>
> This drops support for building the armv7 kernel with gcc and reduces
> the difference to arm64.
>
> I can't test this.
>
> OK? Or it can be rolled into somebody else's larger "remove gcc
> from armv7" diff.
If we're keeping the gcc bits on other architectures, it makes sense
to keep it here as well. Helps with diffability and someone might
want to run the same tools for armv7 at some point.
> Index: arch/armv7/conf/Makefile.armv7
> ===
> RCS file: /cvs/src/sys/arch/armv7/conf/Makefile.armv7,v
> retrieving revision 1.45
> diff -u -p -r1.45 Makefile.armv7
> --- arch/armv7/conf/Makefile.armv721 Jun 2019 15:34:07 - 1.45
> +++ arch/armv7/conf/Makefile.armv72 Sep 2019 15:26:17 -
> @@ -25,14 +25,10 @@ INCLUDES= -nostdinc -I$S -I. -I$S/arch
> CPPFLAGS=${INCLUDES} ${IDENT} ${PARAM} -D_KERNEL -D__${_mach}__ -MD -MP
> CWARNFLAGS= -Werror -Wall -Wimplicit-function-declaration \
> -Wno-uninitialized -Wno-pointer-sign \
> + -Wno-constant-conversion -Wno-address-of-packed-member \
> -Wframe-larger-than=2047
>
> -CMACHFLAGS= -msoft-float
> -.if ${COMPILER_VERSION:Mgcc4}
> -CMACHFLAGS+= -march=armv6 -Wa,-march=armv7a
> -.else
> -CMACHFLAGS+= -march=armv7a
> -.endif
> +CMACHFLAGS= -msoft-float -march=armv7a
> CMACHFLAGS+= -ffreestanding ${NOPIE_FLAGS}
> SORTR= sort -R
> .if ${IDENT:M-DNO_PROPOLICE}
> @@ -42,10 +38,6 @@ CMACHFLAGS+= -fno-stack-protector
> SORTR= cat
> COPTS?= -Oz
> .endif
> -.if ${COMPILER_VERSION:Mclang}
> -NO_INTEGR_AS=-no-integrated-as
> -CWARNFLAGS+= -Wno-address-of-packed-member -Wno-constant-conversion
> -.endif
>
> DEBUG?= -g
> COPTS?= -O2
> @@ -103,7 +95,7 @@ LINKFLAGS+=-S
> assym.h: $S/kern/genassym.sh Makefile \
>${_archdir}/${_arch}/genassym.cf ${_machdir}/${_mach}/genassym.cf
> cat ${_archdir}/${_arch}/genassym.cf ${_machdir}/${_mach}/genassym.cf |
> \
> - sh $S/kern/genassym.sh ${CC} ${NO_INTEGR_AS} ${CFLAGS} ${CPPFLAGS}
> -MF assym.P > assym.h.tmp
> + sh $S/kern/genassym.sh ${CC} ${CFLAGS} ${CPPFLAGS}
> -no-integrated-as -MF assym.P > assym.h.tmp
> sed '1s/.*/assym.h: \\/' assym.P > assym.d
> sort -u assym.h.tmp > assym.h
>
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
>
Re: smtpd: change PATH for filters
On Mon, 02 Sep 2019 21:15:23 +0200, Martijn van Duren wrote:
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
> {_POSIX_ARG_MAX}
> Maximum length of argument to the exec functions including environment da
> ta.
> Value: 4 096
Note that this is the minimum value POSIX requires, implementations
are allowed to have larger values. The _actual_ value on OpenBSD
is ARG_MAX which is much higher, 256 * 1024.
Personally, I'd just use asprintf() here. The actual limit is going
to be closer to ARG_MAX - (strlen("sh) + strlen("-c") so I don't
think you are likely to get it exactly. The kernel should enforce
that limit, not smtpd.
- todd
Re: libedit: Does not run input command in vi mode
Hello Masato-san,
Masato Asou wrote on Tue, Sep 03, 2019 at 02:39:11PM +0900:
> Does not run input command by vi editor with vi mode.
>
> I do the following:
>
> 1. set vi mode.
>$ echo "bind -v" > ~/.editrc
>
> 2. launch /usr/bin/ftp command.
>$ ftp
>
> 3. launch vi editor with ESC + v.
>ftp> ESC + v
>
> 4. input "help" in vi editor.
>i + help + ESC + :wq
>
> 5. then 'help' command does not run.
>
> I fix this problem with following patch. This fix is come from NetBSD
> lib/libedit/vi.c 1.46 and 1.47.
>
> ok?
Indeed, limiting the length of the command created with vi(1) to
the length of the string the command line contained when vi(1) was
started is wrong.
Both code inspection and testing confirm that this is a bug
and that your patch is the correct fix.
IK schwarze@; please commit.
Thank you,
Ingo
> Index: vi.c
> ===
> RCS file: /cvs/src/lib/libedit/vi.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 vi.c
> --- vi.c 3 Sep 2019 02:28:25 - 1.27
> +++ vi.c 3 Sep 2019 05:34:31 -
> @@ -1058,12 +1058,12 @@ vi_histedit(EditLine *el, wint_t c __att
> while (waitpid(pid, &status, 0) != pid)
> continue;
> lseek(fd, (off_t)0, SEEK_SET);
> - st = read(fd, cp, TMP_BUFSIZ);
> + st = read(fd, cp, TMP_BUFSIZ - 1);
> if (st > 0) {
> - len = (size_t)(el->el_line.lastchar -
> - el->el_line.buffer);
> + cp[st] = '\0';
> + len = (size_t)(el->el_line.limit - el->el_line.buffer);
> len = mbstowcs(el->el_line.buffer, cp, len);
> - if (len > 0 && el->el_line.buffer[len -1] == '\n')
> + if (len > 0 && el->el_line.buffer[len - 1] == '\n')
> --len;
> }
> else
