Re: less: tighten pledge in secure mode
Tobias Stoeckmann(tob...@stoeckmann.org) on 2021.09.21 22:23:55 +0200:
> Hi,
>
> upstream (greenwood) less has disabled history file support for secure
> mode, i.e. LESSSECURE=1: https://github.com/gwsw/less/pull/201
>
> The problem was about permanent marks for which we do not have support
> anyway. Users could possibly access files they should not be able to.
>
> Since upstream does not allow history file in secure mode anymore we
> could do the same and remove wpath from secure mode pledge.
>
> I have added a note about history file to our manual page.
>
> Comments? Okays?
seems reasonable.
ok.
> Tobias
>
> Index: cmdbuf.c
> ===
> RCS file: /cvs/src/usr.bin/less/cmdbuf.c,v
> retrieving revision 1.20
> diff -u -p -u -p -r1.20 cmdbuf.c
> --- cmdbuf.c 2 Sep 2019 14:07:45 - 1.20
> +++ cmdbuf.c 21 Sep 2021 20:16:08 -
> @@ -20,6 +20,7 @@
> #include "cmd.h"
> #include "less.h"
>
> +extern int secure;
> extern int sc_width;
> extern int utf_mode;
>
> @@ -1203,6 +1204,8 @@ init_cmdhist(void)
> FILE *f;
> char *p;
>
> + if (secure)
> + return;
> filename = histfile_name();
> if (filename == NULL)
> return;
> @@ -1274,6 +1277,8 @@ save_cmdhist(void)
> struct stat statbuf;
> int r;
>
> + if (secure)
> + return;
> if (mlist_search.modified)
> modified = 1;
> if (mlist_shell.modified)
> Index: less.1
> ===
> RCS file: /cvs/src/usr.bin/less/less.1,v
> retrieving revision 1.57
> diff -u -p -u -p -r1.57 less.1
> --- less.12 Sep 2019 14:07:45 - 1.57
> +++ less.121 Sep 2021 20:16:09 -
> @@ -1697,6 +1697,8 @@ Use of lesskey files.
> .It Fl t
> Use of tags files.
> .It " "
> +Use of history file.
> +.It " "
> Metacharacters in filenames, such as "*".
> .It " "
> Filename completion (TAB, ^L).
> Index: main.c
> ===
> RCS file: /cvs/src/usr.bin/less/main.c,v
> retrieving revision 1.37
> diff -u -p -u -p -r1.37 main.c
> --- main.c28 Jun 2019 05:44:09 - 1.37
> +++ main.c21 Sep 2021 20:16:09 -
> @@ -91,7 +91,7 @@ main(int argc, char *argv[])
> secure = 1;
>
> if (secure) {
> - if (pledge("stdio rpath wpath tty", NULL) == -1) {
> + if (pledge("stdio rpath tty", NULL) == -1) {
> perror("pledge");
> exit(1);
> }
>
Re: smtpd: srs and ruleset evaluation
Hello,
As discussed, this looks correct to me
> On 22 Sep 2021, at 15:46, Eric Faurot wrote:
>
> Hi.
>
> A user reported that decoded SRS addresses are not correctly evaluated
> against the ruleset. That's because the ruleset always matches against
> the expanded address ("dest") and not the original address ("rcpt").
> This diff should fix it.
>
> Eric.
>
>
> Index: lka_session.c
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/lka_session.c,v
> retrieving revision 1.95
> diff -u -p -r1.95 lka_session.c
> --- lka_session.c 14 Jun 2021 17:58:15 - 1.95
> +++ lka_session.c 21 Sep 2021 19:21:18 -
> @@ -280,19 +280,19 @@ lka_expand(struct lka_session *lks, stru
> /* handle SRS */
> if (env->sc_srs_key != NULL &&
> ep.sender.user[0] == '\0' &&
> - (strncasecmp(ep.rcpt.user, "SRS0=", 5) == 0 ||
> - strncasecmp(ep.rcpt.user, "SRS1=", 5) == 0)) {
> - srs_decoded = srs_decode(mailaddr_to_text());
> + (strncasecmp(ep.dest.user, "SRS0=", 5) == 0 ||
> + strncasecmp(ep.dest.user, "SRS1=", 5) == 0)) {
> + srs_decoded = srs_decode(mailaddr_to_text());
> if (srs_decoded &&
> - text_to_mailaddr(, srs_decoded)) {
> - /* flag envelope internal and override rcpt */
> + text_to_mailaddr(, srs_decoded)) {
> + /* flag envelope internal and override dest */
> ep.flags |= EF_INTERNAL;
> - xn->u.mailaddr = ep.rcpt;
> + xn->u.mailaddr = ep.dest;
> lks->envelope = ep;
> }
> else {
> log_warn("SRS failed to decode: %s",
> - mailaddr_to_text());
> + mailaddr_to_text());
> }
> }
>
>
Re: Should 80MB of RAM be enough for kernel relinking on i386?
If the situation isn't going to change anytime soon then I have some diffs for INSTALL.i386 and INSTALL.amd64. The latter has not specified disk requirements, I guess since anyone who owns an amd64 system will very likely be using a disk big enough for X, so I figured that the same would apply to any user of an i386 system that meets the proposed minimum RAM. These are based on the 2021-09-21 snapshot versions. --- INSTALL.i386.txtWed Sep 22 16:52:38 2021 +++ INSTALL.i386_newWed Sep 22 16:51:17 2021 @@ -201,10 +201,7 @@ OpenBSD/i386 7.0 supports most SMP (Symmetrical MultiP systems. To support SMP operation, a separate SMP kernel (bsd.mp) is included with the installation file sets. -The minimal configuration to install the system is 32MB of RAM and -at least 250MB of disk space to accommodate the `base' set. -To install the entire system, at least 600MB of disk are required, -and to run X or compile the system, more RAM is recommended. +The minimal configuration to install the system is 512MB of RAM. Please refer to the website for a full list of supported hardware: https://www.openbsd.org/i386.html --- INSTALL.amd64.txt Wed Sep 22 16:52:48 2021 +++ INSTALL.amd64_new Wed Sep 22 16:51:12 2021 @@ -202,6 +202,8 @@ is included with the installation file sets. OpenBSD/amd64 7.0 supports both UEFI/GPT booting and BIOS/MBR booting. +The minimal configuration to install the system is 512MB of RAM. + Please refer to the website for a full list of supported hardware. https://www.openbsd.org/amd64.html Patrick Harper
Re: smtpd: srs and ruleset evaluation
On Wed, 22 Sep 2021 15:46:13 +0200, Eric Faurot wrote:
> A user reported that decoded SRS addresses are not correctly evaluated
> against the ruleset. That's because the ruleset always matches against
> the expanded address ("dest") and not the original address ("rcpt").
> This diff should fix it.
Thanks for looking into this. OK millert@
- todd
smtpd: srs and ruleset evaluation
Hi.
A user reported that decoded SRS addresses are not correctly evaluated
against the ruleset. That's because the ruleset always matches against
the expanded address ("dest") and not the original address ("rcpt").
This diff should fix it.
Eric.
Index: lka_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/lka_session.c,v
retrieving revision 1.95
diff -u -p -r1.95 lka_session.c
--- lka_session.c 14 Jun 2021 17:58:15 - 1.95
+++ lka_session.c 21 Sep 2021 19:21:18 -
@@ -280,19 +280,19 @@ lka_expand(struct lka_session *lks, stru
/* handle SRS */
if (env->sc_srs_key != NULL &&
ep.sender.user[0] == '\0' &&
- (strncasecmp(ep.rcpt.user, "SRS0=", 5) == 0 ||
- strncasecmp(ep.rcpt.user, "SRS1=", 5) == 0)) {
- srs_decoded = srs_decode(mailaddr_to_text());
+ (strncasecmp(ep.dest.user, "SRS0=", 5) == 0 ||
+ strncasecmp(ep.dest.user, "SRS1=", 5) == 0)) {
+ srs_decoded = srs_decode(mailaddr_to_text());
if (srs_decoded &&
- text_to_mailaddr(, srs_decoded)) {
- /* flag envelope internal and override rcpt */
+ text_to_mailaddr(, srs_decoded)) {
+ /* flag envelope internal and override dest */
ep.flags |= EF_INTERNAL;
- xn->u.mailaddr = ep.rcpt;
+ xn->u.mailaddr = ep.dest;
lks->envelope = ep;
}
else {
log_warn("SRS failed to decode: %s",
- mailaddr_to_text());
+ mailaddr_to_text());
}
}
bgpctl mrtdump adjustment
In bgpd we do not follow the RFC8050 encoding for RIB_GENERIC_ADDPATH.
Mainly because it does not fit the way the code works and also because the
only other BGP implementation that seems to care about RIB_GENERIC_ADDPATH
does it the same way.
Because of this it makes no sense to parse RIB_GENERIC_ADDPATH strictly
per RFC8050 but instead parse it the way it is implemented.
While there cleanup some unused variables.
--
:wq Claudio
Index: mrtparser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/mrtparser.c,v
retrieving revision 1.15
diff -u -p -r1.15 mrtparser.c
--- mrtparser.c 27 Jul 2021 07:42:37 - 1.15
+++ mrtparser.c 22 Sep 2021 10:22:54 -
@@ -103,10 +103,8 @@ mrt_parse(int fd, struct mrt_parser *p,
struct mrt_bgp_state*s;
struct mrt_bgp_msg *m;
void*msg;
- int addpath;
while ((msg = mrt_read_msg(fd, ))) {
- addpath = 0;
switch (ntohs(h.type)) {
case MSG_NULL:
case MSG_START:
@@ -376,7 +374,7 @@ mrt_parse_v2_rib(struct mrt_hdr *hdr, vo
u_int32_t snum, path_id = 0;
u_int16_t cnt, i, afi;
u_int8_tsafi, aid;
- int ret, addpath = 0;
+ int ret;
if (len < sizeof(snum) + 1)
return NULL;
@@ -417,6 +415,11 @@ mrt_parse_v2_rib(struct mrt_hdr *hdr, vo
goto fail;
break;
case MRT_DUMP_V2_RIB_GENERIC_ADDPATH:
+ /*
+* RFC8050 handling for add-path has special handling for
+* RIB_GENERIC_ADDPATH but nobody implements it that way.
+* So just use the same way as for the other _ADDPATH types.
+*/
r->add_path = 1;
/* FALLTHROUGH */
case MRT_DUMP_V2_RIB_GENERIC:
@@ -434,16 +437,6 @@ mrt_parse_v2_rib(struct mrt_hdr *hdr, vo
if ((aid = mrt_afi2aid(afi, safi, verbose)) == AID_UNSPEC)
goto fail;
- /* RFC8050 handling for add-path */
- if (r->add_path) {
- if (len < sizeof(path_id))
- goto fail;
- memcpy(_id, b, sizeof(path_id));
- b += sizeof(path_id);
- len -= sizeof(path_id);
- path_id = ntohl(path_id);
- }
-
/* prefix */
ret = mrt_extract_prefix(b, len, aid, >prefix,
>prefixlen, verbose);
@@ -487,12 +480,9 @@ mrt_parse_v2_rib(struct mrt_hdr *hdr, vo
len -= sizeof(otm);
entries[i].originated = ntohl(otm);
- /* RFC8050 handling for add-path */
- if (r->add_path &&
- ntohs(hdr->subtype) != MRT_DUMP_V2_RIB_GENERIC_ADDPATH) {
+ if (r->add_path) {
if (len < sizeof(path_id) + sizeof(alen))
goto fail;
- addpath = 0;
memcpy(_id, b, sizeof(path_id));
b += sizeof(path_id);
len -= sizeof(path_id);
Re: pf.conf(5) & reply-to
On Wed, Sep 22, 2021 at 10:38:14AM +0100, Stuart Henderson wrote: > On 2021/09/22 11:28, Landry Breuil wrote: > > Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a ?crit : > > > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200: > > > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote: > > > > > did i screwup something somewhere in my config and there's a better > > > > > way > > > > > for that ? > > > > > > > > This was changed in February. No more interface, but gateway > > > > addresses. It seems that some parts of the documentation were > > > > missed. > > > > > > > > > should the manpage be improved for reply-to and talk about > > > > > 'destination > > > > > address' instead of 'interface' like route-to does ? > > > > > > > > Yes. > > > > > > > > It looks like most information is in the commit message. > > > > https://marc.info/?l=openbsd-cvs=161213948819452=2 > > > > > > It's also on http://www.openbsd.org/faq/upgrade69.html > > > > my english sucks and i'm not sure i got the meaning right, but here's a > > try: > > > > Index: pf.conf.5 > > === > > RCS file: /cvs/src/share/man/man5/pf.conf.5,v > > retrieving revision 1.587 > > diff -u -r1.587 pf.conf.5 > > --- pf.conf.5 19 Jul 2021 16:23:56 - 1.587 > > +++ pf.conf.5 22 Sep 2021 09:23:14 - > > @@ -1103,13 +1103,14 @@ > > option is similar to > > .Cm route-to , > > but routes packets that pass in the opposite direction (replies) to the > > -specified interface. > > +specified address. > > Opposite direction is only defined in the context of a state entry, and > > .Cm reply-to > > is useful only in rules that create state. > > It can be used on systems with multiple external connections to > > -route all outgoing packets of a connection through the interface > > -the incoming connection arrived through (symmetric routing enforcement). > > +route all outgoing packets of a connection through the interface the > > incoming > > +connection arrived through (symmetric routing enforcement) via the address > > of > > +the gateway specified in the rule. > > I think using "connection" twice (internet connection, and TCP/UDP/...\ > connection) can make this harder to read. Not 100% happy with this and > I have to go out so won't do any more wordsmithing now, but maybe it > gives some ideas? > > It can be used on systems with multiple paths to the internet to ensure > that replies to an incoming network connection to a particular address > are sent using the path associated with that address (symmetric routing > enforcement). > This is done by specifying the address of the gateway in "reply-to". > this reads fine too, stuart. jmc > > > > .It Cm route-to > > The > > .Cm route-to > > > > i wouldnt know how to change the example in faq/upgrade69.html as it is > > valid > > (but only specific to the case of a point-to-point interface with a :peer > > property) > > > > ccing experts :) > >
Re: pf.conf(5) & reply-to
On Wed, Sep 22, 2021 at 11:28:21AM +0200, Landry Breuil wrote: > Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a ?crit : > > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200: > > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote: > > > > did i screwup something somewhere in my config and there's a better way > > > > for that ? > > > > > > This was changed in February. No more interface, but gateway > > > addresses. It seems that some parts of the documentation were > > > missed. > > > > > > > should the manpage be improved for reply-to and talk about 'destination > > > > address' instead of 'interface' like route-to does ? > > > > > > Yes. > > > > > > It looks like most information is in the commit message. > > > https://marc.info/?l=openbsd-cvs=161213948819452=2 > > > > It's also on http://www.openbsd.org/faq/upgrade69.html > > my english sucks and i'm not sure i got the meaning right, but here's a > try: > > Index: pf.conf.5 > === > RCS file: /cvs/src/share/man/man5/pf.conf.5,v > retrieving revision 1.587 > diff -u -r1.587 pf.conf.5 > --- pf.conf.5 19 Jul 2021 16:23:56 - 1.587 > +++ pf.conf.5 22 Sep 2021 09:23:14 - > @@ -1103,13 +1103,14 @@ > option is similar to > .Cm route-to , > but routes packets that pass in the opposite direction (replies) to the > -specified interface. > +specified address. > Opposite direction is only defined in the context of a state entry, and > .Cm reply-to > is useful only in rules that create state. > It can be used on systems with multiple external connections to > -route all outgoing packets of a connection through the interface > -the incoming connection arrived through (symmetric routing enforcement). > +route all outgoing packets of a connection through the interface the incoming > +connection arrived through (symmetric routing enforcement) via the address of looking at "through the interface the incomming connection arrived through". the double "through" sounds odd (but may be correct). would it be better to say through the interface the incoming connection arrived "on"? or just "through the interface of the incoming connection"? i think "using" sounds better than "via" i think a comma after "enforcement)" might make the sentence easier to read all of my points above are really just opinion. the diff reads ok. jmc > +the gateway specified in the rule. > .It Cm route-to > The > .Cm route-to > > i wouldnt know how to change the example in faq/upgrade69.html as it is valid > (but only specific to the case of a point-to-point interface with a :peer > property) > > ccing experts :)
Re: pf.conf(5) & reply-to
On 2021/09/22 11:28, Landry Breuil wrote: > Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a écrit : > > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200: > > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote: > > > > did i screwup something somewhere in my config and there's a better way > > > > for that ? > > > > > > This was changed in February. No more interface, but gateway > > > addresses. It seems that some parts of the documentation were > > > missed. > > > > > > > should the manpage be improved for reply-to and talk about 'destination > > > > address' instead of 'interface' like route-to does ? > > > > > > Yes. > > > > > > It looks like most information is in the commit message. > > > https://marc.info/?l=openbsd-cvs=161213948819452=2 > > > > It's also on http://www.openbsd.org/faq/upgrade69.html > > my english sucks and i'm not sure i got the meaning right, but here's a > try: > > Index: pf.conf.5 > === > RCS file: /cvs/src/share/man/man5/pf.conf.5,v > retrieving revision 1.587 > diff -u -r1.587 pf.conf.5 > --- pf.conf.5 19 Jul 2021 16:23:56 - 1.587 > +++ pf.conf.5 22 Sep 2021 09:23:14 - > @@ -1103,13 +1103,14 @@ > option is similar to > .Cm route-to , > but routes packets that pass in the opposite direction (replies) to the > -specified interface. > +specified address. > Opposite direction is only defined in the context of a state entry, and > .Cm reply-to > is useful only in rules that create state. > It can be used on systems with multiple external connections to > -route all outgoing packets of a connection through the interface > -the incoming connection arrived through (symmetric routing enforcement). > +route all outgoing packets of a connection through the interface the incoming > +connection arrived through (symmetric routing enforcement) via the address of > +the gateway specified in the rule. I think using "connection" twice (internet connection, and TCP/UDP/...\ connection) can make this harder to read. Not 100% happy with this and I have to go out so won't do any more wordsmithing now, but maybe it gives some ideas? It can be used on systems with multiple paths to the internet to ensure that replies to an incoming network connection to a particular address are sent using the path associated with that address (symmetric routing enforcement). This is done by specifying the address of the gateway in "reply-to". > .It Cm route-to > The > .Cm route-to > > i wouldnt know how to change the example in faq/upgrade69.html as it is valid > (but only specific to the case of a point-to-point interface with a :peer > property) > > ccing experts :) >
Re: pf.conf(5) & reply-to
Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a écrit : > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200: > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote: > > > did i screwup something somewhere in my config and there's a better way > > > for that ? > > > > This was changed in February. No more interface, but gateway > > addresses. It seems that some parts of the documentation were > > missed. > > > > > should the manpage be improved for reply-to and talk about 'destination > > > address' instead of 'interface' like route-to does ? > > > > Yes. > > > > It looks like most information is in the commit message. > > https://marc.info/?l=openbsd-cvs=161213948819452=2 > > It's also on http://www.openbsd.org/faq/upgrade69.html my english sucks and i'm not sure i got the meaning right, but here's a try: Index: pf.conf.5 === RCS file: /cvs/src/share/man/man5/pf.conf.5,v retrieving revision 1.587 diff -u -r1.587 pf.conf.5 --- pf.conf.5 19 Jul 2021 16:23:56 - 1.587 +++ pf.conf.5 22 Sep 2021 09:23:14 - @@ -1103,13 +1103,14 @@ option is similar to .Cm route-to , but routes packets that pass in the opposite direction (replies) to the -specified interface. +specified address. Opposite direction is only defined in the context of a state entry, and .Cm reply-to is useful only in rules that create state. It can be used on systems with multiple external connections to -route all outgoing packets of a connection through the interface -the incoming connection arrived through (symmetric routing enforcement). +route all outgoing packets of a connection through the interface the incoming +connection arrived through (symmetric routing enforcement) via the address of +the gateway specified in the rule. .It Cm route-to The .Cm route-to i wouldnt know how to change the example in faq/upgrade69.html as it is valid (but only specific to the case of a point-to-point interface with a :peer property) ccing experts :)
Re: ksh(1) search-history fix
> I suggest that entering a NUL character will abort the search-history > mode, much like ^[ does. This leaves the handling of said character to > the "ordinary" command editing. Makes sense. In vi mode, this problem doesn't occur, as the ^@ is displayed in the search string. ok tb for after release
