Re: Removing syscall(2) from libc and kernel
On Fri, Oct 27, 2023 at 09:36:25AM -0600, Theo de Raadt wrote:
> Index: sys/arch/m88k/m88k/trap.c
> ===
> RCS file: /cvs/src/sys/arch/m88k/m88k/trap.c,v
> diff -u -p -u -r1.128 trap.c
> --- sys/arch/m88k/m88k/trap.c 2 Aug 2023 06:14:46 - 1.128
> +++ sys/arch/m88k/m88k/trap.c 27 Oct 2023 03:17:47 -
> @@ -1153,9 +1153,9 @@ void
> m88100_syscall(register_t code, struct trapframe *tf)
> {
> int i, nap;
> - const struct sysent *callp;
> + const struct sysent *callp = sysent;
> struct proc *p = curproc;
> - int error, indirect = -1;
> + int error;
> register_t args[8] __aligned(8);
> register_t rval[2] __aligned(8);
> register_t *ap;
> @@ -1172,19 +1172,9 @@ m88100_syscall(register_t code, struct t
> ap = >tf_r[2];
> nap = 8; /* r2-r9 */
>
> - switch (code) {
> - case SYS_syscall:
> - indirect = code;
> - code = *ap++;
> - nap--;
> - break;
> - }
> -
> - callp = sysent;
> - if (code < 0 || code >= SYS_MAXSYSCALL)
> - callp += SYS_syscall;
> - else
> - callp += code;
> + if (code <= 0 || code >= SYS_MAXSYSCALL)
> + goto bad;
> + callp += code;
>
> i = callp->sy_argsize / sizeof(register_t);
> if (i > sizeof(args) / sizeof(register_t))
> @@ -1200,7 +1190,7 @@ m88100_syscall(register_t code, struct t
> rval[0] = 0;
> rval[1] = tf->tf_r[3];
>
> - error = mi_syscall(p, code, indirect, callp, args, rval);
> + error = mi_syscall(p, code, callp, args, rval);
>
> /*
>* system call will look like:
> @@ -1266,7 +1256,7 @@ void
> m88110_syscall(register_t code, struct trapframe *tf)
> {
> int i, nap;
> - const struct sysent *callp;
> + const struct sysent *callp = sysent;
> struct proc *p = curproc;
> int error;
> register_t args[8] __aligned(8);
> @@ -1285,17 +1275,8 @@ m88110_syscall(register_t code, struct t
> ap = >tf_r[2];
> nap = 8;/* r2-r9 */
>
> - switch (code) {
> - case SYS_syscall:
> - code = *ap++;
> - nap--;
> - break;
> - }
> -
> - callp = sysent;
> - if (code < 0 || code >= SYS_MAXSYSCALL)
> - callp += SYS_syscall;
> - else
> + // XXX out of range stays on syscall0, which we assume is enosys
> + if (code >= 0 || code <= SYS_MAXSYSCALL)
> callp += code;
>
> i = callp->sy_argsize / sizeof(register_t);
Shouldn't this be
if (code > 0 && code < SYS_MAXSYSCALL)
?
All the other places in the diff modify callp under that condition. Also
all the values of code >= SYS_MAXSYSCALL will be covered by code >= 0.
Out of curiosity, any reason why m88k doesn't do the goto bad early on?
Other than RTFM for the calling convention.
> Index: sys/arch/mips64/mips64/trap.c
> ===
> RCS file: /cvs/src/sys/arch/mips64/mips64/trap.c,v
> diff -u -p -u -r1.167 trap.c
> --- sys/arch/mips64/mips64/trap.c 26 Apr 2023 16:53:59 - 1.167
> +++ sys/arch/mips64/mips64/trap.c 27 Oct 2023 03:17:44 -
> @@ -396,14 +396,12 @@ fault_common_no_miss:
> case T_SYSCALL+T_USER:
> {
> struct trapframe *locr0 = p->p_md.md_regs;
> - const struct sysent *callp;
> - unsigned int code, indirect = -1;
> + const struct sysent *callp = sysent;
> + unsigned int code;
> register_t tpc;
> uint32_t branch = 0;
> int error, numarg;
> - struct args {
> - register_t i[8];
> - } args;
> + register_t args[8];
> register_t rval[2];
>
> atomic_inc_int();
> @@ -422,51 +420,22 @@ fault_common_no_miss:
> trapframe->pc, 0, branch);
> } else
> locr0->pc += 4;
> - callp = sysent;
> code = locr0->v0;
> - switch (code) {
> - case SYS_syscall:
> - /*
> - * Code is first argument, followed by actual args.
> - */
> - indirect = code;
> - code = locr0->a0;
> - if (code >= SYS_MAXSYSCALL)
> - callp += SYS_syscall;
> - else
> - callp += code;
> - numarg = callp->sy_argsize / sizeof(register_t);
> - args.i[0] = locr0->a1;
> - args.i[1] = locr0->a2;
> - args.i[2] = locr0->a3;
> - if (numarg > 3) {
> - args.i[3] = locr0->a4;
> - args.i[4] = locr0->a5;
> -
Fix function names in imsg_init.3
There is no imsg_seek_set_n{32,64}, but imsg_set_n{32,64}.
diff refs/heads/master 34767f41b5371661bc7d3b47c3f780279d1bcd9c
commit - c7bb30c9e72387bdcf13f2516a8d63c49f7eae54
commit + 34767f41b5371661bc7d3b47c3f780279d1bcd9c
blob - 11915f377f9b38df97bd67ca9b1768962a998637
blob + db3021ed6c199c4fef8f544313894999fe1b4380
--- lib/libutil/imsg_init.3
+++ lib/libutil/imsg_init.3
@@ -472,9 +472,9 @@ with the data of extent
.Pp
.Fn ibuf_set_n8 ,
.Fn ibuf_set_n16 ,
-.Fn ibuf_seek_set_n32
+.Fn ibuf_set_n32
and
-.Fn ibuf_seek_set_n64
+.Fn ibuf_set_n64
replace a 1-byte, 2-byte, 4-byte or 8-byte
.Fa value
at offset
Re: document USE_NOBTCFI in bsd.port.mk
On Fri, Sep 08, 2023 at 03:22:32PM -0600, Anthony J. Bentley wrote:
> Lucas Raab writes:
> > +writes a wrapper script to ${WRKDIR}/bin/ld in
>
> Use:
>
> .Pa ${WRKDIR}/bin/ld
>
> I see it's wrong elsewhere in the manpage, but let's not introduce another.
>
> > +.Cm patch
> > +to request that the linker adds an
> > +.Dv PT_OPENBSD_NOBTCFI
> > +ELF section. Use when a port requires no enforcement of indirect branch
>
> The second sentence needs to begin on its own line. This affects
> inter-sentence spacing in the rendered manpage.
Ah, I understand now. I think I was initially confusing that with new
paragraphs starting out on their own line.
>
> ELF section.
> Use when a port ...
>
> > Use when a port requires no enforcement of indirect branch targets.
>
> Reading it again, I think this could be misinterpreted. Better would be
> to word it like USE_NOEXECONLY:
>
> "Use when a port does not work with the default strict enforcement of
> indirect branch targets."
New version attached
diff /usr/src
commit - 2933f00289463a6d1923d1b9cc5e5c1c5c697ece
path + /usr/src
blob - 00ec6c3f81fcf03ea69eabe8de1741a6e562
file + share/man/man5/bsd.port.mk.5
--- share/man/man5/bsd.port.mk.5
+++ share/man/man5/bsd.port.mk.5
@@ -3613,6 +3613,22 @@ and not intended to be a user setting.
See
.Ev WRKOBJDIR_MFS
for configuration.
+.It Ev USE_NOBTCFI
+If set to
+.Sq Yes ,
+writes a wrapper script to
+.Pa ${WRKDIR}/bin/ld
+in
+.Cm patch
+to request that the linker adds an
+.Dv PT_OPENBSD_NOBTCFI
+ELF section.
+Use when a port does not work with the default strict enforcement of
+indirect branch targets.
+.Pp
+Applies to all architectures; set
+.Ev USE_NOBTCFI-${MACHINE_ARCH}
+to apply to only a specific architecture.
.It Ev USE_NOEXECONLY
If set to
.Sq Yes ,
Re: document USE_NOBTCFI in bsd.port.mk
On Fri, Sep 08, 2023 at 02:49:56PM -0600, Anthony J. Bentley wrote:
> Lucas Raab writes:
> > +Use when a port requires no enforcement of indirect branch targets. Use
>
> New sentence, new line.
>
> > +.Ev USE_NOBTCFI-${MACHINE_ARCH}
> > +to apply to specific architectures instead of all architectures.
>
> I would invert the wording: "Applies to all architectures; set
> USE_NOBTCFI-${MACHINE_ARCH} to apply to only a specific architecture."
More like this?
diff /usr/src
commit - 2933f00289463a6d1923d1b9cc5e5c1c5c697ece
path + /usr/src
blob - 00ec6c3f81fcf03ea69eabe8de1741a6e562
file + share/man/man5/bsd.port.mk.5
--- share/man/man5/bsd.port.mk.5
+++ share/man/man5/bsd.port.mk.5
@@ -3613,6 +3613,19 @@ and not intended to be a user setting.
See
.Ev WRKOBJDIR_MFS
for configuration.
+.It Ev USE_NOBTCFI
+If set to
+.Sq Yes,
+writes a wrapper script to ${WRKDIR}/bin/ld in
+.Cm patch
+to request that the linker adds an
+.Dv PT_OPENBSD_NOBTCFI
+ELF section. Use when a port requires no enforcement of indirect branch
+targets.
+.Pp
+Applies to all architectures; set
+.Ev USE_NOBTCFI-${MACHINE_ARCH}
+to apply to only a specific architecture.
.It Ev USE_NOEXECONLY
If set to
.Sq Yes ,
document USE_NOBTCFI in bsd.port.mk
Hello,
Following up on a suggestion from tb@, here's a proposed addition to
bsd.port.mk to document the use of USE_NOBTCFI[-${MACHINE_ARCH}]. Text and
formatting mostly borrowed from the other USE_ sections so feedback welcome on
improvements (particularly placement of the ${MACHINE_ARCH}, I wasn't sure if
that warranted its own section a la SUBST_CMD-sub).
Thanks,
Lucas
diff /usr/src
commit - 2933f00289463a6d1923d1b9cc5e5c1c5c697ece
path + /usr/src
blob - 00ec6c3f81fcf03ea69eabe8de1741a6e562
file + share/man/man5/bsd.port.mk.5
--- share/man/man5/bsd.port.mk.5
+++ share/man/man5/bsd.port.mk.5
@@ -3613,6 +3613,17 @@ and not intended to be a user setting.
See
.Ev WRKOBJDIR_MFS
for configuration.
+.It Ev USE_NOBTCFI
+If set to
+.Sq Yes,
+writes a wrapper script to ${WRKDIR}/bin/ld in
+.Cm patch
+to request that the linker adds an
+.Dv PT_OPENBSD_NOBTCFI
+ELF section.
+Use when a port requires no enforcement of indirect branch targets. Use
+.Ev USE_NOBTCFI-${MACHINE_ARCH}
+to apply to specific architectures instead of all architectures.
.It Ev USE_NOEXECONLY
If set to
.Sq Yes ,
Re: simple pledge for xeyes(1)
On 2023-09-08, Sebastien Marie wrote:
> "rpath" is a bit odd in xeyes(1) normal behaviour (but it will be required on
> X11 error, as if I remember well, error codes are "translated" to message by
> reading some file).
Exactly. X11 reads the error database `/usr/X11R6/share/X11/XErrorDB`
if it needs to issue an error.
However, we can force xeyes(1) to read the error database into memory at
initialization before pledging; so if an error occurs, it would not need
to read the database again.
Quoting from `xenocara/app/xclock/xclock.c`:
> {
> /* force reading of XErrorDB into memory to avoid adding "rpath" to
>pledge below */
> char buf[1];
>
>(void)XGetErrorDatabaseText(XtDisplay(toplevel), "XProtoError", "0", "",
> buf, 1);
> }
> if (pledge("stdio", NULL) == -1)
>err(1, "pledge");
XGetErrorDatabaseText uses a static variable to hold the database.
This variable is initialized in the first call, and then used by
the following calls.
On 2023-09-08, Sebastien Marie wrote:
> For me, you are pledging too early (before initialization). It should be done
> at
> least after calling XtAppInitialize(3).
>
> It will be the main limitation for a tool like `abstain`. pledge(2) should be
> called *after* initialization, and not at the beginning of the program.
I also think that.
If we pledge(2) after initializing the connection to the X Server, we
can drop the "unix" and "inet" promises.
Lucas de Sena
Re: Regularize shift $((OPTIND - 1)) after getopts
Simon Branch wrote: > In an arithmetic substitution -- that is, the $(( ... )) construct in a > shell script -- one can reference variables either with ($a) or without > (a) the dollar sign. However, the latter is slightly better: the > variable is interpreted as an integer, and then the integer is used > inside the expression. With the former, the variable's contents are > spliced into the expression before it is parsed. For example: > > $ a='1+5' > $ echo $((a * 2)) > 12 > $ echo $(($a * 2)) > 11 [Speaking only about POSIX, not OpenBSD ksh and sh.] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04 > If the shell variable x contains a value that forms a valid integer > constant, optionally including a leading or , > then the arithmetic expansions "$((x))" and "$(($x))" shall return the > same value. and before that > - Only the decimal-constant, octal-constant, and hexadecimal-constant >constants specified in the ISO C standard, Section 6.4.4.1 are >required to be recognized as constants. Technically, your example is UB. Then the description of OPTIND also makes no guarantees about whether it can be used as $((OPTIND)) or not. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/getopts.html > [...] the shell variable OPTIND shall be set to the index of the first > operand, or the value "$#" +1 if there are no operands; [...] That being said, consistency is always nice, and quite surely $(($OPTIND - 1)) and $((OPTIND - 1)) behaves the same in most sane usages. -Lucas
Re: fw_update lock_db should exit when parent exits
Andrew Hewus Fresh wrote:
> I noticed this when testing how signal handling worked in fw_update, it
> turns out that if you `pkill -KILL -f fw_update` it may leave behind a perl
> process that is locking the package database. Instead of just waiting
> to be killed, we can have that process check to see if its parent is
> still around and exit if not.
>
> Is there a more appropriate solution to this?
> What's the right way to notice your parent exited?
Your approach is racey. Instead, pass the soon-to-be-parent pid as an
argument to the perl script. I don't know if there is a better solution
to "detect if your parent exited".
-Lucas
diff /usr/src
commit - e425abdca99af75b418563580e5a2e31165f6f10
path + /usr/src
blob - 53efe8160238c66dc5628ea8d56e37e42988a9b4
file + usr.sbin/fw_update/fw_update.sh
--- usr.sbin/fw_update/fw_update.sh
+++ usr.sbin/fw_update/fw_update.sh
@@ -213,7 +213,7 @@ lock_db() {
[ -e /usr/bin/perl ] || return 0
set -o monitor
- perl <<'EOL' |&
+ perl - "$$" <<'EOL' |&
use v5.16;
use warnings;
no lib ('/usr/local/libdata/perl5/site_perl');
@@ -221,10 +221,15 @@ lock_db() {
$|=1;
+ $0 = "fw_update: lock_db"
lock_db(0);
say $$;
- sleep;
+
+ # If our parent exits unexpectedly,
+ # ppid will become init and we should exit.
+ my $parent = shift;
+ sleep 1 while getppid == $parent;
EOL
set +o monitor
Re: installer: disk crypto: crank KDF rounds to hardware based default
Klemens Nanni wrote:
> @@ -1117,13 +1117,6 @@ bio_changepass(char *dev)
>
> /* Current passphrase. */
> bio_kdf_derive(, , "Old passphrase: ", 0);
> -
> - /*
> - * Unless otherwise specified, keep the previous number of rounds as
> - * long as we're using the same KDF.
> - */
> - if (kdfhint.generic.type == SR_CRYPTOKDFT_BCRYPT_PBKDF && !rflag)
> - rflag = kdfhint.rounds;
>
> /* New passphrase. */
> bio_kdf_generate();
This will potentially downgrade the amount of rounds on password change
if `-r` is omitted, which is not ideal imo. What about the following to
keep the previous amount of rounds if its bigger than the automatic
estimate?
-Lucas
diff refs/heads/master 758422c5a8c4e618082a6dc3dc0f268ed05e9cd9
commit - d4b9d4747036fa562b886f23a67e486ba94b3dc6
commit + 758422c5a8c4e618082a6dc3dc0f268ed05e9cd9
blob - d6617b14595e278f687a9f114767438f5fe51326
blob + 951df4da4db2e69c058a2bcb0d460543b602cc7a
--- sbin/bioctl/bioctl.8
+++ sbin/bioctl/bioctl.8
@@ -282,11 +282,12 @@ If
passphrase of an existing encrypted volume.
A larger number of iterations takes more time, but offers increased resistance
against passphrase guessing attacks.
-If
+By default, or if
.Ar rounds
-is specified as "auto", the number of rounds will be automatically determined
-based on system performance.
-Otherwise the minimum is 4 rounds and the default is 16.
+is specified as
+.Cm auto ,
+the number of rounds will automatically be based on system performance.
+The minimum is 16 rounds.
.It Fl s
Read the passphrase for the selected crypto volume from
.Pa /dev/stdin
blob - 2928cfba3d52f5f3a4c6589d4e363e09f6da30d4
blob + ba4a15bab4d8d1ac1211aec9a6c315bfb6f29bb6
--- sbin/bioctl/bioctl.c
+++ sbin/bioctl/bioctl.c
@@ -66,7 +66,7 @@ void bio_kdf_generate(struct
sr_crypto_kdfinfo *);
intbio_parse_devlist(char *, dev_t *);
void bio_kdf_derive(struct sr_crypto_kdfinfo *,
struct sr_crypto_pbkdf *, char *, int);
-void bio_kdf_generate(struct sr_crypto_kdfinfo *);
+void bio_kdf_generate(struct sr_crypto_kdfinfo *, int);
intbcrypt_pbkdf_autorounds(void);
void derive_key(u_int32_t, int, u_int8_t *, size_t,
u_int8_t *, size_t, char *, int);
@@ -89,7 +89,7 @@ int rflag = 0;
inthuman;
intverbose;
u_int32_t cflags = 0;
-intrflag = 0;
+intrflag = -1; /* auto */
char *password;
void *bio_cookie;
@@ -182,7 +182,7 @@ main(int argc, char *argv[])
rflag = -1;
break;
}
- rflag = strtonum(optarg, 4, 1<<30, );
+ rflag = strtonum(optarg, 16, 1<<30, );
if (errstr != NULL)
errx(1, "number of KDF rounds is %s: %s",
errstr, optarg);
@@ -902,7 +902,7 @@ bio_createraid(u_int16_t level, char *dev_list, char *
bio_kdf_derive(, , "Passphrase: ", 0);
memset(, 0, sizeof(kdfhint));
} else {
- bio_kdf_generate();
+ bio_kdf_generate(, -1);
}
create.bc_opaque =
@@ -968,17 +968,20 @@ bio_kdf_generate(struct sr_crypto_kdfinfo *kdfinfo)
}
void
-bio_kdf_generate(struct sr_crypto_kdfinfo *kdfinfo)
+bio_kdf_generate(struct sr_crypto_kdfinfo *kdfinfo, int hint_rounds)
{
if (!kdfinfo)
errx(1, "invalid KDF info");
- if (rflag == -1)
+ if (rflag == -1) {
rflag = bcrypt_pbkdf_autorounds();
+ if (rflag < hint_rounds)
+ rflag = hint_rounds;
+ }
kdfinfo->pbkdf.generic.len = sizeof(kdfinfo->pbkdf);
kdfinfo->pbkdf.generic.type = SR_CRYPTOKDFT_BCRYPT_PBKDF;
- kdfinfo->pbkdf.rounds = rflag ? rflag : 16;
+ kdfinfo->pbkdf.rounds = rflag;
kdfinfo->flags = SR_CRYPTOKDF_KEY | SR_CRYPTOKDF_HINT;
kdfinfo->len = sizeof(*kdfinfo);
@@ -1097,7 +1100,7 @@ bio_changepass(char *dev)
struct sr_crypto_kdfpair kdfpair;
struct sr_crypto_kdfinfo kdfinfo1, kdfinfo2;
struct sr_crypto_pbkdf kdfhint;
- int rv;
+ int rv, hint_rounds = -1;
memset(, 0, sizeof(bd));
memset(, 0, sizeof(kdfhint));
@@ -1119,14 +1122,14 @@ bio_changepass(char *dev)
bio_kdf_derive(, , "Old passphrase: ", 0);
/*
-* Unless otherwise specified, keep the previous number of rounds
Re: ldd: check read return value to avoid unitialized struct fields
Greg Steuck wrote:
> Thanks for the patch.
>
> I could see some value in tightening the conditions to always check
> `!= expected`. I don't see enough improvement from separating the error
> case of -1 from the incomplete read case considering the otherwise
> identical behavior.
Like this? The int -> size_t promotion can be a different commit or left
out.
---
commit 7663fd702838ae390515cb9326c2706a57a2983b (ldd-read-rv)
from: Lucas
date: Fri Aug 11 11:43:32 2023 UTC
Check for a full read. Don't use warn when errno might be unmodified.
Promote size from int to size_t.
M libexec/ld.so/ldd/ldd.c | 5+ 4-
1 file changed, 5 insertions(+), 4 deletions(-)
diff 7d242c13afd19e56cc21befac2ce5cdc1ac4992b
7663fd702838ae390515cb9326c2706a57a2983b
commit - 7d242c13afd19e56cc21befac2ce5cdc1ac4992b
commit + 7663fd702838ae390515cb9326c2706a57a2983b
blob - 9e8c5065cd843ff36d91efcb868b94ffd4c98365
blob + 16b59a75e63bfe894922c4195aa11cd5e75802a1
--- libexec/ld.so/ldd/ldd.c
+++ libexec/ld.so/ldd/ldd.c
@@ -96,7 +96,8 @@ doit(char *name)
{
Elf_Ehdr ehdr;
Elf_Phdr *phdr;
- int fd, i, size, status, interp=0;
+ size_t size;
+ int fd, i, status, interp=0;
char buf[PATH_MAX];
struct stat st;
void * dlhandle;
@@ -118,8 +119,8 @@ doit(char *name)
return 1;
}
- if (read(fd, , sizeof(ehdr)) < 0) {
- warn("read(%s)", name);
+ if (read(fd, , sizeof(ehdr)) != sizeof(ehdr)) {
+ warnx("%s: incomplete ELF header", name);
close(fd);
return 1;
}
@@ -141,7 +142,7 @@ doit(char *name)
size = ehdr.e_phnum * sizeof(Elf_Phdr);
if (pread(fd, phdr, size, ehdr.e_phoff) != size) {
- warn("read(%s)", name);
+ warnx("%s: incomplete program header", name);
close(fd);
free(phdr);
return 1;
Re: ldd: check read return value to avoid unitialized struct fields
Greg Steuck wrote:
> Thanks for the patch.
>
> I could see some value in tightening the conditions to always check
> `!= expected`. I don't see enough improvement from separating the error
> case of -1 from the incomplete read case considering the otherwise
> identical behavior.
I'll refer to https://marc.info/?l=openbsd-tech=169120238326202=2 :
> What errno is being printed here?
So then it becomes a matter of wanting to signal the user that something
went wrong other than a short read.
Will it be fine to fold into `!= expected` and warning that an
incomplete {ELF,program} header was encountered (the warnx)?
-Lucas
Re: ldd: check read return value to avoid unitialized struct fields
Bump.
---
commit 92f58b2a1cd576c3e72303004388ab1e9709e327 (ldd-read-rv)
from: Lucas
date: Sat Aug 5 16:34:16 2023 UTC
Check {,p}read return values consistently
Check that read performs a full header read. Explicitly check against -1
for failure instead of < 0. Split pread error message between error
handling and short reads. Promote size from int to size_t.
M libexec/ld.so/ldd/ldd.c
diff 194ff02fb6be247e27fe964e901d891d99ec0b74
92f58b2a1cd576c3e72303004388ab1e9709e327
commit - 194ff02fb6be247e27fe964e901d891d99ec0b74
commit + 92f58b2a1cd576c3e72303004388ab1e9709e327
blob - 9e8c5065cd843ff36d91efcb868b94ffd4c98365
blob + 532feb9855a03480c289fa2188768657a4f82e7c
--- libexec/ld.so/ldd/ldd.c
+++ libexec/ld.so/ldd/ldd.c
@@ -96,7 +96,9 @@ doit(char *name)
{
Elf_Ehdr ehdr;
Elf_Phdr *phdr;
- int fd, i, size, status, interp=0;
+ size_t size;
+ ssize_t nr;
+ int fd, i, status, interp=0;
char buf[PATH_MAX];
struct stat st;
void * dlhandle;
@@ -118,11 +120,16 @@ doit(char *name)
return 1;
}
- if (read(fd, , sizeof(ehdr)) < 0) {
+ if ((nr = read(fd, , sizeof(ehdr))) == -1) {
warn("read(%s)", name);
close(fd);
return 1;
}
+ if (nr != sizeof(ehdr)) {
+ warnx("%s: incomplete ELF header", name);
+ close(fd);
+ return 1;
+ }
if (!IS_ELF(ehdr) || ehdr.e_machine != ELF_TARG_MACH) {
warnx("%s: not an ELF executable", name);
@@ -140,12 +147,18 @@ doit(char *name)
err(1, "reallocarray");
size = ehdr.e_phnum * sizeof(Elf_Phdr);
- if (pread(fd, phdr, size, ehdr.e_phoff) != size) {
- warn("read(%s)", name);
+ if ((nr = pread(fd, phdr, size, ehdr.e_phoff)) == -1) {
+ warn("pread(%s)", name);
close(fd);
free(phdr);
return 1;
}
+ if (nr != size) {
+ warnx("%s: incomplete program header", name);
+ close(fd);
+ free(phdr);
+ return 1;
+ }
close(fd);
for (i = 0; i < ehdr.e_phnum; i++)
Re: ldd: check read return value to avoid unitialized struct fields
Theo Buehler wrote:
> > - if (pread(fd, phdr, size, ehdr.e_phoff) != size) {
> > + if ((nr = pread(fd, phdr, size, ehdr.e_phoff)) != -1) {
>
> did you intend to check for == -1?
>
> > warn("read(%s)", name);
>
> should that not say pread?
Indeed, thanks for spotting both things.
---
commit 92f58b2a1cd576c3e72303004388ab1e9709e327 (ldd-read-rv)
from: Lucas
date: Sat Aug 5 16:34:16 2023 UTC
Check {,p}read return values consistently
Check that read performs a full header read. Explicitly check against -1
for failure instead of < 0. Split pread error message between error
handling and short reads. Promote size from int to size_t.
M libexec/ld.so/ldd/ldd.c
diff 194ff02fb6be247e27fe964e901d891d99ec0b74
92f58b2a1cd576c3e72303004388ab1e9709e327
commit - 194ff02fb6be247e27fe964e901d891d99ec0b74
commit + 92f58b2a1cd576c3e72303004388ab1e9709e327
blob - 9e8c5065cd843ff36d91efcb868b94ffd4c98365
blob + 532feb9855a03480c289fa2188768657a4f82e7c
--- libexec/ld.so/ldd/ldd.c
+++ libexec/ld.so/ldd/ldd.c
@@ -96,7 +96,9 @@ doit(char *name)
{
Elf_Ehdr ehdr;
Elf_Phdr *phdr;
- int fd, i, size, status, interp=0;
+ size_t size;
+ ssize_t nr;
+ int fd, i, status, interp=0;
char buf[PATH_MAX];
struct stat st;
void * dlhandle;
@@ -118,11 +120,16 @@ doit(char *name)
return 1;
}
- if (read(fd, , sizeof(ehdr)) < 0) {
+ if ((nr = read(fd, , sizeof(ehdr))) == -1) {
warn("read(%s)", name);
close(fd);
return 1;
}
+ if (nr != sizeof(ehdr)) {
+ warnx("%s: incomplete ELF header", name);
+ close(fd);
+ return 1;
+ }
if (!IS_ELF(ehdr) || ehdr.e_machine != ELF_TARG_MACH) {
warnx("%s: not an ELF executable", name);
@@ -140,12 +147,18 @@ doit(char *name)
err(1, "reallocarray");
size = ehdr.e_phnum * sizeof(Elf_Phdr);
- if (pread(fd, phdr, size, ehdr.e_phoff) != size) {
- warn("read(%s)", name);
+ if ((nr = pread(fd, phdr, size, ehdr.e_phoff)) == -1) {
+ warn("pread(%s)", name);
close(fd);
free(phdr);
return 1;
}
+ if (nr != size) {
+ warnx("%s: incomplete program header", name);
+ close(fd);
+ free(phdr);
+ return 1;
+ }
close(fd);
for (i = 0; i < ehdr.e_phnum; i++)
Re: ldd: check read return value to avoid unitialized struct fields
"Theo de Raadt" wrote:
> Nope, that is not correct.
>
> errno is not being cleared. It just happens to be zero. Future
> code changes could insert another operation above which would set
> errno, and then this would print a report about that error.
Although I was being sarcastic with """Everything is alright""", yes,
correct. Point taken.
> No, your diff is still wrong.
>
> errno is only updated when a system call returns -1.
>
> So your diff is looking at an old, unrelated, errno.
How? This is now correctly looking at errno only when {,p}read returns
-1, and is using warnx in the other cases.
Re: ldd: check read return value to avoid unitialized struct fields
"Theo de Raadt" wrote:
> What errno is being printed here?
"""Everything is alright""" error,
$ : >empty && ./obj/ldd empty
ldd: read(empty): Undefined error: 0
which would be the same as a short read in the pread below.
Bigger suggestion below, addressing both read and pread. Also promoted
size to a size_t, as the multiplication could overflow an int. read < 0
was changed into read == -1 for alignment with read(2).
There are an open and wait that could receive the same < 0 vs == -1
treatment.
Bike can be repainted at will.
-Lucas
---
commit f1255c0035aa37752a298b752fd20215a1d7adef (ldd-read-rv)
from: Lucas
date: Sat Aug 5 14:36:58 2023 UTC
Check {,p}read return values consistently
Check that read performs a full header read. Explicitly check against -1
for failure instead of < 0. Split pread error message between error
handling and short reads. Promote size from int to size_t.
M libexec/ld.so/ldd/ldd.c
diff 7b0c383483702d9a26856c2b4754abb44950ed82
f1255c0035aa37752a298b752fd20215a1d7adef
commit - 7b0c383483702d9a26856c2b4754abb44950ed82
commit + f1255c0035aa37752a298b752fd20215a1d7adef
blob - 9e8c5065cd843ff36d91efcb868b94ffd4c98365
blob + 12777f2420a6a74f9f456f080c207bf47760b258
--- libexec/ld.so/ldd/ldd.c
+++ libexec/ld.so/ldd/ldd.c
@@ -96,7 +96,9 @@ doit(char *name)
{
Elf_Ehdr ehdr;
Elf_Phdr *phdr;
- int fd, i, size, status, interp=0;
+ size_t size;
+ ssize_t nr;
+ int fd, i, status, interp=0;
char buf[PATH_MAX];
struct stat st;
void * dlhandle;
@@ -118,11 +120,16 @@ doit(char *name)
return 1;
}
- if (read(fd, , sizeof(ehdr)) < 0) {
+ if ((nr = read(fd, , sizeof(ehdr))) == -1) {
warn("read(%s)", name);
close(fd);
return 1;
}
+ if (nr != sizeof(ehdr)) {
+ warnx("%s: incomplete ELF header", name);
+ close(fd);
+ return 1;
+ }
if (!IS_ELF(ehdr) || ehdr.e_machine != ELF_TARG_MACH) {
warnx("%s: not an ELF executable", name);
@@ -140,12 +147,18 @@ doit(char *name)
err(1, "reallocarray");
size = ehdr.e_phnum * sizeof(Elf_Phdr);
- if (pread(fd, phdr, size, ehdr.e_phoff) != size) {
+ if ((nr = pread(fd, phdr, size, ehdr.e_phoff)) != -1) {
warn("read(%s)", name);
close(fd);
free(phdr);
return 1;
}
+ if (nr != size) {
+ warnx("%s: incomplete program header", name);
+ close(fd);
+ free(phdr);
+ return 1;
+ }
close(fd);
for (i = 0; i < ehdr.e_phnum; i++)
Re: ldd: check read return value to avoid unitialized struct fields [was "ldd: check {,p}read return
Bump.
Lucas wrote:
> Now with a better subject.
>
> I was also wondering about the lack of pledge() other than the newly
> added one. That goes because dlopen() can do anything?
>
> Lucas wrote:
> > Hi,
> >
> > I wanted to understand how the pledge execpromises commit worked in ldd
> > and went to read it, and noticed that there is both a
> >
> > if (read(fd, , sizeof(ehdr)) < 0) {
> >
> > and a
> >
> > if (pread(fd, phdr, size, ehdr.e_phoff) != size) {
> >
> > In particular, the "read < 0" confused me quite a lot, but the manpage
> > states that, if the file descriptor _is a regular file_ and there are
> > enough bytes, it reads to completion. The check for a being a regular
> > file is already in place, but there is nothing guarding against a short
> > file, so check instead if read == sizeof(ehdr).
> >
> > -Lucas
diff refs/heads/master refs/heads/ldd-read-rv
commit - 7b0c383483702d9a26856c2b4754abb44950ed82
commit + 862cbcc132ebcd92cb4b44eb1b453ea9ada0bbc3
blob - 9e8c5065cd843ff36d91efcb868b94ffd4c98365
blob + ad624d9cd0e72944b93e951de9b31f57a6258601
--- libexec/ld.so/ldd/ldd.c
+++ libexec/ld.so/ldd/ldd.c
@@ -118,7 +118,7 @@ doit(char *name)
return 1;
}
- if (read(fd, , sizeof(ehdr)) < 0) {
+ if (read(fd, , sizeof(ehdr)) != sizeof(ehdr)) {
warn("read(%s)", name);
close(fd);
return 1;
ldd: check read return value to avoid unitialized struct fields [was "ldd: check {,p}read return value consistently"]
Now with a better subject.
I was also wondering about the lack of pledge() other than the newly
added one. That goes because dlopen() can do anything?
Lucas wrote:
> Hi,
>
> I wanted to understand how the pledge execpromises commit worked in ldd
> and went to read it, and noticed that there is both a
>
> if (read(fd, , sizeof(ehdr)) < 0) {
>
> and a
>
> if (pread(fd, phdr, size, ehdr.e_phoff) != size) {
>
> In particular, the "read < 0" confused me quite a lot, but the manpage
> states that, if the file descriptor _is a regular file_ and there are
> enough bytes, it reads to completion. The check for a being a regular
> file is already in place, but there is nothing guarding against a short
> file, so check instead if read == sizeof(ehdr).
>
> -Lucas
diff refs/heads/master refs/heads/ldd-read-rv
commit - 7b0c383483702d9a26856c2b4754abb44950ed82
commit + 862cbcc132ebcd92cb4b44eb1b453ea9ada0bbc3
blob - 9e8c5065cd843ff36d91efcb868b94ffd4c98365
blob + ad624d9cd0e72944b93e951de9b31f57a6258601
--- libexec/ld.so/ldd/ldd.c
+++ libexec/ld.so/ldd/ldd.c
@@ -118,7 +118,7 @@ doit(char *name)
return 1;
}
- if (read(fd, , sizeof(ehdr)) < 0) {
+ if (read(fd, , sizeof(ehdr)) != sizeof(ehdr)) {
warn("read(%s)", name);
close(fd);
return 1;
Re: Zenbleed
, 16MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo acpicmos0 at acpi0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0010" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 function 0 "Qumranet Virtio 1.x GPU" rev 0x01 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci1 at ppb0 bus 1 virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio0 at virtio0: address 96:00:01:e4:f0:79 virtio0: msix shared ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci2 at ppb1 bus 2 xhci0 at pci2 dev 0 function 0 vendor "Red Hat", unknown product 0x000d rev 0x01: apic 0 int 22, xHCI 0.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev 3.00/1.00 addr 1 ppb2 at pci0 dev 2 function 2 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci3 at ppb2 bus 3 virtio1 at pci3 dev 0 function 0 "Qumranet Virtio 1.x Console" rev 0x01 virtio1: no matching child driver; not configured ppb3 at pci0 dev 2 function 3 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci4 at ppb3 bus 4 virtio2 at pci4 dev 0 function 0 vendor "Qumranet", unknown product 0x1045 rev 0x01 viomb0 at virtio2 virtio2: apic 0 int 22 ppb4 at pci0 dev 2 function 4 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci5 at ppb4 bus 5 virtio3 at pci5 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01 viornd0 at virtio3 virtio3: apic 0 int 22 ppb5 at pci0 dev 2 function 5 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci6 at ppb5 bus 6 virtio4 at pci6 dev 0 function 0 "Qumranet Virtio 1.x SCSI" rev 0x01 vioscsi0 at virtio4: qsize 128 scsibus1 at vioscsi0: 255 targets sd0 at scsibus1 targ 0 lun 0: sd0: 39064MB, 512 bytes/sector, 80003072 sectors, thin virtio4: msix shared ppb6 at pci0 dev 2 function 6 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci7 at ppb6 bus 7 ppb7 at pci0 dev 2 function 7 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci8 at ppb7 bus 8 ppb8 at pci0 dev 3 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 23 pci9 at ppb8 bus 9 pcib0 at pci0 dev 31 function 0 "Intel 82801IB LPC" rev 0x02 ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.0 ahci0: port 0: 1.5Gb/s scsibus2 at ahci0: 32 targets cd0 at scsibus2 targ 0 lun 0: removable ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 0 int 16 iic0 at ichiic0 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 uhidev0 at uhub0 port 5 configuration 1 interface 0 "QEMU QEMU USB Tablet" rev 2.00/0.00 addr 2 uhidev0: iclass 3/0 ums0 at uhidev0: 3 buttons, Z dir wsmouse1 at ums0 mux 0 vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (b8f88f9185934966.a) swap on sd0b dump on sd0b -Lucas
ldd: check {,p}read return value consistently
Hi,
I wanted to understand how the pledge execpromises commit worked in ldd
and went to read it, and noticed that there is both a
if (read(fd, , sizeof(ehdr)) < 0) {
and a
if (pread(fd, phdr, size, ehdr.e_phoff) != size) {
In particular, the "read < 0" confused me quite a lot, but the manpage
states that, if the file descriptor _is a regular file_ and there are
enough bytes, it reads to completion. The check for a being a regular
file is already in place, but there is nothing guarding against a short
file, so check instead if read == sizeof(ehdr).
-Lucas
diff refs/heads/master 7e3ddbbb1ef48b81704d0e34d128de01a109fa8c
commit - d50cee607213855e35b101e74926cd801369edd4
commit + 7e3ddbbb1ef48b81704d0e34d128de01a109fa8c
blob - 9e8c5065cd843ff36d91efcb868b94ffd4c98365
blob + ad624d9cd0e72944b93e951de9b31f57a6258601
--- libexec/ld.so/ldd/ldd.c
+++ libexec/ld.so/ldd/ldd.c
@@ -118,7 +118,7 @@ doit(char *name)
return 1;
}
- if (read(fd, , sizeof(ehdr)) < 0) {
+ if (read(fd, , sizeof(ehdr)) != sizeof(ehdr)) {
warn("read(%s)", name);
close(fd);
return 1;
Re: posix_spawn(3): explain that handling NULL envp is an extension
On 2023-06-26, Marc Espie wrote: > Note that a NULL environment is undefined behavior according to POSIX. > If you read the OpenGroup description, it very clearly states that > envp is a pointer to a NULL terminated array. > > Does GNU/Linux at least document that passing a NULL pointer means no > environment for them ? No, GNU/Linux does not document that. Neither NetBSD (which behaves like GNU/Linux on NULL envp) or FreeBSD (which behaves like OpenBSD) document that behavior. All three systems do check envp, handling it as a special case when NULL (either by passing the child an empty environment or a copy of the parent's environment), but none document such behavior. But, since OpenBSD does document such behavior, it is necessary to say that it is a special case not covered by the standard. Either do that or, like the others, do not document it at all.
posix_spawn(3): explain that handling NULL envp is an extension
The manual already describes how posix_spawn(3) behaves when passing it a NULL envp, but does not make it clear that it is an OpenBSD extension: > If envp is NULL, the environment is passed unchanged from the parent > process. That differs from GNU/Linux, for example, where a NULL envp gives the child an empty environment rather than a copy. Index: posix_spawn.3 === RCS file: /cvs/src/lib/libc/gen/posix_spawn.3,v retrieving revision 1.9 diff -u -p -r1.9 posix_spawn.3 --- posix_spawn.3 17 Oct 2017 22:47:58 - 1.9 +++ posix_spawn.3 25 Jun 2023 21:38:47 - @@ -122,6 +122,10 @@ with exit status 127. .Sh STANDARDS Both functions conform to .St -p1003.1-2001 . +.Pp +The handling of NULL +.Fa envp +is an extension to that standard. .Sh HISTORY These functions were ported from .Fx
Re: ksh, test: test -t file descriptor isn't optional
Omar Polo wrote: > sorry for the delay, this is another mail that I meant to take a look > earlier... Thanks for the review, Omar! > > > together with a small > > > rewrite in test_eval TO_FILTT case, as it was a bit too difficult for me > > > to read: it seems that, for legacy reason (haven't looked at the code > > > history), opnd1 could be NULL for TO_FILTT, the only test with such > > > behaviour. My understanding is that ptest_getopnd avoids that by > > > returning "1". So, opnd1 can't be NULL. bi_getn writes to res, but took > > > me a while to understand that looking only at the conditional call of > > > bi_getn in the if condition. Finally, for some reason, is opnd1 managed > > > to be NULL, isatty(0) is called. I believe that the intention was to do > > > > > > res = opnd1 ? isatty(res) : 0; > > > > > > instead. I think the proposed rewrite is easier to follow. > > I think that the rewrite is more complex than needed. I'm attaching a > slightly revised diff that is closer to the current code. I agree and I like your chunk better. I tried to write as dummy-proof as possible so it was easier to follow for me.
Re: Bail out on "id -R user"
Ping.
> According to both usage() and id.1, "id -R" doesn't accept any
> positional arguments. This diff makes program behave like that.
diff refs/heads/master refs/heads/id-R-usage
commit - 55055d619d36cc45f8c6891404c51cd405214e86
commit + 214ec9c042895b8482378b6ee43530ce4ffe9e21
blob - 30e2c58e088b69dba98577693e37dd961b4eadc4
blob + 1f4b678597065fb4243f660b4f66040021c56895
--- usr.bin/id/id.c
+++ usr.bin/id/id.c
@@ -128,6 +128,8 @@ main(int argc, char *argv[])
usage();
if (Rflag) {
+ if (argc != 0)
+ usage();
printf("%d\n", getrtable());
exit(0);
}
Re: ksh, test: test -t file descriptor isn't optional
Ping.
> Hi tech@,
>
> Both test.1 and ksh.1 (under the non-POSIX compatibility flag) state
> that `test -t` will default to test whether fd 1 is a TTY if the
> argument is omitted. This isn't the case, and both treat `-t` as the
> equivalent of `test -n -t`, ie, test if `-t` is a non-empty string,
> trivially true.
>
> It's easy to see it in `test`: it exits right away in switch(argc).
> `ksh` is a bit more difficult to follow: builtins eventually call c_test
> in c_test.c. For `test -t`, c_test will be called with wp being "test",
> "-t". It'll eventually call test_parse, with the test environment set
> with
>
> te.pos.wp = wp + 1;
> te.wp_end = wp + argc;
>
> For this particular case, argc is 2. Bearing that in mind, test_parse
> will make a call stack of test_aexpr -> test_oexpr -> test_nexpr ->
> test_primary. The first 2 ifs are skipped (asuming no TEF_ERROR is set)
> and the next if, which would handle `test -t` gracefully, isn't entered:
> one of the && operands, >pos.wp[1] < te->wp_end, is false.
> Afterwards, `-t` is evaled as TO_SNTZE, ie if it's a non-empty string.
>
> The following diff amends the manpages, removing the "file descriptor
> is optional" parts, and removes the unused machinery of bin/ksh/c_test.c
> to deal with an optional argument in `test -t`, together with a small
> rewrite in test_eval TO_FILTT case, as it was a bit too difficult for me
> to read: it seems that, for legacy reason (haven't looked at the code
> history), opnd1 could be NULL for TO_FILTT, the only test with such
> behaviour. My understanding is that ptest_getopnd avoids that by
> returning "1". So, opnd1 can't be NULL. bi_getn writes to res, but took
> me a while to understand that looking only at the conditional call of
> bi_getn in the if condition. Finally, for some reason, is opnd1 managed
> to be NULL, isatty(0) is called. I believe that the intention was to do
>
> res = opnd1 ? isatty(res) : 0;
>
> instead. I think the proposed rewrite is easier to follow.
>
> Regress is happy, although nothing in there tests `test -t` or `test -t
> n`. Existing scripts shouldn't break with this change: `test -t` will
> keep being true, whether fd 1 is a TTY or not. The diff can be further
> split on man changes and code changes if needed.
>
> btw, the easy test for `test -t` being wrong, whether under POSIX compat
> or not, is
>
> $ test -t 1; echo $? # 1 is TTY in an interactive session
> 0
> $ test -t 1 >&-; echo $? # 1 isn't a TTY because it's closed
> 1
> $ test -t >&-; echo $?
> 0
diff refs/heads/master refs/heads/ksh-t-fd
commit - 55055d619d36cc45f8c6891404c51cd405214e86
commit + 00fa44f8caccc78154e093b5fa719e392716b81e
blob - 7038a52bfa432d515d9683187930407c4d6bd6d5
blob + db16b71a9b64afb7047803c65ec620f03e18e42d
--- bin/ksh/c_test.c
+++ bin/ksh/c_test.c
@@ -156,12 +156,6 @@ c_test(char **wp)
}
if (argc == 1) {
opnd1 = (*te.getopnd)(, TO_NONOP, 1);
- /* Historically, -t by itself test if fd 1
-* is a file descriptor, but POSIX says its
-* a string test...
-*/
- if (!Flag(FPOSIX) && strcmp(opnd1, "-t") == 0)
- break;
res = (*te.eval)(, TO_STNZE, opnd1,
NULL, 1);
if (invert & 1)
@@ -271,14 +265,18 @@ test_eval(Test_env *te, Test_op op, const char *opnd1,
case TO_FILGZ: /* -s */
return stat(opnd1, ) == 0 && b1.st_size > 0L;
case TO_FILTT: /* -t */
- if (opnd1 && !bi_getn(opnd1, )) {
- te->flags |= TEF_ERROR;
- res = 0;
- } else {
- /* generate error if in FPOSIX mode? */
- res = isatty(opnd1 ? res : 0);
+ {
+ int s, v;
+
+ s = bi_getn(opnd1, );
+ if (!s) {
+ te->flags |= TEF_ERROR;
+ res = 0;
+ } else {
+ res = isatty(v);
+ }
+ return res;
}
- return res;
case TO_FILUID: /* -O */
return stat(opnd1, ) == 0 && b1.st_uid == ksheuid;
case TO_FILGID: /* -G */
@@ -527,7 +525,7 @@ ptest_getopnd(Test_env *te, Test_op op, int do_eval)
ptest_getopnd(Test_env *te, Test_op op, int do_eval)
{
if (te->pos.wp >= te->wp_end)
- return op == TO_FILTT ? "1" : NULL;
+ return NULL;
return *te->pos.wp++;
}
blob - cd3bfc3ebf41217b46c69eaff634cd8e9771c425
blob + c8406305e706cff12711bbcb934f13d67f49ebdf
--- bin/ksh/ksh.1
+++
Bail out on "id -R user"
According to both usage() and id.1, "id -R" doesn't accept any
positional arguments. This diff makes program behave like that.
-Lucas
diff refs/heads/master refs/heads/id-R-usage
commit - 55055d619d36cc45f8c6891404c51cd405214e86
commit + 214ec9c042895b8482378b6ee43530ce4ffe9e21
blob - 30e2c58e088b69dba98577693e37dd961b4eadc4
blob + 1f4b678597065fb4243f660b4f66040021c56895
--- usr.bin/id/id.c
+++ usr.bin/id/id.c
@@ -128,6 +128,8 @@ main(int argc, char *argv[])
usage();
if (Rflag) {
+ if (argc != 0)
+ usage();
printf("%d\n", getrtable());
exit(0);
}
Re: ksh, test: test -t file descriptor isn't optional
Several months bump.
Lucas wrote:
> Hi tech@,
>
> Both test.1 and ksh.1 (under the non-POSIX compatibility flag) state
> that `test -t` will default to test whether fd 1 is a TTY if the
> argument is omitted. This isn't the case, and both treat `-t` as the
> equivalent of `test -n -t`, ie, test if `-t` is a non-empty string,
> trivially true.
>
> It's easy to see it in `test`: it exits right away in switch(argc).
> `ksh` is a bit more difficult to follow: builtins eventually call c_test
> in c_test.c. For `test -t`, c_test will be called with wp being "test",
> "-t". It'll eventually call test_parse, with the test environment set
> with
>
> te.pos.wp = wp + 1;
> te.wp_end = wp + argc;
>
> For this particular case, argc is 2. Bearing that in mind, test_parse
> will make a call stack of test_aexpr -> test_oexpr -> test_nexpr ->
> test_primary. The first 2 ifs are skipped (asuming no TEF_ERROR is set)
> and the next if, which would handle `test -t` gracefully, isn't entered:
> one of the && operands, >pos.wp[1] < te->wp_end, is false.
> Afterwards, `-t` is evaled as TO_SNTZE, ie if it's a non-empty string.
>
> The following diff amends the manpages, removing the "file descriptor
> is optional" parts, and removes the unused machinery of bin/ksh/c_test.c
> to deal with an optional argument in `test -t`, together with a small
> rewrite in test_eval TO_FILTT case, as it was a bit too difficult for me
> to read: it seems that, for legacy reason (haven't looked at the code
> history), opnd1 could be NULL for TO_FILTT, the only test with such
> behaviour. My understanding is that ptest_getopnd avoids that by
> returning "1". So, opnd1 can't be NULL. bi_getn writes to res, but took
> me a while to understand that looking only at the conditional call of
> bi_getn in the if condition. Finally, for some reason, is opnd1 managed
> to be NULL, isatty(0) is called. I believe that the intention was to do
>
> res = opnd1 ? isatty(res) : 0;
>
> instead. I think the proposed rewrite is easier to follow.
>
> Regress is happy, although nothing in there tests `test -t` or `test -t
> n`. Existing scripts shouldn't break with this change: `test -t` will
> keep being true, whether fd 1 is a TTY or not. The diff can be further
> split on man changes and code changes if needed.
>
> btw, the easy test for `test -t` being wrong, whether under POSIX compat
> or not, is
>
> $ test -t 1; echo $? # 1 is TTY in an interactive session
> 0
> $ test -t 1 >&-; echo $? # 1 isn't a TTY because it's closed
> 1
> $ test -t >&-; echo $?
> 0
diff refs/heads/master refs/heads/ksh-t-fd
commit - 55055d619d36cc45f8c6891404c51cd405214e86
commit + 00fa44f8caccc78154e093b5fa719e392716b81e
blob - 7038a52bfa432d515d9683187930407c4d6bd6d5
blob + db16b71a9b64afb7047803c65ec620f03e18e42d
--- bin/ksh/c_test.c
+++ bin/ksh/c_test.c
@@ -156,12 +156,6 @@ c_test(char **wp)
}
if (argc == 1) {
opnd1 = (*te.getopnd)(, TO_NONOP, 1);
- /* Historically, -t by itself test if fd 1
-* is a file descriptor, but POSIX says its
-* a string test...
-*/
- if (!Flag(FPOSIX) && strcmp(opnd1, "-t") == 0)
- break;
res = (*te.eval)(, TO_STNZE, opnd1,
NULL, 1);
if (invert & 1)
@@ -271,14 +265,18 @@ test_eval(Test_env *te, Test_op op, const char *opnd1,
case TO_FILGZ: /* -s */
return stat(opnd1, ) == 0 && b1.st_size > 0L;
case TO_FILTT: /* -t */
- if (opnd1 && !bi_getn(opnd1, )) {
- te->flags |= TEF_ERROR;
- res = 0;
- } else {
- /* generate error if in FPOSIX mode? */
- res = isatty(opnd1 ? res : 0);
+ {
+ int s, v;
+
+ s = bi_getn(opnd1, );
+ if (!s) {
+ te->flags |= TEF_ERROR;
+ res = 0;
+ } else {
+ res = isatty(v);
+ }
+ return res;
}
- return res;
case TO_FILUID: /* -O */
return stat(opnd1, ) == 0 && b1.st_uid == ksheuid;
case TO_FILGID: /* -G */
@@ -527,7 +525,7 @@ ptest_getopnd(Test_
Re: xonly on amd64: testing wanted
"Theo de Raadt" wrote:
> So I'd like to recruit some help from those of you capable of building
> your own kernels. Can you apply the following kernel diff, and try the
> applications you are used to. A list of applications that fail on some
> way would be handy. Be sure to ktrace -di then, and check there is a
> SIGSEGV near the end, and include a snippet of that information.
Gave this a shot. In the test program, I get the same results as
> userland kernel
> ld.so 0x59bd652920 readable readable
> mmap xz 0x5a08e6d000 unreadable unreadable
> mmap x 0x5a33152000 readable readable
> mmap nrx0x597c8af000 readable readable
> mmap nwx0x5988309000 readable readable
> mmap xnwx 0x59e6118000 readable readable
> main0x5773dfe390 readable readable
> libc0x5a2ec49b00 readable readable
for both before and after.
I added a printf in amd64/pmap.c:pmap_bootstrap which doesn't get
triggered
+ if (cpuid_level >= 0x7) {
+ uint32_t ecx, dummy;
+ CPUID_LEAF(0x7, 0, dummy, dummy, ecx, dummy);
+ if (ecx & SEFF0ECX_PKU) {
+ lcr4(rcr4() | CR4_PKE);
+ pmap_pke = 1;
+ }
+ }
+ printf("XXX pmap_pke=%d\n", pmap_pke);
Doubting myself, I also added a printf in amd64/cpu.c:cpu_init
lcr4(cr4);
+ printf("XXX cr4=0x%08u\n", cr4);
which yields the following in dmesg:
XXX cr4=0x01312504
XXX cr4=0x01312432
CR4_PKE is defined as 0x0040, so I understand that I don't have
the right bits in my processor to use this. Is that correct?
Nevertheless, I compiled LLVM and then ld.so, and after reboot, some of
my daemons fail to start: i2pd, tor, iked, sshd, unbound_t{1,2} (the
last two being unbound on rdomains 1 and 2). Also, ssh (not sshd)
segfaulted on start, making it impossible for me to write this email,
reason why I'm back on a GENERIC.MP kernel + LLVM + ld.so patches.
For sshd, I got both a ktrace -di and a coredump. I can share both on
request. For a small kdump of sshd,
46155 sshd CALL close(3)
46155 sshd RET close 0
46155 sshd CALL
mmap(0,0x5000,0x3,0x1002,-1,0)
46155 sshd RET mmap 12759024181248/0xb9ab11aa000
46155 sshd CALL mprotect(0xb9ab11ae000,0x1000,0)
46155 sshd RET mprotect 0
46155 sshd CALL kbind(0x7f7e88e8,24,0x9215016ab2963bb4)
46155 sshd RET kbind 0
46155 sshd CALL kbind(0x7f7e88a8,24,0x9215016ab2963bb4)
46155 sshd RET kbind 0
46155 sshd CALL kbind(0x7f7e8828,24,0x9215016ab2963bb4)
46155 sshd RET kbind 0
46155 sshd CALL kbind(0x7f7e8828,24,0x9215016ab2963bb4)
46155 sshd RET kbind 0
46155 sshd CALL kbind(0x7f7e87f8,24,0x9215016ab2963bb4)
46155 sshd RET kbind 0
46155 sshd CALL kbind(0x7f7e87f8,24,0x9215016ab2963bb4)
46155 sshd RET kbind 0
46155 sshd CALL kbind(0x7f7e87f8,24,0x9215016ab2963bb4)
46155 sshd RET kbind 0
46155 sshd CALL kbind(0x7f7e8828,24,0x9215016ab2963bb4)
46155 sshd RET kbind 0
46155 sshd CALL kbind(0x7f7e8828,24,0x9215016ab2963bb4)
46155 sshd RET kbind 0
46155 sshd PSIG SIGSEGV SIG_DFL code=SEGV_ACCERR addr=0xb9b416debc0
trapno=6
46155 sshd NAMI "sshd.core"
For iked, I also have a ktrace -di, but no coredump. Also died from a
SIGSEGV, with the same pattern: repeated kbind calls with the very same
parameters. Given the different subprocesses, it's a bit more noisy to
share directly in the email, but I can also share on request.
dmesg follows.
OpenBSD 7.2-current (XONLY) #2: Thu Jan 19 19:17:53 UTC 2023
lu...@oolong.home.arpa:/usr/src/sys/arch/amd64/compile/XONLY
real mem = 12534018048 (11953MB)
avail mem = 12134768640 (11572MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (70 entries)
bios0: vendor LENOVO version "G2ET33WW (1.13 )" date 07/24/2012
bios0: LENOVO 2325BG4
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF!
UEFI UEFI POAT SSDT SSDT DMAR UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3)
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 1197.34 MHz, 06-3a-09
cpu0:
Re: acme-client: allow configuring key and cert owner
Stuart Henderson wrote:
> On 2022/12/18 03:06, Lucas wrote:
> > The following patch expands acme-client config file `domain` blocks to
> > allow for a `owner user:group` directive, which allows to get rid of
> > customs scripts that "fix" permissions for issued certs, mostly needed
> > in ports land. I don't find it too invasive, so I thought it could be
> > merged. Most of the code and manpage bits were taken from vmd.
>
> Why do you need to chown a certificate? It is published to the world
> anyway in Certificate Transparency logs, what's the problem with
> root-owned and world-readable?
You're absolutely right. And even without CT, the certificate is public,
otherwise you won't be able to establish a TLS session. I guess the
obsessive in me wanted matching ownership for key and cert.
> (There would be more reason to do this for a key, but the existing
> handling seems good enough for that).
Yes, and that partly makes it even less of a case for this patch. There
is still the need to chown to the right user, and currently the handling
of that is manually by the operator. Arguably, currently that only
happens when issuing a certificate for the very first time, or on manual
secret key rotation.
Nevertheless, dropping the cert part is easy, with the upside of not
needing chown pledge anymore in the patch. It was a fun learning
experience. I'll stop pursuing the patch, but leave the final version
anyways.
-Lucas
diff /usr/src
commit - 93aad84f8cf14cfaff5b9cdb67494e561810ddc4
path + /usr/src
blob - eb5f19eb298c117c3957faa0ed6ced14972ffaca
file + usr.sbin/acme-client/acme-client.conf.5
--- usr.sbin/acme-client/acme-client.conf.5
+++ usr.sbin/acme-client/acme-client.conf.5
@@ -131,7 +131,7 @@ plain domain name forms.
The common name is included automatically if this option is present,
but there is no automatic conversion/inclusion between "www." and
plain domain name forms.
-.It Ic domain key Ar file Op Ar keytype
+.It Ic domain key Ar file Oo Ar keytype Oc Oo Ic owner Ar user : Ns Ar group Oc
The private key file for which the certificate will be obtained.
.Ar keytype
can be
@@ -146,6 +146,18 @@ or secp384r1 for
.Cm rsa
or secp384r1 for
.Cm ecdsa ) .
+If
+.Cm owner
+is given, set the key owner to
+.Ar user
+and
+.Ar group .
+If only
+.Ar user
+is given, only the user is set.
+If only
+.Pf : Ar group
+is given, only the group is set.
.It Ic domain certificate Ar file
The filename of the certificate that will be issued.
This is optional if
blob - 4b43b6ef4ac302706859bf14b681cf8052aa55c8
file + usr.sbin/acme-client/extern.h
--- usr.sbin/acme-client/extern.h
+++ usr.sbin/acme-client/extern.h
@@ -209,7 +209,7 @@ int keyproc(int, const char *, const char **,
size_t
int fileproc(int, const char *, const char *, const char *,
const char *);
int keyproc(int, const char *, const char **, size_t,
- enum keytype);
+ enum keytype, uid_t, gid_t);
int netproc(int, int, int, int, int, int, int,
struct authority_c *, const char *const *,
size_t);
blob - a3bc2796c30b97c5628e5f3d350a765c87cb
file + usr.sbin/acme-client/keyproc.c
--- usr.sbin/acme-client/keyproc.c
+++ usr.sbin/acme-client/keyproc.c
@@ -75,7 +75,7 @@ keyproc(int netsock, const char *keyfile, const char *
*/
int
keyproc(int netsock, const char *keyfile, const char **alts, size_t altsz,
-enum keytype keytype)
+enum keytype keytype, uid_t uid, gid_t gid)
{
char*der64 = NULL, *der = NULL, *dercp;
char*sans = NULL, *san = NULL;
@@ -97,7 +97,18 @@ keyproc(int netsock, const char *keyfile, const char *
prev = umask((S_IWUSR | S_IXUSR) | S_IRWXG | S_IRWXO);
if ((f = fopen(keyfile, "r")) == NULL && errno == ENOENT) {
+ int fd;
+
f = fopen(keyfile, "wx");
+ if (f != NULL) {
+ fd = fileno(f);
+ if (fd >= 0) {
+ if (fchown(fd, uid, gid) == -1) {
+ warn("chown %s", keyfile);
+ goto out;
+ }
+ }
+ }
newkey = 1;
}
umask(prev);
blob - bec17254297fb1e770411c1cb8ddb718e150ee0f
file + usr.sbin/acme-client/main.c
--- usr.sbin/acme-client/main.c
+++ usr.sbin/acme-client/main.c
@@ -248,7 +248,7 @@ main(int argc, char *argv[])
close(file_fds[1]);
c = keyproc(key_fds[0], domain->key,
(const char **)alts, altsz,
- domain->keytype);
+ domain->keytype, domain->owner.uid, domain->owner.gid);
exit(c ? EXIT_SUCCESS : E
Re: acme-client: allow configuring key and cert owner
Lucas wrote:
> Hi tech@,
>
> The following patch expands acme-client config file `domain` blocks to
> allow for a `owner user:group` directive, which allows to get rid of
> customs scripts that "fix" permissions for issued certs, mostly needed
> in ports land. I don't find it too invasive, so I thought it could be
> merged. Most of the code and manpage bits were taken from vmd.
>
> Noteworthy details:
>
> 1. fileproc.c pledge is expanded with chown. In particular, I don't
>understand pledge manpage: I was under the impression that wpath and
>fattr would allow for fchown, but I got an "Operation not supported"
>while testing. I guess this is related to the paragraph stating that
>some syscalls be allowed with limitations under some categories.
> 2. if the private key already exists, keyproc.c won't interfere with its
>ownership, the same way it does now. The fchown call can be moved if
>"fixing" the ownership is desirable.
After checking chown(2), -1 seems more sensible as the default values
for [gu]id, instead of 0.
-Lucas
diff /usr/src
commit - 93aad84f8cf14cfaff5b9cdb67494e561810ddc4
path + /usr/src
blob - eb5f19eb298c117c3957faa0ed6ced14972ffaca
file + usr.sbin/acme-client/acme-client.conf.5
--- usr.sbin/acme-client/acme-client.conf.5
+++ usr.sbin/acme-client/acme-client.conf.5
@@ -197,6 +197,17 @@ will be used.
If it is not specified, a default of
.Pa /var/www/acme
will be used.
+.It Ic owner Ar user : Ns Ar group
+Set the owner of the key and certificate files create to
+.Ar user
+and
+.Ar group .
+If only
+.Ar user
+is given, only the user is set.
+If only
+.Pf : Ar group
+is given, only the group is set.
.El
.Sh FILES
.Bl -tag -width /etc/examples/acme-client.conf -compact
blob - 4b43b6ef4ac302706859bf14b681cf8052aa55c8
file + usr.sbin/acme-client/extern.h
--- usr.sbin/acme-client/extern.h
+++ usr.sbin/acme-client/extern.h
@@ -207,9 +207,9 @@ int fileproc(int, const char *, const char *,
const
int revokeproc(int, const char *, int, int, const char *const *,
size_t);
int fileproc(int, const char *, const char *, const char *,
- const char *);
+ const char *, uid_t, gid_t);
int keyproc(int, const char *, const char **, size_t,
- enum keytype);
+ enum keytype, uid_t, gid_t);
int netproc(int, int, int, int, int, int, int,
struct authority_c *, const char *const *,
size_t);
blob - b8b8651c31907c6d37147c779f302481a1cb3c86
file + usr.sbin/acme-client/fileproc.c
--- usr.sbin/acme-client/fileproc.c
+++ usr.sbin/acme-client/fileproc.c
@@ -29,7 +29,8 @@ serialise(const char *real, const char *v, size_t vsz,
#include "extern.h"
static int
-serialise(const char *real, const char *v, size_t vsz, const char *v2, size_t
v2sz)
+serialise(const char *real, const char *v, size_t vsz, const char *v2,
+size_t v2sz, uid_t uid, gid_t gid)
{
int fd;
char *tmp;
@@ -64,6 +65,10 @@ serialise(const char *real, const char *v, size_t vsz,
warn("fchmod");
goto out;
}
+ if (fchown(fd, uid, gid) == -1) {
+ warn("fchown");
+ goto out;
+ }
if ((ssize_t)vsz != write(fd, v, vsz)) {
warnx("write");
goto out;
@@ -91,7 +96,7 @@ fileproc(int certsock, const char *certdir, const char
int
fileproc(int certsock, const char *certdir, const char *certfile, const char
-*chainfile, const char *fullchainfile)
+*chainfile, const char *fullchainfile, uid_t uid, gid_t gid)
{
char*csr = NULL, *ch = NULL;
size_t chsz, csz;
@@ -108,7 +113,7 @@ fileproc(int certsock, const char *certdir, const char
* rpath and cpath for rename, wpath and cpath for
* writing to the temporary. fattr for fchmod.
*/
- if (pledge("stdio cpath wpath rpath fattr", NULL) == -1) {
+ if (pledge("stdio cpath wpath rpath fattr chown", NULL) == -1) {
warn("pledge");
goto out;
}
@@ -173,7 +178,7 @@ fileproc(int certsock, const char *certdir, const char
goto out;
if (chainfile) {
- if (!serialise(chainfile, ch, chsz, NULL, 0))
+ if (!serialise(chainfile, ch, chsz, NULL, 0, uid, gid))
goto out;
dodbg("%s: created", chainfile);
@@ -190,7 +195,7 @@ fileproc(int certsock, const char *certdir, const char
goto out;
if (certfile) {
- if (!serialise(certfile, csr, csz, NULL, 0))
+ if (!serialise(certfile, csr, csz, NULL, 0, uid,
acme-client: allow configuring key and cert owner
Hi tech@,
The following patch expands acme-client config file `domain` blocks to
allow for a `owner user:group` directive, which allows to get rid of
customs scripts that "fix" permissions for issued certs, mostly needed
in ports land. I don't find it too invasive, so I thought it could be
merged. Most of the code and manpage bits were taken from vmd.
Noteworthy details:
1. fileproc.c pledge is expanded with chown. In particular, I don't
understand pledge manpage: I was under the impression that wpath and
fattr would allow for fchown, but I got an "Operation not supported"
while testing. I guess this is related to the paragraph stating that
some syscalls be allowed with limitations under some categories.
2. if the private key already exists, keyproc.c won't interfere with its
ownership, the same way it does now. The fchown call can be moved if
"fixing" the ownership is desirable.
bye,
-Lucas
diff /usr/src
commit - 93aad84f8cf14cfaff5b9cdb67494e561810ddc4
path + /usr/src
blob - eb5f19eb298c117c3957faa0ed6ced14972ffaca
file + usr.sbin/acme-client/acme-client.conf.5
--- usr.sbin/acme-client/acme-client.conf.5
+++ usr.sbin/acme-client/acme-client.conf.5
@@ -197,6 +197,17 @@ will be used.
If it is not specified, a default of
.Pa /var/www/acme
will be used.
+.It Ic owner Ar user : Ns Ar group
+Set the owner of the key and certificate files create to
+.Ar user
+and
+.Ar group .
+If only
+.Ar user
+is given, only the user is set.
+If only
+.Pf : Ar group
+is given, only the group is set.
.El
.Sh FILES
.Bl -tag -width /etc/examples/acme-client.conf -compact
blob - 4b43b6ef4ac302706859bf14b681cf8052aa55c8
file + usr.sbin/acme-client/extern.h
--- usr.sbin/acme-client/extern.h
+++ usr.sbin/acme-client/extern.h
@@ -207,9 +207,9 @@ int fileproc(int, const char *, const char *,
const
int revokeproc(int, const char *, int, int, const char *const *,
size_t);
int fileproc(int, const char *, const char *, const char *,
- const char *);
+ const char *, uid_t, gid_t);
int keyproc(int, const char *, const char **, size_t,
- enum keytype);
+ enum keytype, uid_t, gid_t);
int netproc(int, int, int, int, int, int, int,
struct authority_c *, const char *const *,
size_t);
blob - b8b8651c31907c6d37147c779f302481a1cb3c86
file + usr.sbin/acme-client/fileproc.c
--- usr.sbin/acme-client/fileproc.c
+++ usr.sbin/acme-client/fileproc.c
@@ -29,7 +29,8 @@ serialise(const char *real, const char *v, size_t vsz,
#include "extern.h"
static int
-serialise(const char *real, const char *v, size_t vsz, const char *v2, size_t
v2sz)
+serialise(const char *real, const char *v, size_t vsz, const char *v2,
+size_t v2sz, uid_t uid, gid_t gid)
{
int fd;
char *tmp;
@@ -64,6 +65,10 @@ serialise(const char *real, const char *v, size_t vsz,
warn("fchmod");
goto out;
}
+ if (fchown(fd, uid, gid) == -1) {
+ warn("fchown");
+ goto out;
+ }
if ((ssize_t)vsz != write(fd, v, vsz)) {
warnx("write");
goto out;
@@ -91,7 +96,7 @@ fileproc(int certsock, const char *certdir, const char
int
fileproc(int certsock, const char *certdir, const char *certfile, const char
-*chainfile, const char *fullchainfile)
+*chainfile, const char *fullchainfile, uid_t uid, gid_t gid)
{
char*csr = NULL, *ch = NULL;
size_t chsz, csz;
@@ -108,7 +113,7 @@ fileproc(int certsock, const char *certdir, const char
* rpath and cpath for rename, wpath and cpath for
* writing to the temporary. fattr for fchmod.
*/
- if (pledge("stdio cpath wpath rpath fattr", NULL) == -1) {
+ if (pledge("stdio cpath wpath rpath fattr chown", NULL) == -1) {
warn("pledge");
goto out;
}
@@ -173,7 +178,7 @@ fileproc(int certsock, const char *certdir, const char
goto out;
if (chainfile) {
- if (!serialise(chainfile, ch, chsz, NULL, 0))
+ if (!serialise(chainfile, ch, chsz, NULL, 0, uid, gid))
goto out;
dodbg("%s: created", chainfile);
@@ -190,7 +195,7 @@ fileproc(int certsock, const char *certdir, const char
goto out;
if (certfile) {
- if (!serialise(certfile, csr, csz, NULL, 0))
+ if (!serialise(certfile, csr, csz, NULL, 0, uid, gid))
goto out;
dodbg("%s: created", certfile);
@@ -204,7 +209,7 @@ fileproc(int certsock, const char *certdir, const char
*/
if (fullchainfile
Re: ksh, test: test -t file descriptor isn't optional
Bump. In the meantime I did some digging. The issue was introduced by
r1.18, 2009-03-01. There, `test -t` should've worked as advertised, as
the first check in test_primary would be whether the operand is unary.
> Hi tech@,
>
> Both test.1 and ksh.1 (under the non-POSIX compatibility flag) state
> that `test -t` will default to test whether fd 1 is a TTY if the
> argument is omitted. This isn't the case, and both treat `-t` as the
> equivalent of `test -n -t`, ie, test if `-t` is a non-empty string,
> trivially true.
>
> It's easy to see it in `test`: it exits right away in switch(argc).
> `ksh` is a bit more difficult to follow: builtins eventually call c_test
> in c_test.c. For `test -t`, c_test will be called with wp being "test",
> "-t". It'll eventually call test_parse, with the test environment set
> with
>
> te.pos.wp = wp + 1;
> te.wp_end = wp + argc;
>
> For this particular case, argc is 2. Bearing that in mind, test_parse
> will make a call stack of test_aexpr -> test_oexpr -> test_nexpr ->
> test_primary. The first 2 ifs are skipped (asuming no TEF_ERROR is set)
> and the next if, which would handle `test -t` gracefully, isn't entered:
> one of the && operands, >pos.wp[1] < te->wp_end, is false.
> Afterwards, `-t` is evaled as TO_SNTZE, ie if it's a non-empty string.
>
> The following diff amends the manpages, removing the "file descriptor
> is optional" parts, and removes the unused machinery of bin/ksh/c_test.c
> to deal with an optional argument in `test -t`, together with a small
> rewrite in test_eval TO_FILTT case, as it was a bit too difficult for me
> to read: it seems that, for legacy reason (haven't looked at the code
> history), opnd1 could be NULL for TO_FILTT, the only test with such
> behaviour. My understanding is that ptest_getopnd avoids that by
> returning "1". So, opnd1 can't be NULL. bi_getn writes to res, but took
> me a while to understand that looking only at the conditional call of
> bi_getn in the if condition. Finally, for some reason, is opnd1 managed
> to be NULL, isatty(0) is called. I believe that the intention was to do
>
> res = opnd1 ? isatty(res) : 0;
>
> instead. I think the proposed rewrite is easier to follow.
>
> Regress is happy, although nothing in there tests `test -t` or `test -t
> n`. Existing scripts shouldn't break with this change: `test -t` will
> keep being true, whether fd 1 is a TTY or not. The diff can be further
> split on man changes and code changes if needed.
>
> btw, the easy test for `test -t` being wrong, whether under POSIX compat
> or not, is
>
> $ test -t 1; echo $? # 1 is TTY in an interactive session
> 0
> $ test -t 1 >&-; echo $? # 1 isn't a TTY because it's closed
> 1
> $ test -t >&-; echo $?
> 0
bye,
Lucas
diff 45d281fcfba6e40007d9a498265cdbf711d94ed0
ebffbda379cd24f3bb8c9e43b712b9d699c9980c
commit - 45d281fcfba6e40007d9a498265cdbf711d94ed0
commit + ebffbda379cd24f3bb8c9e43b712b9d699c9980c
blob - 7038a52bfa432d515d9683187930407c4d6bd6d5
blob + db16b71a9b64afb7047803c65ec620f03e18e42d
--- bin/ksh/c_test.c
+++ bin/ksh/c_test.c
@@ -156,12 +156,6 @@ c_test(char **wp)
}
if (argc == 1) {
opnd1 = (*te.getopnd)(, TO_NONOP, 1);
- /* Historically, -t by itself test if fd 1
-* is a file descriptor, but POSIX says its
-* a string test...
-*/
- if (!Flag(FPOSIX) && strcmp(opnd1, "-t") == 0)
- break;
res = (*te.eval)(, TO_STNZE, opnd1,
NULL, 1);
if (invert & 1)
@@ -271,14 +265,18 @@ test_eval(Test_env *te, Test_op op, const char *opnd1,
case TO_FILGZ: /* -s */
return stat(opnd1, ) == 0 && b1.st_size > 0L;
case TO_FILTT: /* -t */
- if (opnd1 && !bi_getn(opnd1, )) {
- te->flags |= TEF_ERROR;
- res = 0;
- } else {
- /* generate error if in FPOSIX mode? */
- res = isatty(opnd1 ? res : 0);
+ {
+ int s, v;
+
+ s = bi_getn(opnd1, );
+ if (!s) {
+ te->flags |= TEF_ERROR;
+ res = 0;
+ } else {
+ res = isatty(v);
+ }
+ return res;
ksh, test: test -t file descriptor isn't optional
Hi tech@,
Both test.1 and ksh.1 (under the non-POSIX compatibility flag) state
that `test -t` will default to test whether fd 1 is a TTY if the
argument is omitted. This isn't the case, and both treat `-t` as the
equivalent of `test -n -t`, ie, test if `-t` is a non-empty string,
trivially true.
It's easy to see it in `test`: it exits right away in switch(argc).
`ksh` is a bit more difficult to follow: builtins eventually call c_test
in c_test.c. For `test -t`, c_test will be called with wp being "test",
"-t". It'll eventually call test_parse, with the test environment set
with
te.pos.wp = wp + 1;
te.wp_end = wp + argc;
For this particular case, argc is 2. Bearing that in mind, test_parse
will make a call stack of test_aexpr -> test_oexpr -> test_nexpr ->
test_primary. The first 2 ifs are skipped (asuming no TEF_ERROR is set)
and the next if, which would handle `test -t` gracefully, isn't entered:
one of the && operands, >pos.wp[1] < te->wp_end, is false.
Afterwards, `-t` is evaled as TO_SNTZE, ie if it's a non-empty string.
The following diff amends the manpages, removing the "file descriptor
is optional" parts, and removes the unused machinery of bin/ksh/c_test.c
to deal with an optional argument in `test -t`, together with a small
rewrite in test_eval TO_FILTT case, as it was a bit too difficult for me
to read: it seems that, for legacy reason (haven't looked at the code
history), opnd1 could be NULL for TO_FILTT, the only test with such
behaviour. My understanding is that ptest_getopnd avoids that by
returning "1". So, opnd1 can't be NULL. bi_getn writes to res, but took
me a while to understand that looking only at the conditional call of
bi_getn in the if condition. Finally, for some reason, is opnd1 managed
to be NULL, isatty(0) is called. I believe that the intention was to do
res = opnd1 ? isatty(res) : 0;
instead. I think the proposed rewrite is easier to follow.
Regress is happy, although nothing in there tests `test -t` or `test -t
n`. Existing scripts shouldn't break with this change: `test -t` will
keep being true, whether fd 1 is a TTY or not. The diff can be further
split on man changes and code changes if needed.
btw, the easy test for `test -t` being wrong, whether under POSIX compat
or not, is
$ test -t 1; echo $? # 1 is TTY in an interactive session
0
$ test -t 1 >&-; echo $? # 1 isn't a TTY because it's closed
1
$ test -t >&-; echo $?
0
bye,
Lucas
diff 45d281fcfba6e40007d9a498265cdbf711d94ed0
ebffbda379cd24f3bb8c9e43b712b9d699c9980c
commit - 45d281fcfba6e40007d9a498265cdbf711d94ed0
commit + ebffbda379cd24f3bb8c9e43b712b9d699c9980c
blob - 7038a52bfa432d515d9683187930407c4d6bd6d5
blob + db16b71a9b64afb7047803c65ec620f03e18e42d
--- bin/ksh/c_test.c
+++ bin/ksh/c_test.c
@@ -156,12 +156,6 @@ c_test(char **wp)
}
if (argc == 1) {
opnd1 = (*te.getopnd)(, TO_NONOP, 1);
- /* Historically, -t by itself test if fd 1
-* is a file descriptor, but POSIX says its
-* a string test...
-*/
- if (!Flag(FPOSIX) && strcmp(opnd1, "-t") == 0)
- break;
res = (*te.eval)(, TO_STNZE, opnd1,
NULL, 1);
if (invert & 1)
@@ -271,14 +265,18 @@ test_eval(Test_env *te, Test_op op, const char *opnd1,
case TO_FILGZ: /* -s */
return stat(opnd1, ) == 0 && b1.st_size > 0L;
case TO_FILTT: /* -t */
- if (opnd1 && !bi_getn(opnd1, )) {
- te->flags |= TEF_ERROR;
- res = 0;
- } else {
- /* generate error if in FPOSIX mode? */
- res = isatty(opnd1 ? res : 0);
+ {
+ int s, v;
+
+ s = bi_getn(opnd1, );
+ if (!s) {
+ te->flags |= TEF_ERROR;
+ res = 0;
+ } else {
+ res = isatty(v);
+ }
+ return res;
}
- return res;
case TO_FILUID: /* -O */
return stat(opnd1, ) == 0 && b1.st_uid == ksheuid;
case TO_FILGID: /* -G */
@@ -527,7 +525,7 @@ ptest_getopnd(Test_env *te, Test_op op, int do_eval)
ptest_getopnd(Test_env *te, Test_op op, int do_eval)
{
if (te->pos.wp >= te->wp_end)
- return op == TO_FILTT ? "1" : NULL;
+ return NULL;
return *te->pos.wp++;
}
b
OpenSSH and -current out-of-tree patched for ~C?
Hi tech@, I noticed that ~C stopped working in my -current, from last Saturday, holding the message "commandline disabled". The rest of the ~-escapes work tho, and ~C is no longer present in ~?. Went to check the code, currenlty sitting on Git commit e0b284df3ba7772329d85f200545e3bc5a84d54e only to find out that there are no instances of that message in it. A `make` later, the "classic" behaviour is restored. 1. For how long this experiment is going to last? Is there a way to disable it? I tried with `permitlocalcommand=yes` with no success. 2. Can I see the patch? And more generally, is there a way to know of this experiments other than running into them? TIA,
Re: M1 Macmini lost hw.cpuspeed
On Mon, Oct 24, 2022 at 04:37:14PM +0200, Otto Moerbeek wrote: > On Mon, Oct 24, 2022 at 04:15:40PM +0200, Mark Kettenis wrote: > > > > Date: Mon, 24 Oct 2022 14:52:00 +0200 > > > From: Robert Nagy > > > > > > On 24/10/22 14:49 +0200, Theo Buehler wrote: > > > > On Mon, Oct 24, 2022 at 09:24:14AM +0200, Otto Moerbeek wrote: > > > > > Hello, > > > > > > > > > > after updating my M1 macmini after my vacatiuon to the latest snap it > > > > > seems to have lost a few sysctl nodes, making apm(8) fail: > > > > > > > > > > [otto@macmini:4]$ ktrace apm > > > > > Battery state: unknown, 0% remaining, unknown life estimate > > > > > AC adapter state: not known > > > > > Performance adjustment mode: invalid (0 MHz) > > > > > > > > > > ... > > > > > 88255 apm CALL > > > > > sysctl(6.12,0x7f10d4,0x7f10c8,0,0) > > > > > 88255 apm RET sysctl -1 errno 45 Operation not supported > > > > > ... > > > > > > > > > > > > > > > Beforre I spend time on this, does anybody have a clue? > > > > > > > > > > -Otto > > > > > > > > > > > > > I'm seeing the same on my m1 mini. Reverting the commit below fixes it > > > > for me. > > > > > > Maybe you need a new u-boot that has the new tree? > > > > Yes there has been some churn in this area in the device tree and I > > removed backwards compatibility for the old old way this was done. > > > > Now the question is when did you install OpenBSD? If you have a > > directory called M1N1 on your msdos partition with the file BOOT.BIN > > in it, this will be fairly easy to fix. Download > > > > https://cdn.asahilinux.org/os/uefi-only-20220717-1.zip > > > > unzip it and copy esp/m1n1/boot.bin to your msdos partition. Maybe > > make a copy of the old file first (and leave it in that directory) > > just in case. > > > > If not, fixing this will be a little bit more involved, and I need to > > figure out instructions. I'm pretty sure this is the case for tb@. > > > > Cheers, > > > > Mark > > Hi, > > the instructions worked for me, thanks! > > -Otto > Same here, thanks! Lucas
Re: hidmt: clickpad detection
On Tue, Sep 13, 2022 at 11:06:33PM +0200, Ulf Brosziewski wrote: > The diff below improves the way hidmt identifies clickpads, and > addresses the problems described in > https://marc.info/?l=openbsd-tech=165296530618617=2 > and > https://marc.info/?l=openbsd-tech=165980534415586=2 > > If devices don't report a HUD_BUTTON_TYPE property, the driver checks > whether they claim to have an external left button, and if they do, > hidmt doesn't treat them as clickpads. > > I think this part of the logic should be turned around: hidmt should > treat everything as clickpad except if there is no "clickpad button" > (HUP_BUTTON 1) *and* both an external left and an external right button > (HUP BUTTON 2 and 3) are being reported. Touchpads without the internal > button are still usable with the clickpad configuration, it does less > harm to err on this side. > > Tests and OKs would be welcome. Not qualified to give an OK, but I've been running this for the past few days on a second gen Framework and double/triple click works as expected. Lucas
Re: sysupgrade: apply bsd.re-config(5) to /bsd.upgrade
Klemens Nanni wrote: > On Tue, Sep 06, 2022 at 05:50:31PM +0000, Lucas wrote: > > Sorry for the noise. I wasn't aware that `set -e` only takes into > > consideration the last command in an AND-OR list and not the exit status > > of the AND-OR list itself. > > What is the status of the list itself? > A && B > returns the exit code of A if it is non-zero or the exit code of B if > A exited non-zero. It's becoming a bit off-topic to the patch itself, but... What you say is correct. The problem is the interaction with set -e. If you have scripts # test1.sh false echo $? and # test2.sh false && true echo $? both `sh test1.sh` and `sh test2.sh` will output "1". If instead are run as `sh -e test1.sh` and `sh -e test2.sh`, only test2.sh will output "1". My original understanding was that neither should output at all. Behaviour is the same using ksh instead of sh. The normative reference is https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set . It's just another case of `set -e` acting unintuitively. > Oh dear... these mistakes slip in if you test a diff on one machine and > reconstruct it on another rather than copying over a patch file. Been there done that.
Re: sysupgrade: apply bsd.re-config(5) to /bsd.upgrade
Klemens Nanni wrote: > Yes I want it to fail, just like reorder_kernel.sh using `set -o errexit' > does with > [ -f /etc/bsd.re-config ] && config -e -c /etc/bsd.re-config -f bsd > > If the config file exists but is invalid, I expect programs using it to fail. Sorry for the noise. I wasn't aware that `set -e` only takes into consideration the last command in an AND-OR list and not the exit status of the AND-OR list itself. > install -F -m 700 bsd.rd /bsd.upgrade > +if [ -f /etc/bsd.re-config ] && > + config -e -c /etc/bsd.re-config -f /bsd.upgrade >/dev/null > logger -t sysupgrade -p kern.info "installed new /bsd.upgrade. Old kernel > version: $(sysctl -n kern.version)" Nevertheless, the thing that prompted me to reply was that the current patch reads `if cmd && something`. It should either what I replied, or the leading `if` should be dropped.
Re: sysupgrade: apply bsd.re-config(5) to /bsd.upgrade
Klemens Nanni wrote:
> On rare occasions, I need 'disable xxx' in /etc/bsd.re-config to be able to
> boot a system, e.g. to ignore quirky devices crashing drivers during attach.
>
> bsd.re-config(5) currently applies to GENERIC(.MP) /bsd alone, but /bsd.rd
> and /bsd.upgrade RAMDISK kernels will require the same quirks to avoid
> crashes.
>
> I currently hit this with arc(4) and one specific RAID card on sparc64 where
> manually editing /bsd.upgrade each time I sysupgrade(8) until arc(4) is
> fixed annoys me.
>
> So copy over the bits from libexec/reorder_kernel/reorder_kernel.sh to make
> sysupgrade produce bootable kernels.
>
> reorder_kernel output lands in some log, but running config(8) in sysupgrade
> would print on stdout, which looks ugly, so hide the output we're not really
> interested in, anyway:
>
> # cat /etc/bsd.re-config
> disable arc
> # config -e -c /etc/bsd.re-config -f /bsd.rd
> OpenBSD 7.2-beta (RAMDISK) #1377: Fri Sep 2 19:05:24 MDT 2022
>
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK
> disable arc
>83 arc* disabled
> Saving modified kernel.
>
>
> Feedback? Objection? OK?
>
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.48
> diff -u -p -r1.48 sysupgrade.sh
> --- sysupgrade.sh 8 Jun 2022 09:03:11 - 1.48
> +++ sysupgrade.sh 6 Sep 2022 15:00:49 -
> @@ -208,6 +208,8 @@ fi
> VNAME="${_NEXTKERNV[0]}" fw_update -p ${FW_URL} || true
>
> install -F -m 700 bsd.rd /bsd.upgrade
> +if [ -f /etc/bsd.re-config ] &&
> + config -e -c /etc/bsd.re-config -f /bsd.upgrade >/dev/null
> logger -t sysupgrade -p kern.info "installed new /bsd.upgrade. Old kernel
> version: $(sysctl -n kern.version)"
> sync
>
I think you meant
if [ -f /etc/bsd.re-config ]; then
config -e -c /etc/bsd.re-config -f /bsd.upgrade >/dev/null
fi
in here. Given that the script is `set -e` at the very beginning, you
can't use && without making the script fail if /etc/bsd.re-config
doesn't exists.
-Lucas
/etc/rc.d/iked regression after r1.9
Hello tech@,
commit r1.9 removed the rc_exec call in iked's rc_pre. Because of that,
the exit code of rc_pre is that of the && list. In the case of
sasyncd_flags=NO, this means that rc_pre fails and triggers the break
in the while true loop in rc_cmd start case. I solved this using the
same approach as in isakmpd rc file: hardcoding a return 0 afterwards.
The other alternative is using an if instead of && list, idiom which I
prefer, but haven't seen much in these files.
-Lucas
diff /usr/src
commit - a300f670c8e17f72646e4eaedfbfeb3ce01a295f
path + /usr/src
blob - 8cfb786e6a883c83d4d27de65fb55ce894632cab
file + etc/rc.d/iked
--- etc/rc.d/iked
+++ etc/rc.d/iked
@@ -15,6 +15,7 @@ rc_configtest() {
rc_pre() {
[[ ${sasyncd_flags} != NO ]] &&
daemon_flags="-S ${daemon_flags}"
+ return 0
}
rc_cmd $1
Introduce spkrcat (was Re: speaker(4): unhook driver and manpage from build)
Scott Cheloha wrote:
> speaker(4) is a whimsical thing, but I don't think we should have a
> dedicated chiptune interpreter in the kernel.
>
> This patch unhooks the driver and the manpage from the build. The
> driver is built for alpha, amd64, and i386.
>
> A subsequent patch will move all relevant files to the attic and clean
> up manpage cross references.
>
> Nothing in base or xenocara includes .
>
> I see a couple SPKRTONE and SPKRTUNE symbols in ports, but I imagine
> those ports don't use the symbols if they are missing.
>
> ok?
Hello tech@,
So, after the proposal to remove speaker(4), it came up that parsing the
play string in the kernel might not be the nicest thing. Here there is a
first approach to do that. spkrcat is a CLI that takes the play string
as an argument, parses it, and use the appropiate ioctl to play it.
Name is inspired by aucat.
DIFFERENCES WITH spkr.c IMPLEMENTATION
- slightly verbose identifiers names.
- more chatty.
- sound duration math is slightly different:
- for dotted notes, this is not computed correctly in kernelland: for
example, with default articulation (7/8th play time, 1/8th rest
time) and one dot, total length is computed as 25/16th of original
duration instead of 3/2th (== 24/16th).
After compiling with SPKRDEBUG, with 'T60 L4 c.', the total duration
should be 1500ms: spkrcat does this in 1313ms of sound + 187ms of
silence. spkr(4) computes this as 1375ms of sound + 187ms of
silence.
- even for non-dotted notes, I perceived sound duration slightly
different. Maybe related to "rounding errors" in kernelland?
After compiling with SPKRDEBUG, with 'T30 cbdcbdcbd', spkrcat does
59ms sound + 8ms rest, while spkr(4) does 58ms sound + 8ms. The
ideal total duration would be 66.666ms. spkrcat does round away
from zero, spkr(4) doesn't.
- legato is (almost) fully smooth: adjacent tones with the same
frequency are combined into one tone_t with the sum of the durations
(as long as it doesn't overflow an int), which results in a single
call to pcppi_bell.
- instead of using the default value on invalid inputs, clamp the value
to the valid range.
- unveil.
CURIOSITIES CARRIED OVER FROM spkr.c
- bounds are checked in playnote / addsound:
- "O0C-" has the same effect as "P"
- "O6B+" is a noop
MISSING / QUESTIONS
- I have absolutely no clue how many / which of the license headers /
comments from spkr.c should be carried over. As I'm in doubt, I
included all of them.
- no manpage yet: shouldn't be too difficult as it's mostly moving the
description from spkr(4), but haven't found the time to do so.
- ideally, this should be a bit more privsep'd, in a fashion similar to
file(1): a parsing process + a ioctl process. The parsing process can
be heavily pledge'd, as right now there is no way to pledge spkrcat
and use the appropiat ioctl interface. The other option is adding
ioctl(SPKR{TONE,TUNE}) to audio pledge. In any case, am unfamiliar
with both imsg and pledge internals, but I don't mind learning it once
an approach is set.
- no diff against the tree: I don't know where to place this between
usr.bin/ and usr.sbin/, and some part of me even wonders if it even
makes sense to include it there and not in games, or to even include
it in base and not distribute it as a port. The main reason I see for
including it in base (and in particular one of usr.{,s}bin/) is that
it provides an interface for a feature that currently resides in
kernelland.
- no code removal from spkr(4) yet: to be done after knowing in where to
place spkrcat.
Feedback and comments welcome.
-Lucas
# Copyright (c) 2022 Lucas Gabriel Vuotto
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
PROG= spkrcat
NOMAN= spkrcat
.include
/* $OpenBSD$ */
/* $NetBSD: spkr.c,v 1.1 1998/04/15 20:26:18 drochner Exp $*/
/*
* Copyright (c) 2022 Lucas Gabriel Vuotto
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS"
Re: speaker(4): unhook driver and manpage from build
Scott Cheloha wrote: > speaker(4) is a whimsical thing, but I don't think we should have a > dedicated chiptune interpreter in the kernel. > > This patch unhooks the driver and the manpage from the build. The > driver is built for alpha, amd64, and i386. > > A subsequent patch will move all relevant files to the attic and clean > up manpage cross references. > > Nothing in base or xenocara includes . > > I see a couple SPKRTONE and SPKRTUNE symbols in ports, but I imagine > those ports don't use the symbols if they are missing. > > ok? PCEngines' APU2 [1] attach spkr(4) and I have used it in the past for some rudimentary monitoring, beeping when a certain condition is met. It does the big advantage of being something that can be done offline. I don't have experience with device drivers development, but the code for it doesn't seem bad nor complex nor rot-prone, and stayed basically unmodified since it was imported. I can understand having a music language interpreter in the kernel being the only bad thing about it. In that case, wouldn't it be an option to keep the core of driver and move the language interpreter to userland? Something like spkrctl(8). I can probably put that together over the weekend in fact, if patch or GTFO is the norm. [1]: https://pcengines.ch/apu2.htm -Lucas
Re: Faster unhibernate by skipping devices
Since I'm using a snapshot with this, almost everytime I unhibernate I get a "false start": devices start to get enumerated and at one point, the machine reboots and goes back to the POST screen. Most of the time, the second time it boots normally. If it helps, most of the time there are around 8 hours between hibernating and unhibernating, as I basically do it instead of powering it off. dmesg below. It's worth noting that I *think* everytime it reboots after printing the line following `pckbc0 at isa0 port 0x60/5 irq 1 irq 12`. I still haven't managed to read if it prints `pckbd0 at pckbc0 (kbd slot)` or something else. OpenBSD 7.0-current (GENERIC.MP) #72: Fri Nov 5 10:08:43 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12534018048 (11953MB) avail mem = 12138131456 (11575MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (70 entries) bios0: vendor LENOVO version "G2ET33WW (1.13 )" date 07/24/2012 bios0: LENOVO 2325BG4 acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT DMAR UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 1197.48 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 1197.29 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 4 (EXP3) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x104a rev 0x4e acpibat0 at acpi0: BAT0 model "45N1029" serial 15304 type LION oem "LGC" acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2 acpitz0 at acpi0: critical temperature is 103 degC acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivout0 at acpivideo0: LCD0 acpivideo1 at acpi0: VID_ cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 1197 MHz: speeds: 2601, 2600, 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi, IVYBRIDGE, gen 7 xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured puc0 at pci0 dev 22 function 3 "Intel 7 Series KT" rev 0x04: ports: 16 com com4 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo com4: probed fifo depth: 0 bytes em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address 3c:97:0e:31:1f:fa ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
Re: unwind(8): WIP support using a custom CA
Florian Obser wrote:
> I'm not a fan and I'm not personally interested in the functionality.
>
> I'd suggest getting a certificate from a recognized CA or add your CA to
> /etc/ssl/cert.pem if it's trustworthy enough.
>
> Removing the unveil(2) call shows that you don't understand what that
> does. Hint: you opened up the whole filesystem to the resolver process.
Before I give up, I'll try with the following approach. It keeps
unveil(2) in place, doesn't mess with yacc and it feels a bit more
cleaner than the previous one.
Thanks for the review anyway. :)
-Lucas
Index: resolver.c
===
RCS file: /home/cvs/src/sbin/unwind/resolver.c,v
retrieving revision 1.144
diff -u -p -r1.144 resolver.c
--- resolver.c 12 Jul 2021 15:09:19 - 1.144
+++ resolver.c 22 Jul 2021 19:33:03 -
@@ -335,6 +335,8 @@ const char bogus_past[] = "validation f
const char bogus_future[] = "validation failure <. NS IN>: signature "
"before inception date";
+static const char *resolver_cafile = TLS_DEFAULT_CA_CERT_FILE;
+
void
resolver_sig_handler(int sig, short event, void *arg)
{
@@ -353,7 +355,7 @@ resolver_sig_handler(int sig, short even
}
void
-resolver(int debug, int verbose)
+resolver(int debug, int verbose, const char *cafile)
{
struct event ev_sigint, ev_sigterm;
struct passwd *pw;
@@ -376,8 +378,10 @@ resolver(int debug, int verbose)
setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid))
fatal("can't drop privileges");
- if (unveil(TLS_DEFAULT_CA_CERT_FILE, "r") == -1)
- fatal("unveil %s", TLS_DEFAULT_CA_CERT_FILE);
+ if (cafile != NULL)
+ resolver_cafile = cafile;
+ if (unveil(resolver_cafile, "r") == -1)
+ fatal("unveil %s", resolver_cafile);
if (pledge("stdio inet dns rpath recvfd", NULL) == -1)
fatal("pledge");
@@ -1321,7 +1325,7 @@ create_resolver(enum uw_resolver_type ty
case UW_RES_ODOT_DHCP:
set_forwarders(res, _forwarder_list, 853);
ub_ctx_set_option(res->ctx, "tls-cert-bundle:",
- TLS_DEFAULT_CA_CERT_FILE);
+ resolver_cafile);
ub_ctx_set_tls(res->ctx, 1);
break;
case UW_RES_FORWARDER:
@@ -1330,13 +1334,13 @@ create_resolver(enum uw_resolver_type ty
case UW_RES_ODOT_FORWARDER:
set_forwarders(res, _conf->uw_forwarder_list, 853);
ub_ctx_set_option(res->ctx, "tls-cert-bundle:",
- TLS_DEFAULT_CA_CERT_FILE);
+ resolver_cafile);
ub_ctx_set_tls(res->ctx, 1);
break;
case UW_RES_DOT:
set_forwarders(res, _conf->uw_dot_forwarder_list, 0);
ub_ctx_set_option(res->ctx, "tls-cert-bundle:",
- TLS_DEFAULT_CA_CERT_FILE);
+ resolver_cafile);
ub_ctx_set_tls(res->ctx, 1);
break;
default:
Index: resolver.h
===
RCS file: /home/cvs/src/sbin/unwind/resolver.h,v
retrieving revision 1.17
diff -u -p -r1.17 resolver.h
--- resolver.h 18 Dec 2019 09:18:27 - 1.17
+++ resolver.h 22 Jul 2021 19:09:35 -
@@ -71,6 +71,6 @@ struct ctl_mem_info {
size_t neg_cache_max;
};
-voidresolver(int, int);
+voidresolver(int, int, const char *);
int resolver_imsg_compose_main(int, pid_t, void *, uint16_t);
int resolver_imsg_compose_frontend(int, pid_t, void *, uint16_t);
Index: unwind.8
===
RCS file: /home/cvs/src/sbin/unwind/unwind.8,v
retrieving revision 1.10
diff -u -p -r1.10 unwind.8
--- unwind.825 Jan 2021 16:57:00 - 1.10
+++ unwind.822 Jul 2021 22:27:51 -
@@ -24,6 +24,7 @@
.Sh SYNOPSIS
.Nm
.Op Fl dnv
+.Op Fl C Ar file
.Op Fl f Ar file
.Op Fl s Ar socket
.Sh DESCRIPTION
@@ -80,6 +81,8 @@ If this option is specified,
.Nm
will run in the foreground and log to
.Em stderr .
+.It Fl C Ar file
+Specify an alternative CA certificates file.
.It Fl f Ar file
Specify an alternative configuration file.
.It Fl n
@@ -107,6 +110,8 @@ Trust anchor for DNSSEC validation.
.Ux Ns -domain
socket used for communication with
.Xr unwindctl 8 .
+.It Pa /etc/ssl/cert.pem
+Default CA file.
.El
.Sh SEE ALSO
.Xr unwind.conf 5 ,
Index: unwind.c
===
RCS file: /home/cvs/src/sbin/unwind/unwind.c,v
retrieving revision 1.61
diff -u -p -r1.61 unwind.c
--- unwind.c27 Feb 2021 10:32:28 - 1.61
+++ unwind.c22
Re: unwind(8): WIP support using a custom CA
Updated patch. It now:
- Allows using a custom CA
- Reconfigure DoT resolvers' config when just the CA changed (previous
version only impacted CA changes when there were also resolvers
changes)
Have been running it without problems so far, and it seemed to work in
the early boot process too. If anyone has a better way to test that
other than "ntpd works", am all ears.
I'd really like to see this merged. Comments?
-Lucas
P.S.: I found a remnant of a previous imsg in the form of IMSG_ADD_DNS,
which should be IMSG_REPLACE_DNS. I included it in the patch.
Index: frontend.c
===
RCS file: /home/cvs/src/sbin/unwind/frontend.c,v
retrieving revision 1.68
diff -u -p -r1.68 frontend.c
--- frontend.c 6 Feb 2021 18:01:02 - 1.68
+++ frontend.c 20 Jul 2021 18:21:30 -
@@ -365,6 +365,7 @@ frontend_dispatch_main(int fd, short eve
case IMSG_RECONF_FORWARDER:
case IMSG_RECONF_DOT_FORWARDER:
case IMSG_RECONF_FORCE:
+ case IMSG_RECONF_CA_FILE:
imsg_receive_config(, );
break;
case IMSG_RECONF_END:
Index: parse.y
===
RCS file: /home/cvs/src/sbin/unwind/parse.y,v
retrieving revision 1.25
diff -u -p -r1.25 parse.y
--- parse.y 27 Feb 2021 10:32:28 - 1.25
+++ parse.y 20 Jul 2021 20:40:34 -
@@ -103,6 +103,7 @@ typedef struct {
%token FORWARDER DOT PORT ODOT_FORWARDER ODOT_DHCP
%token AUTHENTICATION NAME PREFERENCE RECURSOR DHCP STUB
%token BLOCK LIST LOG FORCE ACCEPT BOGUS
+%token CA FILE
%token STRING
%token NUMBER
@@ -120,6 +121,7 @@ grammar : /* empty */
| grammar uw_forwarder '\n'
| grammar block_list '\n'
| grammar force '\n'
+ | grammar cafile '\n'
| grammar error '\n'{ file->errors++; }
;
@@ -343,7 +345,7 @@ acceptbogus:ACCEPT BOGUS{ $$ = 1; }
force_list:force_list optnl STRING {
struct force_tree_entry *e;
- size_t len;
+ size_t len;
len = strlen($3);
e = malloc(sizeof(*e));
@@ -374,6 +376,20 @@ force_list:force_list optnl STRING {
}
;
+cafile : CA FILE STRING {
+ if (conf->ca_file != NULL) {
+ yyerror("CA file already configured");
+ free($3);
+ YYERROR;
+ } else {
+ conf->ca_file = strdup($3);
+ if (conf->ca_file == NULL)
+ err(1, "strdup");
+ free($3);
+ }
+ }
+ ;
+
%%
struct keywords {
@@ -413,8 +429,10 @@ lookup(char *s)
{"authentication", AUTHENTICATION},
{"block", BLOCK},
{"bogus", BOGUS},
+ {"ca", CA},
{"dhcp",DHCP},
{"dot", DOT},
+ {"file",FILE},
{"force", FORCE},
{"forwarder", FORWARDER},
{"include", INCLUDE},
Index: printconf.c
===
RCS file: /home/cvs/src/sbin/unwind/printconf.c,v
retrieving revision 1.16
diff -u -p -r1.16 printconf.c
--- printconf.c 1 Dec 2019 14:37:34 - 1.16
+++ printconf.c 20 Jul 2021 20:41:25 -
@@ -33,6 +33,9 @@ print_config(struct uw_conf *conf)
int i;
enum uw_resolver_typej;
+ if (conf->ca_file != NULL)
+ printf("ca file %s\n", conf->ca_file);
+
if (conf->res_pref.len > 0) {
printf("preference {");
for (i = 0; i < conf->res_pref.len; i++) {
Index: resolver.c
===
RCS file: /home/cvs/src/sbin/unwind/resolver.c,v
retrieving revision 1.144
diff -u -p -r1.144 resolver.c
--- resolver.c 12 Jul 2021 15:09:19 - 1.144
+++ resolver.c 22 Jul 2021 12:43:12 -
@@ -127,6 +127,7 @@ struct running_query {
};
TAILQ_HEAD(, running_query) running_queries;
+static const char *ca_file;
typedef void (*resolve_cb_t)(struct uw_resolver *, void *, int, void *, int,
int, char *);
@@ -376,9 +377,6 @@ resolver(int debu
unwind(8): WIP support using a custom CA
Hi tech@,
I decided to give it a shot at specifying a custom CA for DoT validation
in unwind(8). Patch at the bottom. Selfish reason for this is that I run
my own DoT resolver, using a self-signed certificate. Am able to use
unbound to query it, but the lack of support for a custom CA in unwind
stopped me from switching to it since its inception. Now that the system
is becoming more integrated (dhcpleased and resolved enabled by default,
deep-ish integration between resolvd and unwind), I gave it a shot.
The patch is just the code part, manpage changes are pending but wanted
to know first if the approach is correct and willing to be accepted.
I successfully tried:
- using a custom CA
- adding a DoT forwarder not covered by it and having it rejected
- removing my DoT forwarders and the custom CA to fallback to the
standard CA
I haven't tried yet (but will do very soon):
- verifying that unwind works in early system, placing the custom CA
file in the / mount (ofc won't work if the file resides in another
mountpoint, thing to be documented)
Worth noting, currently, CA changes come into action when forwarders
are added or removed. If a config file undergoes only a CA change, it
won't be reflected in the running unwind. Am unsure if this could be
solved without much refactor, but haven't given up yet.
The default CA file was unveiled. I removed that call, but dunno if
instead I should be unveiling every new CA file or not. Blocklist aren't
managed in that way, fwiw.
Comments?
Index: frontend.c
===
RCS file: /home/cvs/src/sbin/unwind/frontend.c,v
retrieving revision 1.68
diff -u -p -r1.68 frontend.c
--- frontend.c 6 Feb 2021 18:01:02 - 1.68
+++ frontend.c 20 Jul 2021 18:21:30 -
@@ -365,6 +365,7 @@ frontend_dispatch_main(int fd, short eve
case IMSG_RECONF_FORWARDER:
case IMSG_RECONF_DOT_FORWARDER:
case IMSG_RECONF_FORCE:
+ case IMSG_RECONF_CA_FILE:
imsg_receive_config(, );
break;
case IMSG_RECONF_END:
Index: parse.y
===
RCS file: /home/cvs/src/sbin/unwind/parse.y,v
retrieving revision 1.25
diff -u -p -r1.25 parse.y
--- parse.y 27 Feb 2021 10:32:28 - 1.25
+++ parse.y 20 Jul 2021 20:40:34 -
@@ -103,6 +103,7 @@ typedef struct {
%token FORWARDER DOT PORT ODOT_FORWARDER ODOT_DHCP
%token AUTHENTICATION NAME PREFERENCE RECURSOR DHCP STUB
%token BLOCK LIST LOG FORCE ACCEPT BOGUS
+%token CA FILE
%token STRING
%token NUMBER
@@ -120,6 +121,7 @@ grammar : /* empty */
| grammar uw_forwarder '\n'
| grammar block_list '\n'
| grammar force '\n'
+ | grammar cafile '\n'
| grammar error '\n'{ file->errors++; }
;
@@ -343,7 +345,7 @@ acceptbogus:ACCEPT BOGUS{ $$ = 1; }
force_list:force_list optnl STRING {
struct force_tree_entry *e;
- size_t len;
+ size_t len;
len = strlen($3);
e = malloc(sizeof(*e));
@@ -374,6 +376,20 @@ force_list:force_list optnl STRING {
}
;
+cafile : CA FILE STRING {
+ if (conf->ca_file != NULL) {
+ yyerror("CA file already configured");
+ free($3);
+ YYERROR;
+ } else {
+ conf->ca_file = strdup($3);
+ if (conf->ca_file == NULL)
+ err(1, "strdup");
+ free($3);
+ }
+ }
+ ;
+
%%
struct keywords {
@@ -413,8 +429,10 @@ lookup(char *s)
{"authentication", AUTHENTICATION},
{"block", BLOCK},
{"bogus", BOGUS},
+ {"ca", CA},
{"dhcp",DHCP},
{"dot", DOT},
+ {"file",FILE},
{"force", FORCE},
{"forwarder", FORWARDER},
{"include", INCLUDE},
Index: printconf.c
===
RCS file: /home/cvs/src/sbin/unwind/printconf.c,v
retrieving revision 1.16
diff -u -p -r1.16 printconf.c
--- printconf.c 1 Dec 2019 14:37:34 - 1.16
+++ printconf.c 20 Jul 2021 20:41:25 -
@@ -33,6 +33,9 @@ print_config(struct uw_conf *conf)
int i;
enum uw_resolver_typej;
+ if (conf->ca_file != NULL)
+
Re: ftp(1): handle HTTP 308
Weekly bump
Index: fetch.c
===
RCS file: /home/cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.198
diff -u -p -r1.198 fetch.c
--- fetch.c 18 Oct 2020 20:35:18 - 1.198
+++ fetch.c 24 Dec 2020 14:03:03 -
@@ -843,6 +843,7 @@ noslash:
case 302: /* Found */
case 303: /* See Other */
case 307: /* Temporary Redirect */
+ case 308: /* Permanent Redirect */
isredirect++;
if (redirect_loop++ > 10) {
warnx("Too many redirections requested");
ftp(1): handle HTTP 308
Hello tech@,
Given that ftp already deals with HTTP 307, I think we can teach it to
deal with HTTP 308 too. HTTP 308 is to HTTP 301 what HTTP 307 is to HTTP
302: Permanently Moved, but doesn't allow to change the HTTP verb.
Definition of HTTP 308 can be found in RFC 7538.
oolong$ ftp -Mo /dev/null http://h.lgv5.net/c/308
Trying 78.47.117.79...
Requesting http://h.lgv5.net/c/308
ftp: Error retrieving http://h.lgv5.net/c/308: 308 Permanent Redirect
oolong$ ./ftp -Mo /dev/null http://h.lgv5.net/c/308
Trying 78.47.117.79...
Requesting http://h.lgv5.net/c/308
Redirected to http://h.lgv5.net/c/200
Trying 78.47.117.79...
Requesting http://h.lgv5.net/c/200
480 bytes received in 0.00 seconds (4.66 MB/s)
Cheers!
-Lucas
Index: fetch.c
===
RCS file: /home/cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.198
diff -u -p -r1.198 fetch.c
--- fetch.c 18 Oct 2020 20:35:18 - 1.198
+++ fetch.c 24 Dec 2020 14:03:03 -
@@ -843,6 +843,7 @@ noslash:
case 302: /* Found */
case 303: /* See Other */
case 307: /* Temporary Redirect */
+ case 308: /* Permanent Redirect */
isredirect++;
if (redirect_loop++ > 10) {
warnx("Too many redirections requested");
Re: smtpd filters: accept bypass in commit stage
Martijn van Duren wrote: > Does this filter actually work for you? Not by my testing, nor my > understanding of filters. Filter-dkimsign works during the > filter-dataline phase, so you'd have to circumvent that one, which is > not supported. Finally got around to test it. Found the problem too late in the night to fetch the sources, build and see if it solved the issue for me. You're correct, the mail is getting signed everytime anyways. Got the impression that `commit` was the right phase after running `smtpd -dvvv -T filters` when I first tried with setting `bypass` in `mail-from` phase: 15eac9cd3aadddc1 filters session-begin 15eac9cd3aadddc1 filters protocol phase=connect, resume=n, action=proceed 15eac9cd3aadddc1 filters protocol phase=ehlo, resume=n, action=proceed 15eac9cd3aadddc1 filters protocol phase=mail-from, resume=n, action=bypass, filter=ext_relay, query=lucas@domain.invalid 15eac9cd3aadddc1 filters protocol phase=rcpt-to, resume=n, action=proceed 15eac9cd3aadddc1 filters protocol phase=data, resume=n, action=proceed smtp: 0x8941daca000: fd 16 from queue smtp: 0x8941daca000: message fd 16 15eac9cd3aadddc1 filters data-begin fd=11 smtp: 0x8941daca000: fd 17 from lka smtp: 0x8941daca000: filter fd 17 smtp: 0x8941daca000: message begin 15eac9cd3aadddc1 filters protocol phase=commit, resume=n, action=deferred, filter=dkimsign 15eac9cd3aadddc1 filters protocol phase=connect, resume=y, action=proceed `dkimsign` is only showing up in `commit` phase. After patching, it looks like this: 4ebd6c3015e64c8c smtp connected address=local host=mx.sexy.is 4ebd6c3015e64c8c filters session-begin 4ebd6c3015e64c8c filters protocol phase=connect, resume=n, action=proceed 4ebd6c3015e64c8c filters protocol phase=ehlo, resume=n, action=proceed 4ebd6c3015e64c8c filters protocol phase=mail-from, resume=n, action=proceed 4ebd6c3015e64c8c filters protocol phase=rcpt-to, resume=n, action=proceed 4ebd6c3015e64c8c filters protocol phase=data, resume=n, action=proceed smtp: 0x908842d5000: fd 16 from queue smtp: 0x908842d5000: message fd 16 4ebd6c3015e64c8c filters data-begin fd=11 smtp: 0x908842d5000: fd 17 from lka smtp: 0x908842d5000: filter fd 17 smtp: 0x908842d5000: message begin 4ebd6c3015e64c8c filters protocol phase=commit, resume=n, action=bypass, filter=ext_relay_dkimsign_override, query= but `filter-dkimsign` is being executed anyways. Later on I'll give hijacking `data` phase a shot, but I wonder if it'll, as `filter-dkimsign` registers for both `data-line` and `commit`. What will if I just hijack `data` and not `commit`? Will `filter-dkimsign` produce a empty email? - >8 - That being said, I still think that either the grammar is wrong, or the manpage should mention that `bypass` isn't available at `commit`. -Lucas
smtpd filters: accept bypass in commit stage
Hello tech@,
I keep getting a syntax error with the following seemingly correct
line:
filter "dkimsign-override" phase commit \
match mail-from bypass
The problem (`/etc/mail/smtpd.conf:20: syntax error`) arises from
smtpd.conf's grammar only allowing `filter_action_builtin_nojunk` for
`commit` phase. It turns out that the current definition of
`filter_action_builtin_nojunk` means no junk and no bypass. Address
that moving bypass action to nojunk.
My usecase for it is to avoid DKIM-signing emails that are externally
relayed with `opensmtpd-filters-dkimsign`: if I also own
lucas@domain.invalid, I don't want smtpd to sign lucas@domain.invalid's
emails, just lu...@sexy.is'. This seems possible with `filter-chain`,
and technically could be decided in `mail-from` phase, but sadly
`bypass` doesn't short-circuit. Second best option is to `bypass`
during `commit` phase, which is when `filter-dkimsign` does its magic.
Comments?
-Lucas
Index: parse.y
===
RCS file: /home/cvs/src/usr.sbin/smtpd/parse.y,v
retrieving revision 1.278
diff -u -p -r1.278 parse.y
--- parse.y 1 Jun 2020 05:21:30 - 1.278
+++ parse.y 25 Aug 2020 04:05:27 -
@@ -1527,9 +1527,6 @@ filter_action_builtin_nojunk
| JUNK {
filter_config->junk = 1;
}
-| BYPASS {
- filter_config->bypass = 1;
-}
;
filter_action_builtin_nojunk:
@@ -1544,6 +1541,9 @@ REJECT STRING {
}
| REPORT STRING {
filter_config->report = $2;
+}
+| BYPASS {
+ filter_config->bypass = 1;
}
;
Re: userland clock_gettime proof of concept
Hi Paul,
I'm just a bystander that likes to read diffs. I can't speak about how
the diff fits in the kernel, but I can do some basic checks of
correctness.
As a matter of syntax, there are quite some places with functions
without parameters defined as `f()` instead of `f(void)`.
Paul Irofti wrote:
> diff --git lib/libc/arch/amd64/gen/usertc.c lib/libc/arch/amd64/gen/usertc.c
> new file mode 100644
> index 000..ee44d61de4b
> --- /dev/null
> +++ lib/libc/arch/amd64/gen/usertc.c
> @@ -0,0 +1,53 @@
> +/* $OpenBSD$ */
> +/*
> + * Copyright (c) 2020 Paul Irofti
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include
> +#include
> +
> +static uint
> +rdtsc()
> +{
> + uint32_t hi, lo;
> + asm volatile("rdtsc" : "=a"(lo), "=d"(hi));
> + return ((uint64_t)lo)|(((uint64_t)hi)<<32);
> +}
> +
> +static uint
> +acpihpet()
> +{
> + return rdtsc(); /* JUST TO COMPILE */
> +}
> +
> +static uint (*const get_tc[])(void) =
> +{
> + [TC_TSC] = rdtsc,
> + [TC_HPET] = acpihpet,
> +};
> +
> +int
> +tc_get_timecount(struct timekeep *tk, uint *tc)
> +{
> + int tk_user = tk->tk_user;
> +
> + if (tc == NULL || tk_user < 1 || tk_user > TC_LAST)
Shouldn't you check for >= TC_LAST in here? Otherwise you'll be reading
and invoking dragons in the following lines.
*Unless*, the semantic meaning of TC_LAST is to indicate the last valid
index of get_tc[]. In that case, TC_LAST is defined to 3 in amd64,
instead of 2.
> + return -1;
> +
> + *tc = (*get_tc[tk_user])();
> + return 0;
> +}
> +int (*const _tc_get_timecount)(struct timekeep *tk, uint *tc)
> + = tc_get_timecount;
> diff --git sys/arch/amd64/include/timetc.h sys/arch/amd64/include/timetc.h
> new file mode 100644
> index 000..72dfc969a76
> --- /dev/null
> +++ sys/arch/amd64/include/timetc.h
> @@ -0,0 +1,25 @@
> +/* $OpenBSD$ */
> +/*
> + * Copyright (c) 2020 Paul Irofti
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#ifndef _MACHINE_TIMETC_H_
> +#define _MACHINE_TIMETC_H_
> +
> +#define TC_TSC 1
> +#define TC_HPET 2
> +#define TC_LAST 3
> +
> +#endif /* _MACHINE_TIMETC_H_ */
loongson/macppc default and staff login class limits coherency
Hello tech@, While using my macppc to try a port I noticed there is a discrepancy between login classes limits: default datasize-cur is defined to 2048M while staff datasize-cur is 512M. This happened in /src/etc/etc.macppc/login.conf 1.12 as "grow limits a bit because clang is a pig." A similar change was introduced for loongson in that commit too. I checked all the arch-specific login.conf for similar discrepancy just between default and staff classes. Only these are affected, and only datasize-cur is below default's. Find a diff for bumping it. Out of curiosity, what is the rationale for bumping limits in one arch but not the others? For example, default class' datasize-cur in amd64 is only 768MB, despite them being more beefy in general than most of macppc devices, yet this ship a 2048MB datasize-cur. -Lucas PD: is there a easy way in CVS to look at all the affected files by one commit, very much like Git? for this I used `cvs log -d` and a AWK script) Index: etc.loongson/login.conf === RCS file: /home/cvs/src/etc/etc.loongson/login.conf,v retrieving revision 1.13 diff -u -p -r1.13 login.conf --- etc.loongson/login.conf 12 Mar 2020 15:32:21 - 1.13 +++ etc.loongson/login.conf 31 May 2020 20:45:30 - @@ -71,7 +71,7 @@ daemon:\ # Staff have fewer restrictions and can login even when nologins are set. # staff:\ - :datasize-cur=768M:\ + :datasize-cur=1024M:\ :datasize-max=infinity:\ :maxproc-max=512:\ :maxproc-cur=128:\ Index: etc.macppc/login.conf === RCS file: /home/cvs/src/etc/etc.macppc/login.conf,v retrieving revision 1.13 diff -u -p -r1.13 login.conf --- etc.macppc/login.conf 23 May 2020 13:16:03 - 1.13 +++ etc.macppc/login.conf 31 May 2020 20:45:50 - @@ -70,7 +70,7 @@ daemon:\ # Staff have fewer restrictions and can login even when nologins are set. # staff:\ - :datasize-cur=512M:\ + :datasize-cur=2048M:\ :datasize-max=infinity:\ :maxproc-max=512:\ :maxproc-cur=128:\
Re: [PATCH} efifb support for wsmoused + smaller fonts
On Mon, May 25, 2020 at 09:13:43PM +1000, Jonathan Gray wrote: > On Sun, May 24, 2020 at 05:01:16PM -0700, jo...@armadilloaerospace.com wrote: > > The efifb driver behaves almost identically to the inteldrm driver > > for wscons, but did not implement the getchar() accessops, so > > wsmoused would fail at startup. > > This seems reasonable, though your mail client has line wrapped the > patch so it won't apply. In this case it is simple enough to apply by > hand. > > > Separately, I increased the maximum screen dimensions to 160x50 to > > allow the 12x24 font to be used on an 1920 monitor, which looks great! > > Something similiar was done and reverted as it somehow broke inteldrm > taking the fb over from efifb on a 4k display. Perhaps someone with a > 4k display can confirm if this is still a problem. > > https://marc.info/?l=openbsd-bugs=155337866226121=2 > > That was back before we deferred most of inteldrm to when the root fs is > mounted and interrupts are available. And just before the last big drm > update by the look of it. I tried out the patch twice, once with John's value for EFIFB_HEIGHT of 50 and once with the original original value of 160. The behavior of the bug report I submitted doesn't reappear so it looks everything is working as intended. This is with the same monitor as in the bug report > > > revision 1.22 > date: 2019/03/25 14:17:58; author: fcambus; state: Exp; lines: +3 -3; > commitid: hL9P1vyWGBp5FHhE; > Revert back to using previous values for EFIFB_WIDTH and EFIFB_HEIGHT, > as raising them expose an issue which breaks inteldrm on large screen > resolutions. > > Reported by chris@, and by Lucas Raab on bugs@. Thanks! > > revision 1.21 > date: 2019/03/16 13:16:49; author: fcambus; state: Exp; lines: +3 -3; > commitid: wsqjyS7rXDKbqGS3; > Now that efifb(4) supports remapping the framebuffer in write combining > mode, it's fast enough to raise the maximum size of the EFI framebuffer > console. > > Set it to 160 columns and 160 rows, to match inteldrm and radeondrm. > > OK jcs@, kettenis@ > > > > > > Unlike the intel driver, efifb has a static buffer of that size, > > which is a non-trivial amount of memory. Not setting the backing > > store to save the memory results in an ultra-slow console until the > > driver gets fully initialized, because it is doing scrolls by reading > > from write combined memory instead of the redrawing all the > > characters. > > > > I plan on changing that to a dynamic allocation once I am more > > comfortable with the reinitialization that goes on when autoconf > > gets around to the console display device, so feel free to punt on > > that if you want to wait. > > Drivers which can act as a console have a cnattach function for very > early init and then later probe again and run attach. In the case of > efifb there is also efifb_cnremap() which is called when mainbus > attaches. The drm drivers call efifb_detach() to stop autoconf from > doing the normal probe/attach when taking over the console. >
Re: [PLEASE TEST] acpi(4): acpi_sleep(): tsleep(9) -> tsleep_nsec(9)
On Sun, Mar 15, 2020, at 21:55, Scott Cheloha wrote: > Hi, > > This is a straightforward ticks-to-milliseconds conversion, but IIRC > pirofti@ wanted me to get some tests before committing it. > > The only users of acpi_sleep() are (a) acpitz(4) and (b) any AML code > that uses AMLOP_SLEEP. AMLOP_SLEEP seems to trigger just before a > suspend. I don't know when else it is used. > > If you have an acpi(4) laptop with suspend/resume support, please > apply this patch and let me know if anything doesn't work, > particularly with suspend/resume. > > I've been running with this since November without apparent issue... > But this driver impacts many people, so I think I need more tests. > > Cheers, > > Scott > No problems so far on a Thinkpad X1C7 Lucas
Re: diff: simplify MGETHDR error handling in tcp_output
Hello Jan,
Jan Klemkow wrote:
> Hi,
>
> the following diff simplifies the error handling of MGETHDR() in
> tcp_output(). Jumps earlier to out, prevents a double check of NULL and
> makes the code more readable.
>
> OK?
>
> Bye,
> Jan
>
> Index: netinet/tcp_output.c
> ===
> RCS file: /cvs/src/sys/netinet/tcp_output.c,v
> retrieving revision 1.128
> diff -u -p -r1.128 tcp_output.c
> --- netinet/tcp_output.c 10 Nov 2018 18:40:34 - 1.128
> +++ netinet/tcp_output.c 6 Nov 2019 14:34:40 -
> @@ -652,17 +652,17 @@ send:
> m->m_data -= hdrlen;
> #else
> MGETHDR(m, M_DONTWAIT, MT_HEADER);
> - if (m != NULL && max_linkhdr + hdrlen > MHLEN) {
> + if (m == NULL) {
> + error = ENOBUFS;
> + goto out;
> + }
> + if (max_linkhdr + hdrlen > MHLEN) {
> MCLGET(m, M_DONTWAIT);
> if ((m->m_flags & M_EXT) == 0) {
> m_freem(m);
> m = NULL;
> }
> }
> - if (m == NULL) {
> - error = ENOBUFS;
> - goto out;
> - }
> m->m_data += max_linkhdr;
> m->m_len = hdrlen;
I might be missing something, but m can be NULL here, if (m->m_flags &
M_EXT) == 0.
> if (len <= m_trailingspace(m)) {
> @@ -701,16 +701,16 @@ send:
> tcpstat_inc(tcps_sndwinup);
>
> MGETHDR(m, M_DONTWAIT, MT_HEADER);
> - if (m != NULL && max_linkhdr + hdrlen > MHLEN) {
> + if (m == NULL) {
> + error = ENOBUFS;
> + goto out;
> + }
> + if (max_linkhdr + hdrlen > MHLEN) {
> MCLGET(m, M_DONTWAIT);
> if ((m->m_flags & M_EXT) == 0) {
> m_freem(m);
> m = NULL;
> }
> - }
> - if (m == NULL) {
> - error = ENOBUFS;
> - goto out;
> }
> m->m_data += max_linkhdr;
> m->m_len = hdrlen;
And same here.
-Lucas
ssh-keygen.1 fixes regarding new -Y flag
Hello tech@, Find a patch fixing some details in ssh-keygen.1 regarding the new -Y flag for signing and verifying signatures. Precisely: - Include a missing 'returning a zero exit status' in `-Y verify` paragraph. - Don't include `option` in `.Fl I` in ALLOWED SIGNERS section. -Lucas Index: ssh-keygen.1 === RCS file: /home/cvsroot/src/usr.bin/ssh/ssh-keygen.1,v retrieving revision 1.171 diff -u -p -u -p -r1.171 ssh-keygen.1 --- ssh-keygen.13 Oct 2019 17:07:50 - 1.171 +++ ssh-keygen.119 Oct 2019 14:18:45 - @@ -716,6 +716,7 @@ flag. The revocation file may be a KRL or a one-per-line list of public keys. Successful verification by an authorized signer is signalled by .Nm +returning a zero exit status. .It Fl Y Cm check-novalidate Checks that a signature generated using .Nm @@ -987,8 +988,8 @@ The principals field is a pattern-list ( consisting of one or more comma-separated USER@DOMAIN identity patterns that are accepted for signing. When verifying, the identity presented via the -.Fl I option -must match a principals pattern in order for the corresponding key to be +.Fl I +option must match a principals pattern in order for the corresponding key to be considered acceptable for verification. .Pp The options (if present) consist of comma-separated option specifications.
Fix hid_get_data return type in usbhib.3
Hello tech@, I stumbled with this typo while poking around random manpages. After finding it, I ran `grep -Fnr -e int_8t -e int_16t -e int_32t -e int_64t /usr/src` to see if there was other similar typo and just send one patch with all the fixes. Turns out that a comment in line 1012 from /usr/src/gnu/llvm/lib/Target/AArch64/AArch64LoadStoreOptimizer.cpp also has that typo, but dunno if it should be corrected here or in upstream, hence I left it from the diff. Cheers. Index: usbhid.3 === RCS file: /cvs/src/lib/libusbhid/usbhid.3,v retrieving revision 1.18 diff -u -p -u -p -r1.18 usbhid.3 --- usbhid.327 May 2018 18:45:51 - 1.18 +++ usbhid.318 Feb 2019 06:34:52 - @@ -77,7 +77,7 @@ .Fn hid_init "char *file" .Ft int .Fn hid_start "char *file" -.Ft int_32t +.Ft int32_t .Fn hid_get_data "void *data" "hid_item_t *h" .Ft void .Fn hid_set_data "void *data" "hid_item_t *h" "int32_t data"
gre(4): remove linkX from example
Hi tech@, According rev 1.45, linkX in gre(4) is a deprecated style and isn't documented in ifconfig(8) (couldn't find it ever was, but I'm not to used to cvs so I couldn't search properly). This removes linkX from the example in the manpage. Cheers. Index: share/man/man4/gre.4 === RCS file: /cvs/src/share/man/man4/gre.4,v retrieving revision 1.47 diff -u -p -u -p -r1.47 gre.4 --- share/man/man4/gre.48 Jun 2017 12:37:14 - 1.47 +++ share/man/man4/gre.430 Nov 2017 23:32:16 - @@ -129,7 +129,7 @@ On Host A .Bd -literal -offset indent # route add default B # ifconfig greN create -# ifconfig greN A D netmask 0x linkX up +# ifconfig greN A D netmask 0x up # ifconfig greN tunnel A D # route add E D .Ed
Re: mg backup directory (bump)
Bump.
Emacs gets HOME from environment here. I think that getting it from pw entry is
more correct, but I can make a patch to behave like emacs if needed.
On 19/05/17 14:11, Lucas Gabriel Vuotto wrote:
> Previous patch shall be ignored, as it was an ugly hack. Below is a patch
> that is simpler and fixes expandtilde instead, so it fixes the problem in
> other situations (writing files to ~, for example). The only thing that I'm
> not sure is whether to use getuid or geteuid. Any suggestion / explanation is
> welcome.
>
> Index: usr.bin/mg/fileio.c
> ===
> RCS file: /cvs/src/usr.bin/mg/fileio.c,v
> retrieving revision 1.103
> diff -u -p -u -p -r1.103 fileio.c
> --- usr.bin/mg/fileio.c28 Jul 2016 21:40:25 -1.103
> +++ usr.bin/mg/fileio.c18 May 2017 17:53:03 -
> @@ -723,15 +723,12 @@ expandtilde(const char *fn)
> return(ret);
> }
> if (ulen == 0) { /* ~/ or ~ */
> -if ((un = getlogin()) != NULL)
> -(void)strlcpy(user, un, sizeof(user));
> -else
> -user[0] = '\0';
> +pw = getpwuid(getuid());
> } else { /* ~user/ or ~user */
> memcpy(user, [1], ulen);
> user[ulen] = '\0';
> +pw = getpwnam(user);
> }
> -pw = getpwnam(user);
> if (pw != NULL) {
> plen = strlcpy(path, pw->pw_dir, sizeof(path));
> if (plen == 0 || path[plen - 1] != '/') {
>
Re: mg backup directory
bump because I forgot to CC florian@ On 26/05/17 18:11, Lucas Gabriel Vuotto wrote: On 26/05/17 12:38, Florian Obser wrote: On Fri, May 19, 2017 at 02:11:22PM -0300, Lucas Gabriel Vuotto wrote: Previous patch shall be ignored, as it was an ugly hack. Below is a patch that is simpler and fixes expandtilde instead, so it fixes the problem in other situations (writing files to ~, for example). The only thing that I'm not sure is whether to use getuid or geteuid. Any suggestion / explanation is welcome. what is emacs doing in this case? It reads HOME from environment (from lisp--arghhh) if the path is ~/foo, or calls getpwnam if the path is ~user/foo.
Re: mg backup directory
On 26/05/17 12:38, Florian Obser wrote: On Fri, May 19, 2017 at 02:11:22PM -0300, Lucas Gabriel Vuotto wrote: Previous patch shall be ignored, as it was an ugly hack. Below is a patch that is simpler and fixes expandtilde instead, so it fixes the problem in other situations (writing files to ~, for example). The only thing that I'm not sure is whether to use getuid or geteuid. Any suggestion / explanation is welcome. what is emacs doing in this case? It reads HOME from environment (from lisp--arghhh) if the path is ~/foo, or calls getpwnam if the path is ~user/foo.
Re: mg backup directory
Previous patch shall be ignored, as it was an ugly hack. Below is a patch that
is simpler and fixes expandtilde instead, so it fixes the problem in other
situations (writing files to ~, for example). The only thing that I'm not sure
is whether to use getuid or geteuid. Any suggestion / explanation is welcome.
Index: usr.bin/mg/fileio.c
===
RCS file: /cvs/src/usr.bin/mg/fileio.c,v
retrieving revision 1.103
diff -u -p -u -p -r1.103 fileio.c
--- usr.bin/mg/fileio.c 28 Jul 2016 21:40:25 - 1.103
+++ usr.bin/mg/fileio.c 18 May 2017 17:53:03 -
@@ -723,15 +723,12 @@ expandtilde(const char *fn)
return(ret);
}
if (ulen == 0) { /* ~/ or ~ */
- if ((un = getlogin()) != NULL)
- (void)strlcpy(user, un, sizeof(user));
- else
- user[0] = '\0';
+ pw = getpwuid(getuid());
} else { /* ~user/ or ~user */
memcpy(user, [1], ulen);
user[ulen] = '\0';
+ pw = getpwnam(user);
}
- pw = getpwnam(user);
if (pw != NULL) {
plen = strlcpy(path, pw->pw_dir, sizeof(path));
if (plen == 0 || path[plen - 1] != '/') {
On 13/05/17 01:32, Lucas Gabriel Vuotto wrote:
Sorry, space got mangled in previous email.
Index: fileio.c
===
RCS file: /cvs/src/usr.bin/mg/fileio.c,v
retrieving revision 1.103
diff -u -p -u -p -r1.103 fileio.c
--- fileio.c28 Jul 2016 21:40:25 - 1.103
+++ fileio.c13 May 2017 04:15:15 -
@@ -641,14 +641,15 @@ bkuplocation(const char *fn)
int
backuptohomedir(int f, int n)
{
- const char *c = _PATH_MG_DIR;
- char*p;
+ char*home;
if (bkupdir == NULL) {
- p = adjustname(c, TRUE);
- bkupdir = strndup(p, NFILEN);
- if (bkupdir == NULL)
- return(FALSE);
+ if ((home = getenv("HOME")) == NULL || *home == '\0')
+ return (FALSE);
+ if (asprintf(, _PATH_MG_DIR, home) == -1) {
+ bkupdir = NULL;
+ return (FALSE);
+ }
if (mkdir(bkupdir, 0700) == -1 && errno != EEXIST) {
free(bkupdir);
@@ -736,7 +737,7 @@ expandtilde(const char *fn)
plen = strlcpy(path, pw->pw_dir, sizeof(path));
if (plen == 0 || path[plen - 1] != '/') {
if (strlcat(path, "/", sizeof(path)) >= sizeof(path)) {
- dobeep();
+ dobeep();
ewprintf("Path too long");
return (NULL);
}
Index: pathnames.h
===
RCS file: /cvs/src/usr.bin/mg/pathnames.h,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 pathnames.h
--- pathnames.h 18 Jun 2012 07:14:55 - 1.1
+++ pathnames.h 13 May 2017 04:15:15 -
@@ -6,6 +6,6 @@
* standard path names
*/
-#define_PATH_MG_DIR"~/.mg.d"
+#define_PATH_MG_DIR"%s/.mg.d"
#define_PATH_MG_STARTUP"%s/.mg"
#define_PATH_MG_TERM "%s/.mg-%s"
Re: ksh(1): don't output invalid UTF-8 characters
Hi,
On 19/05/17 03:42, Anton Lindqvist wrote:
> Hi,
> I did submit this problem[1] earlier but with an incomplete analysis and
> fix. Here's a second attempt.
>
> This does only occur when running ksh with emacs mode under tmux. How to
> re-produce:
>
> 1. Run ksh under tmux.
>
> 2. Input the following characters, without spaces:
>
>a (any character) ^B (backward-char) ö (any UTF-8 character)
>
> 3. At this point, the prompt gets overwritten.
>
> Since ksh read a single byte of input, it will display a partial UTF-8
> character before the whole character has been read. This is especially
> troublesome when the cursor is not placed at the end of the line. In the
> scenario above, after reading the first byte of 'ö' the following
> sequence will be displayed:
>
> 0xc3 0x61 0x08
>
> That is the first byte of 'ö' (0xc3), 'a' (0x61), '\b' (0x08). tmux
> does the right thing here, since 0xc3 is a valid UTF-8 start byte it
> expects it to be followed by a UTF-8 continuation byte which is not the
> case. The two first bytes (0xc3, 0x61) are discarded and the parser is
> reset to its initial state causing the backspace to be accepted and the
> first character in the prompt to be overwritten.
>
> After the second byte of 'ö' (0xb6) is read by ksh, the following
> sequence will be displayed:
>
>0x08 0xc3 0xb6 0x61 0x08
>
> That is '\b' (0x08), 'ö' (0xc3, 0xb6), 'a' (0x61), '\b' (0x08). Since
> ksh assumes the cursor is correctly positioned it displays a leading
> backspace in order to move passed the first character. This is however
> not true causing another character in the prompt to be overwritten.
>
> Below is diff that make sure to read a whole UTF-8 character in
> x_emacs() prior doing another iteration of the main-loop which solves
> the problem. It does not validate UTF-8 input but instead assumes every
> such character is valid.
>
> Comments and feedback are much appreciated.
>
> [1] http://marc.info/?l=openbsd-misc=148509346310901=2
>
> Index: emacs.c
> ===
> RCS file: /cvs/src/bin/ksh/emacs.c,v
> retrieving revision 1.67
> diff -u -p -r1.67 emacs.c
> --- emacs.c 12 May 2017 14:37:52 - 1.67
> +++ emacs.c 14 May 2017 08:21:26 -
> @@ -98,6 +98,7 @@ static int x_col;
> static int x_displen;
> static int x_arg; /* general purpose arg */
> static int x_arg_defaulted;/* x_arg not explicitly set; defaulted to 1 */
> +static int x_getc_again;
>
> static int xlp_valid;
> /* end from 4.9 edit.h } */
> @@ -142,6 +143,7 @@ static intx_fold_case(int);
> static char *x_lastcp(void);
> static void do_complete(int, Comp_type);
> static int isu8cont(unsigned char);
> +static int u8len(unsigned char);
>
> /* proto's for keybindings */
> static int x_abort(int);
> @@ -272,6 +274,21 @@ isu8cont(unsigned char c)
> return (c & (0x80 | 0x40)) == 0x80;
> }
>
> +static int
> +u8len(unsigned char c)
> +{
> + switch (c & 0xF0) {
> + case 0xF0:
> + return 4;
> + case 0xE0:
> + return 3;
> + case 0xC0:
> + return 2;
> + default:
> + return 1;
> + }
> +}
> +
This is wrong: most codepoints in the range U+0080-U+07ff (the ones greater
than U+0400) would be interpreted as being 1 character long instead of 2.
> int
> x_emacs(char *buf, size_t len)
> {
> @@ -318,10 +335,12 @@ x_emacs(char *buf, size_t len)
> x_last_command = NULL;
> while (1) {
> x_flush();
> - if ((c = x_e_getc()) < 0)
> - return 0;
> + do {
> + if ((c = x_e_getc()) < 0)
> + return 0;
>
> - line[at++] = c;
> + line[at++] = c;
> + } while (x_getc_again > 0);
> line[at] = '\0';
>
> if (x_arg == -1) {
> @@ -364,7 +383,10 @@ x_emacs(char *buf, size_t len)
> } else {
> if (submatch)
> continue;
> - if (at == 1)
> + if (at > 1) {
> + x_ins(line);
> + ret = KSTD;
> + } else if (at == 1)
> ret = x_insert(c);
> else
> ret = x_error(c); /* not matched meta sequence
> */
> @@ -1887,8 +1909,12 @@ x_e_getc(void)
> macro_args = NULL;
> c = x_getc();
> }
> - } else
> + } else {
> c = x_getc();
> + if (x_getc_again == 0)
> + x_getc_again = u8len(c);
> + x_getc_again--;
> + }
>
> return c;
> }
>
Re: mg backup directory
Sorry, space got mangled in previous email.
Index: fileio.c
===
RCS file: /cvs/src/usr.bin/mg/fileio.c,v
retrieving revision 1.103
diff -u -p -u -p -r1.103 fileio.c
--- fileio.c28 Jul 2016 21:40:25 - 1.103
+++ fileio.c13 May 2017 04:15:15 -
@@ -641,14 +641,15 @@ bkuplocation(const char *fn)
int
backuptohomedir(int f, int n)
{
- const char *c = _PATH_MG_DIR;
- char*p;
+ char*home;
if (bkupdir == NULL) {
- p = adjustname(c, TRUE);
- bkupdir = strndup(p, NFILEN);
- if (bkupdir == NULL)
- return(FALSE);
+ if ((home = getenv("HOME")) == NULL || *home == '\0')
+ return (FALSE);
+ if (asprintf(, _PATH_MG_DIR, home) == -1) {
+ bkupdir = NULL;
+ return (FALSE);
+ }
if (mkdir(bkupdir, 0700) == -1 && errno != EEXIST) {
free(bkupdir);
@@ -736,7 +737,7 @@ expandtilde(const char *fn)
plen = strlcpy(path, pw->pw_dir, sizeof(path));
if (plen == 0 || path[plen - 1] != '/') {
if (strlcat(path, "/", sizeof(path)) >= sizeof(path)) {
- dobeep();
+ dobeep();
ewprintf("Path too long");
return (NULL);
}
Index: pathnames.h
===
RCS file: /cvs/src/usr.bin/mg/pathnames.h,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 pathnames.h
--- pathnames.h 18 Jun 2012 07:14:55 - 1.1
+++ pathnames.h 13 May 2017 04:15:15 -
@@ -6,6 +6,6 @@
* standard path names
*/
-#define_PATH_MG_DIR"~/.mg.d"
+#define_PATH_MG_DIR"%s/.mg.d"
#define_PATH_MG_STARTUP"%s/.mg"
#define_PATH_MG_TERM "%s/.mg-%s"
On 13/05/17 01:25, Lucas Gabriel Vuotto wrote:
> Hi tech@,
>
> mg(1)'s backup-to-home-directory writes backup files to `~/.mg.d'
> according to the manpage. In order to expand the tilde, it uses a
> custom function (expandtilde, fileio.c:700) which uses the pw entry for
> the user name returned by getlogin(2). This can lead to an undesired
> result if mg is run under another user via su.
>
> For reading the startup file `~/.mg', it just tries to get HOME from
> environment and falls back to a default location defined at compile
> time if it can't get HOME. I think that it should do the same to
> setup the backup directory, with no fall back. Inlined is a patch
> to do that. While there, remove trailing spaces in fileio.c. A fall
> back could be added if needed. In that case I suggest using `/tmp'
> instead of a path defined at compile time.
>
> If it isn't viable to merge the patch, I think the current behaviour
> should be reflected in the manpage. I can also write a patch for that.
>
> OK?
>
> Cheers.
>
> Index: fileio.c
> ===
> RCS file: /cvs/src/usr.bin/mg/fileio.c,v
> retrieving revision 1.103
> diff -u -p -u -p -r1.103 fileio.c
> --- fileio.c28 Jul 2016 21:40:25 -1.103
> +++ fileio.c13 May 2017 04:15:15 -
> @@ -641,14 +641,15 @@ bkuplocation(const char *fn)
> int
> backuptohomedir(int f, int n)
> {
> -const char*c = _PATH_MG_DIR;
> -char*p;
> +char*home;
>
> if (bkupdir == NULL) {
> -p = adjustname(c, TRUE);
> -bkupdir = strndup(p, NFILEN);
> -if (bkupdir == NULL)
> -return(FALSE);
> +if ((home = getenv("HOME")) == NULL || *home == '\0')
> +return (FALSE);
> +if (asprintf(, _PATH_MG_DIR, home) == -1) {
> +bkupdir = NULL;
> +return (FALSE);
> +}
>
> if (mkdir(bkupdir, 0700) == -1 && errno != EEXIST) {
> free(bkupdir);
> @@ -736,7 +737,7 @@ expandtilde(const char *fn)
> plen = strlcpy(path, pw->pw_dir, sizeof(path));
> if (plen == 0 || path[plen - 1] != '/') {
> if (strlcat(path, "/", sizeof(path)) >= sizeof(path)) {
> -dobeep();
> +dobeep();
> ewprintf("Path too long");
> return (NULL);
> }
> Index: pathnames.h
> ===
> RCS file: /cvs/src/usr.bin/mg/pathnames.h,v
&g
mg backup directory
Hi tech@,
mg(1)'s backup-to-home-directory writes backup files to `~/.mg.d'
according to the manpage. In order to expand the tilde, it uses a
custom function (expandtilde, fileio.c:700) which uses the pw entry for
the user name returned by getlogin(2). This can lead to an undesired
result if mg is run under another user via su.
For reading the startup file `~/.mg', it just tries to get HOME from
environment and falls back to a default location defined at compile
time if it can't get HOME. I think that it should do the same to
setup the backup directory, with no fall back. Inlined is a patch
to do that. While there, remove trailing spaces in fileio.c. A fall
back could be added if needed. In that case I suggest using `/tmp'
instead of a path defined at compile time.
If it isn't viable to merge the patch, I think the current behaviour
should be reflected in the manpage. I can also write a patch for that.
OK?
Cheers.
Index: fileio.c
===
RCS file: /cvs/src/usr.bin/mg/fileio.c,v
retrieving revision 1.103
diff -u -p -u -p -r1.103 fileio.c
--- fileio.c28 Jul 2016 21:40:25 - 1.103
+++ fileio.c13 May 2017 04:15:15 -
@@ -641,14 +641,15 @@ bkuplocation(const char *fn)
int
backuptohomedir(int f, int n)
{
- const char *c = _PATH_MG_DIR;
- char*p;
+ char*home;
if (bkupdir == NULL) {
- p = adjustname(c, TRUE);
- bkupdir = strndup(p, NFILEN);
- if (bkupdir == NULL)
- return(FALSE);
+ if ((home = getenv("HOME")) == NULL || *home == '\0')
+ return (FALSE);
+ if (asprintf(, _PATH_MG_DIR, home) == -1) {
+ bkupdir = NULL;
+ return (FALSE);
+ }
if (mkdir(bkupdir, 0700) == -1 && errno != EEXIST) {
free(bkupdir);
@@ -736,7 +737,7 @@ expandtilde(const char *fn)
plen = strlcpy(path, pw->pw_dir, sizeof(path));
if (plen == 0 || path[plen - 1] != '/') {
if (strlcat(path, "/", sizeof(path)) >= sizeof(path)) {
- dobeep();
+ dobeep();
ewprintf("Path too long");
return (NULL);
}
Index: pathnames.h
===
RCS file: /cvs/src/usr.bin/mg/pathnames.h,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 pathnames.h
--- pathnames.h 18 Jun 2012 07:14:55 - 1.1
+++ pathnames.h 13 May 2017 04:15:15 -
@@ -6,6 +6,6 @@
* standard path names
*/
-#define_PATH_MG_DIR"~/.mg.d"
+#define_PATH_MG_DIR"%s/.mg.d"
#define_PATH_MG_STARTUP"%s/.mg"
#define_PATH_MG_TERM "%s/.mg-%s"
Re: regarding OpenSSL License change
On Fri, Mar 24, 2017 at 02:37:58PM +0100, Sebastian Benoit wrote: > It's about "You cannot change the licence without consent of the author" and > "We just assume that you say yes to this because we dont care about your > rights", which is morally and legally wrong. It's very simple. Four words. "Silence is not consent." Not in contracts. Not in sex. And not in licensing. ==ml -- Michael W. LucasTwitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/
-current relayd TLS interception and SNI?
Hi folks,
It *appears* that relayd doesn't speak SNI when used as a transparent
intercepting proxy ala
http://www.reykfloeter.com/post/41814177050/relayd-ssl-interception
What did & what I saw:
Set up the proxy as per Reyk's article. Configs below. Running today's
amd64 snapshot on vmware.
# uname -a
OpenBSD r2.mwlucas.org 6.0 GENERIC#204 amd64
Call up wapo.st from a client with my private CA installed. There's a
cert error. The site identifies itself as bit.ly. https://bit.ly works
fine.
Hit my blog, https://blather.michaelwlucas.com. Works fine.
Call up any of my other TLS sites on that IP: https://mwl.io,
https://michaelwlucas.com, https://michaelwarrenlucas.com,
https://tiltedwindmillpress.com. All get identified as blather.
System setup:
# openssl req -x509 -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/ca.key
-out /etc/ssl/ca.crt
# openssl req -nodes -x509 -days 365 -newkey rsa:2048 -keyout
/etc/ssl/private/127.0.0.1:8443.key -out /etc/ssl/127.0.0.1:8443.crt
relayd.conf:
--
log all
http protocol "intercept" {
tls ca cert "/etc/ssl/ca.crt"
tls ca key "/etc/ssl/private/ca.key" password "komodia"
pass url log
}
http protocol "wtf" {
return error
}
relay "tlsintercept" {
listen on 127.0.0.1 port 8443 tls
protocol intercept
forward with tls to destination
}
relay "proxy" {
listen on 127.0.0.1 port 8080
protocol wtf
forward to destination
}
--
Am I screwing up here? Or is it a real bug?
Thanks,
==ml
--
Michael W. LucasTwitter @mwlauthor
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
blog: http://blather.michaelwlucas.com/
relayd man page example doesn't parse
Running 5 February amd64 snapshot on VMWare.
OpenBSD r1.mwlucas.org 6.0 GENERIC#162 amd64
Trying to use relayd's filtering on query strings.
According to the man page, I can block or pass specific query terms,
and values of those terms. Blocking the whole term works, but matching
the query value doesn't. I'm using the strings from relayd.conf(5):
query option [key [value value]]
Look up the entity as a query variable in the URL when using the
http protocol. This type is only available with the direction
request, for example:
# Will match /cgi-bin/example.pl?foo=bar=yes
request query expect "bar" from "foo"
Here's my relayd.conf:
table { 192.0.2.101 192.0.2.102 }
http protocol daft {
return error
block request query "foo"
pass request query expect "bar" from "foo"
}
relay www {
listen on 203.0.113.213 port 80
forward to port http check http "/" code 200
protocol daft
}
Checking the file gives:
relayd.mini.conf:15: syntax error
relayd.mini.conf:21: no such protocol: daft
no actions, nothing to do
Am I missing something obvious here? Or did something else break?
Thanks,
==ml
--
Michael W. LucasTwitter @mwlauthor
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
blog: http://blather.michaelwlucas.com/
relayd crash using DNS-sanitizing protocol
Hi,
Running 6.0 snapshot from 5 Feb on amd64, and experimenting with
relayd.
I set up a DNS cluster using redirects, as per relayd.conf(5). Worked
fine, so I'm pretty sure the DNS servers behind my relayd box work.
The man page says that relayd has a relay protocol for DNS, that
randomizes query IDs. Cool idea, let's try it. My relayd.conf now
looks like so:
--
table { 192.0.2.101 192.0.2.102 }
dns protocol dnsfix
relay dns {
listen on 203.0.113.213 port 53
forward to port 53 check tcp
protocol dnsfix
}
--
With "protocol dnsfix" present, relayd listens on UDP only. I'm
guessing using relayd's DNS protocol makes this happen. Which would
make sense, you don't need it for TCP queries.
So let's try to run this critter.
# relayd -d
startup
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
pfe: filter init done
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
relayd_tls_ticket_rekey: rekeying tickets
relay_privinit: adding relay dns
protocol 1: name dnsfix
flags: used, relay flags:
tls session tickets: enabled
type: dns
hce_notify_done: 192.0.2.101 (tcp connect ok)
host 192.0.2.101, check tcp (4ms,tcp connect ok), state unknown -> up,
availability 100.00%
hce_notify_done: 192.0.2.102 (tcp connect ok)
host 192.0.2.102, check tcp (6ms,tcp connect ok), state unknown -> up,
availability 100.00%
pfe_dispatch_hce: state 1 for host 1 192.0.2.101
pfe_dispatch_hce: state 1 for host 2 192.0.2.102
adding 2 hosts from table dns:53
adding 2 hosts from table dns:53
relay_launch: running relay dns
relay_launch: running relay dns
adding 2 hosts from table dns:53
relay_launch: running relay dns
I make a DNS query from a client, say to google.com or my site or
whatever, and get:
lost child: pid 779 terminated; signal 11
hce exiting, pid 61465
pfe exiting, pid 93428
ca exiting, pid 1166
ca exiting, pid 11360
ca exiting, pid 57827
lost child: pid 38872 terminated; signal 11
lost child: pid 57998 terminated; signal 11
parent terminating, pid 76339
Am I abusing this program? Or is this a real crash?
Thanks,
==ml
--
Michael W. LucasTwitter @mwlauthor
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
blog: http://blather.michaelwlucas.com/
Re: err with multiple TLS sites but one OCSP?
On Fri, Jan 27, 2017 at 09:53:25PM +, Bob Beck wrote:
>On Fri, Jan 27, 2017 at 14:12 Michael W. Lucas
> Or a misconfiguration. ? show configs
Configs follow.
# cat /etc/httpd.conf
include "/etc/sites/www3.conf"
include "/etc/sites/www4.conf"
www3.conf:
server "www3.mwlucas.org" {
listen on * port 80
block return 302 "https://$SERVER_NAME$REQUEST_URI;
}
server "www3.mwlucas.org" {
alias tarpit.mwlucas.org
listen on * tls port 443
hsts
# TLS certificate and key files created with acme-client(1)
tls certificate "/etc/ssl/acme/www3/www3.fullchain.pem"
tls key "/etc/ssl/acme/www3/www3.key"
tls ocsp "/etc/ssl/acme/www3/www3.der"
tcp nodelay
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
}
www4:
server "www4.mwlucas.org" {
alias bill.mwlucas.org
alias auction.mwlucas.org
listen on * port 80
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
block return 301 "https://$DOCUMENT_URI;
}
server "www4.mwlucas.org" {
alias bill.mwlucas.org
alias auction.mwlucas.org
root "/www4"
listen on * tls port 443
hsts
# TLS certificate and key files created with acme-client(1)
tls certificate "/etc/ssl/acme/www4/www4.fullchain.pem"
tls key "/etc/ssl/acme/www4/www4.key"
# tls ocsp "/etc/ssl/acme/www4/www4.der"
tcp nodelay
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
}
--
Michael W. LucasTwitter @mwlauthor
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
blog: http://blather.michaelwlucas.com/
Re: err with multiple TLS sites but one OCSP?
On Fri, Jan 27, 2017 at 02:50:29PM -0500, Michael W. Lucas wrote: > On Fri, Jan 27, 2017 at 06:49:06PM +, Stuart Henderson wrote: > > That looks like a web server bug, it shouldn't return a staple > > in that case. What software are you using for that? > > > > OpenBSD httpd, of course. amd64 snapshot downloaded yesterday from > ftp3.usa.openbsd.org. To be clear, that's a "How the hell could I forget to include that?" facepalm, not anything about Stuart asking the question... -- Michael W. LucasTwitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/
Re: err with multiple TLS sites but one OCSP?
On Fri, Jan 27, 2017 at 06:49:06PM +, Stuart Henderson wrote: > That looks like a web server bug, it shouldn't return a staple > in that case. What software are you using for that? OpenBSD httpd, of course. amd64 snapshot downloaded yesterday from ftp3.usa.openbsd.org. ==ml -- Michael W. LucasTwitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/
err with multiple TLS sites but one OCSP?
Hi, Not sure if this is an expected part of OCSP or a bug. I've configured two TLS sites on one host, one with OCSP stapling (www3.mwlucas.org) and one without (www4.mwlucas.org). The OCSP site works fine, but the non-OCSP site generates an err. It *appears* that queries to the non-OCSP site return the OCSP site's OCSP cert. Following please find openssl queries on both. Feel free to check the sites yourself, I'm FAR from a TLS guru. # openssl s_client -connect www4.mwlucas.org:443 -status -servername www4.mwlucas.org ... verify return:1 OCSP response: == OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 Produced At: Jan 26 23:02:00 2017 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1 Serial Number: 032CBDA721856F117CC7D57A72BBFA77B578 Cert Status: good This Update: Jan 26 23:00:00 2017 GMT Next Update: Feb 2 23:00:00 2017 GMT Signature Algorithm: sha256WithRSAEncryption 6a:1e:f1:44:8c:a9:a6:7e:40:25:3a:f7:50:e9:43:42:0f:74: 9b:dc:ee:56:a3:47:0b:ce:73:88:ee:f0:84:fc:b0:25:5b:3d: 67:d0:66:20:c7:60:7c:ee:26:91:72:4e:d0:f2:67:5a:e3:c1: 06:57:31:47:29:1a:55:19:48:e7:e6:32:0b:18:d9:33:9d:55: d7:36:38:f1:96:57:bc:5d:89:82:31:bb:4e:12:0c:5c:ab:1a: f6:1d:a1:48:be:1c:1d:3b:52:a0:60:2f:1d:f9:3c:48:cd:df: a6:5e:b5:79:0c:b9:ed:d5:61:29:53:ee:83:5f:89:af:35:27: d6:94:05:f5:fb:d1:a8:4d:26:8d:8b:cf:e9:db:53:ad:e6:47: a7:db:91:9e:9d:a1:b2:2c:1e:d9:98:c5:af:5c:12:d1:04:5a: 82:be:8d:80:1f:38:c2:5d:b1:6f:99:e1:ca:53:71:1c:85:0d: 3e:f3:14:bc:3b:c9:c0:dd:6b:ec:59:d4:54:dc:fb:9c:da:72: 91:45:61:55:69:e9:75:51:8f:e2:82:6a:dd:ec:bc:bd:3c:2c: 92:43:f7:d9:65:1d:60:14:91:e0:b0:2b:46:25:49:35:74:99: 71:a3:c0:d0:91:66:29:7e:01:1b:35:f1:2e:40:dc:f3:4d:98: 69:40:6f:46 # openssl s_client -connect www3.mwlucas.org:443 -status -servername www3.mwlucas.org CONNECTED(0003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = www3.mwlucas.org verify return:1 OCSP response: == OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 Produced At: Jan 26 23:02:00 2017 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1 Serial Number: 032CBDA721856F117CC7D57A72BBFA77B578 Cert Status: good This Update: Jan 26 23:00:00 2017 GMT Next Update: Feb 2 23:00:00 2017 GMT Signature Algorithm: sha256WithRSAEncryption 6a:1e:f1:44:8c:a9:a6:7e:40:25:3a:f7:50:e9:43:42:0f:74: 9b:dc:ee:56:a3:47:0b:ce:73:88:ee:f0:84:fc:b0:25:5b:3d: 67:d0:66:20:c7:60:7c:ee:26:91:72:4e:d0:f2:67:5a:e3:c1: 06:57:31:47:29:1a:55:19:48:e7:e6:32:0b:18:d9:33:9d:55: d7:36:38:f1:96:57:bc:5d:89:82:31:bb:4e:12:0c:5c:ab:1a: f6:1d:a1:48:be:1c:1d:3b:52:a0:60:2f:1d:f9:3c:48:cd:df: a6:5e:b5:79:0c:b9:ed:d5:61:29:53:ee:83:5f:89:af:35:27: d6:94:05:f5:fb:d1:a8:4d:26:8d:8b:cf:e9:db:53:ad:e6:47: a7:db:91:9e:9d:a1:b2:2c:1e:d9:98:c5:af:5c:12:d1:04:5a: 82:be:8d:80:1f:38:c2:5d:b1:6f:99:e1:ca:53:71:1c:85:0d: 3e:f3:14:bc:3b:c9:c0:dd:6b:ec:59:d4:54:dc:fb:9c:da:72: 91:45:61:55:69:e9:75:51:8f:e2:82:6a:dd:ec:bc:bd:3c:2c: 92:43:f7:d9:65:1d:60:14:91:e0:b0:2b:46:25:49:35:74:99: 71:a3:c0:d0:91:66:29:7e:01:1b:35:f1:2e:40:dc:f3:4d:98: 69:40:6f:46 == ... ==ml -- Michael W. LucasTwitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/
tls_config_parse_protocols vs httpd in snapshot
Hi,
Something doesn't seem right between httpd.conf and
tls_config_parse_protocols. Running today's snapshot, but was first
attempted in the 15 Dec snapshot.
httpd.conf(5) says to get TLS protocols from
tls_config_parse_protocols(3). That page says:
The tls_config_parse_protocols() function parses a protocol string and
returns the corresponding value via the protocols argument. This value
can then be passed to the tls_config_set_protocols() function. The
protocol string is a comma or colon separated list of keywords.
Comma or colon delimited. Seems fine.
My httpd.conf is this:
server "www3.mwlucas.org" {
listen on * port 80
block return 302 "https://$SERVER_NAME$REQUEST_URI;
}
server "www3.mwlucas.org" {
alias tarpit.mwlucas.org
listen on * tls port 443
hsts
# TLS certificate and key files created with acme-client(1)
tls certificate "/etc/ssl/acme/fullchain.pem"
tls key "/etc/ssl/acme/private/privkey.pem"
tls ocsp "/etc/ssl/acme/ocsp.der"
tls protocols tlsv1.0,tlsv1.1
location "/.well-known/acme-challenge/*" {
root "/acme"
root strip 2
}
}
The man page says I can use a comma instead of a colon, so I change it
like so.
tls protocols tlsv1.0,tlsv1.1
This gives me
# httpd -n
/etc/httpd.conf:16: syntax error
Looks like something doesn't match.
The man page also says:
If a value has a negative prefix (in the form
of a leading exclamation mark) then it is removed from the list of
available protocols, rather than being added to it.
I read this as the following should work.
tls protocols all:!tlsv1.0
Instead, I get:
httpd -n
/etc/httpd.conf:16: invalid tls protocols
==ml
--
Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor
http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 01:06:37PM -0600, Theo de Raadt wrote: Look, if people keep being unspecific on how DUIDs interfere with their usage patterns, then the non-DUID configuration mode is going to go away. WHY must be use the non-DUID option in the installer??!?!?! As someone who recently had several OpenBSD boxes in production, in a variety of roles: I can't imagine why DUIDs wouldn't work. We defaulted to DUIDs the moment they became available. They worked fine. Even for the Linux guys. If someone has a particular dislike of DUIDs, they can easily change them back. Anyone who has a whole bunch of OpenBSD boxes probably has uses a post-install script, and a couple lines of sed/awk/perl/whatever will make them happy. If you have one OpenBSD box, and you just don't like DUIDs, again, it's really easy to revert. ==ml PS: Yes, I still have OpenBSD hosts. But I'm no longer a pro sysadmin, so I can't claim to be running a server farm or anything like that. -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Re: 27 Mar 2014 amd64 snapshot
On Fri, Mar 28, 2014 at 07:07:42PM +, Stuart Henderson wrote: On 2014/03/28 13:53, Michael W. Lucas wrote: Yep. Lots of users going through proxy. Ran tcpdump on the proxy. The only packets that arrived from the OpenBSD host were my pings. It appeared that the installer wasn't even trying to reach the proxy. Note appeared that, there could be something else going on. Earlier upgrades were over FTP, but tried http this time. I would try ^Z'ing to isolate the script. Make sure network is up, then try ftp -d -o- http://proxyhost:3128/ and see if you get packets (obviously won't get a good page, expect a 400 or similar error, but enough to see if it can reach it). Then try http_proxy=http://proxyhost:3128/ ftp -d -o- http://ftp3.usa.openbsd.org/, etc. Basically try a few things to see if you can isolate exactly what's working and what's failing. Thanks for the suggestion. Trying the 31 March snapshot now, because it's there. Once again, the installer doesn't send any packets to the proxy. I ^Z out to a shell, then did: # ftp -d -o- http://proxy:8080 Packets arrived at the proxy, and ftp showed an error. I set http_proxy in the shell and do: # cd /mnt/tmp # ftp http://ftp3.usa.openbsd.org/pub/OpenBSD/snapshots/amd64/bsd.rd Packet sniffing on the network shows that the host is trying to reach ftp3.usa directly, without using the proxy. I booted back into the January snapshot and ran the same command: # env | grep -i http FTP_PROXY=http://concrete.lodden.com:8080 ftp_proxy=http://concrete.lodden.com:8080 HTTP_PROXY=http://concrete.lodden.com:8080 http_proxy=http://concrete.lodden.com:8080 ftp http://ftp3.usa.openbsd.org/pub/OpenBSD/snapshots/amd64/bsd.rd Trying 139.171.199.21... Requesting http://ftp3.usa.openbsd.org/pub/OpenBSD/snapshots/amd64/bsd.rd (via http://concrete.lodden.com) 100% |**| 8810 KB00:06 9021473 bytes received in 6.32 seconds (1.36 MB/s) (Yes, OpenBSD doesn't need HTTP_PROXY or FTP_PROXY, but I copy my .cshrc everywhere.) So, to my eyes, it appears that ftp on the new snapshot installer isn't respecting http_proxy. ==ml -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Re: 27 Mar 2014 amd64 snapshot
On Tue, Apr 01, 2014 at 11:34:35AM -0600, Theo de Raadt wrote: So, to my eyes, it appears that ftp on the new snapshot installer isn't respecting http_proxy. The ftp program has not changed in any way. And as nobody else has reported problems by now, it's clearly something weird that only triggers in my environment. I have tried specifying proxy as hostname and as IP in the upgrade script. The host doesn't try to contact the proxy at all. I'll poke at it some more, see if I can identify the edge case I'm hitting. Thanks, ==ml -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
27 Mar 2014 amd64 snapshot
Hi, Trying to upgrade to $SUBJECT. Have done so on this same host many times before. Boot bsd.rd. Type U, enter x 5. Select http. Enter proxy server -- proxy is necessary. Type in ftp3.usa.openbsd.org, take default path Wait... ftp: connect: Operation timed out Escape to command prompt. Can ping proxy by hostname. Host currently running: OpenBSD gepetto.lodden.com 5.5 GENERIC#224 amd64 # ls -la /bsd -rw-r--r-- 1 root wheel 11259291 Jan 17 11:18 /bsd tcpdump on proxy shows no packets arriving from host during install process. Proxy error? -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e coupon code ILUVMICHAEL gets you 30% off helps me.
Re: 27 Mar 2014 amd64 snapshot
Yep. Lots of users going through proxy. Ran tcpdump on the proxy. The only packets that arrived from the OpenBSD host were my pings. It appeared that the installer wasn't even trying to reach the proxy. Note appeared that, there could be something else going on. Earlier upgrades were over FTP, but tried http this time. On Fri, Mar 28, 2014 at 11:28:50AM -0600, Bob Beck wrote: Does your proxy do http? no ftp protocol in new installers - we're killing it with fire. On Fri, Mar 28, 2014 at 9:30 AM, Michael W. Lucas mwlu...@michaelwlucas.com wrote: Hi, Trying to upgrade to $SUBJECT. Have done so on this same host many times before. Boot bsd.rd. Type U, enter x 5. Select http. Enter proxy server -- proxy is necessary. Type in ftp3.usa.openbsd.org, take default path Wait... ftp: connect: Operation timed out Escape to command prompt. Can ping proxy by hostname. Host currently running: OpenBSD gepetto.lodden.com 5.5 GENERIC#224 amd64 # ls -la /bsd -rw-r--r-- 1 root wheel 11259291 Jan 17 11:18 /bsd tcpdump on proxy shows no packets arriving from host during install process. Proxy error? -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e coupon code ILUVMICHAEL gets you 30% off helps me. -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e coupon code ILUVMICHAEL gets you 30% off helps me.
RTL8723AS-VAU
Hi tech@, Driver/help request: RTL8723AS-VAU either in urtwn or new driver. Found on: Lenovo IdeaPad Yoga 13 port 2 addr 3: high speed, power 500 mA, config 1, GW-USValue-EZ(0x7811), GW-USValue-EZ(0x7392), rev 2.00, iSerialNumber 00e04c01 - note serial number urtwn0 port 3 addr 4: high speed, power 500 mA, config 1, USB2.0-CRW(0x0129), Generic(0x0bda), rev 39.60, iSerialNumber 2010020139600 ugen0 (card in question) port 4 addr 5: high speed, self powered, config 1, 802.11n WLAN Adapter(0x1724), Realtek(0x0bda), rev 2.00, iSerialNumber 00e04c01 ugen1 ^ same serial urtwn1 at uhub2 port 4 Realtek 802.11n WLAN Adapter rev 2.00/2.00 addr 5 urtwn1: MAC/BB RTL8188CUS, RF 6052 1T1R, address fu:nf:un:fu:nf Pretty wild card, seeing as it has a PROPRIETARY USB CONNECTOR on the motherboard itself. It is detachable, but highly unlikely it'll plug into anything; its a weird rectangular connector. Hence, highly likely that only someone with this laptop can help. Also, someone can help by checking out chipset differences from classic urtwn and those used by Larry Finger's beta Linux driver for this card @ http://github.com/lwfinger/rtl8723au (doing this ATM) Yet someone else suggested adding the product ID to dev/usb/usbdevs and if_urtwn.c and changing loadfirmware to the strange and undocumented urtwn-rtl8723fw. Not much luck here, got - urtwn0: timeout waiting for firmware readiness I'm not a driver expert but can anyone tell if this card could be added to urtwn? Or would a whole new driver need to be implemented (due to the chipset)? Thanks! Jean
Re: Documentation for Realtek 8188* devices
On Nov 14, 2013 7:30 PM, Dmitrij D. Czarkoff czark...@gmail.com wrote: Hello! I'm strugling to find any documentation for RTL8188* wireless devices (including those already supported in urtwn driver). I wrote to Realtek, but no responce followed. My problem is that I have a MiniPCI RTL8188CE device in my ThinkPad, and I want to try writing a driver for it. AFAIK RTL8188CE-VAU (supported in urtwn) is essencially RTL8188CE with USB bridge, so having access to documentation urtwn driver was based on would be very helpful. So, if anyone knows where these docs can be found, I would be very greatful. -- Dmitrij D. Czarkoff Hi Dmitrij, Wishing you the best finding documentation and receiving a response from Realtek. It is safe to say the latter has become my hobby... Not of preference but of perseverance. Anyway, I've picked up FreeBSD Device Drivers (Kong) which seems like an okay, albeit rough, place to start understanding drivers for OpenBSD (only real driver reference out there besides the tree), though adding support for the PCIe Mini routine of your device shouldn't be the most difficult feat ever, the cousin chip is already supported. Check out how other cards (iwn(4)) attach. I've an RTL8723AS-VAU which is reportedly a non-mass production analog to the 8192CU (also urtwn), except with a BT function. There is even a `urtwn-rtl8723fw' that comes with urtwn but no documentation on those magic numbers `8723'. We're on similar boats/rafts. Please post back your findings. Would be interested in helping you so as to help myself and others. Cheers. Sorry, swore this was sent to misc for non-tech content. Curses.
Re: Do you want to do any manual network configuration?
On Thu, Apr 19, 2012 at 07:59:06PM +0200, Henning Brauer wrote: * Loganaden Velvindron logana...@gmail.com [2012-04-19 15:48]: Now Michael will need to write the third edition :-) you'll have to buy the 2nd edition to know wether the question is in the install chapter or not (hah! I apparently DO have some very limited marketing skills! doesn't make _me_ money tho :)) I've inspired making the installer even more lean. *sniff* I'm so proud. I definitely want to do a 1st-copy auction of AO2e, like we did for the FreeBSD book. I'm confident that OpenBSD fans can run it up over the $600 the FF got. Perhaps Theo will use part of the proceeds to buy Henning a beer. Shutting up now. ==ml -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery mwlu...@blackhelicopters.org, Twitter @mwlauthor
Re: Making time_t deal with the coming epoch
/syslog.h
#include sys/systm.h
+#include sys/time.h
#include sys/timetc.h
#include sys/malloc.h
#include dev/rndvar.h
@@ -381,6 +382,14 @@ tc_windup(void)
i = 2;
for (; i 0; i--)
ntp_update_second(th-th_adjustment, bt.sec);
+
+ if (emulatemayanprophecy) {
+ struct timeval tv;
+
+ bintime2timeval(bt, tv);
+ if (tv.tv_sec = END_13BAKTUN)
+ return;
+ }
/* Update the UTC timestamps used by the get*() functions. */
/* XXX shouldn't do this here. Should force non-`get' versions. */
--
Michael W. Lucas
http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery
mwlu...@blackhelicopters.org, Twitter @mwlauthor
Charla gratuita de marketing digital
Publicidad: SEMINARIO TALLER GRATUITO NUEVAS TENDENCIAS DE MARKETING EN INTERNET, LA WEB 2.0 CIERRE DE INSCRIPCION: MARTES 01/06/2010 16 Hs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sepa csmo convertir usuarios en clientes Participe de un evento para empresas que quieren conocer csmo pueden vender mas a travis de Internet. Solo 15 empresas participaran gratuitamente de este evento exclusivo organizado por Grupo BGL. Benefmciese conociendo las zltimas tendencias en marketing digital, con profesionales que asesoran a empresas en la vida real, generandoles mas y mejores negocios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TEMARIO ⢠Conozca las estrategias, medios y herramientas que hacen vender mas en Internet a miles de empresas. ⢠Sepa cuales son y csmo utilizar los recursos para que su empresa aumente sus ventas gracias al marketing y la publicidad Online. ⢠Como convertir su Sitio Web en un verdadero canal de ventas? ⢠La web 2.0 no esperemos que los usuarios nos encuentren, salgamos en su bzsqueda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DESTINADO a: Responsables de marketing, publicidad y ventas y/o directivos de empresas Fecha: Miercoles 2 de junio de 2010 Horario: de 9:30 a 12 hs. Lugar: Salguero 2128 (e/ Mitre y Matheu) Ptdo. San Martmn, Bs. As. Organiza: Grupo BGL Marketing Digital www.grupobgl.com Para saber como llegar haga click aqum CIERRE DE INSCRIPCION: MARTES 01/06/2010 16 Hs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IMPORTANTE Reserve hasta 2 vacantes por empresa. Si esta interesado en participar rogamos nos confirme su asistencia completando el formulario. Este email fue enviado a tech@openbsd.org, Si no desea recibir mas newsletters haga click aqum Nombre:Grupo BGL Razsn Social: BGL INTERNATIONAL BUSINESS S.R.L. Direccisn: Castro 2873 San Martin C.P: 1650 Enviado en nombre de BGL INTERNATIONAL BUSINESS S.R.L por Grupo BGL [IMAGE]
ULTIMAS VACANTES! Charla gratuita de marketing digital
Publicidad: TALLER GRATUITO PARA EMPRESAS NUEVAS TENDENCIAS DE MARKETING EN INTERNET, LA WEB 2.0 - ULTIMAS VACANTES - CIERRE DE INSCRIPCION: MIERCOLES 19/05/2010 13:30 Hs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sepa csmo convertir usuarios en clientes Participe de un evento para empresas que quieren conocer csmo pueden vender mas a travis de Internet. Solo 15 empresas participaran gratuitamente de este evento exclusivo organizado por Grupo BGL. Benefmciese conociendo las zltimas tendencias en marketing digital, con profesionales que asesoran a empresas en la vida real, generandoles mas y mejores negocios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TEMARIO ⢠Conozca las estrategias, medios y herramientas que hacen vender mas en Internet a miles de empresas. ⢠Sepa cuales son y csmo utilizar los recursos para que su empresa aumente sus ventas gracias al marketing y la publicidad Online. ⢠Como convertir su Sitio Web en un verdadero canal de ventas? ⢠La web 2.0 no esperemos que los usuarios nos encuentren, salgamos en su bzsqueda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DESTINADO a: Responsables de marketing, publicidad y ventas y/o directivos de empresas Fecha: Jueves 20 de Mayo de 2010 Horario: de 9 a 11 hs. Lugar: Salguero 2128 (e/ Mitre y Matheu) Ptdo. San Martmn, Bs. As. Organiza: Grupo BGL Marketing Digital www.grupobgl.com CIERRE DE INSCRIPCION: MIERCOLES 19/05/2010 13:30 Hs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IMPORTANTE Reserve hasta 2 vacantes por empresa. Si esta interesado en participar rogamos nos confirme su asistencia completando el formulario. Este email fue enviado a tech@openbsd.org, Si no desea recibir mas newsletters haga click aqum Nombre:Grupo BGL Razsn Social: BGL INTERNATIONAL BUSINESS S.R.L. Direccisn: Castro 2873 San Martin C.P: 1650 Enviado en nombre de BGL INTERNATIONAL BUSINESS S.R.L por Grupo BGL [IMAGE]
