Re: disable HPN in sshd for the -10 branch?
On May 3, 13:00, Greg Troxel wrote: } mlel...@serpens.de (Michael van Elst) writes: } } > Part of the HPN patches is to optionally strip encryption (and now even } > integrity checks) for the data transfer. Doesn't fit into what } > the OpenSSH people want, not even as an option. } } I would say that doesn't really fit with what we want either, certainly } without somebody really trying. It breaks the rule that using ssh can } count on confidentiality and integrity and makes systems with ssh as a } component harder to reason about. I would say it is something that should be available as an option (likely a command line option). ssh/scp has pretty much completely replaced rsh/rcp (other than for people that go out of their way to use those); however, there are many things that get copied around that are completely public where encrypting them for data transfer is useless overhead. That said you likely still want passwords encrypted and integrity checks. }-- End of excerpt from Greg Troxel
Re: Adding ?
On May 13, 22:37, Joerg Sonnenberger wrote: } On Thu, May 13, 2021 at 09:58:50PM +0200, JaromÃr DoleÄek wrote: } > Le jeu. 13 mai 2021 à 21:44, Joerg Sonnenberger a écrit : } > > > No we don't, unless you are using PCC :D } > > > } > > > The block in only provides an alloca(3) prototype, and only } > > > if the compiler already #defines alloca as __builtin_alloca. } > > > } > > > While this works for gcc in some -std modes (e.g. gnu++14), it does } > > > not in others (c++14, c++11). } > > } > > Your analysis is wrong. We don't provide a prototype in standard modes } > > as that violates the user request. The prototype is enough to trigger } > > the builtin logic in GCC and Clang. } > } > Allright. } > } > Anyway, would it be wrong to add which unconditionally } > makes alloca() use the builtin, similar to what e.g. glibc (Linux) and } > FreeBSD do, or is it fundamentally wrong doing so? } } I don't see the point in it. The source is wrong to request strict C++14 } compatibility and then use an extension. Just because Linux folks do } that wrong doesn't mean we should cater to their bugs. This comment reminds me of Henry Spencer's "All the World's a VAX" comment: https://www.brcline.com/blog/the-ten-commandments-for-c-programmers . In a way, he is correct (adjusted for time of original posting). However, the reality is that Linux sets the standard, whether we like it or not. There are situations where we are going to have to bite the bullet and accept things that are impure. Whether or not this is one of those situations is current subject of debate. }-- End of excerpt from Joerg Sonnenberger
Re: inetd enhancements - config syntax
On Jan 14, 12:21, James Browning wrote: } } >I also don't like the only form of include being include-a-directory; } >in my estimation, that wires too much policy into the mechanism. I } >would prefer to see either two include directives, one for directories } >and one for files, or a single directive that somehow subsumes both. } >(Two ways come to mind immediately. (A) if the argument names a file, } >it's a file include; if a directory, a directory include. (B) to } >include files in a directory, write something like "include dir/*" or } >"include dir/*.conf" or something of the sort. Though there is the } >conflict with a possible service named "include" - perhaps ".include"?) } } We like the idea of being able to include files along with } directories. Our current plan is to implement directories first, } along with files if time permits us. If we don't have time to } implement include-a-file, then we will make sure our include-a-directory } implementation can easily be extended to support fies in the future. You should really start by implementing functionality to include files as that is your base. The way to implement including directories is to stat the item being included to see if it is a directory, and if it is, then branch to a routine that will scan the directory and call the file inclusion routine on each file found (skipping . and .. of course). If the item being included is a file, then simply make a call to the file inclusion routine. It isn't possible to include a directory without also being able to include a file. It is just a matter of properly modularising the code so that the routine to include a file is separate. }-- End of excerpt from James Browning
Re: Waiting for Randot (or: nia and maya were right and I was wrong)
On Jan 15, 0:13, Taylor R Campbell wrote: } } > Date: Thu, 14 Jan 2021 10:15:41 + } > From: nia } } > The man page is very clearly written, aside from the parts that } > recommend tossing coins. } } Thanks! I know tossing coins sounds silly. But as a fallback if you } have no other options, it really is 100% guaranteed to work, it's easy } for anyone to confidently understand, and as a bonus it avoids any } concerns with supply chain attacks on HWRNGs, So that's why I } mention it -- buried near the bottom, as a last resort. Dice would be an excellent fallback too and they have more than one bit. Unless the dice are loaded: https://www.youtube.com/watch?v=zbkizy-Y3qw }-- End of excerpt from Taylor R Campbell
Re: tolower()/islower() and char
On Jan 14, 7:46, Mouse wrote: } } > The standard is explicit that the argument must be EOF or an unsigned } > char. There is no way to support both true 8bit locales and } > magically fix this. } } No way for ctype.h to do so independent of the rest of the system. But } it's not at all hard to fix it from a libc design perspective; you just } need to choose a value for EOF that is out of range for signed char. } } > '\xff' in Latin1 is a letter for example and EOF is not. } } But nothing says (signed char)'\xff' == EOF. } } Nothing except existing practice, that is; the C spec chose (rightly, } IMO) to support existing practice in this regard. } } > I'm still shocked by how many developers have been using C for 20 } > years and still manage to not use ctype.h correctly... } } I've seen worse. I've even corresponded with someone holding the } curious delusion that uncast NULL was suitable as a stdarg pointer Anybody remember PR 34632, where a PHP developer was seriously arguing that they should be able to pass any sort of garbage to a ctype function and they should not get a segfault as a result? } argument, apparently believing that all pointer types had to be } sufficiently similar, at least in an argument list, that this was } possible. } } /~\ The ASCII Mouse } \ / Ribbon Campaign } X Against HTML mo...@rodents-montreal.org } / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B }-- End of excerpt from Mouse
Re: vndconfig vs mount_cd9660
On Dec 28, 22:43, Thomas Klausner wrote: } } I wanted to mount an ISO image (on 9.99.77/amd64), so I did, } following the guide: } } # vnconfig -c vnd0 file.iso } # mount -t cd9660 /dev/vnd0a /mnt } mount_cd9660: /dev/vnd0a on /mnt: Invalid argument I always use "-r", i.e. "# mount -r -t cd9660 /dev/vnd0a /mnt". I don't know if that would be a factor or not, but certainly you're never going to write to a CD image. } # mount -t cd9660 /dev/vnd0d /mnt } mount_cd9660: /dev/vnd0d on /mnt: Invalid argument } } but that didn't work, nor did using vnd0d. } } The disklabel looks unpromising. } } 4 partitions: } #sizeoffset fstype [fsize bsize cpg/sgs] } a: 16868776 0 4.2BSD 0 0 0 # (Cyl. 0 - 8236*) } d: 16868776 0 unused 0 0# (Cyl. 0 - 8236*) } disklabel: boot block size 0 } disklabel: super block size 0 CDs don't have disklabels (unless it is a Sun CD), so that is a fake label. If you did "disklabel -r vnd0" (-r forces a read from disk), it would likely tell you that there isn't a label. }-- End of excerpt from Thomas Klausner
Re: Proposal to remove catman(8)
On Nov 10, 19:28, Kamil Rytarowski wrote:
} On 10.11.2020 12:59, Robert Elz wrote:
} > Date:Tue, 10 Nov 2020 11:14:12 +0100
} > From:Kamil Rytarowski
} > Message-ID:
} >
} > | If you still can find any man-page that is unsupported by mandoc, please
} > | let me know and I will report it.
} >
} > That was done (by someone else, sorry, I have forgotten who that was)
} > earlier in this thread. groff_char(7) Because it is an externally
} > maintained man page, we cannot just alter its format, and I really don't
} > think you're going to convince anyone to make mandoc handle:
} >
} > . di CC
} > . ie c\\$3 \{\
} > .nop \\&\\$3\c
} > .\" The \x values assure that oversized symbols don't
} > .\" overlap vertically. The constant 1.5p is heuristic.
} > .nop \x'(\w'('*0 - ((\\n[.cht]u - \\n[rst]u - 1.5p) >? 0))'\c
} > .nop \x'((\\n[.cdp]u + \\n[rsb]u - 1.5p) >? 0)'\c
} > .nop \h'(\\n[c1]u - \\n[.k]u)'\\*[CH]\c
} > .nop \h'(\\n[c2]u - \\n[.k]u)'\\$2\c
} > . \}
} > . el \{\
} > .nop (N/A)\c
} > .nop \h'(\\n[c1]u - \\n[.k]u)'\\*[CH]\c
} > . \}
} > . nop \h'(\\n[c3]u - \\n[.k]u)'\\$4\c
} > . nop \h'(\\n[c4]u - \\n[.k]u)'\\$5\c
} > . br
} > . di
} >
} > [that's just one piece of a larger macro definition in that page]
} >
} > On the other hand, after a simple
} >
} > groff -man -T ascii /usr/share/man/man7/groff_char.7 \
} > > /usr/share/man/cat7/groff_char.7
} >
} > I now have a man page I can (better anyway) read. If I had the time
} > to read up on all the groff -T options, it would probably be possible
} > yo make something quite readable.
}
} I hope this is a typo, and not the indication that you forgot how to use
} the cat-pages at all and miss a computer to cross-check how these files
} are named. It's not a bad thing to forget how to use them, but I'm
} unsure whether the reason of blocking the removal (post-removal) is an
} optimal motivation for relearning. cat-pages always finish with .0
} (unless compressed) and that way they are integrated into man.conf(5).
There's a popular expression: "When you're in a hole, stop digging."
} Other tools like groff and nroff are around and not intended to be removed.
}
} Personally, I miss ditroff, as I have got some documentation in this
} format that is not formatted promptly with other tools I checked. If
} someone has a good sources of ditroff, I support the import to src/.
You might want to look up Heirloom troff.
} > | Removal of the whole cat-pages support was implied
} >
} > It wasn't.
}
} I wrote:
}
} "I propose to drop the support for MKCATPAGES=yes. catpages are
} preformatted .txt files that happen to contain manual pages and are
} cat(1)able.
}
} Over the past more than 5 years, I was the only person reporting any
} fallout and fixing the regressions in the MKCATPAGES=yes build failures.
}
} I'm going to switch to dynamic manual pages formatting through mandoc(1)
} as superior, allowing to tune the behavior of the display.
} "
}
} I didn't differentiate MKCATPAGES=yes from catpages support. I also
} wrote explicitly to use dynamic manual pages afterward. But I accept
} that I could be ambiguous in the proposal.
As people writing posts, we always know what meaning we intend
to convey. People might misinterpret what we say for a variety of
reasons, such as insufficient command of the language (this goes
both ways), insufficient background information, we were simply
unclear, etc. When multiple competant people don't pickup on the
intended meaning, then it is most likely the latter, which is ALWAYS
the fault of the poster, not the reader. At that point, it behooves
the poster to clarify, and not in any way imply that the reader is
at fault.
} FreeBSD implements it by disabling cat-pages behind the scenes. I find
} this approach waste of time in 2020. It could be maybe tentative in 2011
} when implemented in FreeBSD.
This is completely and utterly irrelevant, we are not FreeBSD.
Just because they take away features, doesn't mean we should. If
they add something that is good, we may choose to adopt it based
on our own standards; however, this has nothing to do with taking
away features.
}-- End of excerpt from Kamil Rytarowski
Re: Proposal to remove catman(8)
On Nov 10, 1:13, Kamil Rytarowski wrote: } On 10.11.2020 01:05, Paul Goyette wrote: } > On Tue, 10 Nov 2020, Kamil Rytarowski wrote: } > } > } >> } >> It's not a selling point to any regular user, born after A.D. 2000 to } >> optimize reading man pages. } > } > Whoa there.=C2=A0 Don't put down us older folks.=C2=A0 And why would you want } > to characterize "regular user" as being "not yet two decades old" ? } } Please relax. I'm older too. The point is with the target audience, e.g. } our GSoC students (who born around A.D. 2000) might not be attracted by } retro-computing, by things that passed away before their date of birth. Overhauling the system to make it attractive to GSOC students is bizarre to say the least. That is a tiny audience and specifically catering to it at the expense of the main audience is not wise. }-- End of excerpt from Kamil Rytarowski
Re: Proposal to drop MKCATPAGES
On Oct 25, 16:22, Thor Lancelot Simon wrote: } On Sun, Oct 25, 2020 at 03:45:56PM -0400, Mouse wrote: } > } > I once had an hp300 with all of 5M of RAM. Years ago, when I had it } > running, thorpej told me it was quite possibly an instance of the } > slowest machine then supported by NetBSD. (Amusingly, at the same time } > I had an alpha that he said was possibly an instance of the fastest.) } } I think -- with the possible exception of the 725 or 730 if anyone ever } made them work, they were very hard to get going even with 4.3! -- the } Sun 2/50 is likely the slowest machine that ever ran NetBSD. I don't think } we support any 68010-based HP300 models, though I am not entirely sure. } } Was the Australian machine kre mentioned one of those bizarre dual-68000 } designs that ran two CPUs in lockstep to handle non-restartable } instructions? I've heard about them but never seen one. If I recall correctly (30 year old memories here), Apollo did that, but I haven't seen/touched one of those in about 30 years. It also had an interesting file system / networking trick where you could do ///... to get at files on a different machine. }-- End of excerpt from Thor Lancelot Simon
Re: wedge device to name
On Sep 18, 2:57pm, Michael van Elst wrote: } } >Is there a reason why we do not translate wedges devices to their name? } >I mean, df and mount report about /dev/dkN, which is not very helpful } >since it can change quickly. Reporting about NAME= seems a better idea. } } >In order to do it, we need a reverse getfsspecname(), and use it everywhere } >reasonable: df mount swapctl raidctl ... other ideas? } } It's not necessarily a good idea to hide the dk devices, so that probably } needs to be an optional output. Also because there are people parsing } such output and expect a device path. We just need the device path to be the name, which it already is for LVMs. This is something that a devfs could do easily. :-> More seriously, I do believe that a devfs would be a good thing. }-- End of excerpt from Michael van Elst
Re: colorls in base
On Feb 17, 10:33am, Christos Zoulas wrote: } On Feb 17, 11:45am, ch...@groessler.org (Christian Groessler) wrote: } | On 2/17/19 5:52 AM, John Nemeth wrote: } | > } We resist also personal taste but aesthetics is also important for } | > } many/most(?) people. For the some reason probably nobody deliberately } | > } watches black-white TV and old valuable movies are now often painted. } | > } | > Many people consider this to be ruining them. } | } | +1 } } Both the original and the colorized versions are available. Colorizing them } opens them to new audiences who would have never seen them otherwise. Why can't new audiences watch them in the original format for which they were designed to be viewed? Movies are a form of art. Should we be changing the colours on a Picasso to match modern tastes? }-- End of excerpt from Christos Zoulas
Re: colorls in base
On Feb 17, 12:52am, Kamil Rytarowski wrote: } On 16.02.2019 20:50, John Nemeth wrote: } > I'm not a no changenik. However, I think change needs to have } > demonstrated value. I do oppose change when it is done for the } > sake of change. To me, fluff is not demonstrated value, especially } > when you consider our market segmen } } That has been explained that colors ship information that cannot be } encoded in a different way on a terminal and has to be prompted with } different commands, tools or arguments to utilities. Nonsense. } We resist also personal taste but aesthetics is also important for } many/most(?) people. For the some reason probably nobody deliberately } watches black-white TV and old valuable movies are now often painted. Many people consider this to be ruining them. }-- End of excerpt from Kamil Rytarowski
Re: colorls in base
On Feb 16, 3:02pm, Christos Zoulas wrote: } In article <20190216102435.ga10...@grapefruit.pr0.tips>, } Timo Buhrmester wrote: } >> All I know is that some directories look like an "explosion in a } >> paint factory" or "angry fruit salad". } >I wonder why the die-hard monochrome users keep arguing from a } >"but it isn't pretty" point of view. It's not supposed to be pretty, } >it's supposed to augment the information presented. } > } >> The colours convey absolutely no information to me. I need to use } >> other information to figure out what the colours are trying to tell } >> me. } >And that's fine and how it's supposed to be. The colors helped drawing } >your attention to it quickly. I don't think anybody here is arguing } >that colors would directly encode high-level diagnostic information. } > } > } >To the color-blind people, I get it, it's counter productive for you. } >However I don't get the feeling that anybody is trying to enable } >colors unconditionally, or by default even. I also have issues with } >the "I can't tell apart colors, so nobody may use colors" mindset. } > } >We shouldn't put up artificial barriers for color-blind people (nor any } >other disability), which in this case would mean "colors, if present, } >shouldn't be enabled by default" (that said, our installer is blue...) } >but that's about the extent of it IMHO. } } Yes, what I don't understand (because nobody has stated a technical } reason other than 'fluff'), why we shouldn't we have the feature in base } at all. Nobody proposed to enable it by default. As features become } standard to other OS's we should evaluate if we should follow suit. I consider this to be a good reason. We shouldn't be adding fluff just so that we can keep up with the Joneses. } Things change over time; we don't go rip out color output compiler } support from the compilers. It is not enabled by default so it is } invisible. So will be having color in some programs in base. It will } be invisible unless you specifically turn it on. I'm not a no changenik. However, I think change needs to have demonstrated value. I do oppose change when it is done for the sake of change. To me, fluff is not demonstrated value, especially when you consider our market segment. } It is not frictionless (and should be but that's another issue) to } "install from pkgsrc" and it's a good question why not have the feature You're right, that's a different question. If it is really problem, then it needs solving, independently of any other question. } in base when the majority of the users just install replacements from } pkgsrc because of the lack of features. It is not 1980 anymore and Who is this "majority" of which you speak? I haven't take a count, but it feels to me that there are less then a dozen people participating in this thread (some of whom are very vocal). } we don't need to be frugal about resources (specially when they can } be compiled out). Compiling out stuff is not free. It takes disk space and large amounts of admin time for on-going maintenance. }-- End of excerpt from Christos Zoulas
Re: colorls in base
On Feb 16, 12:42pm, Timo Buhrmester wrote: } } > Prettiness is the last thing that concerns me, cloaking information with } > gleeful colorized flashlights and blinding me with candy colored dots is. } Sorry, I wasn't aware how messed up cognition can be. Which color } is the most blinding to you? Does the 'cloaking' aspect increase or } decrease with the increase/decrease in intensity/brightness, for } information printed in that particular color? I fail to see how it is possible for people to so completely not "get it". } > You may use colors all day long, it's as simple as installing a color-ls } > program. } That has already been established and is besides the point here. No, it is completely the point. People that want this kind of stuff can easily get it without corrupting the base system. }-- End of excerpt from Timo Buhrmester
Re: colorls in base
On Feb 16, 3:16am, Kamil Rytarowski wrote: } On 16.02.2019 03:03, Christian Groessler wrote: } > On 2/16/19 2:35 AM, Kamil Rytarowski wrote: } >> On 16.02.2019 02:14, m...@netbsd.org wrote: } >>> There's a topic on peace-keeping in a large project. } >>> } >>> There are two types of feedback: } >>> } >>> - "this change makes the code simpler and twice as fast" (it's } >>> =C2=A0=C2=A0 objectively better) } >>> - "I like colorful terminals" (my personal opinion) } >>> } >> I object that this is just 'I like' case, I consider colors as an } >> elementary feature. } > } > Me not. Let's agree to disagree... } } Does it mean that people not interested in music can now prompt for } removing audio support? If they are not interested in it they can move } on and ignore it in their uses-cases. That's easy, I just don't install speakers. On the other hand, having to deal with a Linux box is often a major hassle to do even basic things. I often get difficult to read paint factory explosions and basic things like "ifconfig" have disappeared (every freaking unix-like system I've touched in the last 30 years has had "ifconfig", but now a few NIHs are trying to make it go away). }-- End of excerpt from Kamil Rytarowski
Re: colorls in base
On Feb 16, 2:35am, Kamil Rytarowski wrote: } On 16.02.2019 02:14, m...@netbsd.org wrote: } > There's a topic on peace-keeping in a large project. } > } > There are two types of feedback: } > } > - "this change makes the code simpler and twice as fast" (it's } > objectively better) } > - "I like colorful terminals" (my personal opinion) } } I object that this is just 'I like' case, I consider colors as an } elementary feature. It's more visible in code or text editors as they You can object all you want, but that doesn't change the fact that it is personal preference. } can show you whether the inserted program or config file is well formed } or not. There were also programming languages using them (forthColor) as } a part of syntax. In the ls(1) case it's much easier to spot that there Yeah, so? } is something wrong with a file (like a broken symlink). Actually, it tells me absolutely nothing as I have no clue what the different colours mean (not to mention that colours disappear when output is logged). All I know is that some directories look like an "explosion in a paint factory" or "angry fruit salad". The colours convey absolutely no information to me. I need to use other information to figure out what the colours are trying to tell me. And, at that point, I might as well just be using the other information. } The world has moved on, it's today not just color vs no-color, but } truecolor vs ansicolor. For example vt.c was patched in the Linux kernel There's a really tempting expression that can be put here... }-- End of excerpt from Kamil Rytarowski
Re: colorls in base
On Feb 15, 10:56am, Rin Okuyama wrote: } } I'd like to propose to introduction -G (colorized output) option } to ls(1), which is compatible to FreeBSD and macOS: } } http://www.netbsd.org/~rin/colorls-20190215.patch } } I know that we already have misc/colorls in pkgsrc. In the era of -1 we don't need this kind of annoying crap in base. }-- End of excerpt from Rin Okuyama
Re: Pressure sensors
On Jan 2, 6:38pm, David Holland wrote:
} On Tue, Jan 01, 2019 at 12:03:31PM -0500, Greg Troxel wrote:
} > > my sensor does fill ->value_cur with mPa, so pressure does fit into the
} > > "everything else"-else{} with ->cur_value / 100.0 for printout in
kPa.
} >
} > Until very recently I had never seen pressure in kPa. For atmospheric
} > pressure, the standard unit seems to be hPa. I realize that's a
} > less-normal SI prefix, but it happens to match mbar. But, I am seeing
} > kPa more tha last 6 months.
}
} Environment Canada was reporting pressure in kPa when I was a kid. Did
} they stop?
}
} > So, I wonder why you are choosing kPa vs hPa, and if that choice ends
} > up being a framework choice for everything. And how the rest of the
} > world deals with this issue.
}
} Most of the world uses millibars and occasionally labels them hPa.
} Since judging by the patch the framework isn't up to handling both,
} the best course is probably to use and label as millibars and just
} duck the occasional brickbat from metrication nuts.
I'm pretty sure that millibars and hPa is metric as well.
}-- End of excerpt from David Holland
Re: deleting telnet/telnetd
On Dec 20, 3:56pm, haad wrote: } } Maybe we can use [1] to write new client. As we probably don't need a telnetd. Numerous people have stated that they use telnet on a local network on older systems where ssh is too slow. For this purpose, it is pretty obvious that a telnetd would be needed. } [1] https://github.com/seanmiddleditch/libtelnet } }-- End of excerpt from haad
Re: deleting telnet/telnetd
On Dec 19, 4:14pm, "J. Lewis Muir" wrote: } Subject: Re: deleting telnet/telnetd } On Wed, Dec 19, 2018 at 1:11 PM David Holland wrote: } > If the conclusion is that we really need a telnet client (I myself } > really don't care if it's in base or not) then we should write a new } > one. } } Or use an existing one? } } PuTTY } } https://www.chiark.greenend.org.uk/~sgtatham/putty/ } } claims to be a client implementation of Telnet. I've never used it PuTTY comes with a built-in terminal emulator and GUI based menus. As far as I know, there is no way use it via a CLI. If somebody does know of one, please tell us. }-- End of excerpt from "J. Lewis Muir"
Re: deleting telnet/telnetd
On Dec 20, 1:25am, m...@netbsd.org wrote: } On Thu, Dec 20, 2018 at 09:24:35AM +0900, Rin Okuyama wrote: } > On 2018/12/20 7:08, Hisashi T Fujinaka wrote: } > > On Wed, 19 Dec 2018, David Holland wrote: } > > } > > > On Wed, Dec 19, 2018 at 01:36:48PM -0800, Hisashi T Fujinaka wrote: } > > > > Telnet is used every day and most of the use cases can use nc. } > > > > } > > > > I wish you'd get rid of it because that would mean I can resign and } > > > > delete NetBSD and get rid of a lot of old hardware. } > > > } > > > You realize I'm not one of the deletionists, right? } > > } > > Yeah, I'm just tired of listening how the sky is falling. I'm off of IRC } > > and I'm going to quit reading the mailing lists for a while. } > > } > } > +1 } > } > David, do you understand your attitude is one of the best } > example of "bad communication" without dirty word? } } I don't think that is fair to say. } Swear words are meant to hurt. Not necessarily. Some people use them as filler words and insert them randomly into otherwise peaceful conversations. Personally I think they have no place in pretty much any conversation (and definitely no place where professional decorum is expected) and demonstrate a lack of intelligence on the part of the user (or, at least a lack of vocabulary). } David's attitude is originating from him feeling that the sky is } falling, and isn't intended to make you feel bad (but happens to). Except that there isn't any credible evidence that the sky is falling. Simply being old, and possibly icky, code doesn't count. }-- End of excerpt from m...@netbsd.org
Re: deleting telnet/telnetd
On Dec 19, 11:48pm, David Holland wrote: } On Wed, Dec 19, 2018 at 11:06:58PM +0100, Manuel Bouyer wrote: } > On Wed, Dec 19, 2018 at 10:03:19PM +, David Holland wrote: } > > On Wed, Dec 19, 2018 at 10:58:14PM +0100, Manuel Bouyer wrote: } > > > On Wed, Dec 19, 2018 at 09:03:27PM +, David Holland wrote: } > > > > [...] } > > > > The hope, I think, was that the conclusion would be that we don't } > > > > really need one. } > > > } > > > We really need one, and the one we have does the job. I really don't see } > > > why we shoud rewrite something that works. } > > } > > Have you looked at the code? } > } > no but I do use it quite often. } } If you value your sanity, don't. But, also, you might want to rethink I could say the same thing about OpenSSH, something that is supposed to use modern coding standards to be secure. At one time, I maintained SunOS 4.x systems past their "best before" dates. I ran OpenSSH on them. Every other release, they broke the portability layer. Looking at that code seriously hurt my head. My point is that there is a lot of code out there that can hurt your sanity, and some of it isn't all that old. } how much you trust it. If there was a suitable replacement for OpenSSH, I would jump on it in an instance. }-- End of excerpt from David Holland
Re: deleting telnet/telnetd
On Dec 19, 9:03pm, David Holland wrote: } On Wed, Dec 19, 2018 at 12:32:08PM -0800, Hisashi T Fujinaka wrote: } > I don't understand your position. Let me explain why. } > } > You're saying, "Write a new one, and it's going to be close to } > impossible," at the same time you're saying, "Delete this one." } > } > If it's impossible, and we need one, we'll need to keep the old one no } > matter how bad it is, right? And if you can't fix it after all the } > experience you have with it, how am I going to be able to fix it? } } I don't really follow. It's not impossible. It's just not trivial. } } Keeping the old one has been the answer for the past twenty-odd } years. But it can't be fixed and sooner or later someone's going to } find a critical problem with it. You can make this argument about pretty much everything. Which is, to say, a totally meaningless argument. } The reason it came up this week is that someone found and posted a } couple noncritical problems in one of the other forks of it. And, how many years has it been since the last significant bug? }-- End of excerpt from David Holland
Re: deleting telnet/telnetd
On Dec 19, 12:32pm, Hisashi T Fujinaka wrote: } } I don't understand your position. Let me explain why. } } You're saying, "Write a new one, and it's going to be close to } impossible," at the same time you're saying, "Delete this one." } } If it's impossible, and we need one, we'll need to keep the old one no } matter how bad it is, right? And if you can't fix it after all the } experience you have with it, how am I going to be able to fix it? Maybe you're a better programmer. :-> } On Wed, 19 Dec 2018, David Holland wrote: } } > The previous telnet thread, contentious as it has been, has completely } > missed the critical context, which is that telnet is 14,700 lines } > cutpasted from the Necronomicon and telnetd is only slightly better. } > } > If the conclusion is that we really need a telnet client (I myself } > really don't care if it's in base or not) then we should write a new } > one. } > } > The old one should be deleted, the sooner the better. } > } > Keep in mind that I say this from the perspective of having been the } > upstream maintainer of the linux fork of it for some years and having } > wasted quite a bit of time and sanity points trying to improve it, } > i.e., arguments of the form "it's not that bad" not grounded in } > similar experience aren't going to be very convincing. } > } > Which of y'all who have been vocal on the other thread are willing to } > help write this? Speak up. } > } > Note that there are 50-odd RFCs on telnet and those document only the } > basics. Making it work with the legacy router in your junkheap will } > require that you get off your duff and test it against that router... } > } > } } -- } Hisashi T Fujinaka - ht...@twofifty.com } BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee }-- End of excerpt from Hisashi T Fujinaka
Re: deleting telnet/telnetd
On Dec 19, 7:11pm, David Holland wrote: } } The previous telnet thread, contentious as it has been, has completely } missed the critical context, which is that telnet is 14,700 lines } cutpasted from the Necronomicon and telnetd is only slightly better. Yeah, so? } If the conclusion is that we really need a telnet client (I myself } really don't care if it's in base or not) then we should write a new } one. } } The old one should be deleted, the sooner the better. Why? There are lots of other things that need doing, that I would consider to be much higher priority. If you feel this strongly about it, then why aren't you volunteering to do the rewrite (insert something here about not being able to tell volunteers what to do)? } [snip] } } Note that there are 50-odd RFCs on telnet and those document only the } basics. Making it work with the legacy router in your junkheap will } require that you get off your duff and test it against that router... In other words, a pretty much impossible task... }-- End of excerpt from David Holland
Re: Moving telnet/telnetd from base to pkgsrc
On Dec 17, 10:24am, Marc Balmer wrote: } > Am 17.12.2018 um 08:57 schrieb Martin Husemann : } > On Sat, Dec 15, 2018 at 10:43:14PM +0100, Marc Balmer wrote: } >> To me it looks like one or two people don't like telnet and have become } >> very vocal and loud about removing it and did not invest a lot of thought } >> in to the cause. Yes, I call them *** } > } > Name calling and other personal insults have no place in our mailing lists. } > Please keep discussion content technical. We will deal with the incident } > privately. } } I want to clear a few things. } } An insult was not intended at all, I am sorry if you or someone } else was insulted. } } When I wrote "dummies" I actually meant that they did not think } the consequences to the end, I am not aware of any other meanings } of that word. Realizing that English is probably not your first language, I'll just point out the word "dummy" is often used as a synonym for "stupid" or "idiot". In terms of grades, it's a more minor insult, but the implication is there. However, failing to think about consequences is certainly a problem. Posting inflammatory comments is likely to get one burned. } As from a technical point of view, I think that both telnet and } telnetd have their valid uses, e.g. in a VPN/Ipsec environment, True, and this is the reason for the pushback. } where using ssh results in double encryption. } }-- End of excerpt from Marc Balmer
Re: Moving telnet/telnetd from base to pkgsrc
On Dec 15, 8:13pm, m...@netbsd.org wrote: } On Sat, Dec 15, 2018 at 01:45:04PM +0700, Robert Elz wrote: } > Date:Fri, 14 Dec 2018 21:28:34 -0800 } > From: John Nemeth } > Message-ID: <201812150528.wbf5syhr025...@server.cornerstoneservice.ca> } > } > | As kre noted, it is probably the oldest network application } > | around. According to Wikipedia, the protocol was developed in } > | 1969, predating TCP/IP, which means that it is probably the oldest } > | TCP/IP application there is. } > } > That's actually what I meant. I have no idea in which order the BSD } > applications were written (nor, for that matter, their original origins.) } > } > But if there are bugs in any of them (and that is not impossible, just as } > with any other software) then we should simply fix them, not just declare } > some apps as "too old, abandon it". } > } > I also simply cannot believe that any issue that might exist in telnet is } > going to be any worse than firefox with a http:// URL ... and I do not see } > anyone suggesting that firefox (and every other browser) should be } > abandoned. } } firefox makes an active effort to handle such things and recently had a } massive rewrite into a language better suited for large scale handling } of untrusted input. They also attempt to limit the impact of bugs with What evidence do you have that the language is better? Besides that, you can write a steaming pile of dung in any language. } sandboxing (although this doesn't apply for netbsd) Why not? } We can probably get away with keeping C for simple things like telnet, } but it takes fuzzing, love, and the willingness to limit the number of } features. Really? } The discussion about telnet was something like } "Why is doing more input processing after hitting an error? then again, } if I change this, there's probably a Rube Goldberg mistake of engineering } reason that it will break 80% of the remaining users of telnet (all } four of them)" This "all four of them" is a truly moronic comment. } "That is absolutely what will happen. That's what happens when you touch } telnet" } } Even the idae of writing a new one was rejected, because who is going to } test it against all the legacy servers today? The only person bring up that idea was you, and you rejected it yourself. Given that, by your own admission, it wouldn't be functional, it makes no sense to write it. }-- End of excerpt from m...@netbsd.org
Re: Moving telnet/telnetd from base to pkgsrc
On Dec 14, 4:22pm, co...@sdf.org wrote: } } You know I'm writing this as telnet on netbsd is vulnerable to remote } exploits, and everyone that can MITM you can do that to you whenever you } 'telnet to see if ports are open'? Name the remote exploit! And, don't tell me about MITM. }-- End of excerpt from co...@sdf.org
Re: Moving telnet/telnetd from base to pkgsrc
On Dec 14, 1:21pm, Taylor R Campbell wrote: } > Date: Fri, 14 Dec 2018 09:46:08 +0100 } > From: Edgar Fuß } > } > > Y'all seem to think it's totally reasonable to telnet in the open internet } > What's the problem with "telnet www.uni-bonn.de http"? } } If the telnet client is remotely exploitable then that exposes you to } exploitation by www.uni-bonn.de and by anyone on the internet between } you and www.uni-bonn.de. The attack surface is unmaintained network } code from the '80s. } } > Date: Fri, 14 Dec 2018 02:13:40 -0800 } > From: John Nemeth } > } > This statement is total nonsense. It works just fine. And, } > it's not like there is a crap-ton of CVEs against it. In fact, } > there have been almost none, which is pretty impressive considering } > how old the code is. } } This reflects how little attention telnet has gotten, not how much } scrutiny it has withstood. That is certainly one interpretation. But, I'm going to disagree. As kre noted, it is probably the oldest network application around. According to Wikipedia, the protocol was developed in 1969, predating TCP/IP, which means that it is probably the oldest TCP/IP application there is. It continued to be used long after SSH became common. In fact, the last major issue that comes to my mind, which was in telnetd, was found long after SSH became common. I'm quite sure that it has received a lot of scrutiny over the years. } If it is used only on a carefully isolated network for something like } a serial management console, that's not really worse than the security } of a lot of management console tooling, but it's not clear to me that } it needs to be in base any more than ipmitool or amtterm. We should I actually wouldn't mind seeing ipmitool in base. Of course, it would be better if our kernel driver was capable of doing more then just reading a handful of sensors, like actually being able to do things like configure the IPMI network settings. ipmitool is very useful for people running real servers. The biggest limitation is our sucky ipmi(4). } at least have warnings on it until someone takes up maintenance not to } use it on the open internet. This is like putting a warning on a gun that says, "don't point at self". This might be considered sensible in the highly litigious US, but for most of the world, this is a ridiculous notion. BTW, even if "someone takes up maintenance" it would still be an unencrypted protocol, so it still wouldn't be usable in a security sensitive setting. Furthermore, why make life more difficult for us crusty old people for no particularly good reason? I've been using telnet to manually do SMTP since the late 80s. Yes, I could learn nc, but I prefer to spend my time on more important tasks that then replacing things that work perfectly well. }-- End of excerpt from Taylor R Campbell
Re: Moving telnet/telnetd from base to pkgsrc
On Dec 13, 10:50pm, co...@sdf.org wrote: } } telnet: } 1. terrible code, with many abstraction violations } 2. something people expect to talk to their legacy machines, which } nobody but them has access to. } 3. common use case is served by netcat, already in base. } 4. too much superfluous functionality. } } Let's pull it out as a package, the alternative being breaking } functionality for the four remaining users. } } send hate mail my way. Here's your hate mail. Stop with @#$!@$ deletenik stuff. Seriously, telnet is basic network functionality. It is also self-contained and doesn't require any maintenance. Thus it doesn't cause any problems for anybody doing maintenance on NetBSD. There is no reason to remove it. Also, you can't be serious in claiming that netcat can replace telnet. }-- End of excerpt from co...@sdf.org
Re: Providing access to USB devices
On Sep 20, 10:49am, Martin Husemann wrote: } On Thu, Sep 20, 2018 at 10:41:01AM +0200, Pierre Pronchery wrote: } > Would it make sense to create a _usb group, and setting the permissions } > of /dev/ugen* and maybe also /dev/usb* to mode 0660 root:_usb? } > } > With this we should also be able to run services like pcscd (from } > pkgsrc) without requiring root. } } We had some discussion about this some time ago in the context of usb } scanners. Alternatives propsoed where the GiveConsole/TakeConsole } scripts used by X login managers and a script that matches certain } devices. } } An alterntive Jared suggested was to add console users temporarily to a } dynamic group. I like this idea. } } And I bet Jason would now chime in and talk about a aproper devfs ;-) I don't know to which Jason you are referring, but I will chime in support of this idea. I've often thought about going back and pulling the archives of the discussion around mjf-devfs and seeing if there is any useful code. Pointers to the early days of devfs in FreeBSD would also be welcome. What I don't want is the Solaris idea of "devfs" which was nothing but a symlink farm and caused massive headaches. }-- End of excerpt from Martin Husemann
Re: Moving virecover to ~/
On Nov 14, 5:35pm, Izaac wrote: } On Sat, Nov 11, 2017 at 08:10:57PM +0700, Robert Elz wrote: } > } > It is unreasonable to inflict on people who don't want/need it, just } > because it happens to be useful to you. } } Elz? Robert Elz? The same one I chastised for a bunch of unnecessary } changes to /bin/sh several weeks ago? Or, Robert Elz, the rather famous elder of the 'net: https://en.wikipedia.org/wiki/Kevin_Robert_Elz }-- End of excerpt from Izaac
Re: Moving virecover to ~/
My concern about this is the same as it would be about moving anything from system-wide stuff to personal stuff or updates to the default dot files. The concern is that people's personal dot files aren't going to be updated when an OS update is done. Generally, only new installs and new users (people often carry dot files from system to system) are going to get the change. This means that updates to the default dot files have a tendency to cause problems for existing users. This isn't to say that there can never be updates but rather that they have to be rare and have a demonstrated strong necessity. Like, kre, I'm not sure that bar has been met.
Re: getaddrinfo(3) on numerical addresses
On Oct 24, 7:32pm, Edgar =?iso-8859-1?B?RnXf?= wrote: } } > I suspect there's some misunderstanding. } Yes. It's about numerical IPv4 addresses being looked up with an AF_INET6 hint. } } check_ping tries to figure out whether it needs to call ping6 (suppose } wer'e on a system where ping6 is different from ping). } Suppose that check_ping is invoked without -4/-6 and with -H 1.2.3.4. } Now check_ping tries to figure out whether the -H argument is a/resolves to } a IPv6 address. To do so, it checks whether getaddrinfo() on the -H argument } (which is 1.2.3.4) with an AF_INET6 hint succeeds. But this triggers a DNS } lookup. } Given this is a monitoring system, who's job it is to detect server failures, } marking random servers/switches as dead while the resolver is going mad and } so check_ping on their numerical IPv4 times out is not particularily useful. This totally sounds like a bug in the monitoring system, not a libc bug. If it is depending on esoteric implementation defined behaviour then it is buggy and needs to find another way to do what it wants. } I guess the point is what you expect getaddrinfo on 1.2.3.4 with a AF_INET6 } hint to do. Well, you could have a search domain of numerical.org and } 1.2.3.4.numerical.org have an record. How likely is that? Irrelevant how likely it is. If it is legal then getaddrinfo() needs to handle it. }-- End of excerpt from Edgar =?iso-8859-1?B?RnXf?=
uuid_name_lookup()
I'm thinking of importing uuid_name_lookup() and uuid_addr_lookup() from DragonflyBSD. These functions look in a file, /etc/uuids and /etc/defaults/uuids, which contains a table mapping uuids to descriptive strings. The advantage is that it makes it easy for various tools to know about new uuids without having to recompile them. The code is here: http://gitweb.dragonflybsd.org/dragonfly.git/blob/refs/heads/master:/lib/libc/uuid/uuid_name_lookup.c or http://tinyurl.com/j4kotc7 . The problem is that the code uses sys/tree.h with extensions (the DragonflyBSD version is based on an old NetBSD version). Also, the interfaces in sys/tree.h are considered to be deprecated. It seems that I have three choices: extend sys/tree.h, convert uuid_name_lookup.c to use the newer sys/rbtree.h, or redo it completely. I was thinking of a small array to cache the items being looked up. It is highly unlikely that more then a handful of items will be needed at any given time, which means that using an rbtree is overkill and the time spent manipulating the tree is likely to be excessive overhead. Any thoughts on which route to go?
Re: dlopen fails from static binary
On Apr 18, 7:17am, Emmanuel Dreyfus wrote: } } On netbsd-6, using dlopen in a static binary will return NULL without } setting errno. errno is for syscalls. dlopen is not a syscall, so why would you expect it to set errno? }-- End of excerpt from Emmanuel Dreyfus
