Re: CVS commit: src/common/lib/libc/string
Hello, "Joerg Sonnenberger" wrote: |Module Name: src |Committed By: joerg |Date: Mon Apr 14 18:18:58 UTC 2014 | |Modified Files: | src/common/lib/libc/string: bcopy.c | |Log Message: |Using bcopy/memcpy with NULL arguments is valid as long as the size is |also 0. This is great interface design and easy to use, but it is not specified in neither POSIX nor ISO C (11). And worse i'm afraid that the ISO C people would actively veto this very behaviour given that wmemcpy(3) is standardized as If n is zero, the application shall ensure that ws1 and ws2 are valid pointers, and the function shall copy zero wide characters. --steffen
Re: CVS commit: src/common/lib/libc/string
P.S.: i wasn't subscribed to this list (until hopefully now), so i haven't seen that Alan Barrett already commented. But now that i read it, ISO C 2011 states the same (7.24.1). --steffen
Re: CVS commit: src/sys/kern
"Maxime Villard" wrote:
|Module Name: src
|Committed By: maxv
|Date: Tue Jun 24 07:28:23 UTC 2014
|
|Modified Files:
| src/sys/kern: subr_kmem.c
|
|Log Message:
|KMEM_REDZONE+KMEM_POISON is supposed to detect buffer overflows. But it only
|poisons memory after kmem_roundup_size(), which means that if an overflow
|occurs in the page padding, it won't be detected.
|
|Fix this by making KMEM_REDZONE independent from KMEM_POISON and making it
|put a 2-byte pattern at the end of each requested buffer, and check it when
|freeing memory to ensure the caller hasn't written outside \
|the requested area.
Interesting.
Having no idea of kernel programming i blindly assume that those
pages are somehow isolated against "preceeding pages", so that no
checks of the lower bound are necessary or even useful, and of
course checking wether the address as such can be safely accessed
is also not necessary / done differently.
But, whereas i really think it is a smart idea to use
a mathematically verifieable pattern, how can you be sure that the
pattern doesn't generate values which are extremely common,
especially at E-O-B, such as '\0'? Shouldn't at least 0 be
replaced with a different value?
(I always used fixed patterns for that, e.g., for S-nail i have
a mix of regular and irregular bit patterns:
if (__xl.p_ui8p[0] != 0xDE) __i |= 1<<0;\
if (__xl.p_ui8p[1] != 0xAA) __i |= 1<<1;\
if (__xl.p_ui8p[2] != 0x55) __i |= 1<<2;\
if (__xl.p_ui8p[3] != 0xAD) __i |= 1<<3;\
if (__xl.p_ui8p[4] != 0xBE) __i |= 1<<4;\
if (__xl.p_ui8p[5] != 0x55) __i |= 1<<5;\
if (__xl.p_ui8p[6] != 0xAA) __i |= 1<<6;\
if (__xl.p_ui8p[7] != 0xEF) __i |= 1<<7;\
if (__i != 0) {\
(BAD) = TRU1;\
alert("%p: corrupt lower canary: 0x%02X: %s, line %u",\
__xl.p_p, __i, mdbg_file, mdbg_line);\
}\
though i guess havin 0xAA first is even better here.)
--steffen
Re: CVS commit: src/sys/kern
Maxime Villard wrote: |That was in my TODO list, it's fixed in r1.59. Oh please, did you hear me complain? It is NetBSD in the end. (Cute :->) --steffen
Re: CVS commit: src/sys/kern
Maxime Villard wrote: |Le 03/07/2014 15:59, Steffen Nurpmeso a écrit : |> |> Maxime Villard wrote: |>|That was in my TODO list, it's fixed in r1.59. |> |> Oh please, did you hear me complain? |> It is NetBSD in the end. |> (Cute :->) | |What do you mean? Scratch the first two sentences of mine. --steffen
Re: CVS commit: src/lib/libc/stdio
|Module Name: src |Committed By: christos |Date: Mon Sep 29 14:58:33 UTC 2014 | |Modified Files: | src/lib/libc/stdio: printf.3 vsnprintf.c vsnprintf_ss.c | |Log Message: |Return EOVERFLOW like FreeBSD does if the buffer size exceeds INT_MAX |(well FreeBSD documents INT_MAX + 1, but in the code it is INT_MAX). I would "pull up" that. (Just in case i get 6.1.4 installed and then - later - upgraded.) (And also i would place a link to the current pull-ups (to the wiki) on www.netbsd.org/developers/releng/pullups.html, since Google shows the latter first, yet that is astonishing empty.) --steffen
Re: CVS commit: src/lib/libc/stdio
Martin Husemann wrote: |On Mon, Sep 29, 2014 at 08:29:10PM +0200, Steffen Nurpmeso wrote: |> (And also i would place a link to the current pull-ups (to the |> wiki) on www.netbsd.org/developers/releng/pullups.html, since |> Google shows the latter first, yet that is astonishing empty.) | |Can you say that again, please? Not being able to get to the list of pull-ups from that page, or at least getting a hint of where to find them is... a mistake. --steffen
Re: CVS commit: src/lib/libc/stdio
Martin Husemann wrote: |On Mon, Sep 29, 2014 at 09:35:04PM +0200, Steffen Nurpmeso wrote: |> Not being able to get to the list of pull-ups from that page, or |> at least getting a hint of where to find them is... a mistake. | |I wouldn't call it a mistake (though links certainly can be added) - |that page documents something completely different. And I'm also not |sure how usefull the queue (open tickets) or the list of resolved |tickets would be. Can be added, right. Should be added for those who are not familiar with internals, since such a person is pretty lost. E.g., there are Sushi let me say artists which can prepare a fish in such a way that she or he is still breathing whereas anything behind the head is prepared for eating. By non-vegetarians, that is. Christs may also ask if all that is necessary if there is Jesus? |What would be really usefull would be a link in the source-changes email, |pointing to cvsweb (or whatever), and that showing pullup state for each |individual source change ;-) I finally found a project that uses the automatic notification mechanism that i thought (long ago that) OpenBSD implemented for maintaining their plus.html: Crux Linux commit messages can be tagged for at least security notifications, which then get mailed out automatically. (On the other hand it is quite boring, chromium, firefox, flash-player, php, dhcpcd ... the usual suspects.) |Another topic, slightly orthogonal, is: how can we improve the google |hits for various of the dynamic pages on releng.netbsd.org. That is beyond my understanding. --steffen
Re: Leak Sanitizer - how to suppress leaks
Warner Losh wrote in : |On Thu, Sep 12, 2019, 7:24 PM Simon Burge <[1]sim...@netbsd.org[/1]> wrote: | | [1] mailto:sim...@netbsd.org | ||Kamil Rytarowski wrote: | ||> I will revert it, but I am looking for a more generic approach. ||> ||> How about adding ifdef __NO_LEAKS like: ||> ||> #ifdef __NO_LEAKS ||> free(3)? ||> #endif ||> ||> And in lsan/asan/valgrind/etc checks use -D__NO_LEAKS. | ||Sorry if I'm missing something that has been already explained, ||but why (practically) do we care about memory leaks for a utility ||that is about to finish? | ||If we're doing some ugly #ifdef dance only when running the ||sanitiser(s), then we haven't actually done anything to "fix" ||the leak in the installed binaries so it seems that there was ||no practical problem that we were trying to solve in the first ||place. | |When multiple people are doing leak busting, maybe over years, they \ |eliminate many false positives so you can focus on the real issues \ |w/o a run time penalty. Especially something in the library that |comes up often... otherwise they get in the way of making progress... Also overall i found it results in better design. I had atexit and atexit_final and with debug enabled _start could call (in-library) main several times in a row without causing leaks or any other problems, since anything would have been correctly destructed. (Not using constructor or destructor nor any other ELF attributes.) It is much nicer to see "Memory cache is entirely empty.", than not. Imho. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/libexec/httpd
Jared McNeill wrote in
:
|On Sat, 12 Sep 2020, Olaf Seibert wrote:
|
|> bozohttpd: add .m4a and .m4v file extensions.
|
|I don't think audio/mpeg is correct for .m4a. Since .m4a is MPEG audio in
|an MP4 container, I would follow RFC 4337 ("MIME Type Registration for
|MPEG-4") here which says you should use audio/mp4 instead.
audio/mp4 mp4 mp4a m4a m4b
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: CVS commit: src/sys/kern
David Young wrote in <20191107155806.gl1...@pobox.com>: |On Thu, Nov 07, 2019 at 04:26:51PM +0100, Martin Husemann wrote: |> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote: |>> On 07.11.2019 14:25, Valery Ushakov wrote: .. |I think the problem is that if you have the series of statements, | |element_t *e = &s->element; | |if (s == NULL) |return; ... |There is probably an argument to be made that in a |segmented/tagged/capability architecture that has run C programs |(8086; Burroughs Large Systems) or may run them in the future (CHERI), |&(NULL)->element cannot sensibly be computed. You mean they will render any non-compiler-builtin approach to create field_offsetof() and field_sizeof() impossible. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/share/tmac
Valeriy E. Ushakov wrote in <20191223201734.0e415f...@cvs.netbsd.org>: |Module Name: src |Committed By: uwe |Date: Mon Dec 23 20:17:33 UTC 2019 | |Modified Files: | src/share/tmac: doc2html | |Log Message: |Fix if/else syntax in previous. What was wrong with that? . ie 'utf8'\*[.T]' \ . ds mx:istty . el .ie 'latin1'\*[.T]' \ . ds mx:istty . el .ie 'ascii'\*[.T]' \ . ds mx:istty . el .ie 'pdf'\*[.T]' \ . mx:dump-init-pdf . el .ie 'html'\*[.T]' \ . mx:dump-init-html . el \ . rm mx:gogogo is perfectly valid roff code. |To generate a diff of this commit: |cvs rdiff -u -r1.69 -r1.70 src/share/tmac/doc2html --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/share/tmac
Valery Ushakov wrote in <20191223222133.gj24...@pony.stderr.spb.ru>: |On Mon, Dec 23, 2019 at 22:13:23 +0100, Steffen Nurpmeso wrote: |> Valeriy E. Ushakov wrote in <20191223201734.0e415f...@cvs.netbsd.org>: |> |>|Modified Files: |>| src/share/tmac: doc2html |>| |>|Log Message: |>|Fix if/else syntax in previous. |> |> What was wrong with that? |> |> . ie 'utf8'\*[.T]' \ |> . ds mx:istty |> . el .ie 'latin1'\*[.T]' \ |> . ds mx:istty |> . el .ie 'ascii'\*[.T]' \ |> . ds mx:istty |> . el .ie 'pdf'\*[.T]' \ |> . mx:dump-init-pdf |> . el .ie 'html'\*[.T]' \ |> . mx:dump-init-html |> . el \ |> . rm mx:gogogo |> |> is perfectly valid roff code. | |Try running it with warnings (-ww), as the build process does. You'll |get | |warning: unbalanced .el request | |Consider | | .ie '\*(.T'ascii' .ds html-charset US-ASCII | .el .ie '\*(.T'latin1' .ds html-charset ISO-8859-1 | .el .ie '\*(.T'utf8' .ds html-charset UTF-8 | .el .ab unsupported encoding \*(.T | |executed with -Tascii. | |Troff reads .ie and checks the condition. The condition is true and |so the rest of the line is executed. Then troff reads .el that |matches successful .ie, so the .el is discarded. | |Then it reads .el which is not matched with any .ie that troff has |seen. It's usually silently discarded, but since we run with -ww we |get the warning about an unbalanced .el | |The the same happens again for the next .el, the number of warnings |depends on which .ie in the chain was successful (no warnings for |utf-8, 1 warning for latin1, two for ascii). Interesting. You are right. Never encountered that, i have to change some macros of mine! A nice Christmas i wish! Ciao from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/share/tmac
Robert Elz wrote in <18872.1577152...@jinx.noi.kre.to>:
|Date:Mon, 23 Dec 2019 23:45:34 +0100
|From: Steffen Nurpmeso
|Message-ID: <20191223224534.8ufgy%stef...@sdaoden.eu>
|
|
|||Troff reads .ie and checks the condition. The condition is true and
|||so the rest of the line is executed. Then troff reads .el that
|||matches successful .ie, so the .el is discarded.
|||
|||Then it reads .el which is not matched with any .ie that troff has
|||seen. It's usually silently discarded,
|
|That is what is (always was) intended to happen.
|
|||but since we run with -ww we
|||get the warning about an unbalanced .el
|
|That's a broken warning. The code in a "discarded" .el needs to be
|examined anyway (if it weren't, the \{ \} block to group the code
|together wouldn't work, and when doing that, it can easily notice an
|embedded .ie (it must be immediately after the .el so looking for it is
|not hard) which will require another matching .el, and make sure that
|things are correctly balanced. That would be a useful wraning.
|
|The
| .ie
| .el .ie
| .el .ie
| .el
|
|idiom has been used in troff (including by troff's authors) forever.
Forever, me too. It is the very first groff commit of James Clark
which added that behaviour (1991-06-02 04:20:34 -0500). Other
than that i do not think it is a broken warning, my mailer for
example simply bails with error if the if conditional stack is
empty, so broken is possibly that the warning only happens with
-w, and not by default.
|Deciding to make that improper now, just because someone who doesn't
|understand, or cannot work out how to handle it correctly, is absurd.
|
|Perhaps (originally) the ".el .ie" combination could have been made
|a macro of its own, it should really be treated as if it were (like
|the "elif" word in sh), but adding more code to process another macro,
|just to save (what would be) 3 input bytes per use wouldn't really
|have been justifiable.
Maybe the warning should really simply be removed, or only occur
if explicitly requested, i.e., remove the "el" warning bit from
the "all" level, just as is already done for some others; i guess
that would be the best.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: CVS commit: src/share/tmac
Robert Elz wrote in <11416.1577299...@jinx.noi.kre.to>: |Date:Wed, 25 Dec 2019 18:06:39 +0100 |From: Steffen Nurpmeso |Message-ID: <20191225170639.ddhqn%stef...@sdaoden.eu> | || Maybe the warning should really simply be removed, or only occur || if explicitly requested, i.e., remove the "el" warning bit from || the "all" level, just as is already done for some others; i guess || that would be the best. | |Not really, a truly unmatched .el (the common cause is | | .if ... | .el ... | |) truly is an error, and a warning for that case is entirely |reasonable. What's broken is generating it because of a chain |of .ie / .el .ie / .el .ie / .el | |Each .ie needs a matching .el whether or not the .ie is actually |executed. The warning occurs on "if stack is empty" condition. This was my impression after doing a grep and having a short completely context free look at the code, of course. Other than that you are of course right. |kre --End of <11416.1577299...@jinx.noi.kre.to> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/common/lib/libc/arch/x86_64/string
Sorry for answering out of thread, but the message is long gone.
I just remembered very old x86 code of mine.
More than fifteen years ago it was still faster to go for 32-bit
wide testing when more than 20 bytes had to be compared, and to
redo a short byte loop to work around the fact that the carry flag
stats the wrong byteorder for the matching slot.
Maybe of interest.
|Andrew Doran writes:
|> Hi,
|>
|> Change backed out. Sorry about the disruption.
/// MEMCMP - sir (*)(const void *_ba, const void *_bb, uir _bytes)
#undef FUN
#undef FUN_STR
#define FUN __XX_mem_Compare
#define FUN_STR "sir XXX::Mem::Utils::Compare(const void*,const void*,uir)"
ASSERT_FUNVARS_STR()
NYD_FUNVARS_STR()
.global G(FUN)
.type G(FUN), @function
G(FUN):
pushl %edi
pushl %esi
.if __ALL
GET_GOT()
NYDIN()
.endif
.if SF_DEBUG
movl PICSO(12)(%esp), %eax // _ba
testl %eax, %eax
jnz 1f
ASSERT_CRASH("_ba != NIL")
1:
movl PICSO(16)(%esp), %eax // _bb
testl %eax, %eax
jnz 2f
ASSERT_CRASH("_bb != NIL")
2:
.endif
// load args (_ba, _bb, _bytes)
movl __PICSO(12)(%esp), %esi
movl __PICSO(16)(%esp), %edi
movl __PICSO(20)(%esp), %ecx
cld // forward cried the man from the rear
xorl %edx, %edx // default return
cmpl $20, %ecx // byte loop?
jle 7f
1: // align at least one on ui4 boundary; use a bytewise loop for that
testl $3, %esi
jz 2f
cmpsb
jne 8f // query result (CF)
decl %ecx
jmp 1b
2: // perform a uir loop; does not help us much due to the little endian
// byte order, but gives us at least an equality indication..
// (and is much faster than the byteloop ...)
movl %ecx, %eax // save bytecount
shrl $2, %ecx // >> Register::shift
repz cmpsl
jne 3f
movb %al, %cl // restore rem. bytecount
andl $3, %ecx // max. two bits remain (<= 3)
jz 9f
jmp 7f // to the byte loop please
3: // we have found an unequal slot, but CF aka the result is based on
// the "wrong" byte order. this is not easy to solve, thus simply
// adjust the pointers and the count and restart the byte loop.
// doing so is easier than the other thinkable approaches?
movl $4, %eax // avoid immediate ops..
subl %eax, %esi
subl %eax, %edi
addl %eax, %ecx
7: // byte loop
repz cmpsb
je 9f
8: // have result, calculate it accordingly (edx is still 0)
sbbl %edx, %edx // a -= b+CF --> 0 || -1 (borrow sub)
orb $1, %dl // 1 or still -1
9: // and finalize
movl %edx, %eax // overtake result into eax
.if __ALL
NYDOUT()
UNGET_GOT()
.endif
popl %esi
popl %edi
ret
.size G(FUN), .-G(FUN)
.align 16
// /__XX_mem_Compare
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: CVS commit: src/share/misc
Jason R Thorpe wrote in <20230301040454.c3b17f...@cvs.netbsd.org>: |Module Name: src |Committed By: thorpej |Date: Wed Mar 1 04:04:54 UTC 2023 | |Modified Files: | src/share/misc: acronyms.comp | |Log Message: |Add NHACP (NABU HCCA Application Communication Protocol) NABU is Naturschutzbund Deutschland! (Nature and Biodiversity Conservation Union Germany. [Heck, they loose the Game!]) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/usr.bin/mail
This is fully yours and who am i but "Christos Zoulas" wrote: |Module Name: src |Committed By: christos |Date: Tue Dec 16 19:30:24 UTC 2014 | |Modified Files: | src/usr.bin/mail: cmd3.c extern.h fio.c mail.1 names.c send.c | |Log Message: |Fix various security related issues: | |0001. Do not recognize paths, mail folders, and pipes in mail addresses |by default. That avoids a direct command injection with syntactically |valid email addresses starting with |. | |Such addresses can be specified both on the command line, the mail |headers (with -t) or in address lines copied over from previous |while replying. |Added expandaddr option to explicitly enable this behavior. why does a Christos Zoulas silently wave through this sloppy programmed shit from oss-sec that simply returns from outof() instead of giving any indication on what is going on? Unbelievable. --steffen
Re: CVS commit: src/usr.bin/mail
chris...@astron.com (Christos Zoulas) wrote: |In article <20141217131849.r2prgpje%sdao...@yandex.com>, |Steffen Nurpmeso wrote: |>This is fully yours and who am i but |> |>|Added expandaddr option to explicitly enable this behavior. |> |>why does a Christos Zoulas silently wave through this sloppy |>programmed shit from oss-sec that simply returns from outof() |>instead of giving any indication on what is going on? |>Unbelievable. | |All you have to do is to set a variable to get the previous behavior, |and this is now documented. It is unexpected behavior that a mail |program can run commands on behalf of the user using special syntax. |Just a few weeks ago, we fixed a similar issue in ftp. Why didn't you |complain for that? ftp is completely beyond my horizon except for open/close/mreget. What is expected behaviour. But yes it is better if there are ways to disable it, i also see this now. |I believe that all maintained versions of mail upstream are being |adjusted to comply with this. What's the downside? It seems i'm the last. Missing checks, complete silence, no report at all, e.g. exit status. Bad programs. |Or are you sure that everything that passes addresses to the mail |program command line sanitizes their addresses properly? No, of course not -- except that "validate user input" screams from every wall. Maybe i'm just disappointed. But any environment that passes a string that includes shell meta characters through to whatever else seems broken. Tomorrow BSD Mail / POSIX mailx(1) get a CVE for QoS attacks because of passing through malformed addresses to MTAs that lead to nowhere but cause several process lifetimes and log entries... That doesn't seem right. --steffen
Re: CVS commit: src/lib/libc/time
Hi, "Brian Ginsbach" wrote: |Module Name: src |Committed By: ginsbach |Date: Fri Oct 30 01:49:36 UTC 2015 | |Modified Files: | src/lib/libc/time: strptime.c | |Log Message: |Reject timezone offsets more than 12 hours (east or west). i saw this, but i definetely remember offsets of 12:30 plus (and then websearch and still true (i no longer have tz.git, on the new box; yes, noone cares)). So these would be rejected with this commit? --steffen
Re: CVS commit: src/lib/libc/time
Paul Goyette wrote: |Just to show how complicated the subject of timezones really is, here |are a couple of interesting quotes from the wikipedia article on |International Date Line Oh i'm prowd of my Timezone, but the code which uses this clean thing is one of the worst things. I haven't seen the thread on -d, which won't see this message either. Sorry. (E.g., Gmane -d via HTTP ends on October 21st!) But good the code ends up aligned to RFC 3339. Ciao, --steffen
Re: CVS commit: src/lib/libc/net
oops, of course ?0[sdaoden@wales]$ git grep IS_ASCII_ master master:modules/dns/config.h:#define _IS_ASCII_PRINTABLE(CHAR) ((CHAR) > 0x20 && (CHAR) < 0x7F) master:modules/dns/config.h:#define _IS_ASCII_ALNUM(CHAR) (_IS_ASCII_ALPHA(CHAR) ||_IS_ASCII_DIGIT(CHAR)) master:modules/dns/config.h:#define _IS_ASCII_ALPHA(CHAR) ( ((CHAR) >= 0x41 && (CHAR) <= 0x5A) \ master:modules/dns/config.h:#define _IS_ASCII_DIGIT(CHAR) ((CHAR) >= 0x30 && (CHAR) <= 0x39) --steffen
Re: CVS commit: src/lib/libc/net
Erik Fair wrote:
|So, what did we do by default: allow “_” in hostnames when that’s exp\
|licitly against standard, or not? I read the patch in the PR and coul\
|dn’t make heads or tails of it.
fwiw i don't think this is generally true, my own one has
a DNS::verifyName() and that does
// find label border, if any
#if(_ASSUME_LONG)
wbuf = s(char*,Mem::Utils::find(_dname, _DOT, _dnamelen));
llen = (wbuf ? s(ui32,wbuf-_dname) : _dnamelen);
#else
for(wbuf=_dname, llen^=llen; llen < _dnamelen; ++llen)
if(*(wbuf++) == _DOT)
break;
#endif
if(!llen || llen > 63)
goto jesll;
[and]
// 1033, 1034, 2929 (3.3): rather anything (printable ASCII)
[these numbers are RFCs, vnm_ is enum DNS::VerifyNameMode:
vnm_none= 0,// boundary checks only
vnm_boundary= vnm_none,
vnm_dname = 1,// printable ASCII
vnm_hostname= 2,// hostname acc. RFC 1035 + 1123, 2.1
vnm_srv = 3,// vnm_hostname plus _ label start
]
case vnm_dname:
while(llen--) {
ui8 c = s(ui8,*(wbuf++));
if(!_IS_ASCII_PRINTABLE(c))
goto jeill;
}
break;
// hostname acc. 1035:2.3.1, 1123:2.1
[these numbers are RFCs]
case vnm_hostname:
case vnm_srv:
// may start with letter or digit (latter 1123, 2.1)
if(!_IS_ASCII_ALNUM(wbuf[0]))
// t_srv may start with underscore (RFC 2782)
if(_vnm != vnm_srv || wbuf[0] != _UNDERSCORE)
goto jeill;
// may consist of letters, digits and hyphen
while(s(si32,--llen) > 0) {
charc = *(++wbuf);
if(c != _HYPHEN && !_IS_ASCII_ALNUM(c))
goto jeill;
}
// but may end with letter or digit only
if(wbuf[0] == _HYPHEN)
goto jeill;
break;
} // switch(_vnm)
and then
?0[sdaoden@wales ]$ git grep IS_ASCII_PRI master
master:modules/dns/config.h:#define _IS_ASCII_PRINTABLE(CHAR) ((CHAR) > 0x20
&& (CHAR) < 0x7F)
So vnm_srv does regulary allow underscore as in
/*!
* \var vnm_srv
* Boundary check (#vnm_none) plus content verification.
* This is exactly like #vnm_hostname,
* but additionally allows a label to start with an underscore ("_").
* RFC 2782 introduced the use of underscores as a leading character for
* service and protocol names to reduce accidental clashes,
* and thus we support them as required.
* Note however that this check is stupid
* in that \e all labels are allowed to start with underscores \ldots
*/
Oh, it seems not to be completely correct, unfortunately. I think
i should stop tracking -d again.
--steffen
Re: CVS commit: src/lib/libc/net
Robert Elz wrote: |Which standard? RFC 1035 2.3.1 defines hostnames. |ps: do go read section 11 of rfc2181 while you're pondering all of this. I think RFC 6895 would then be for the better: 3.3.1. Label Types At the present time, there are two categories of label types: data labels and compression labels. Compression labels are pointers to data labels elsewhere within an RR or DNS message and are intended to shorten the wire encoding of NAMEs. The two existing data label types are sometimes referred to as Text and Binary. Text labels can, in fact, include any octet value including zero-value octets, but many current uses involve only printing ASCII characters [US-ASCII]. For retrieval, Text labels are defined to treat ASCII uppercase and lowercase letter codes as matching [RFC4343]. Binary labels are bit sequences [RFC2673]. The Binary Label type is Historic [RFC6891]. Thank you. --steffen |ps: do go read section 11 of rfc2181 while you're pondering all of this. For my own taste all those other RFCs from all those honorable people are not outweighed by a single sentence of an RFC that otherwise pushes forward that completely refusable DNSSEC system that i personally did not implement consciously back in 2004+. And even a thousand more IETF announcements which read something like "DNSSEC now enters widespread usage [and here is another one which aids in supporting another part of the game]" won't change that. Instead i'm personally thrilled by draft-ietf-dnsop-5966bis, and then on top of TLS and a library which gets used a billion times a time. But anyway the second half of that sentence.
Re: CVS commit: src/usr.bin
Christos Zoulas wrote in : |In article <20180724185738.ga15...@britannica.bec.de>, |Joerg Sonnenberger wrote: |> |>Why do we need another base64 encoder/decoder? | |So I've been looking into how to get rid of it and re-use uuencode |uudecode for it and it is proving difficult. I am trying to provide |a command line compatible utility with the "base64" command from |MacOS/X and Linux: | |- They use a single command to encode and decode (uuencode and decode | are two separate programs). I would have to either write a shell | script front end (and modify them not to output a header) to be | able to emulate that. |- uudecode is using b64_pton() which does not handle arbitrary whitespace. To me the difference in between "openssl base64" and Linux base64 is that the latter can deal with invalid base64, as is indeed not uncommon in mail message parts. MUAs like mutt (or my one) can deal with this, but they of course operate in the MIME surroundings. For example, comparing busybox base64 and NetBSD base64.c from yesterday (after getting rid of __dead and getprogname()): #?0[steffen@essex tmp]$ base64 -d is deprecated tcc: Decoding failed 13 This is caused by an exclamation mark at the end of the first line, which is 990 bytes. (The data is an excerpt from a mail that has been sent to IANA tz in April 2015.) In comparison, complete frustration with LibreSSL and OpenSSL: #?0[steffen@essex tmp]$ openssl base64 -d
Re: CVS commit: src/doc
Hello, Sevan Janiyan wrote in <20180806224530.0eb41f...@cvs.netbsd.org>: |Module Name: src |Committed By: sevan |Date: Mon Aug 6 22:45:29 UTC 2018 | |Modified Files: | src/doc: 3RDPARTY | |Log Message: |Update current version info for IANA services & protocols databases. | |heads up by | |To generate a diff of this commit: |cvs rdiff -u -r1.1537 -r1.1538 src/doc/3RDPARTY | |Please note that diffs are not public domain; they are subject to the |copyright notices on the relevant files. | --End of <20180806224530.0eb41f...@cvs.netbsd.org> For your possible interest, for CRUX-Linux i have adjusted a script from Gaetan Bisson of ArchLinux which works with plain awk and updates protocols and services to the current version. (Because the full list of especially services is _very_ large, much larger than what the BSDs have, for example, and also changes pretty frequently.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) iana-etc-update.sh Description: Bourne shell script
Re: CVS commit: src/lib/libcurses
Roy Marples wrote in <20181005115905.8d52ef...@cvs.netbsd.org>: |Module Name: src |Committed By: roy |Date: Fri Oct 5 11:59:05 UTC 2018 | |Modified Files: | src/lib/libcurses: newwin.c refresh.c | |Log Message: |curses: allow drawing the lowest right hand cell of the terminal | |This is a historical behaviour that needs fixing |If any terminal does scroll when drawing in the lowest right hand cell |of the terminal then an entry should be made in the terminfo database |(currently there is no standard code) to state that and define 'im' and 'ei'? |__SCROLLWIN as before. | |Fixes PR# 30978. | | |To generate a diff of this commit: |cvs rdiff -u -r1.52 -r1.53 src/lib/libcurses/newwin.c |cvs rdiff -u -r1.88 -r1.89 src/lib/libcurses/refresh.c | |Please note that diffs are not public domain; they are subject to the |copyright notices on the relevant files. | --End of <20181005115905.8d52ef...@cvs.netbsd.org> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/lib/libcurses
Roy Marples wrote in <7148ef5a-b17d-f7b3-e58e-3c200a1e1...@marples.name>: |On 05/10/2018 13:52, Steffen Nurpmeso wrote: |> Roy Marples wrote in <20181005115905.8d52ef...@cvs.netbsd.org>: |>|Module Name: src |>|Committed By: roy |>|Date: Fri Oct 5 11:59:05 UTC 2018 |>| |>|Modified Files: |>| src/lib/libcurses: newwin.c refresh.c |>| |>|Log Message: |>|curses: allow drawing the lowest right hand cell of the terminal |>| |>|This is a historical behaviour that needs fixing |>|If any terminal does scroll when drawing in the lowest right hand cell |>|of the terminal then an entry should be made in the terminfo database |>|(currently there is no standard code) to state that and define |> |> 'im' and 'ei'? | |Enter insert Mode and exit insert mode have no relation to this. No automatic cursor advancement in insert mode allows doing something in the very last cell of the screen. (Normally.) --End of <7148ef5a-b17d-f7b3-e58e-3c200a1e1...@marples.name> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: PR/30978 CVS commit: src/lib/libcurses
Valery Ushakov wrote in <20181006033501.8e3407a...@mollari.netbsd.org>: |The following reply was made to PR lib/30978; it has been noted by GNATS. | |From: Valery Ushakov |To: gnats-b...@netbsd.org |Cc: |Subject: Re: PR/30978 CVS commit: src/lib/libcurses |Date: Sat, 6 Oct 2018 06:32:00 +0300 | | On Sat, Oct 06, 2018 at 04:19:43 +0300, Valery Ushakov wrote: | |> As I expected the new curses is broken with TERM=sun. Emitting that |> character into the lower-right corner causes the line to wrap and, |> consequenly, the screen contents to scroll up, messing up the display. | | IIRC the common hack^Wsolution for this is to use insertion, either | smir/rmir or ich1 (or ich). But careful, in my sources i find that cons25 makes problems with this, so there may be buggy consoles which state they can insert, but fail to do the right thing nonetheles. | E.g. the following will print "AZ" at the lower-right corner on both | TERM=vt100 and TERM=sun | | tput clear | | # this is intended to be in the lower right corner | # but emit it one column before | tput cup $(expr $LINES - 1) $(expr $COLUMNS - 2) | echo -n Z | sleep 5 | | # re-emit the character that was overwritten by the above | # shifting 'Z' to its target position at the lower right corner | tput cup $(expr $LINES - 1) $(expr $COLUMNS - 2) | tput smir# enter insert mode - nop is not present | tput ich1# insert 1 character - nop is not present | echo -n A | tput rmir# end insert mode - nop is not present | | tput cup 0 0 | sleep 5 | | Presence of :xn:LP: in termcap just tells you that you can avoid this | song and dance and just write to the lower-right corner directly, so | it's a micro-optimization and if these capabilities are not present, | the display will still be correct at the cost of a few more bytes sent | to the terminal. It is anything but a micro-optimization, really. Handling of lowermost-rightmost is a pain for your bu.ho.e. Ciao, and a nice weekend. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/sys/kern
Manuel Bouyer wrote in <20181203183537.ga1...@antioche.eu.org>: |On Mon, Dec 03, 2018 at 12:54:26PM +0100, Maxime Villard wrote: |> In other words, 80% of KASLR is enabled by default, regardless of #ifdef |> KASLR. Therefore, it is wrong to add an ifdef, because in either case we | |So there's no way to completely disable KASLR now ? |Although I admit it's usefull to have it on by default, there should \ |be a way |to turn it off for low-level debugging As an idiot from user space only: why is layout randomization still something desirable now that kernel and user address space is totally, cleanly and completely separated, and caches etc. are flushed upon context-switches and system calls? It is like that, right? Also, i was always curious whether there were any runtime costs implied due to the massive splitting of object files, i wondered whether that negatively affects the cache "hotness" in any way. As a programmer i always tried to keep things as compact as possible. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/doc
Christos Zoulas wrote in <20190108184053.e22c1f...@cvs.netbsd.org>: |Module Name: src |Committed By: christos |Date: Tue Jan 8 18:40:53 UTC 2019 | |Modified Files: | src/doc: 3RDPARTY | |Log Message: |- put all the GPLv3 software together |- put all the Last GPLv2 version software at the end. |Perhaps it is better to use separate files (per license) at this point? The current version of groff is 1.22.4. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/lib/libc/time
Taylor R Campbell wrote in <20221023170035.2542f60...@jupiter.mumble.net>: ... |If you use a monotonic timer to sample the POSIX clock before and |after a leap second, the POSIX clock will appear to have taken twice |as long as it should to pass the leap second. Just to note that the next leap second could be a negative one. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/doc
Nia Alarie wrote in <20230629214647.db217f...@cvs.netbsd.org>: |Module Name: src |Committed By: nia |Date: Thu Jun 29 21:46:47 UTC 2023 | |Modified Files: | src/doc: CHANGES | |Log Message: |ch-ch-changes station to station --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/external/historical/nawk/dist
Christos Zoulas wrote in
<20240721194847.c8c05f...@cvs.netbsd.org>:
|Module Name: src
|Committed By: christos
|Date: Sun Jul 21 19:48:47 UTC 2024
|
|Modified Files:
| src/external/historical/nawk/dist: lib.c
|
|Log Message:
|PR/58421: RVP: fix readdir on tmpfs. Upstream merge is complicated \
|now because
|the bsd branch has not been updated in ages.
Hmm, is this the "real" aka Kernighan's nawk? Then upstream now
is at https://github.com/onetrueawk/awk.git, with Aharon Robbins
of Gawk having spent lots of time on it, and Kernighan himself
adding some UTF-8 support (which, pssst, had quite some bugs fixed
by Robbins and Millert as of sudo aka OpenBSD), and i maintain
a package for the BSD branch, which is up-to-date, via
name=nawk
version=20240623-bsd
realn=awk
gitver=9f971fba471ba561af661694ea55769b2b914988
release=1
source=(https://github.com/onetrueawk/${realn}/archive/${gitver}/${realn}-${version}.tar.gz)
build() {
cd ${realn}-${gitver}
# Fix term sequence mess in "box-ports -> fakeroot pkgmk" container
sed -Ei'' 's/^YACC .+$/YACC = bison -d --color=no/' makefile
make
install -D a.out "${PKG}"/usr/bin/${name}
install -D -m 0644 awk.1 "${PKG}"/usr/share/man/man1/${name}.1
}
--End of <20240721194847.c8c05f...@cvs.netbsd.org>
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
| Only during dog days:
| On the 81st anniversary of the Goebbel's Sportpalast speech
| von der Leyen gave an overlong hypocritical inauguration one.
| The brew's essence of our civilizing advancement seems o be:
| Total war - shortest war -> Permanent war - everlasting war
Re: CVS commit: src/distrib/sets/lists/man
Greg Troxel wrote in : |Valery Ushakov writes: | |> On Fri, Aug 16, 2024 at 19:06:15 +0900, Rin Okuyama wrote: |> |>> I've changed mknative-gdb to generate *.info by using makeinfo(1) |>> provided by pkgsrc-2024Q2: |>> |>> https://github.com/IIJ-NetBSD/netbsd-src/compare/master...rokuyama:netbs\ |>> d-src:exp/mknative-gdb-makeinfo |>> |>> Then, pre-generated infos are installed for normal builds. |> |> I haven't looked at the actual code, but as an emacs user I'm obviolsy |> all for shipping the info files. Thanks. | |I also think we should have info files. Not just for emacs, but info(1) |standalone. It is a bug to not build the documentation, even if we have |to work around it needing newer info than base has, if that's what is |going on. Btw *please* do join in upstream bell ringing whenever you can. It has become one "absurdism" of our time that *release tarballs* no longer ship with pre-generated manuals. More and more require superweight build infrastructures. --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS commit: src/lib/libc/time
Valery Ushakov wrote in : |On Fri, Dec 08, 2023 at 01:32:49 +0300, Valery Ushakov wrote: | |> On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote: |> |>> While here, consistemntly use minus when minus is meant, rather that |>> just using a hyphen. |> |> One has to be careful with this. | |And to have this on record for refernce: https://lwn.net/Articles/947941/ 'Could be you like that: https://lists.gnu.org/archive/html/groff/2022-09/msg00048.html (or these https://lists.gnu.org/archive/html/groff/2022-09/msg00053.html https://lists.gnu.org/archive/html/groff/2022-09/msg00057.html heck i could vomit all thread long. :-) |-uwe --End of Ciao. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | | Only in December: lightful Dubai COP28 Narendra Modi quote: | A small part of humanity has ruthlessly exploited nature. | But the entire humanity is bearing the cost of it, | especially the inhabitants of the Global South. | The selfishness of a few will lead the world into darkness, | not just for themselves but for the entire world.
