Re: Question about man 2 fcntl

2019-09-05 Thread Theo de Raadt
This looks like a mis-merge in revision 1.30 of fcntl.2

The chunk was added in the wrong place, and I can see why.  A sentence
component was accidentally deleted.  Your diff looked funny, so I redid
it and came to the same conclusion.

ok deraadt


Masato Asou  wrote:

> The following statement is a part of man 2 fctl.
> 
>  [EINTR]The argument cmd is invalid.
> 
> The argument cmd is F_SETLKW, and the function
> was
> interrupted by a signal.
> 
> Will EINVAL be returned in the case of 'The argument cmd is invalid'?
> 
> Will EINTR be returned for F_SETLK?
> The following code is sys/kern/kern_descrip.c sys_fcntl():
> 
> case F_SETLKW:
> flg |= F_WAIT;
> /* FALLTHROUGH */
> 
> case F_SETLK:
> 
> How about it?
> 
> Index: fcntl.2
> ===
> RCS file: /cvs/src/lib/libc/sys/fcntl.2,v
> retrieving revision 1.32
> diff -u -p -r1.32 fcntl.2
> --- fcntl.2   10 Nov 2018 11:54:03 -  1.32
> +++ fcntl.2   4 Sep 2019 07:15:33 -
> @@ -465,14 +465,14 @@ and a deadlock condition was detected.
>  .It Bq Er EINTR
>  The argument
>  .Fa cmd
> -is invalid.
> -.Pp
> -The argument
> -.Fa cmd
>  is
> -.Dv F_SETLKW ,
> +.Dv F_SETLK or F_SETLKW ,
>  and the function was interrupted by a signal.
>  .It Bq Er EINVAL
> +The argument
> +.Fa cmd
> +is invalid.
> +.Pp
>  .Fa cmd
>  is
>  .Dv F_DUPFD
> --
> ASOU Masato
> 



rcctl issues when running in non-default rdomain

2019-09-05 Thread Matthieu Herrb
Hi,

on my redundant firealls I have an " admin" interface in rdomain 1
with a sshd listening, used to be able to access the slave machine and
let it access the internet to be able to run syspatch or pkg_add.

This works well, but but if I use rcctl in this non default rdomain to
control services normally running in the default rdomain, things don't
behave too well. In particular, 'rcctl start' or 'restart' starts the
service with rtable 1.

Alternatives would be to run the admin interface in the default rdomain
and all other interfaces in a separate one, but it feels more painful
to setup.

It seems to me that the patch below helps, but may be it has other
unforseen and unwanted effects ?

Thoughts ?

Index: rc.subr
===
RCS file: /cvs/OpenBSD/src/etc/rc.d/rc.subr,v
retrieving revision 1.131
diff -u -r1.131 rc.subr
--- rc.subr 21 Mar 2019 15:10:27 -  1.131
+++ rc.subr 5 Sep 2019 20:56:38 -
@@ -320,5 +320,4 @@
 # make sure pexp matches the process (i.e. doesn't include the quotes)
 pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
 rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
-[ "${daemon_rtable}" -eq "$(id -R)" ] ||
-   rcexec="route -T ${daemon_rtable} exec ${rcexec}"
+rcexec="route -T ${daemon_rtable} exec ${rcexec}"


-- 
Matthieu Herrb



Re: [PATCH] Extend OAEP support

2019-09-05 Thread Kinichiro Inoguchi
I thought this patch could give an ability to handle OAEP label with
openssl(1) pkeyutl command, and encryption works fine, but decryption fails.
--
openssl genrsa -out rsakey.pem

echo "abcd" | openssl pkeyutl -encrypt -inkey rsakey.pem \
-pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_label:0011223344556677 \
-out rsaoaep.enc

openssl pkeyutl -decrypt -inkey rsakey.pem
-pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_label:0011223344556677 \
-in rsaoaep.enc
--

Last command fails with this message.
--
Public Key operation error
2798804220048:error:04FFF079:rsa routines:CRYPTO_internal:oaep decoding 
error:rsa/rsa_oaep.c:215:
--

These commands had succeeded with OpenSSL 1.0.2.
RSA_padding_check_PKCS1_OAEP_mgf1() appears to cause this.


On Wed, Sep 04, 2019 at 06:41:21AM +0300, Stefan Strogin wrote:
> Provide methods: EVP_PKEY_CTX_{g,s}et_rsa_oaep_md,
> EVP_PKEY_CTX_{g,s}et0_rsa_oaep_label.
> 
> Based on Stephen Henson's patches for OpenSSL 1.1.0:
> https://github.com/openssl/openssl/commit/271fef0ef39a1c0cb5233a5adf3ff8733abb375e
> https://github.com/openssl/openssl/commit/211a14f6279f127f7a5a59948819bd939131b0b6



Re: rad(8) and carp interfaces

2019-09-05 Thread Klemens Nanni
On Thu, Sep 05, 2019 at 10:32:25AM +0200, Sebastian Benoit wrote:
> Unrelated, but noticed by florian, this bit in the manpage is no longer
> needed since he removed soii for link-local adresses in
> sys/netinet6/in6_ifattach.c rev 1.114
Good catch, OK kn.



Re: rad(8) and carp interfaces

2019-09-05 Thread Sebastian Benoit
Matthieu Herrb(matth...@openbsd.org) on 2019.09.04 18:07:35 +0200:
> Hi,
> 
> I've a pair of redundant routers, which need to run rad(8) on the
> internal interfaces.
> 
> But using carp, on the inactive router, rad complains every
> time it tries to send a RA:
> 
>  rad[65590]: sendmsg on carp2: Can't assign requested address
> 
> Which I can understand since it currently doesnt "own" the shared IPv6
> address of the carp interface.

correct. rad(8) needs to look at the interface state to not try sending on
a (carp) interface that is in backup state, or just not print this warning
at all. It is possible to monitor the link state since the frontend process
already has a route socket and could certainly track the link state, buts
its a little bit of work.
 
> Is there a way to configure rad to avoid these errors?

At the moment none other than patching out the log_warn().

> How do other people handle the situation?
> 
> Thanks in advance,
> -- 
> Matthieu Herrb
> 

Unrelated, but noticed by florian, this bit in the manpage is no longer
needed since he removed soii for link-local adresses in
sys/netinet6/in6_ifattach.c rev 1.114

ok?

diff b31eb29f59f3580445ea0341b271e321d53958a6 /opt/git/benoit/src
blob - d93e64d4648dfe25a5c76faac3994780d1ce02f8
file + usr.sbin/rad/rad.8
--- usr.sbin/rad/rad.8
+++ usr.sbin/rad/rad.8
@@ -146,15 +146,3 @@ The
 .Nm
 program was written by
 .An Florian Obser Aq Mt flor...@openbsd.org .
-.Sh CAVEATS
-When running
-.Nm
-on a
-.Xr carp 4
-interface, it is recommended to either disable SOIIs (persistent Semantically
-Opaque Interface Identifiers) on the interface with
-.Xr ifconfig 8 ,
-or ensure that all CARP peers have the same SOII key stored in
-.Pa /etc/soii.key .
-Otherwise the default IPv6 router's link-local address will change during CARP
-failover, which temporarily disrupts connectivity of IPv6 autoconf clients.