Recent 'ftplist' changes visible in the installer
So, as some of you know the installer hits ftp.openbsd.org during the install process to query a CGI to provide you with a list of nearby mirrors and some other useful things. I've recently made some changes to modernize and improve this after the retirement of the GEO:IP modules and increasing fun with using maxmind without hitting an API server. While it's true that if you install from a mirror or hit the cgi, we know where you came from, I'm not super comfortable handing that information to a third party for no good reason. Fortunately with the help of fcambus@, I managed to switch over to the free dbip databases, which can be installed from ports and kept local to the machine. With the help of afresh1@ we managed to get self contained timezone information as well, based on some earlier work by andy hook. Which is long way to say, there should be improvements in what mirrors you are offered in the installer, especially if you are in some of the more isolated places lacking an openbsd mirror in your country. If you can try it out, and you see anything problematic, please let me know. Thanks -Bob
Re: sdmmc: CIS tuple can have empty body
On Tue, Apr 28, 2020 at 11:16:43PM +0200, Patrick Wildt wrote:
> Hi,
>
> on my i.MX8MM EVK there's a ath10k-based WiFi chip which we
> unfortunately do not support (yet?). But the SD/MMC CIS parser
> complains:
>
> sdmmc0: CIS parse error at 4136, tuple code 0x14, length 0
> manufacturer 0x0271, product 0x0701 at sdmmc0 function 1 not configured
>
> It's not a transmission bug though, since I saw prints from a Linux
> dmesg on the web[0] stating something similar:
>
> <4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
> <4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
> <4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
> <4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
>
> I guess the ath10k-Chips use some vendor-specific tuples in the CIS
> structure. The thing that our CIS parser complains about is the tuple
> without a length.
>
> Section 16 of the SDIO Simplified Specification 3.0[1] describes the CIS
> formats, with Section 16.2 describing the Basic Tuple Format. What our
> code calls "tpllen", the tuple body length, is called "link field" in
> the specification.
>
> The specification explicitly says, that a empty tuple body is fine, by
> saying: "If the link field is 0, then the tuple body is empty."
>
> Thus I propose that instead of complaining about that tuple, we just
> continue our job. I guess sometimes the existance of a code is infor-
> mation enough.
>
> ok?
>
> Patrick
>
> [0]
> https://linuxlists.cc/l/9/linux-wireless/t/3226749/ath10k-sdio:_failed_to_load_firmware
> [1]
> https://www.sdcard.org/downloads/pls/pdf/index.php?p=PartE1_SDIO_Simplified_Specification_Ver3.00.jpg=PartE1_SDIO_Simplified_Specification_Ver3.00.pdf=EN_SSE1
Actually it would be even better to just remove the check, since
then we would fall into the default case which, given SDMMC_DEBUG
is on, also lets us know of the unknown tuple:
sdmmc0: unknown tuple code 0x1, length 3
sdmmc0: unknown tuple code 0x22, length 4
sdmmc0: unknown tuple code 0x1a, length 5
sdmmc0: unknown tuple code 0x1b, length 8
sdmmc0: unknown tuple code 0x14, length 0
sdmmc0: unknown tuple code 0x22, length 42
sdmmc0: unknown tuple code 0x80, length 1
sdmmc0: unknown tuple code 0x81, length 1
sdmmc0: unknown tuple code 0x82, length 1
The individual switch-cases are checking tpllen properly, so there
is no harm.
ok?
Patrick
diff --git a/sys/dev/sdmmc/sdmmc_cis.c b/sys/dev/sdmmc/sdmmc_cis.c
index 21cf530b24f..70e5b6283a7 100644
--- a/sys/dev/sdmmc/sdmmc_cis.c
+++ b/sys/dev/sdmmc/sdmmc_cis.c
@@ -76,12 +76,6 @@ sdmmc_read_cis(struct sdmmc_function *sf, struct sdmmc_cis
*cis)
continue;
tpllen = sdmmc_io_read_1(sf0, reg++);
- if (tpllen == 0) {
- printf("%s: CIS parse error at %d, "
- "tuple code %#x, length %d\n",
- DEVNAME(sf->sc), reg, tplcode, tpllen);
- break;
- }
switch (tplcode) {
case SD_IO_CISTPL_FUNCID:
sdmmc: CIS tuple can have empty body
Hi,
on my i.MX8MM EVK there's a ath10k-based WiFi chip which we
unfortunately do not support (yet?). But the SD/MMC CIS parser
complains:
sdmmc0: CIS parse error at 4136, tuple code 0x14, length 0
manufacturer 0x0271, product 0x0701 at sdmmc0 function 1 not configured
It's not a transmission bug though, since I saw prints from a Linux
dmesg on the web[0] stating something similar:
<4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
<4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
<4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
<4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
I guess the ath10k-Chips use some vendor-specific tuples in the CIS
structure. The thing that our CIS parser complains about is the tuple
without a length.
Section 16 of the SDIO Simplified Specification 3.0[1] describes the CIS
formats, with Section 16.2 describing the Basic Tuple Format. What our
code calls "tpllen", the tuple body length, is called "link field" in
the specification.
The specification explicitly says, that a empty tuple body is fine, by
saying: "If the link field is 0, then the tuple body is empty."
Thus I propose that instead of complaining about that tuple, we just
continue our job. I guess sometimes the existance of a code is infor-
mation enough.
ok?
Patrick
[0]
https://linuxlists.cc/l/9/linux-wireless/t/3226749/ath10k-sdio:_failed_to_load_firmware
[1]
https://www.sdcard.org/downloads/pls/pdf/index.php?p=PartE1_SDIO_Simplified_Specification_Ver3.00.jpg=PartE1_SDIO_Simplified_Specification_Ver3.00.pdf=EN_SSE1
diff --git a/sys/dev/sdmmc/sdmmc_cis.c b/sys/dev/sdmmc/sdmmc_cis.c
index 21cf530b24f..09f3a70af40 100644
--- a/sys/dev/sdmmc/sdmmc_cis.c
+++ b/sys/dev/sdmmc/sdmmc_cis.c
@@ -76,12 +76,8 @@ sdmmc_read_cis(struct sdmmc_function *sf, struct sdmmc_cis
*cis)
continue;
tpllen = sdmmc_io_read_1(sf0, reg++);
- if (tpllen == 0) {
- printf("%s: CIS parse error at %d, "
- "tuple code %#x, length %d\n",
- DEVNAME(sf->sc), reg, tplcode, tpllen);
- break;
- }
+ if (tpllen == 0)
+ continue;
switch (tplcode) {
case SD_IO_CISTPL_FUNCID:
Re: iked(8): remove insecure EC2N curves
...after some more research:
ec2n never actually made it into the IKEv2 RFC, it was present in drafts
up to 15, but removed in
https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-ipsec-ikev2-16.txt
the relevant entry from https://datatracker.ietf.org/doc/rfc4306/history/ is
: 2004-09-02 17 Russ Housley[Ballot discuss]
:
: In 2002, the working group decided not to pursue elliptic curves.
: Hilarie Orman made several presentation advocating them; her slides
: are in the minutes. However, the IPR concerns associate with
: elliptic curves lead the working group to classic Diffie-Hellman.
: Yet, two elliptic curve groups are still included in the document.
: This seems to contradict the working group decision. I suggest the
: removal of the elliptic curve groups from Appendix B.
A quick search doesn't find any implementations supporting ec2n other
than iked and CLJ^H^H^H routeros. OK I have changed my mind and agree
with you Tobias, I am happy to kill it now.
On 2020/04/28 08:59, Theo de Raadt wrote:
> If so, immediately. That means for about 2 weeks someone in snaps
> can scream.
>
> Tobias Heider wrote:
>
> > On Tue, Apr 28, 2020 at 11:22:02AM +0100, Stuart Henderson wrote:
> > > On 2020/04/28 01:09, Tobias Heider wrote:
> > > > Hi,
> > > >
> > > > the EC2N family of curves have been marked as insecure for at least 10
> > > > years.
> > > > In fact, IANA has stopped listing them altogether [1].
> > > > Their former IDs are now 'reserved'.
> > > >
> > > > I think it's time for us to drop them as well.
> > > >
> > > > ok?
> > >
> > > I agree with dropping them. Timing-wise perhaps it's better to do it
> > > after release (possible text for upgrade notes below); OTOH probably
> > > nobody really uses ec2n so it's not all that likely to hurt users (we
> > > can use similar text but say "prior to upgrade, add alternative groups
> > > [...]" instead).
> > >
> > > "The insecure ec2n D-H groups will be removed from iked in the next
> > > release; if you are using these, add alternative groups to ikesa/childsa
> > > in iked.conf, then you can move clients across one by one and remove
> > > the ec2n groups in advance of 6.8.
> > >
> > > While removal of other groups is not imminent, some are considered
> > > insecure (768-bit MODP, group 1) or weak (1024- and 1536-bit MODP,
> > > groups 2 and 5). Prefer curve25519, an ECP group of 256 bits or
> > > more, or a MODP group of 2048 bits or more."
> >
> > I would really rather do it now. It has been marked as insecure for long
> > enough and really no one should be using it.
> > IMHO shipping them for another six months would be rather irresponsible
> > from our side.
> >
> > The upgrade note sound good.
> >
> > >
> > > > Index: iked.conf.5
> > > > ===
> > > > RCS file: /cvs/src/sbin/iked/iked.conf.5,v
> > > > retrieving revision 1.66
> > > > diff -u -p -r1.66 iked.conf.5
> > > > --- iked.conf.5 27 Apr 2020 22:40:09 - 1.66
> > > > +++ iked.conf.5 27 Apr 2020 22:58:24 -
> > > > @@ -909,8 +909,6 @@ keyword:
> > > > .It Em Name Ta Em Group Ta Em Size Ta Em Type
> > > > .It Li modp768 Ta grp1 Ta 768 Ta "MODP"
> > > > .It Li modp1024 Ta grp2 Ta 1024 Ta "MODP"
> > >
> > >.It Li modp768 Ta grp1 Ta 768 Ta "MODP" [insecure]
> > >.It Li modp1024 Ta grp2 Ta 1024 Ta "MODP" [weak]
> > >
> > > > -.It Li ec2n155 Ta grp3 Ta 155 Ta "EC2N [insecure]"
> > > > -.It Li ec2n185 Ta grp4 Ta 185 Ta "EC2N [insecure]"
> > > > .It Li modp1536 Ta grp5 Ta 1536 Ta "MODP"
> > >
> > >.It Li modp1536 Ta grp5 Ta 1536 Ta "MODP" [weak]
> > >
> > > I guess we should sprinkle some other weak/insecure in the manual
> > > too but this is a start.
> >
> > Good idea, your classification makes sense. We should do the same for
> > all algorithms.
> >
> > >
> > > > .It Li modp2048 Ta grp14 Ta 2048 Ta "MODP"
> > > > .It Li modp3072 Ta grp15 Ta 3072 Ta "MODP"
> > > > @@ -931,11 +929,8 @@ keyword:
> > > > .Pp
> > > > The currently supported group types are either
> > > > MODP (exponentiation groups modulo a prime),
> > > > -EC2N (elliptic curve groups over GF[2^N]),
> > > > ECP (elliptic curve groups modulo a prime),
> > > > or Curve25519.
> > > > -Please note that the EC2N groups are considered as insecure and only
> > > > -provided for backwards compatibility.
> > >
> > >Please note that MODP groups of less than 2048 bits are considered
> > >as weak or insecure (see RFC 8247 section 2.4) and only provided for
> > >backwards compatibility.
> > >
> > > > --- dh.h27 Oct 2017 14:26:35 - 1.11
> > > > +++ dh.h27 Apr 2020 22:58:24 -
> > > > @@ -21,7 +21,6 @@
> > > >
> > > > enum group_type {
> > > > GROUP_MODP = 0,
> > > > - GROUP_EC2N = 1,
> > > > GROUP_ECP = 2,
> > > > GROUP_CURVE25519= 3
> > > > };
> > >
> > > Should the others be
Re: iked(8): remove insecure EC2N curves
If so, immediately. That means for about 2 weeks someone in snaps
can scream.
Tobias Heider wrote:
> On Tue, Apr 28, 2020 at 11:22:02AM +0100, Stuart Henderson wrote:
> > On 2020/04/28 01:09, Tobias Heider wrote:
> > > Hi,
> > >
> > > the EC2N family of curves have been marked as insecure for at least 10
> > > years.
> > > In fact, IANA has stopped listing them altogether [1].
> > > Their former IDs are now 'reserved'.
> > >
> > > I think it's time for us to drop them as well.
> > >
> > > ok?
> >
> > I agree with dropping them. Timing-wise perhaps it's better to do it
> > after release (possible text for upgrade notes below); OTOH probably
> > nobody really uses ec2n so it's not all that likely to hurt users (we
> > can use similar text but say "prior to upgrade, add alternative groups
> > [...]" instead).
> >
> > "The insecure ec2n D-H groups will be removed from iked in the next
> > release; if you are using these, add alternative groups to ikesa/childsa
> > in iked.conf, then you can move clients across one by one and remove
> > the ec2n groups in advance of 6.8.
> >
> > While removal of other groups is not imminent, some are considered
> > insecure (768-bit MODP, group 1) or weak (1024- and 1536-bit MODP,
> > groups 2 and 5). Prefer curve25519, an ECP group of 256 bits or
> > more, or a MODP group of 2048 bits or more."
>
> I would really rather do it now. It has been marked as insecure for long
> enough and really no one should be using it.
> IMHO shipping them for another six months would be rather irresponsible
> from our side.
>
> The upgrade note sound good.
>
> >
> > > Index: iked.conf.5
> > > ===
> > > RCS file: /cvs/src/sbin/iked/iked.conf.5,v
> > > retrieving revision 1.66
> > > diff -u -p -r1.66 iked.conf.5
> > > --- iked.conf.5 27 Apr 2020 22:40:09 - 1.66
> > > +++ iked.conf.5 27 Apr 2020 22:58:24 -
> > > @@ -909,8 +909,6 @@ keyword:
> > > .It Em Name Ta Em Group Ta Em Size Ta Em Type
> > > .It Li modp768 Ta grp1 Ta 768 Ta "MODP"
> > > .It Li modp1024 Ta grp2 Ta 1024 Ta "MODP"
> >
> >.It Li modp768 Ta grp1 Ta 768 Ta "MODP" [insecure]
> >.It Li modp1024 Ta grp2 Ta 1024 Ta "MODP" [weak]
> >
> > > -.It Li ec2n155 Ta grp3 Ta 155 Ta "EC2N [insecure]"
> > > -.It Li ec2n185 Ta grp4 Ta 185 Ta "EC2N [insecure]"
> > > .It Li modp1536 Ta grp5 Ta 1536 Ta "MODP"
> >
> >.It Li modp1536 Ta grp5 Ta 1536 Ta "MODP" [weak]
> >
> > I guess we should sprinkle some other weak/insecure in the manual
> > too but this is a start.
>
> Good idea, your classification makes sense. We should do the same for
> all algorithms.
>
> >
> > > .It Li modp2048 Ta grp14 Ta 2048 Ta "MODP"
> > > .It Li modp3072 Ta grp15 Ta 3072 Ta "MODP"
> > > @@ -931,11 +929,8 @@ keyword:
> > > .Pp
> > > The currently supported group types are either
> > > MODP (exponentiation groups modulo a prime),
> > > -EC2N (elliptic curve groups over GF[2^N]),
> > > ECP (elliptic curve groups modulo a prime),
> > > or Curve25519.
> > > -Please note that the EC2N groups are considered as insecure and only
> > > -provided for backwards compatibility.
> >
> >Please note that MODP groups of less than 2048 bits are considered
> >as weak or insecure (see RFC 8247 section 2.4) and only provided for
> >backwards compatibility.
> >
> > > --- dh.h 27 Oct 2017 14:26:35 - 1.11
> > > +++ dh.h 27 Apr 2020 22:58:24 -
> > > @@ -21,7 +21,6 @@
> > >
> > > enum group_type {
> > > GROUP_MODP = 0,
> > > - GROUP_EC2N = 1,
> > > GROUP_ECP = 2,
> > > GROUP_CURVE25519= 3
> > > };
> >
> > Should the others be renumbered so that somebody looking later doesn't
> > have to figure out why there's a gap?
> >
>
> Fixed.
>
> Here's an updated diff:
>
> Index: dh.c
> ===
> RCS file: /cvs/src/sbin/iked/dh.c,v
> retrieving revision 1.22
> diff -u -p -r1.22 dh.c
> --- dh.c 2 Apr 2019 09:42:55 - 1.22
> +++ dh.c 28 Apr 2020 14:50:58 -
> @@ -35,7 +35,7 @@ int modp_getlen(struct group *);
> int modp_create_exchange(struct group *, uint8_t *);
> int modp_create_shared(struct group *, uint8_t *, uint8_t *);
>
> -/* EC2N/ECP */
> +/* ECP */
> int ec_init(struct group *);
> int ec_getlen(struct group *);
> int ec_secretlen(struct group *);
> @@ -83,8 +83,6 @@ const struct group_id ike_groups[] = {
> "",
> "02"
> },
> - { GROUP_EC2N, 3, 155, NULL, NULL, NID_ipsec3 },
> - { GROUP_EC2N, 4, 185, NULL, NULL, NID_ipsec4 },
> { GROUP_MODP, 5, 1536,
> "C90FDAA22168C234C4C6628B80DC1CD1"
> "29024E088A67CC74020BBEA63B139B22514A08798E3404DD"
> @@ -290,7 +288,6 @@ group_get(uint32_t id)
> group->exchange = modp_create_exchange;
> group->shared = modp_create_shared;
>
Re: smtpd: fix catch-all in virtual aliases
April 28, 2020 11:02 AM, "Joerg Jung" mailto:m...@umaxx.net?to=%22Joerg%20Jung%22%20)> wrote: On 28. Apr 2020, at 10:10, gil...@poolp.org (mailto:gil...@poolp.org) wrote: April 28, 2020 8:55 AM, "Joerg Jung" mailto:m...@umaxx.net)> wrote: Also this change might break existing valid setups (e.g. with mailing list servers), but people will likely know how to cope with it. Do you have an example of an existing valid setup that is broken with this ? No example, I just presumed (that’s why I wrote “might”). ok, because I can't think of a setup that could be broken with this as @ is the very last wildcard matching everything not matched earlier. this diff fixes an actual reported bug and passed various tests mixing no wildcard, user wildcard, domain wildcard. I think it should go in as it is a regression that probably got introduced a while back, the @ wildcard used to work for sure.
Re: iked(8): remove insecure EC2N curves
On Tue, Apr 28, 2020 at 11:22:02AM +0100, Stuart Henderson wrote:
> On 2020/04/28 01:09, Tobias Heider wrote:
> > Hi,
> >
> > the EC2N family of curves have been marked as insecure for at least 10
> > years.
> > In fact, IANA has stopped listing them altogether [1].
> > Their former IDs are now 'reserved'.
> >
> > I think it's time for us to drop them as well.
> >
> > ok?
>
> I agree with dropping them. Timing-wise perhaps it's better to do it
> after release (possible text for upgrade notes below); OTOH probably
> nobody really uses ec2n so it's not all that likely to hurt users (we
> can use similar text but say "prior to upgrade, add alternative groups
> [...]" instead).
>
> "The insecure ec2n D-H groups will be removed from iked in the next
> release; if you are using these, add alternative groups to ikesa/childsa
> in iked.conf, then you can move clients across one by one and remove
> the ec2n groups in advance of 6.8.
>
> While removal of other groups is not imminent, some are considered
> insecure (768-bit MODP, group 1) or weak (1024- and 1536-bit MODP,
> groups 2 and 5). Prefer curve25519, an ECP group of 256 bits or
> more, or a MODP group of 2048 bits or more."
I would really rather do it now. It has been marked as insecure for long
enough and really no one should be using it.
IMHO shipping them for another six months would be rather irresponsible
from our side.
The upgrade note sound good.
>
> > Index: iked.conf.5
> > ===
> > RCS file: /cvs/src/sbin/iked/iked.conf.5,v
> > retrieving revision 1.66
> > diff -u -p -r1.66 iked.conf.5
> > --- iked.conf.5 27 Apr 2020 22:40:09 - 1.66
> > +++ iked.conf.5 27 Apr 2020 22:58:24 -
> > @@ -909,8 +909,6 @@ keyword:
> > .It Em Name Ta Em Group Ta Em Size Ta Em Type
> > .It Li modp768 Ta grp1 Ta 768 Ta "MODP"
> > .It Li modp1024 Ta grp2 Ta 1024 Ta "MODP"
>
>.It Li modp768 Ta grp1 Ta 768 Ta "MODP" [insecure]
>.It Li modp1024 Ta grp2 Ta 1024 Ta "MODP" [weak]
>
> > -.It Li ec2n155 Ta grp3 Ta 155 Ta "EC2N [insecure]"
> > -.It Li ec2n185 Ta grp4 Ta 185 Ta "EC2N [insecure]"
> > .It Li modp1536 Ta grp5 Ta 1536 Ta "MODP"
>
>.It Li modp1536 Ta grp5 Ta 1536 Ta "MODP" [weak]
>
> I guess we should sprinkle some other weak/insecure in the manual
> too but this is a start.
Good idea, your classification makes sense. We should do the same for
all algorithms.
>
> > .It Li modp2048 Ta grp14 Ta 2048 Ta "MODP"
> > .It Li modp3072 Ta grp15 Ta 3072 Ta "MODP"
> > @@ -931,11 +929,8 @@ keyword:
> > .Pp
> > The currently supported group types are either
> > MODP (exponentiation groups modulo a prime),
> > -EC2N (elliptic curve groups over GF[2^N]),
> > ECP (elliptic curve groups modulo a prime),
> > or Curve25519.
> > -Please note that the EC2N groups are considered as insecure and only
> > -provided for backwards compatibility.
>
>Please note that MODP groups of less than 2048 bits are considered
>as weak or insecure (see RFC 8247 section 2.4) and only provided for
>backwards compatibility.
>
> > --- dh.h27 Oct 2017 14:26:35 - 1.11
> > +++ dh.h27 Apr 2020 22:58:24 -
> > @@ -21,7 +21,6 @@
> >
> > enum group_type {
> > GROUP_MODP = 0,
> > - GROUP_EC2N = 1,
> > GROUP_ECP = 2,
> > GROUP_CURVE25519= 3
> > };
>
> Should the others be renumbered so that somebody looking later doesn't
> have to figure out why there's a gap?
>
Fixed.
Here's an updated diff:
Index: dh.c
===
RCS file: /cvs/src/sbin/iked/dh.c,v
retrieving revision 1.22
diff -u -p -r1.22 dh.c
--- dh.c2 Apr 2019 09:42:55 - 1.22
+++ dh.c28 Apr 2020 14:50:58 -
@@ -35,7 +35,7 @@ int modp_getlen(struct group *);
intmodp_create_exchange(struct group *, uint8_t *);
intmodp_create_shared(struct group *, uint8_t *, uint8_t *);
-/* EC2N/ECP */
+/* ECP */
intec_init(struct group *);
intec_getlen(struct group *);
intec_secretlen(struct group *);
@@ -83,8 +83,6 @@ const struct group_id ike_groups[] = {
"",
"02"
},
- { GROUP_EC2N, 3, 155, NULL, NULL, NID_ipsec3 },
- { GROUP_EC2N, 4, 185, NULL, NULL, NID_ipsec4 },
{ GROUP_MODP, 5, 1536,
"C90FDAA22168C234C4C6628B80DC1CD1"
"29024E088A67CC74020BBEA63B139B22514A08798E3404DD"
@@ -290,7 +288,6 @@ group_get(uint32_t id)
group->exchange = modp_create_exchange;
group->shared = modp_create_shared;
break;
- case GROUP_EC2N:
case GROUP_ECP:
group->init = ec_init;
group->getlen = ec_getlen;
Index: dh.h
===
RCS file: /cvs/src/sbin/iked/dh.h,v
retrieving revision 1.11
diff -u -p
Re: smtpd: fix catch-all in virtual aliases
On Sun, 26 Apr 2020 18:30:25 +0200, Eric Faurot wrote: > When a catch-all entry (@) is used in a virtual alias table, it > eventually (and mistakenly) catches everything that expands to a > username. For example, with: > > f...@example.com user > @catchall > > "f...@example.com" expands to "user" as expected, but then "user" > expands to "catchall" because it is interpreted as "user@" (empty > domain). > > The catch-all fallback mechanism is really meant for full email > addresses in virtual context, and should not happen for usernames. > The following diff fixes it. That makes sense. OK millert@ I see that the catch-all behavior is documented in makemap(8) but not aliases(5). Does it make sense to document it there too? That's the first place I looked (the makemap manual was the 3rd place I looked). - todd
Re: drm(4) kqfilter & EVFILT_READ
On 28/04/20(Tue) 11:56, Mark Kettenis wrote:
> > Date: Tue, 28 Apr 2020 11:40:17 +0200
> > From: Martin Pieuchot
> >
> > On 27/04/20(Mon) 19:34, Martin Pieuchot wrote:
> > > On 28/04/20(Tue) 01:54, Jonathan Gray wrote:
> > > > On Mon, Apr 27, 2020 at 04:52:33PM +0200, Martin Pieuchot wrote:
> > > > > Diff below extends the existing drmkqfilter() to support EVFILT_READ.
> > > > > This makes drm(4)'s kqueue support in pair with poll().
> > > > >
> > > > > The event list queried in the filt_drmread() should be protected by
> > > > > the
> > > > > `event_lock' mutex. This could be done by using the `kdev'
> > > > > backpointer
> > > > > as shown in comment. However this would require some plumbing to make
> > > > > use of `minor'. The side effect of this approach would be to reduce
> > > > > the
> > > > > diff with Linux.
> > > >
> > > > You seem to be confusing kdev and dev in the drm_minor struct.
> > > > at least in linux kdev is 'struct device *' and dev is
> > > > 'struct drm_device *' (which has the event lock).
> > > > I have a tree which uses the drm_minor struct but it is part of a much
> > > > larger diff.
> > >
> > > Thanks for pointing that out! Do you see another way to comply to the
> > > locking then?
> >
> > If not or if we agree that this can be improved later on I'd like to
> > commit the fixed diff below, ok?
>
> Please don't commit anything with C++ style comments.
Sure, updated diff below!
> I'm also not convinced that this is the appropriate way to implement
> kqueue for drm devices. This is Linux-compat stuff and Linux doesn't
> have kqueue.
I'm in the process of unifying the behavior of all the pieces of code
supporting poll, select and kqueue. drm(4) is one of the exceptions,
video(4) is another, there might be more I haven't finished my audit :)
What would be the proper way to implement kqueue support for OpenBSD if
this is not it?
Index: sys/conf.h
===
RCS file: /cvs/src/sys/sys/conf.h,v
retrieving revision 1.150
diff -u -p -r1.150 conf.h
--- sys/conf.h 21 Apr 2020 08:29:27 - 1.150
+++ sys/conf.h 27 Apr 2020 14:43:48 -
@@ -439,7 +439,7 @@ extern struct cdevsw cdevsw[];
(dev_type_stop((*))) enodev, 0, selfalse, \
(dev_type_mmap((*))) enodev }
-/* open, close, read, ioctl, poll, mmap, nokqfilter */
+/* open, close, read, ioctl, poll, mmap, kqfilter */
#define cdev_drm_init(c,n){ \
dev_init(c,n,open), dev_init(c,n,close), dev_init(c, n, read), \
(dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
Index: dev/pci/drm/drm_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_drv.c,v
retrieving revision 1.174
diff -u -p -r1.174 drm_drv.c
--- dev/pci/drm/drm_drv.c 7 Apr 2020 13:27:51 - 1.174
+++ dev/pci/drm/drm_drv.c 28 Apr 2020 10:15:16 -
@@ -484,6 +484,34 @@ filt_drmkms(struct knote *kn, long hint)
return (kn->kn_fflags != 0);
}
+void
+filt_drmreaddetach(struct knote *kn)
+{
+ struct drm_file *file_priv = kn->kn_hook;
+ int s;
+
+ s = spltty();
+ klist_remove(_priv->rsel.si_note, kn);
+ splx(s);
+}
+
+int
+filt_drmread(struct knote *kn, long hint)
+{
+ struct drm_file *file_priv = kn->kn_hook;
+ int val = 0;
+
+#if notyet
+ mtx_enter(_priv->minor->dev->event_lock);
+#endif
+ val = !list_empty(_priv->event_list);
+#if notyet
+ mtx_leave(_priv->minor->dev->event_lock);
+#endif
+
+ return (val);
+}
+
const struct filterops drm_filtops = {
.f_flags= FILTEROP_ISFD,
.f_attach = NULL,
@@ -491,30 +519,51 @@ const struct filterops drm_filtops = {
.f_event= filt_drmkms,
};
+const struct filterops drmread_filtops = {
+ .f_flags= FILTEROP_ISFD,
+ .f_attach = NULL,
+ .f_detach = filt_drmreaddetach,
+ .f_event= filt_drmread,
+};
+
int
drmkqfilter(dev_t kdev, struct knote *kn)
{
struct drm_device *dev = NULL;
- int s;
+ struct drm_file *file_priv = NULL;
+ int s;
dev = drm_get_device_from_kdev(kdev);
if (dev == NULL || dev->dev_private == NULL)
return (ENXIO);
switch (kn->kn_filter) {
+ case EVFILT_READ:
+ mutex_lock(>struct_mutex);
+ file_priv = drm_find_file_by_minor(dev, minor(kdev));
+ mutex_unlock(>struct_mutex);
+ if (file_priv == NULL)
+ return (ENXIO);
+
+ kn->kn_fop = _filtops;
+ kn->kn_hook = file_priv;
+
+ s = spltty();
+ klist_insert(_priv->rsel.si_note, kn);
+ splx(s);
+ break;
case EVFILT_DEVICE:
kn->kn_fop = _filtops;
+ kn->kn_hook = dev;
Re: iked(8): remove insecure EC2N curves
On 2020/04/28 01:09, Tobias Heider wrote:
> Hi,
>
> the EC2N family of curves have been marked as insecure for at least 10 years.
> In fact, IANA has stopped listing them altogether [1].
> Their former IDs are now 'reserved'.
>
> I think it's time for us to drop them as well.
>
> ok?
I agree with dropping them. Timing-wise perhaps it's better to do it
after release (possible text for upgrade notes below); OTOH probably
nobody really uses ec2n so it's not all that likely to hurt users (we
can use similar text but say "prior to upgrade, add alternative groups
[...]" instead).
"The insecure ec2n D-H groups will be removed from iked in the next
release; if you are using these, add alternative groups to ikesa/childsa
in iked.conf, then you can move clients across one by one and remove
the ec2n groups in advance of 6.8.
While removal of other groups is not imminent, some are considered
insecure (768-bit MODP, group 1) or weak (1024- and 1536-bit MODP,
groups 2 and 5). Prefer curve25519, an ECP group of 256 bits or
more, or a MODP group of 2048 bits or more."
> Index: iked.conf.5
> ===
> RCS file: /cvs/src/sbin/iked/iked.conf.5,v
> retrieving revision 1.66
> diff -u -p -r1.66 iked.conf.5
> --- iked.conf.5 27 Apr 2020 22:40:09 - 1.66
> +++ iked.conf.5 27 Apr 2020 22:58:24 -
> @@ -909,8 +909,6 @@ keyword:
> .It Em Name Ta Em Group Ta Em Size Ta Em Type
> .It Li modp768 Ta grp1 Ta 768 Ta "MODP"
> .It Li modp1024 Ta grp2 Ta 1024 Ta "MODP"
.It Li modp768 Ta grp1 Ta 768 Ta "MODP" [insecure]
.It Li modp1024 Ta grp2 Ta 1024 Ta "MODP" [weak]
> -.It Li ec2n155 Ta grp3 Ta 155 Ta "EC2N [insecure]"
> -.It Li ec2n185 Ta grp4 Ta 185 Ta "EC2N [insecure]"
> .It Li modp1536 Ta grp5 Ta 1536 Ta "MODP"
.It Li modp1536 Ta grp5 Ta 1536 Ta "MODP" [weak]
I guess we should sprinkle some other weak/insecure in the manual
too but this is a start.
> .It Li modp2048 Ta grp14 Ta 2048 Ta "MODP"
> .It Li modp3072 Ta grp15 Ta 3072 Ta "MODP"
> @@ -931,11 +929,8 @@ keyword:
> .Pp
> The currently supported group types are either
> MODP (exponentiation groups modulo a prime),
> -EC2N (elliptic curve groups over GF[2^N]),
> ECP (elliptic curve groups modulo a prime),
> or Curve25519.
> -Please note that the EC2N groups are considered as insecure and only
> -provided for backwards compatibility.
Please note that MODP groups of less than 2048 bits are considered
as weak or insecure (see RFC 8247 section 2.4) and only provided for
backwards compatibility.
> --- dh.h 27 Oct 2017 14:26:35 - 1.11
> +++ dh.h 27 Apr 2020 22:58:24 -
> @@ -21,7 +21,6 @@
>
> enum group_type {
> GROUP_MODP = 0,
> - GROUP_EC2N = 1,
> GROUP_ECP = 2,
> GROUP_CURVE25519= 3
> };
Should the others be renumbered so that somebody looking later doesn't
have to figure out why there's a gap?
Re: drm(4) kqfilter & EVFILT_READ
> Date: Tue, 28 Apr 2020 11:40:17 +0200
> From: Martin Pieuchot
>
> On 27/04/20(Mon) 19:34, Martin Pieuchot wrote:
> > On 28/04/20(Tue) 01:54, Jonathan Gray wrote:
> > > On Mon, Apr 27, 2020 at 04:52:33PM +0200, Martin Pieuchot wrote:
> > > > Diff below extends the existing drmkqfilter() to support EVFILT_READ.
> > > > This makes drm(4)'s kqueue support in pair with poll().
> > > >
> > > > The event list queried in the filt_drmread() should be protected by the
> > > > `event_lock' mutex. This could be done by using the `kdev' backpointer
> > > > as shown in comment. However this would require some plumbing to make
> > > > use of `minor'. The side effect of this approach would be to reduce the
> > > > diff with Linux.
> > >
> > > You seem to be confusing kdev and dev in the drm_minor struct.
> > > at least in linux kdev is 'struct device *' and dev is
> > > 'struct drm_device *' (which has the event lock).
> > > I have a tree which uses the drm_minor struct but it is part of a much
> > > larger diff.
> >
> > Thanks for pointing that out! Do you see another way to comply to the
> > locking then?
>
> If not or if we agree that this can be improved later on I'd like to
> commit the fixed diff below, ok?
Please don't commit anything with C++ style comments.
I'm also not convinced that this is the appropriate way to implement
kqueue for drm devices. This is Linux-compat stuff and Linux doesn't
have kqueue.
> Index: sys/conf.h
> ===
> RCS file: /cvs/src/sys/sys/conf.h,v
> retrieving revision 1.150
> diff -u -p -r1.150 conf.h
> --- sys/conf.h21 Apr 2020 08:29:27 - 1.150
> +++ sys/conf.h27 Apr 2020 14:43:48 -
> @@ -439,7 +439,7 @@ extern struct cdevsw cdevsw[];
> (dev_type_stop((*))) enodev, 0, selfalse, \
> (dev_type_mmap((*))) enodev }
>
> -/* open, close, read, ioctl, poll, mmap, nokqfilter */
> +/* open, close, read, ioctl, poll, mmap, kqfilter */
> #define cdev_drm_init(c,n){ \
> dev_init(c,n,open), dev_init(c,n,close), dev_init(c, n, read), \
> (dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
> Index: dev/pci/drm/drm_drv.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_drv.c,v
> retrieving revision 1.174
> diff -u -p -r1.174 drm_drv.c
> --- dev/pci/drm/drm_drv.c 7 Apr 2020 13:27:51 - 1.174
> +++ dev/pci/drm/drm_drv.c 28 Apr 2020 09:37:31 -
> @@ -484,6 +484,30 @@ filt_drmkms(struct knote *kn, long hint)
> return (kn->kn_fflags != 0);
> }
>
> +void
> +filt_drmreaddetach(struct knote *kn)
> +{
> + struct drm_file *file_priv = kn->kn_hook;
> + int s;
> +
> + s = spltty();
> + klist_remove(_priv->rsel.si_note, kn);
> + splx(s);
> +}
> +
> +int
> +filt_drmread(struct knote *kn, long hint)
> +{
> + struct drm_file *file_priv = kn->kn_hook;
> + int val = 0;
> +
> + //mtx_enter(_priv->minor->dev->event_lock);
> + val = !list_empty(_priv->event_list);
> + //mtx_leave(_priv->minor->dev->event_lock);
> +
> + return (val);
> +}
> +
> const struct filterops drm_filtops = {
> .f_flags= FILTEROP_ISFD,
> .f_attach = NULL,
> @@ -491,30 +515,51 @@ const struct filterops drm_filtops = {
> .f_event= filt_drmkms,
> };
>
> +const struct filterops drmread_filtops = {
> + .f_flags= FILTEROP_ISFD,
> + .f_attach = NULL,
> + .f_detach = filt_drmreaddetach,
> + .f_event= filt_drmread,
> +};
> +
> int
> drmkqfilter(dev_t kdev, struct knote *kn)
> {
> struct drm_device *dev = NULL;
> - int s;
> + struct drm_file *file_priv = NULL;
> + int s;
>
> dev = drm_get_device_from_kdev(kdev);
> if (dev == NULL || dev->dev_private == NULL)
> return (ENXIO);
>
> switch (kn->kn_filter) {
> + case EVFILT_READ:
> + mutex_lock(>struct_mutex);
> + file_priv = drm_find_file_by_minor(dev, minor(kdev));
> + mutex_unlock(>struct_mutex);
> + if (file_priv == NULL)
> + return (ENXIO);
> +
> + kn->kn_fop = _filtops;
> + kn->kn_hook = file_priv;
> +
> + s = spltty();
> + klist_insert(_priv->rsel.si_note, kn);
> + splx(s);
> + break;
> case EVFILT_DEVICE:
> kn->kn_fop = _filtops;
> + kn->kn_hook = dev;
> +
> + s = spltty();
> + klist_insert(>note, kn);
> + splx(s);
> break;
> default:
> return (EINVAL);
> }
>
> - kn->kn_hook = dev;
> -
> - s = spltty();
> - klist_insert(>note, kn);
> - splx(s);
> -
> return (0);
> }
>
> @@ -772,7 +817,6 @@ out:
> return (gotone);
> }
>
> -/* XXX
Re: drm(4) kqfilter & EVFILT_READ
On 27/04/20(Mon) 19:34, Martin Pieuchot wrote:
> On 28/04/20(Tue) 01:54, Jonathan Gray wrote:
> > On Mon, Apr 27, 2020 at 04:52:33PM +0200, Martin Pieuchot wrote:
> > > Diff below extends the existing drmkqfilter() to support EVFILT_READ.
> > > This makes drm(4)'s kqueue support in pair with poll().
> > >
> > > The event list queried in the filt_drmread() should be protected by the
> > > `event_lock' mutex. This could be done by using the `kdev' backpointer
> > > as shown in comment. However this would require some plumbing to make
> > > use of `minor'. The side effect of this approach would be to reduce the
> > > diff with Linux.
> >
> > You seem to be confusing kdev and dev in the drm_minor struct.
> > at least in linux kdev is 'struct device *' and dev is
> > 'struct drm_device *' (which has the event lock).
> > I have a tree which uses the drm_minor struct but it is part of a much
> > larger diff.
>
> Thanks for pointing that out! Do you see another way to comply to the
> locking then?
If not or if we agree that this can be improved later on I'd like to
commit the fixed diff below, ok?
Index: sys/conf.h
===
RCS file: /cvs/src/sys/sys/conf.h,v
retrieving revision 1.150
diff -u -p -r1.150 conf.h
--- sys/conf.h 21 Apr 2020 08:29:27 - 1.150
+++ sys/conf.h 27 Apr 2020 14:43:48 -
@@ -439,7 +439,7 @@ extern struct cdevsw cdevsw[];
(dev_type_stop((*))) enodev, 0, selfalse, \
(dev_type_mmap((*))) enodev }
-/* open, close, read, ioctl, poll, mmap, nokqfilter */
+/* open, close, read, ioctl, poll, mmap, kqfilter */
#define cdev_drm_init(c,n){ \
dev_init(c,n,open), dev_init(c,n,close), dev_init(c, n, read), \
(dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
Index: dev/pci/drm/drm_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_drv.c,v
retrieving revision 1.174
diff -u -p -r1.174 drm_drv.c
--- dev/pci/drm/drm_drv.c 7 Apr 2020 13:27:51 - 1.174
+++ dev/pci/drm/drm_drv.c 28 Apr 2020 09:37:31 -
@@ -484,6 +484,30 @@ filt_drmkms(struct knote *kn, long hint)
return (kn->kn_fflags != 0);
}
+void
+filt_drmreaddetach(struct knote *kn)
+{
+ struct drm_file *file_priv = kn->kn_hook;
+ int s;
+
+ s = spltty();
+ klist_remove(_priv->rsel.si_note, kn);
+ splx(s);
+}
+
+int
+filt_drmread(struct knote *kn, long hint)
+{
+ struct drm_file *file_priv = kn->kn_hook;
+ int val = 0;
+
+ //mtx_enter(_priv->minor->dev->event_lock);
+ val = !list_empty(_priv->event_list);
+ //mtx_leave(_priv->minor->dev->event_lock);
+
+ return (val);
+}
+
const struct filterops drm_filtops = {
.f_flags= FILTEROP_ISFD,
.f_attach = NULL,
@@ -491,30 +515,51 @@ const struct filterops drm_filtops = {
.f_event= filt_drmkms,
};
+const struct filterops drmread_filtops = {
+ .f_flags= FILTEROP_ISFD,
+ .f_attach = NULL,
+ .f_detach = filt_drmreaddetach,
+ .f_event= filt_drmread,
+};
+
int
drmkqfilter(dev_t kdev, struct knote *kn)
{
struct drm_device *dev = NULL;
- int s;
+ struct drm_file *file_priv = NULL;
+ int s;
dev = drm_get_device_from_kdev(kdev);
if (dev == NULL || dev->dev_private == NULL)
return (ENXIO);
switch (kn->kn_filter) {
+ case EVFILT_READ:
+ mutex_lock(>struct_mutex);
+ file_priv = drm_find_file_by_minor(dev, minor(kdev));
+ mutex_unlock(>struct_mutex);
+ if (file_priv == NULL)
+ return (ENXIO);
+
+ kn->kn_fop = _filtops;
+ kn->kn_hook = file_priv;
+
+ s = spltty();
+ klist_insert(_priv->rsel.si_note, kn);
+ splx(s);
+ break;
case EVFILT_DEVICE:
kn->kn_fop = _filtops;
+ kn->kn_hook = dev;
+
+ s = spltty();
+ klist_insert(>note, kn);
+ splx(s);
break;
default:
return (EINVAL);
}
- kn->kn_hook = dev;
-
- s = spltty();
- klist_insert(>note, kn);
- splx(s);
-
return (0);
}
@@ -772,7 +817,6 @@ out:
return (gotone);
}
-/* XXX kqfilter ... */
int
drmpoll(dev_t kdev, int events, struct proc *p)
{
Re: smtpd: fix catch-all in virtual aliases
> On 28. Apr 2020, at 10:10, gil...@poolp.org wrote: > April 28, 2020 8:55 AM, "Joerg Jung" mailto:m...@umaxx.net>> > wrote: > >> Also this change might break existing valid setups (e.g. with mailing list >> servers), but people will likely know how to cope with it. > > Do you have an example of an existing valid setup that is broken with this ? No example, I just presumed (that’s why I wrote “might”).
Re: smtpd: fix catch-all in virtual aliases
April 28, 2020 8:55 AM, "Joerg Jung" wrote: >> On 26. Apr 2020, at 18:30, Eric Faurot wrote: >> >> When a catch-all entry (@) is used in a virtual alias table, it >> eventually (and mistakenly) catches everything that expands to a >> username. For example, with: >> >> f...@example.com user >> @ catchall >> >> "f...@example.com" expands to "user" as expected, but then "user" >> expands to "catchall" because it is interpreted as "user@" (empty >> domain). > > Which makes sense to me. If one doesn’t specify a domain after the ‘@‘, > I would expect to really catch-all for all domains and all users. > that's not how mailaddr work in OpenSMTPD, the semantic is this one: user=> user@* user@domain => user@domain @domain => *@domain @ => * and this is not an aliases only thing, this is how table lookups are performed for type K_MAILADDR. This allows you to do stuff like follows: root : root gil...@poolp.org : gilles e...@faurot.net : eric @poolp.org : poolpcatchall @faurot.net : faurotcatchall @: catchallusuer >> The catch-all fallback mechanism is really meant for full email >> addresses in virtual context, and should not happen for usernames. >> The following diff fixes it. > > Yes, I agree that catch-all only really meant to be used for single virtual > domain context and not with primary domains. > > But instead of allowing the syntax and ignoring the case in aliases.c > as in your diff below, I would prefer to “fail" on parsing of the table and > error logging that an empty domain after ‘@‘ is not a valid syntax, no? > > Also this change might break existing valid setups (e.g. with mailing list > servers), but people will likely know how to cope with it. > Do you have an example of an existing valid setup that is broken with this ?
Re: smtpd: fix catch-all in virtual aliases
> On 26. Apr 2020, at 18:30, Eric Faurot wrote: > > When a catch-all entry (@) is used in a virtual alias table, it > eventually (and mistakenly) catches everything that expands to a > username. For example, with: > >f...@example.com user >@catchall > > "f...@example.com" expands to "user" as expected, but then "user" > expands to "catchall" because it is interpreted as "user@" (empty > domain). Which makes sense to me. If one doesn’t specify a domain after the ‘@‘, I would expect to really catch-all for all domains and all users. > The catch-all fallback mechanism is really meant for full email > addresses in virtual context, and should not happen for usernames. > The following diff fixes it. Yes, I agree that catch-all only really meant to be used for single virtual domain context and not with primary domains. But instead of allowing the syntax and ignoring the case in aliases.c as in your diff below, I would prefer to “fail" on parsing of the table and error logging that an empty domain after ‘@‘ is not a valid syntax, no? Also this change might break existing valid setups (e.g. with mailing list servers), but people will likely know how to cope with it. Regards, Joerg > Index: aliases.c > === > RCS file: /cvs/src/usr.sbin/smtpd/aliases.c,v > retrieving revision 1.77 > diff -u -p -r1.77 aliases.c > --- aliases.c 28 Dec 2018 12:47:28 - 1.77 > +++ aliases.c 26 Apr 2020 16:04:51 - > @@ -164,6 +164,10 @@ aliases_virtual_get(struct expand *expan > if (ret) > goto expand; > > + /* Do not try catch-all entries if there is no domain */ > + if (domain[0] == '\0') > + return 0; > + > if (!bsnprintf(buf, sizeof(buf), "@%s", domain)) > return 0; > /* Failed ? We lookup for catch all for virtual domain */ >
Re: Simplify NET_LOCK() variations
Hello, > That's a bug, updated diff below. > OK I see. the diff looks better then. > If there's a consensus that this is a way to move forward, it would make > sense to commit it after unlock. > I have not spot anything else. I think this change should go in. OK sashan@
