[Bug 240947] Hours calculation in blacklistctl dump output incorrect
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240947 Gordon Bergling changed: What|Removed |Added CC||gbergl...@gmail.com --- Comment #1 from Gordon Bergling --- This is already fixed in HEAD by rS354399. MFC should be around around the beginning of February. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240947] Hours calculation in blacklistctl dump output incorrect
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240947 --- Comment #2 from Gordon Bergling --- This is already fixed in HEAD by rS354399. MFC should be around the beginning of February. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243153] "make buildworld" fails with ..netnatm: No such file or directory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243153 Bug ID: 243153 Summary: "make buildworld" fails with ..netnatm: No such file or directory Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: free...@daemon.de [..] mtree -deU -f /usr/src/include/../etc/mtree/BSD.include.dist -p /usr/obj/usr/src/tmp/usr/include > /dev/null Setting up symlinks to kernel source tree... cd /usr/src/include/../sys/bsm; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/bsm/$h /usr/obj/usr/src/tmp/usr/include/bsm; done cd /usr/src/include/../sys/cam; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/cam/$h /usr/obj/usr/src/tmp/usr/include/cam; done cd /usr/src/include/../sys/geom; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/geom/$h /usr/obj/usr/src/tmp/usr/include/geom; done cd /usr/src/include/../sys/net; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/net/$h /usr/obj/usr/src/tmp/usr/include/net; done cd /usr/src/include/../sys/net80211; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/net80211/$h /usr/obj/usr/src/tmp/usr/include/net80211; done cd /usr/src/include/../sys/netgraph; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/netgraph/$h /usr/obj/usr/src/tmp/usr/include/netgraph; done cd /usr/src/include/../sys/netinet; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/netinet/$h /usr/obj/usr/src/tmp/usr/include/netinet; done cd /usr/src/include/../sys/netinet6; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/netinet6/$h /usr/obj/usr/src/tmp/usr/include/netinet6; done cd /usr/src/include/../sys/netipsec; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/netipsec/$h /usr/obj/usr/src/tmp/usr/include/netipsec; done cd /usr/src/include/../sys/netnatm; for h in *.h; do sh /usr/src/tools/install.sh -l s ../../../sys/netnatm/$h /usr/obj/usr/src/tmp/usr/include/netnatm; done cd: /usr/src/include/../sys/netnatm: No such file or directory *** Error code 2 Stop. make[3]: stopped in /usr/src/include *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src The directory /usr/src/sys/netnatm/ doesn't exist. I'm at revision 356438 of 12.1 releng. I also checked https://svnweb.freebsd.org/base/releng/12.1/sys/, it's not there as well but referenced in BSD.include.dist. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243094] reboot problem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243094 --- Comment #11 from b.l.ber...@t-online.de --- (In reply to Jack from comment #10) It makes little sense to have two different programs for rebooting FreeBSD. Reasons: Double the effort! And one (shutdown) is developed further and the other (reboot) is forgotten. So I think the best thing to do is to move the reboot program into the ports with the new release 13 and the missing features could be included in shutdown. If you still want to use it, you can install it with a warning message and from release 14 on you can remove it from the ports collection, so that there is only one program to start/stop/reboot the system. PS: after a lot of excitement, I have calmed down and am now staying with FreeBSD after all. translated with DeepL from german to english -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243155] Linuxulator: broken fadvise64 for 32-bit applications on amd64
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243155
Bug ID: 243155
Summary: Linuxulator: broken fadvise64 for 32-bit applications
on amd64
Product: Base System
Version: 12.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: iwt...@gmail.com
% cat fadvice_bug.c
#define _GNU_SOURCE
#include
int main() {
posix_fadvise(1, 2, 3, 4);
return 0;
}
% /compat/linux/bin/gcc -m64 fadvice_bug.c -o fadvice_bug64
% truss ./fadvice_bug64
...
linux_fadvise64(0x1,0x2,0x3,0x4)ERR#-19 'Operation not supported by
device' # ok
...
% /compat/linux/bin/gcc -m32 fadvice_bug.c -o fadvice_bug32
% truss ./fadvice_bug32
...
linux_fadvise64(0x1,0x2,0x0,0x3)ERR#-19 'Operation not supported by
device' # hmm
...
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240762] [auditdistd] cannot receive trail files from servers running auditd on FreeBSD12
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240762 Gordon Bergling changed: What|Removed |Added CC||gbergl...@gmail.com --- Comment #1 from Gordon Bergling --- I can reproduce this on a recent 12.1-STABLE. rootaudit 56 Nov 18 18:23 20191118172312.20191118172312. rootaudit 56 Jan 7 14:44 20200107134414.not_terminated. My initial direction was the C macro getTSstr, which is defined in contrib/openbsm/bsm/auditd_lib.h:46. But after I saw that the dot is also appended after "not_terminated" that problem must be located somewhere else. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240762] [auditdistd] cannot receive trail files from servers running auditd on FreeBSD12
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240762 --- Comment #2 from Gordon Bergling --- I can reproduce this on a recent 12.1-STABLE. rootaudit 56 Nov 18 18:23 20191118172312.20191118172312. rootaudit 56 Jan 7 14:44 20200107134414.not_terminated. My initial direction was the C macro getTSstr, which is defined in contrib/openbsm/bsm/auditd_lib.h:46. But after I saw that the dot is also appended after "not_terminated" that problem must be located somewhere else. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 232773] FreeBSD Loader fails with HP GEN8 Microserver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232773 edller changed: What|Removed |Added CC||edl...@gmail.com --- Comment #4 from edller --- Same problem here. Tried several ways to boot Gen8 from internal sata. No lucky. Trying on internal USB port: too slow and lots of bugs. The installer freezes majority of times. I perceived it sometimes passes the initial install phase when I do a cold boot though. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243164] blacklistd not handling masks correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164 Bug ID: 243164 Summary: blacklistd not handling masks correctly Product: Base System Version: 12.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: free...@oldach.net I am afraid the blacklist.conf syntax and description might be a bit misleading. According to the manpage, an IP address may be specified without mentioning an explicit mask. The usual assumption obvioulsy being that lack of a mask spec represents a host address: 192.168.134.99 would be identical to 192.168.134.99/32. It appears that blacklistd behaves differntly. For the sake of the exercise consider the following trivial (and complete) /etc/blacklistd.conf: # adr/mask:port typeproto owner namenfail disable [local] ssh stream * * * 3 3m # adr/mask:port typeproto owner namenfail disable [remote] 192.168.134.99:ssh * * * = * * Basically meaning, ssh would be blocked for 3 minutes after 3 unsuccessful attempts - except when ssh originates at 192.168.134.99, which will always succeed even if invalid. Now, I'm not connecting from that host but from 192.168.134.1. When connecting with an invalid user, access is *NOT* blocked after 3 unsuccessful attempts. Indeed the debug log shows a successful match: Jan 7 18:12:08 latitude blacklistd[1565]: processing type=2 fd=6 remote=192.168.134.1:61329 msg=ssh uid=0 gid=0 Jan 7 18:12:08 latitude blacklistd[1565]: listening socket: 192.168.134.3:22 Jan 7 18:12:08 latitude blacklistd[1565]: look: target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:* Jan 7 18:12:08 latitude blacklistd[1565]: check: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 7 18:12:08 latitude blacklistd[1565]: found: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 7 18:12:08 latitude blacklistd[1565]: conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 7 18:12:08 latitude blacklistd[1565]: conf_apply: to: target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:* Jan 7 18:12:08 latitude blacklistd[1565]: conf_apply: result: target:192.168.134.3:22, proto:6, family:2, uid:*, name:*, nfail:3, duration:180 Jan 7 18:12:08 latitude blacklistd[1565]: Applied address 192.168.134.1:22 Jan 7 18:12:08 latitude blacklistd[1565]: check: target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:* Jan 7 18:12:08 latitude blacklistd[1565]: found: target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:* Jan 7 18:12:08 latitude blacklistd[1565]: conf_merge: merge: target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:* Jan 7 18:12:08 latitude blacklistd[1565]: conf_merge: to: target:192.168.134.1:22, proto:6, family:2, uid:*, name:*, nfail:3, duration:180 Jan 7 18:12:08 latitude blacklistd[1565]: conf_merge: result: target:192.168.134.1:22, proto:6, family:2, uid:*, name:*, nfail:*, duration:* Jan 7 18:12:08 latitude blacklistd[1565]: Applied address 192.168.134.1:22 Note there are *two* "found:" tokens in the log (one for the [local], and one for the [remote] part) which states that our source address (192.168.134.1) does match against 192.168.134.99. This is obviously incorrect. Now, let's add a proper (host) network mask to /etc/blacklistd.conf ... # adr/mask:port typeproto owner namenfail disable [remote] 192.168.134.99/32:ssh * * * = * * In this case, access *IS* blocked after three unsucessful attempts. Indeed the debug log reflects this (first attempt): Jan 7 18:07:13 latitude blacklistd[1506]: processing type=2 fd=6 remote=192.168.134.1:61301 msg=ssh uid=0 gid=0 Jan 7 18:07:13 latitude blacklistd[1506]: listening socket: 192.168.134.3:22 Jan 7 18:07:13 latitude blacklistd[1506]: look: target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:* Jan 7 18:07:13 latitude blacklistd[1506]: check: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 7 18:07:13 latitude blacklistd[1506]: found: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 7 18:07:13 latitude blacklistd[1506]: conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 7 18:07:13 latitude blacklistd[1506]: conf_apply: to: target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:* Jan 7 18:07:13 latitude blacklistd[1506]: conf_apply: result: target:192.168.134.3:22, proto:6, famil
[Bug 240947] Hours calculation in blacklistctl dump output incorrect
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240947 Mark Johnston changed: What|Removed |Added Assignee|b...@freebsd.org|ema...@freebsd.org CC||ma...@freebsd.org Status|New |In Progress --- Comment #3 from Mark Johnston --- Assign to emaste assuming he'll do the MFC. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243164] blacklistd not handling masks correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164 --- Comment #1 from Ed Maste --- (In reply to Helge Oldach from comment #0) Indeed, the changes in D22259 are quite minor and I wouldn't expect to see a difference here. Will try to take a look. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243153] "make buildworld" fails with ..netnatm: No such file or directory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243153 Ed Maste changed: What|Removed |Added CC||bro...@freebsd.org, ||ema...@freebsd.org --- Comment #1 from Ed Maste --- netnatm was removed from LDIRS in include/Makefile in r317383, can you check that you don't somehow have a stale copy? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243155] Linuxulator: broken fadvise64 for 32-bit applications on amd64
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243155 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|emulat...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 233094] [meta] Base system tool chain modernization tracking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233094 Ed Maste changed: What|Removed |Added Depends on||243119 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243119 [Bug 243119] devel/binutils 2.33.1,1 assertion failure in sparc64 buildworld -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 233094] [meta] Base system tool chain modernization tracking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233094 Bug 233094 depends on bug 241374, which changed state. Bug 241374 Summary: devel/sparc64-binutils: segfault during tinderbox https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241374 What|Removed |Added Status|New |Closed Resolution|--- |DUPLICATE -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240700] [META] FreeBSD 12.1-RELEASE post-release EN candidates
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240700 Bug 240700 depends on bug 236724, which changed state. Bug 236724 Summary: igb(4): Interfaces fail to switch active to inactive state https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236724 What|Removed |Added Status|Open|Closed Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 242828] diff -rq still does full file comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242828
--- Comment #1 from fehmi noyan isi ---
It appears BSD diff keeps working on the the files even after it knows whether
the files are identical or not.
In diffreg(), which is called by diff() we have [1]
switch (files_differ(f1, f2, flags)) {
case 0:
goto closem;
case 1:
break;
default:
/* error */
status |= 2;
goto closem;
}
files_differ() returns 0 when the files are identical and 1 when they are
different. For the cases when files_differ() returns 1, instead of just a
single break statement, we can add a check for the command line arguments and
if '-q' supplied, i.e. D_BRIEF, then we should return from diffred() (after
doing some housekeeping if necessary - or add another 'goto' label at the end
of the function).
Instead, BSD diff carries on and hashes each line in both files, sorts them and
do more checks, hence taking more time.
If this sounds reasonable, I can work on a patch.
[1] http://src.illumos.org/source/xref/freebsd-head/usr.bin/diff/diffreg.c#341
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243164] blacklistd not handling masks correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164
Conrad Meyer changed:
What|Removed |Added
CC||c...@freebsd.org
--- Comment #2 from Conrad Meyer ---
I think the problem is this in contrib/blacklist/bin/conf.c:
213 static int
214 getmask(const char *f, size_t l, bool local, const char **p, int *mask)
215 {
216 char *d;
217 const char *s = *p;
218
219 if ((d = strchr(s, ':')) != NULL) {
220 *d++ = '\0';
221 *p = d;
222 }
223 if ((d = strchr(s, '/')) == NULL) {
224 *mask = FSTAR;
225 return 0;
If there is no /mask, *mask is treated as "FSTAR". In conf_addr_set:
585 if (c->c_lmask == FSTAR)
586 c->c_lmask = (int)(alen * 8);
That, uh, suggests no mask should indicate /32 or /128 for v6. I wonder what
goes wrong.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243164] blacklistd not handling masks correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164
--- Comment #3 from Conrad Meyer ---
Ah. I wonder if this is it?
459 #define MASK(m) ((uint32_t)~((1 << (32 - (m))) - 1))
460
461 static int
462 conf_amask_eq(const void *v1, const void *v2, size_t len, int mask)
463 {
464 const uint32_t *a1 = v1;
465 const uint32_t *a2 = v2;
466 uint32_t m;
467 int omask = mask;
468
469 len >>= 2;
470 switch (mask) {
471 case FSTAR:
472 if (memcmp(v1, v2, len) == 0)
473 return 1;
474 goto out;
// Above is definitely wrong, only compares the first 1/4 of the address
// bytes. Maybe that's what we're seeing?
...
484 for (size_t i = 0; i < len; i++) {
485 if (mask > 32) {
486 m = htonl((uint32_t)~0);
487 mask -= 32;
488 } else if (mask) {
489 m = htonl(MASK(mask));
490 mask = 0;
493 if ((a1[i] & m) != (a2[i] & m))
494 goto out;
// This part seems fine for v4, but I'm not sure if it's correct for v6.
495 }
496 return 1;
497 out:
...
506 return 0;
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243164] blacklistd not handling masks correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164
--- Comment #4 from Conrad Meyer ---
Helge, does this fix the issue?
--- a/contrib/blacklist/bin/conf.c
+++ b/contrib/blacklist/bin/conf.c
@@ -466,7 +466,6 @@ conf_amask_eq(const void *v1, const void *v2, size_t len,
int mask)
uint32_t m;
int omask = mask;
- len >>= 2;
switch (mask) {
case FSTAR:
if (memcmp(v1, v2, len) == 0)
@@ -481,7 +480,7 @@ conf_amask_eq(const void *v1, const void *v2, size_t len,
int mask)
break;
}
- for (size_t i = 0; i < len; i++) {
+ for (size_t i = 0; i < (len >> 2); i++) {
if (mask > 32) {
m = htonl((uint32_t)~0);
mask -= 32;
@@ -497,7 +496,6 @@ conf_amask_eq(const void *v1, const void *v2, size_t len,
int mask)
out:
if (debug > 1) {
char b1[256], b2[256];
- len <<= 2;
blhexdump(b1, sizeof(b1), "a1", v1, len);
blhexdump(b2, sizeof(b2), "a2", v2, len);
(*lfun)(LOG_DEBUG, "%s: %s != %s [0x%x]", __func__,
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243164] blacklistd not handling masks correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164 --- Comment #5 from Helge Oldach --- (In reply to Conrad Meyer from comment #3) > // Above is definitely wrong, only compares the first 1/4 of the address > // bytes. Maybe that's what we're seeing? Indeed. That matches with a real-life situation that consistently a (correct) mismatch is observed in case the first octet of an IPv4 address specified in [remote] is not identical to the first octet of the incoming address. In the exercise case, not being 192. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243164] blacklistd not handling masks correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164 --- Comment #6 from Helge Oldach --- (In reply to Conrad Meyer from comment #4) > Helge, does this fix the issue? Yes it does; we are now seeing a mismatch in case the source and [remote] addresses are different: Jan 8 06:06:57 latitude blacklistd[14144]: processing type=1 fd=6 remote=192.168.134.1:61909 msg=ssh uid=22 gid=22 Jan 8 06:06:57 latitude blacklistd[14144]: listening socket: 192.168.134.3:22 Jan 8 06:06:57 latitude blacklistd[14144]: look: target:192.168.134.3:22, proto:6, family:2, uid:22, name:=, nfail:*, duration:* Jan 8 06:06:57 latitude blacklistd[14144]: check: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 8 06:06:57 latitude blacklistd[14144]: found: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 8 06:06:57 latitude blacklistd[14144]: conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*, nfail:3, duration:180 Jan 8 06:06:57 latitude blacklistd[14144]: conf_apply: to: target:192.168.134.3:22, proto:6, family:2, uid:22, name:=, nfail:*, duration:* Jan 8 06:06:57 latitude blacklistd[14144]: conf_apply: result: target:192.168.134.3:22, proto:6, family:2, uid:*, name:*, nfail:3, duration:180 Jan 8 06:06:57 latitude blacklistd[14144]: Applied address 192.168.134.1:22 Jan 8 06:06:57 latitude blacklistd[14144]: check: target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:* Jan 8 06:06:57 latitude blacklistd[14144]: conf_amask_eq: a1: c0a88601 != a2: c0a88663 [0x] Jan 8 06:06:57 latitude blacklistd[14144]: Applied address 192.168.134.1:22 I followed the logic of your patch, it appears OK to me. So it's not a documentation error as I was thinking but indeed a bug. While not being a security issue as such, it's kind of scary, as it might leave ports open unnecessary. Also this should probably be backported upstream to NetBSD. What I still don't understand however is why the netmask can be FSTAR at all? What is the point? I can't follow the semantics. Why would we want to compare an incoming IP address (with implied /32 mask) to a template with an "unknown" netmask? I suspect a proper fix might involve setting it to 32 (or 128 in the IPv6 case) right away if no mask is specified? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243164] blacklistd not handling masks correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164 --- Comment #7 from Conrad Meyer --- (In reply to Helge Oldach from comment #6) Thanks for testing it out. > So it's not a documentation error as I was thinking but indeed a bug. Yep. Nice find! > What I still don't understand however is why the netmask can be FSTAR at all? > What is the point? I can't follow the semantics. Why would we want to compare > an > incoming IP address (with implied /32 mask) to a template with an "unknown" > netmask? I suspect a proper fix might involve setting it to 32 (or 128 in the > IPv6 case) right away if no mask is specified? I completely agree. I'm also not exactly in love with the custom file format (with ad-hoc C parser and no formal grammar) and suggested just using UCL or JSON to Kurt a few years ago, but he was opposed at the time. (IIRC he had indicated plans to use a formal grammar for the existing format, at least, but never got to it.) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243175] Several ports pkgs require clang-9.0.1 to build properly but cc on 11.3-stable is clang-8.0.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243175 Bug ID: 243175 Summary: Several ports pkgs require clang-9.0.1 to build properly but cc on 11.3-stable is clang-8.0.1 Product: Base System Version: 11.3-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: j...@iki.fi Several ports pkgs need clang-9.0.1 to build properly but cc on 11.3-stable is clang-8.0.1. Either the ports pkgs (e.g. gdal, ffmpeg, ...) should be changed to explicitly require clang90 or 11.3 base system should be upgraded to use clang-9.0.1 by default. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243164] blacklistd not handling masks correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164 --- Comment #8 from Helge Oldach --- (In reply to Conrad Meyer from comment #7) > I'm also not exactly in love with the custom file format (with ad-hoc > C parser and no formal grammar) Yes, and there are also potential bugs in that hand-rolled parser. Some time ago I have stumbled over IPv6 address/netmask: [2001:679:2807:60::]/64:ssh stream * * * * * versus [2001:679:2807:60::/64]:ssh stream * * * * * Only the first case works well, the second case however is silently accepted without throwing an error, but doesn't work. This should probably be documented. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243177] Enhancement request: O_CREATFIFO flag for open(2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243177 Bug ID: 243177 Summary: Enhancement request: O_CREATFIFO flag for open(2) Product: Base System Version: 12.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rfg-free...@tristatelogic.com The open(2) system call supports a number of optional flags which may be used to control the exact semantics of the open() operation. Among these is O_CREAT which can be used to atomically create the specified file while effectively, from the userland point of view, simultaneously and uninterruptably creating the file. The addition of the O_CREAT optional flag to the set of optional flags supported by open(2) was made decades ago in recognition of the fact that certain very troublesome race conditions could arise in userland programs in cases where the creation of a file and the opening of that same file might be performed non-atomically. The exact same problem exists in the case where the file to be opened and created happens to be a POSIX FIFO file (POSIX 1003.1b-1993, Section 5.4.2.2.) however in this case it is currently necessary to make two separate, and therefore interruptable system calls (to mkfifo() and open()) in order to effect the creation and opening of a POSIX FIFO file, thus permitting troublesome race conditions of the kind that the O_CREAT flag for open(2) was created and implemented to eliminate. The obvious solution is the addition a new option flag for the open(2) system call, analogous to the already existing O_CREAT flag, which will have the effect of both creating AND opening a POSIX FIFO file in a manner that is atomic and uninterruptable from the point of view of userland processes. I would suggest the name O_CREATFIFO for this new flag, but any reasonable symbolic name will do, provided that the semantics implied are the atomic creation and opening of a FIFO file. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
