Re: xterm(1) changing UTF-8 characters when copy-pasting?
Anthony J. Bentley wrote: > precompose (class Precompose) Thanks! That makes xterm work (almost) as expected: $ ls Thérèse $ ls | od -c 000T h e 314 201 r e 314 200 s e \n 014 $ cp Thérèse Thérèse cp: Thérèse and Thérèse are identical (not copied). The first filename in the cp command above is created using ksh's auto-completion and the second filename is created by copy-pasting the first filename. So xterm doesn't recompose the characters anymore. The strange part is that, when I copy the first filename and paste it to become the second filename, the second filename is shown without any accent, even though the first and second filenames are now the exact same sequence of bytes (I checked using od(1)). So on the command line it actually looks like this: $ cp Thérèse Therese cp: Thérèse and Thérèse are identical (not copied). which looks wrong but works as expected. I tried to play with various things like the allowPasteControls resource but to no avail. It looks like an xterm bug to me but at this point I'm not even sure of that... Anyone has any clue? Thanks, Philippe
OpenBSD Puffy Stickers
I like putting stickers on my laptop, but alas after searching high and low over the internet I wasn't able to find any good OpenBSD stickers So, I got a few printed up myself at StickerMule so now all of my laptops and even my car can show support for OpenBSD. That being said, I have 7 extra Puffy stickers available if anyone else would like to have one. They're 3" wide, and have a matte UV coating on the outside, so they'll work indoors or outdoors. If you'd like one, you can send me your address, and I'll drop one in the mail for you. Even better, you can make a donation to the OpenBSD Foundation as "payment." It's my small way of saying thank you to the amazing OpenBSD community. -- Jay Williams P.S. Does anyone know why the official OpenBSD store doesn't sell stickers? I bet they'd be a big seller!
Re: STYLE: whitespace at end of input line
Jan Stary writes: > The offending portion is: > > .Bd -literal > $ ecurve 7 0 3 > > * * > * * >** > * * >** >** > .Ed > > I can just delete the trailing whitespace and the reader will see the same, > but the whitespace actually has a meaning here: it's a 7x7 ascii bitmap > of an elliptic curve (y^2 = x^3 + 3 over Z_7). Can you draw a box around it? E.g. +---+ | * * | | * * | | ** | | * * | | ** | | ** | +---+ Allan
Re: obligatory leaving letter
Hi Jay, Jay Williams wrote on Tue, Nov 28, 2017 at 05:17:05PM -0600: > As a new user to OpenBSD, who is trying to learn as much as I can, > seeing a message like this is very disheartening. Please do not worry about this particular case. The user who wrote this message contributed almost nothing - a few very simple bug reports at best - but caused several developers (myself included) to waste time because they answered his mails. Besides, he vastly overestimated his own importance. Yes, it did happen in the past that developers left for reasons that were sad in various ways. Some of them came back later. Some of them i still miss. OpenBSD uses an extremely terse communication style. That style is useful to keep technical communication concise in a very small group doing huge amounts of work (i'm one of the few developers who are notorious for being wordy at times and blunt at others). One downside of this efficient style is that it will unavoidably seem impolite to many cultural expectations, in particular in instances where it comes together with people getting upset, and when it comes together with the well-known effect that email communication usually appears more aggressive than face-to-face comminucation, even when that isn't intended. The concise communication style also has the side effect of attracting people to the list - not developers! - who misinterpret the terse style as a license for being disrespectful. That is not OK, mutual respect is essential even in strong disagreement. Admittedly, if you look at the list of developers, it is impossible to deny that OpenBSD is not the most succcessful project ever with respect to inclusiveness. I think it would be good to do a bit better in that respect, in particular since technical merit and inclusiveness are in no way a hindrance to each other, but it is well-known that improvement in that respect is with necessity a very slow process in a project that, by its stated goals and unwritten culture, has an exlusive focus on technical innovation and a general consensus to avoid all formalities. That said, i'm convinced that all developers try to judge contributions solely by their technical merit, and without regard to the person submitting them, and welcome contributions by everybody, which is one of the necessary conditions to slowly improve inclusiveness. Yours, Ingo
Re: obligatory leaving letter
On Wed, Nov 29, 2017 at 12:17 AM, Jay Williams wrote: > As a new user to OpenBSD, who is trying to learn as much as I can, seeing a > message like this is very disheartening. OpenBSD's security focus and passion > for clean, minimal and secure code is something that the world definitely > needs. > > Despite the worldwide trend, especially here in the USA, I hope we can find > ways to get along and work together toward common goals, rather than be > divided > against ourselves. > > Best of luck on your new endeavor! > > -- > Jay Williams > >> On Nov 28, 2017, at 4:43 PM, leo_...@volny.cz wrote: >> >> Haai, >> >> I think it's about time I write this. >> >> I am De Zeurkous. I used the nick 'schaafuit' (originally devised for a >> prank elsewhere) in an attempt not to let past preconceptions (for those >> who don't know, I have a somewhat bad history with the NetBSD project) >> rule the present. The story about using my bf's e-mail address is true, >> however; the only act of deception was the assumption of another nick. >> >> Despite ongoing personal problems (which are not at all relevant here), >> I extended my UNIX experience considerably since 2007 (the year of the >> NetBSD trouble). Things have settled considerably for me since then, so >> I suggest that we let the past be the past and focus on what has been >> happening recently. >> >> I admit to having some troll blood in my veins. However, I have been >> here to contribute to OpenBSD discussion and have found myself genuinely >> distraught the many times it descended into outright flamage. If that >> makes me too soft material for OpenBSD, as Theo at least once implied, >> well, so be it. >> >> Now that is out of the way, I can get to the point. >> >> In all honesty, I have come to the sad conclusion that the various BSD >> projects, with their leaders being full of entitlement, don't really >> appreciate what UNIX is all about (nevermind that gnu weenies are even >> worse in this regard). >> >> As dmr often pointed out (though perhaps not quite in the terms that I >> will use here), UNIX is about community. I'd even argue that early UNIX >> sites were like families, anticipating each other's needs and building >> upon individual strenghts to achieve something that was not just >> technically adequate, but something to be proud of. Unfortunately, I can >> no longer verify this with dmr, but I'd imagine that UNIX did not just >> feel familiar, but like something shared and even homely. >> >> Unfortunately, UNIX development seems to have become profoundly >> seperated from UNIX use. Whether related or not, it also appears to have >> become a bare battle of egos, something that is quite alien to me, and >> to UNIX itself as well. >> >> I chose OpenBSD because of its somewhat desirable technical properties, >> and I had hoped to be able to contribute. Alas, I am forced to concede >> that for me this is not possible, as I appear to have quite different >> goals (and a very different mindset) from its principal contributors, >> despite my profound appreciation for the project's focus on security. >> >> Now, by this point, you might suspect that I have some alternative in >> mind, and possibly in development; this is indeed the case. You might >> also suspect that I'm going to plug it here; however, I won't. >> >> Since I have no particular desire to be a disruptive force to anyone, >> I will leave you folks to your project. >> >> And me to mine =) >> >> Best of luck and greetings, >> >> Baai, >> >>--zeurkous. >> >> P.S.: attached is a main(3) header file and manual page, as a little... >> 'going-away present'. >> >> -- >> Friggin' Machines! > I know I'm just adding to the fucking noise right now, but I for one am just glad a trollish person's gone and there will be less noise (hopefully) from now on. Until the next one shows up... -- :wq!
Re: STYLE: whitespace at end of input line
> 3. If you think the trailing blanks really matter for users > and commonly occur in practice, change the tool itself to > write a dedicated character at line ends to show where the > end of each line is. Of course, that would be a user interface > change for the tool. Right, they don't need to be blanks. Thank you, Jan
Re: obligatory leaving letter
As a new user to OpenBSD, who is trying to learn as much as I can, seeing a message like this is very disheartening. OpenBSD's security focus and passion for clean, minimal and secure code is something that the world definitely needs. Despite the worldwide trend, especially here in the USA, I hope we can find ways to get along and work together toward common goals, rather than be divided against ourselves. Best of luck on your new endeavor! -- Jay Williams > On Nov 28, 2017, at 4:43 PM, leo_...@volny.cz wrote: > > Haai, > > I think it's about time I write this. > > I am De Zeurkous. I used the nick 'schaafuit' (originally devised for a > prank elsewhere) in an attempt not to let past preconceptions (for those > who don't know, I have a somewhat bad history with the NetBSD project) > rule the present. The story about using my bf's e-mail address is true, > however; the only act of deception was the assumption of another nick. > > Despite ongoing personal problems (which are not at all relevant here), > I extended my UNIX experience considerably since 2007 (the year of the > NetBSD trouble). Things have settled considerably for me since then, so > I suggest that we let the past be the past and focus on what has been > happening recently. > > I admit to having some troll blood in my veins. However, I have been > here to contribute to OpenBSD discussion and have found myself genuinely > distraught the many times it descended into outright flamage. If that > makes me too soft material for OpenBSD, as Theo at least once implied, > well, so be it. > > Now that is out of the way, I can get to the point. > > In all honesty, I have come to the sad conclusion that the various BSD > projects, with their leaders being full of entitlement, don't really > appreciate what UNIX is all about (nevermind that gnu weenies are even > worse in this regard). > > As dmr often pointed out (though perhaps not quite in the terms that I > will use here), UNIX is about community. I'd even argue that early UNIX > sites were like families, anticipating each other's needs and building > upon individual strenghts to achieve something that was not just > technically adequate, but something to be proud of. Unfortunately, I can > no longer verify this with dmr, but I'd imagine that UNIX did not just > feel familiar, but like something shared and even homely. > > Unfortunately, UNIX development seems to have become profoundly > seperated from UNIX use. Whether related or not, it also appears to have > become a bare battle of egos, something that is quite alien to me, and > to UNIX itself as well. > > I chose OpenBSD because of its somewhat desirable technical properties, > and I had hoped to be able to contribute. Alas, I am forced to concede > that for me this is not possible, as I appear to have quite different > goals (and a very different mindset) from its principal contributors, > despite my profound appreciation for the project's focus on security. > > Now, by this point, you might suspect that I have some alternative in > mind, and possibly in development; this is indeed the case. You might > also suspect that I'm going to plug it here; however, I won't. > > Since I have no particular desire to be a disruptive force to anyone, > I will leave you folks to your project. > > And me to mine =) > > Best of luck and greetings, > > Baai, > >--zeurkous. > > P.S.: attached is a main(3) header file and manual page, as a little... > 'going-away present'. > > -- > Friggin' Machines!
openbsd 6.2 current on lenovo miix 310
Hi, for anyone whos interested in these tablet+keyboad things here are the facts about openbsd 6.2 current on the lenovo miix 310. forgot to try apm -A ... will do next time tldr; - installation was done to a usb thumb drive (it's not my device..) - Installation works as usual (secureboot disabled), internal storage is recognized, screen is roatetd by 90 degrees - booting works too. console is on fullscreen but rotated 180 degrees - keyboard and touchpad are working - apm bat seems not to be recognized - wireless and ethernet devices are not recognized - audio seems not to work - X11 works ! - USB works here the long story: OpenBSD 6.2-current (GENERIC.MP) #237: Fri Nov 24 21:49:38 MST 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4135493632 (3943MB) avail mem = 4003246080 (3817MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7781a000 (41 entries) bios0: vendor LENOVO version "1HCN40WW" date 11/04/2016 bios0: LENOVO 80SG acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP UEFI TCPA MSDM UEFI HPET LPIT APIC MCFG PRAM SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT TPM2 CSRT FPDT BGRT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 1440.24 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu0: 1MB 64b/line 16-way L2 cache acpihpet0: recalibrated TSC frequency 1439955909 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 79MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 1439.96 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 1439.96 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 1439.96 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus -1 (RP03) acpiprt4 at acpi0: bus -1 (RP04) acpicpu0 at acpi0 C2: state 6: substate 8 >= num 3 C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS acpicpu1 at acpi0 C2: state 6: substate 8 >= num 3 C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS acpicpu2 at acpi0 C2: state 6: substate 8 >= num 3 C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS acpicpu3 at acpi0 C2: state 6: substate 8 >= num 3 C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: WWPR, resource for HS03, MDM1 acpipwrres1 at acpi0: WWPR, resource for HS13, MDM1 acpipwrres2 at acpi0: WWPR, resource for SSC1, MDM3 acpipwrres3 at acpi0: WWPR, resource for SSCW, MDM3 acpipwrres4 at acpi0: WWPR, resource for HSC1, MDM2 acpipwrres5 at acpi0: WWPR, resource for HSC3, MDM4 acpipwrres6 at acpi0: CLK2, resource for CA01, CA13 acpipwrres7 at acpi0: CLK4, resource for CAMR, CAMB, CA00, CA40 acpipwrres8 at acpi0: P28P, resource for CAMR, CAMB, CA00, CA01, CA40, CA13 acpipwrres9 at acpi0: P18P, resource for CAMR, CAMB, CA00, CA01, CA40, CA13 acpipwrres10 at acpi0: P12P, resource for CAMR acpipwrres11 at acpi0: CLK2, resource for CAMC acpipwrres12 at acpi0: CLK3, resource for RTEK, RTK2, RTK1 acpipwrres13 at acpi0: CLK4 acpipwrres14 at acpi0: CLK2 acpipwrres15 at acpi0: CLK1 acpipwrres16 at
Re: Odd problem with interfaces
Aargh! What a day https://media.giphy.com/media/AYcqmj0cUar9S/giphy.gif Sent from ProtonMail Mobile On Wed, Nov 29, 2017 at 16:13, Jiri B wrote: > On Wed, Nov 29, 2017 at 09:56:38AM -0500, Rupert Gallagher wrote: > I ran out > of ideas on the following problem. > > An obsd server has tree ethernet > interfaces, each with its own IP address: > > cat /etc/hostname.* > inet > 192.168.1.2 255.255.255.0 192.168.1.255 mtu 9014 description "em0: > MODEM/ROUTER" > inet 192.168.1.3 255.255.255.0 192.168.1.255 mtu 9014 > description "em1: CISCO SG110D-08" > inet 192.168.1.4 255.255.255.0 > 192.168.1.255 mtu 9014 description "em2: NAS" ^^ using same IP network on 3 > ifaces? This is no-go by default. (If you need that, check rdomains.) > When > all three interfaces are connected, the clients loose NFS > services, and scp > fails from server to any client (but ssh keeps > working). Functionality is > recovered by unplugging em0 and em2. j.
Re: Odd problem with interfaces
https://goo.gl/images/eEeb6 Sent from ProtonMail Mobile On Wed, Nov 29, 2017 at 16:13, Jiri B wrote: > On Wed, Nov 29, 2017 at 09:56:38AM -0500, Rupert Gallagher wrote: > I ran out > of ideas on the following problem. > > An obsd server has tree ethernet > interfaces, each with its own IP address: > > cat /etc/hostname.* > inet > 192.168.1.2 255.255.255.0 192.168.1.255 mtu 9014 description "em0: > MODEM/ROUTER" > inet 192.168.1.3 255.255.255.0 192.168.1.255 mtu 9014 > description "em1: CISCO SG110D-08" > inet 192.168.1.4 255.255.255.0 > 192.168.1.255 mtu 9014 description "em2: NAS" ^^ using same IP network on 3 > ifaces? This is no-go by default. (If you need that, check rdomains.) > When > all three interfaces are connected, the clients loose NFS > services, and scp > fails from server to any client (but ssh keeps > working). Functionality is > recovered by unplugging em0 and em2. j.
Re: STYLE: whitespace at end of input line
Hi Jan, Jan Stary wrote on Wed, Nov 29, 2017 at 09:05:48PM +0100: > the manpage below does not go through mandoc -Tlint -Wstyle, because > > mandoc -Tlint -Wstyle *.1 > mandoc: ecurve.1:48:1: STYLE: whitespace at end of input line > mandoc: ecurve.1:49:7: STYLE: whitespace at end of input line > mandoc: ecurve.1:50:7: STYLE: whitespace at end of input line > mandoc: ecurve.1:51:6: STYLE: whitespace at end of input line > mandoc: ecurve.1:52:7: STYLE: whitespace at end of input line > mandoc: ecurve.1:53:6: STYLE: whitespace at end of input line > mandoc: ecurve.1:54:6: STYLE: whitespace at end of input line > > The offending portion is: > > .Bd -literal > $ ecurve 7 0 3 > > * * > * * >** > * * >** >** > .Ed > > I can just delete the trailing whitespace Probably not ideal because ... > and the reader will see the same, but the whitespace actually has > a meaning here: it's a 7x7 ascii bitmap > of an elliptic curve (y^2 = x^3 + 3 over Z_7). ... you make a reasoanble argument that you actually want to display the trailing whitespace because it is meaningful. > Is it intended that trailing whitespace is an offence even in -literal? Yes, because trailing blanks are not semantically significant in the roff(7) language in general. They are stripped from the input before even starting the formatter, and that's why the warning is adequate, not only because trailing blanks are hard to see in output. Actually, if you have trailing blanks in a file which you display with less(1) in an xterm(1), you *can* see them when you mark them with the mouse. Try that with the input to, and with the output from mandoc. You can see them in the input file, but they are not present in the output. > Not that I really need it, but is there an environment in mdoc(7) > that explicitly permits whitespace, for situations such as this? There is no other environment for that purpose and you don't need any, but you have three options, sorted by increasing intrusiveness and rigorousness: 1. Escape the trailing blanks such that they actually get displayed: --- tmp.mdoc.orig Wed Nov 29 21:38:54 2017 +++ tmp.mdocWed Nov 29 21:32:02 2017 @@ -45,13 +45,13 @@ is the column. .Bd -literal $ ecurve 7 0 3 - - * * - * * - ** - * * - ** - ** + \ \& + * *\ \& + * *\ \& + ** \ \& + * *\ \& + ** \ \& + ** \ \& .Ed .Sh BUGS .Nm Two downsides: They are still hard to see when the manual is displayed, and they become U+00A0 NO-BREAK SPACE in -Tutf8. 2. Use the example command $ ecurve 7 0 3 | sed 's/$/./' instead of the one you show now. One downside: The tool itself still writes trailing blanks, which are still hard to see, assuming that most users will not usually pipe their output through sed(1). 3. If you think the trailing blanks really matter for users and commonly occur in practice, change the tool itself to write a dedicated character at line ends to show where the end of each line is. Of course, that would be a user interface change for the tool. Yours, Ingo
Re: xterm(1) changing UTF-8 characters when copy-pasting?
On Wed, Nov 29, 2017 at 07:05:05PM +0100, Ingo Schwarze wrote: > Anthony J. Bentley wrote on Wed, Nov 29, 2017 at 10:29:28AM -0700: > > The only unexpected thing here is xterm doing these transformations > > without asking. > > I think i would support a diff to fix that Seconded. The current default behaviour is broken.
STYLE: whitespace at end of input line
Hi Ingo, the manpage below does not go through mandoc -Tlint -Wstyle, because mandoc -Tlint -Wstyle *.1 mandoc: ecurve.1:48:1: STYLE: whitespace at end of input line mandoc: ecurve.1:49:7: STYLE: whitespace at end of input line mandoc: ecurve.1:50:7: STYLE: whitespace at end of input line mandoc: ecurve.1:51:6: STYLE: whitespace at end of input line mandoc: ecurve.1:52:7: STYLE: whitespace at end of input line mandoc: ecurve.1:53:6: STYLE: whitespace at end of input line mandoc: ecurve.1:54:6: STYLE: whitespace at end of input line The offending portion is: .Bd -literal $ ecurve 7 0 3 * * * * ** * * ** ** .Ed I can just delete the trailing whitespace and the reader will see the same, but the whitespace actually has a meaning here: it's a 7x7 ascii bitmap of an elliptic curve (y^2 = x^3 + 3 over Z_7). Is it intended that trailing whitespace is an offence even in -literal? Not that I really need it, but is there an environment in mdoc(7) that explicitly permits whitespace, for situations such as this? Jan .Dd November 27, 2017 .Dt ECURVE 1 .Os .Sh NAME .Nm ecurve .Nd display elliptic curves over finite fields .Sh SYNOPSIS .Nm .Op Fl cfg .Ar p .Ar a .Ar b .Sh DESCRIPTION .Nm computes the points of an elliptic curve given by .Ql y^2 = x^3 + ax + b over the finite field Z_p and displays the curve as ascii art. .Pp The .Ar p argument is a prime determining the Z_p field, and the .Ar a and .Ar b parameters are the coeficients of the curve. The options are as follows: .Pp .Bl -tag -width Ds -compact .It Fl c Display the curve. This is the default. .It Fl f Display the algebraic structure of the underlying Z_p field. .It Fl g Display the algebraic structure of the curve as a group. .El .Sh EXAMPLES The following computes the curve given by .Ql y^2 = x^3 + 3 over Z_7. In the picture, .Ar x is the row, .Ar y is the column. .Bd -literal $ ecurve 7 0 3 * * * * ** * * ** ** .Ed .Sh BUGS .Nm does not recognize the GF(p^k), only Z_p.
snmpd high memory page fault / cpu usage and high latency
Hi List, i've a default snmpd.conf. When i starting snmpd then the page fault jumps to 38000: procsmemory pagediskstraps cpu r b wavm fre flt re pi po fr sr sd0 sd1 int sys cs us sy id 1 1 0 575124 60937927 0 0 0 0 0 0 0 12431 286 14949 0 13 87 3 1 0 714620 5953364 38734 0 0 0 0 0 0 0 7621 2874 8141 1 55 45 1 1 0 719240 5945512 1458 0 0 0 0 0 0 0 13983 79593 10611 1 46 53 1 1 0 724648 5938116 1367 0 0 0 0 0 0 0 12625 86397 11556 1 43 56 1 1 0 730144 5931496 1397 0 0 0 0 0 0 0 12205 87469 11460 0 41 59 1 1 0 735576 5925460 1365 0 0 0 0 0 0 0 12180 87416 11405 1 40 59 1 1 0 741796 5918980 1594 0 0 0 0 0 0 0 10088 97679 11000 1 40 59 1 1 0 747544 5913104 1444 0 0 0 0 0 0 0 11300 92602 11123 1 45 54 1 1 0 753160 5907416 1411 0 0 0 0 0 0 0 11480 90342 11342 1 44 55 1 1 0 580448 6085620 5249 0 0 0 0 0 0 0 10764 67811 10606 5 45 50 0 1 0 575124 6093624 1052 0 0 0 0 0 0 0 12453 1152 15157 0 12 88 0 1 0 575124 60936447 0 0 0 0 0 0 0 1215082 15005 0 11 89 0 1 0 575124 60936647 0 0 0 0 0 0 0 12388 2273 15194 0 17 83 1 1 0 575124 60936847 0 0 0 0 0 0 0 12426 287 15152 0 13 87 0 1 0 575124 60937047 0 0 0 0 0 0 0 13449 146 15683 0 14 86 also when i send some snmp requests from another machine (mrtg) its the same result. in this case i get a latency for 500 ms througp this openbsd 6.0 machine (Xeon E3 with 4 Cores on 3,6 GHz) 8 G Memory. cat /etc/sysctl.conf net.inet.ip.forwarding=1 ddb.panic=0 machdep.kbdreset=1 net.inet.carp.preempt=1 net.inet6.ip6.forwarding=1 net.inet.ip.ifq.maxlen=8192 net.inet.carp.log=7 kern.maxclusters=32768 Have everyone an idea ? Thanks Thomas Diese Nachricht wurde versandt mit Webmail von www.tbits.net. This message was sent using webmail of www.tbits.net.
Re: obligatory leaving letter
On Tue, 28 Nov 2017, leo_...@volny.cz wrote: As dmr often pointed out (though perhaps not quite in the terms that I will use here), UNIX is about community. Or about simplicity? UNIX as the opposite to MULTICS? And this is the impression I get when I read Ritchies and Thompson paper "The Unix Time-Sharing System". And even if it is not so simple, they were able to explain it so, that one gets this impression. This is by the way my experience on speches and lectures of best scientists. This is why I like much more the answer of Otto Moerbeek than the one of Theo, but it seems there was a background not known by everyone. [...] as I appear to have quite different goals (and a very different mindset) from its principal contributors, despite my profound appreciation for the project's focus on security. Well, there is not a lot of alternatives. You will have to create the system that follows your goals. Rodrigo.
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Hi Anthony, Anthony J. Bentley wrote on Wed, Nov 29, 2017 at 10:29:28AM -0700: > Ingo Schwarze writes: >> That's a bad idea. Do not use non-ASCII bytes in file names. >> You are in for all kinds of trouble. > I don't agree. In a situation where a single user will be accessing > files, That's a very strong condition, which will rarely hold. But sure, when it does hold, and when the number of files is too large to assign sensible file names, it partially mitigates the problems. But only partially. > you can use whatever naming scheme you like. UTF-8 works exactly > how you would expect: the filename you enter is the filename you'll > get. Until some program from ports decides to legitimately do Unicode normalization, uses buggy built-in locale components, assumes the wrong locale, or incorrectly validates character encoding and crashes or truncates data. Just as a few examples of what can still go wrong even on a purely single-user system. All these are fairly widespread in the wild. Quite certainly, xterm is not the only program doing normalization, and i have rarely seen any program that is not buggy with respect to multibyte-character handling. > Misencoded files can also exist, with exactly the results you would > expect also: you can't necessarily type it, but if you can pass the > exact filename, programs will work. Except those using fgetws(3), mbtowc(3), mbstowcs(3), and friends for reading UTF-8 data and terminating on encoding errors, which includes for example almost all of the FreeBSD base system, including POSIX utilities like cut(1). [...] > This is indeed xterm's fault. > > precompose (class Precompose) > Tells xterm whether to precompose UTF-8 data into Normalization > Form C, which combines commonly-used accents onto base > characters. If it does not do this, accents are left as > separatate characters. The default is "true". > > In my opinion, that's a *very* poor default. I don't expect base tools > to canonicalize text like that. Base tools certainly shouldn't. In my opinion, if Xenocara wouldn't, that would be an improvement, too. In particular in much-used tools like xterm(1). Even if that causes us to diverge a bit from upstream. > The only unexpected thing here is xterm doing these transformations > without asking. I think i would support a diff to fix that near the end of /usr/X11R6/share/X11/app-defaults/XTerm == /usr/xenocara/app/xterm/XTerm.ad Thanks for digging up the root cause of the OP's issue. Yours, Ingo
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Ingo Schwarze writes: > That's a bad idea. Do not use non-ASCII bytes in file names. > You are in for all kinds of trouble. I don't agree. In a situation where a single user will be accessing files, you can use whatever naming scheme you like. UTF-8 works exactly how you would expect: the filename you enter is the filename you'll get. Misencoded files can also exist, with exactly the results you would expect also: you can't necessarily type it, but if you can pass the exact filename, programs will work. Same goes with control characters like backspaces in file names (far more annoying than UTF-8). Saying you can't is impractical. Anyone downloading lots of external files through web browsers, torrent clients, or any number of other programs in ports will eventually encounter files with UTF-8 filenames. They work just fine. Keeping spaces out of filenames is already a lost battle, let alone limiting them to the POSIX portable filename character set (A-Za-z0-9._-). Obviously once you start talking about files on external media or otherwise accessible by users in other locales, that conclusion changes. But I'm talking about a personal desktop here. > > So it looks like xterm is changing > > I'm not convinced it is xterm; it might also be the X libraries > supporting copying with the mouse. Anyway, whatever does it is > allowed to. This is indeed xterm's fault. precompose (class Precompose) Tells xterm whether to precompose UTF-8 data into Normalization Form C, which combines commonly-used accents onto base characters. If it does not do this, accents are left as separatate characters. The default is "true". In my opinion, that's a *very* poor default. I don't expect base tools to canonicalize text like that. UTF-8 strings work fine when passed to grep(1), but grep doesn't -- nor would I expect it to -- canonicalize strings, or ignore zero-width no-break spaces in running text, or any other sort of weird transformation invented by the Unicode committee. The only unexpected thing here is xterm doing these transformations without asking. -- Anthony J. Bentley
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Hi Philippe, Philippe Meunier wrote on Wed, Nov 29, 2017 at 11:35:59AM -0500: > Ingo Schwarze wrote: >> Philippe Meunier wrote: >>> $ ls >>> Thérèse >> That's a bad idea. Do not use non-ASCII bytes in file names. > That's a nice thought but in practice I have some files on that machine > with names written in French, Thai, Chinese, Korean, and Japanese, and for > some of these files renaming is not an option for work reasons. I somehow > doubt that I'm the only one in such a situation. Sure. In some situations, there is no viable alternative to dealing with file systems containing broken filenames. That's why we try to make tools like ls(1) as useful as possible in such a bad situation. But you can never expect a smooth user experience. It is not an OpenBSD-specific problem, in facts it's worse almost everywhere else, although not everybody is likely to admit that. >> It's certainly not ksh(1) because our ksh is not fully multibyte- >> character aware on purpose, but deliberately has only limited >> multibyte-character support. > Actually, since you brought this up, I wish ksh had fuller multibyte > character support. As you say above the problem is mostly hidden and most > of the time it happens to just work, but, for example, trying to delete > double-wide Korean characters (well, syllables, really, which are *all* > double-wide) messes up the command line: That is indeed expected, and it is one of the things that are very unlikely to change even in the long term. Adding support for correctly handling character display widths in shell command line editing would require calling functions like mbtowc(3) and wcwidth(3) on the fly in the command line editing modules. Such changes would be fairly intrusive and carry a substantial risk of introducing nasty, perhaps even security-relevant bugs into the shell, so even if somebody would cook up patches, i'm not convinced that they could go in. That said, i see that you are actually torturing our shell in these respects quite a bit. As long as you don't expect that everything can be fixed, you are quite welcome to report issues that you see. I don't doubt that there are still outright bugs, and it also seems likely that there are missing features which can be implemented without making a mess of the shell. So reports based on real everyday use are definitely helpful. While several developers understand the basics of how multibyte character support works in the shell and in some others of our POSIX utilities, very few use that heavily, as far as i know. Yours, Ingo
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Ingo Schwarze wrote: >Philippe Meunier wrote: >> $ ls >> Thérèse > >That's a bad idea. Do not use non-ASCII bytes in file names. That's a nice thought but in practice I have some files on that machine with names written in French, Thai, Chinese, Korean, and Japanese, and for some of these files renaming is not an option for work reasons. I somehow doubt that I'm the only one in such a situation. >In this respect, OpenBSD is better than other operating systems. >The problem is mostly hidden on OpenBSD because OpenBSD supports >UTF-8 only. Yes, I've noticed that the UTF-8 support in OpenBSD has become much nicer in recent years. My thanks to the devs who did that :-) >That's called "canonical composition" in Unicode. *sigh* I see. Well, I learned something new today. Thanks for the info. >It's certainly not ksh(1) because our ksh is not fully multibyte- >character aware on purpose, but deliberately has only limited >multibyte-character support. Actually, since you brought this up, I wish ksh had fuller multibyte character support. As you say above the problem is mostly hidden and most of the time it happens to just work, but, for example, trying to delete double-wide Korean characters (well, syllables, really, which are *all* double-wide) messes up the command line: the double-wide characters are correctly deleted but the cursor moves left by only one position for each delete which means that very quickly I lose track of which characters I'm actually deleting and I'm forced to redraw the line. Anyway, at this point it's mostly anecdotal; most things work out of the box. Philippe
Re: Odd problem with interfaces
On Wed, Nov 29, 2017 at 09:56:38AM -0500, Rupert Gallagher wrote: > I ran out of ideas on the following problem. > > An obsd server has tree ethernet interfaces, each with its own IP address: > > cat /etc/hostname.* > inet 192.168.1.2 255.255.255.0 192.168.1.255 mtu 9014 description "em0: > MODEM/ROUTER" > inet 192.168.1.3 255.255.255.0 192.168.1.255 mtu 9014 description "em1: CISCO > SG110D-08" > inet 192.168.1.4 255.255.255.0 192.168.1.255 mtu 9014 description "em2: NAS" ^^ using same IP network on 3 ifaces? This is no-go by default. (If you need that, check rdomains.) > When all three interfaces are connected, the clients loose NFS > services, and scp fails from server to any client (but ssh keeps > working). Functionality is recovered by unplugging em0 and em2. j.
Re: xterm(1) changing UTF-8 characters when copy-pasting?
Hi Philippe, Philippe Meunier wrote on Wed, Nov 29, 2017 at 09:11:38AM -0500: > I've noticed something unexpected when copy-pasting UTF-8 characters in > xterm: xterm seems to change some of the characters into something > different but visually similar. Here's an example (using ksh): > > $ uname -a > OpenBSD foo.my.domain 6.1 GENERIC#19 i386 > $ ls > Thérèse That's a bad idea. Do not use non-ASCII bytes in file names. You are in for all kinds of trouble. Not so much because using arbitrary bytes in file names would be invalid, but because their meaning is completely undefined on any UNIX-like operating system. By definition, file names are byte strings, not character strings. They do NOT have a meaning in any particular locale and are NOT representing accented characters. In this respect, OpenBSD is better than other operating systems. The problem is mostly hidden on OpenBSD because OpenBSD supports UTF-8 only. So if you use UTF-8 characters in file names, you often get away with it simply because it's the only locale supported by the system. But, as you see, even on OpenBSD, you do not always get away with such recklessness. On other systems supporting different locales, each user can choose their own locale, so one user may have UTF-8 set, another one ISO-LATIN-something, and yet another one Shift-JIS. But there is only one file system. So every filename will be gibberish for all users except for the one user having a locale where it happens to be validly encoded. Speak after me: A file system does not have a locale. Non-ASCII characters cannot be encoded in file names, on any UNIX in general. (Windows is different, but at the price of badly violating POSIX in significant parts of its C library). > $ ls | od -c > 000T h e 314 201 r e 314 200 s e \n > 014 > $ cp Thérèse Thérèse > > This copy command is typed as follows: type 'cp ', press tab for ksh to > auto-complete the first filename, another space, then use the mouse to > copy-paste the first filename into xterm to get the second filename. > The cp command works without any error. The result is: $ printf "\xcc\x81" | uniname character byte UTF-32 encoded as glyph name 0 0 65 65 e LATIN SMALL LETTER E 1 1 000301 CC 81 COMBINING ACUTE ACCENT $ printf "\xc3\xa9" | uniname character byte UTF-32 encoded as glyph name 0 0 E9 C3 A9 \ LATIN SMALL LETTER E WITH ACUTE That's called "canonical composition" in Unicode. The UTF-8 multibyte character sequences "e\xcc\x81" and "\xc3\xa9" are canonically equivalent, which means that multibyte-character aware software is required to treat both identically, and such software is allowed to silently substitute one for the other. Of course, the file system is not multibyte-character aware and not allowed to be, so as a file name, both names are different. Yes, you heard correctly: Not only can filenames containing *semantically different* Unicode characters have identical visual representation, but the filesystem is also required to treat filenames as different that have *identical* semantics in Unicode. Do not use Unicode for filenames. It simply doesn't work and is a security nightmare on top of that. The reason for UTF-8 support in ls(1) isn't to encourage UTF-8 filenames. It is merely a crutch helping to display as much information as possible about broken file systems. They are still broken and dangerous. > So it looks like xterm is changing I'm not convinced it is xterm; it might also be the X libraries supporting copying with the mouse. Anyway, whatever does it is allowed to. It's certainly not ksh(1) because our ksh is not fully multibyte- character aware on purpose, but deliberately has only limited multibyte-character support. We want predictable, not surprising behaviour in the shell. In particular, our ksh never changes byte sequences. Yours, Ingo
Odd problem with interfaces
I ran out of ideas on the following problem. An obsd server has tree ethernet interfaces, each with its own IP address: > cat /etc/hostname.* inet 192.168.1.2 255.255.255.0 192.168.1.255 mtu 9014 description "em0: MODEM/ROUTER" inet 192.168.1.3 255.255.255.0 192.168.1.255 mtu 9014 description "em1: CISCO SG110D-08" inet 192.168.1.4 255.255.255.0 192.168.1.255 mtu 9014 description "em2: NAS" When all three interfaces are connected, the clients loose NFS services, and scp fails from server to any client (but ssh keeps working). Functionality is recovered by unplugging em0 and em2.
xterm(1) changing UTF-8 characters when copy-pasting?
Hello, I've noticed something unexpected when copy-pasting UTF-8 characters in xterm: xterm seems to change some of the characters into something different but visually similar. Here's an example (using ksh): $ uname -a OpenBSD foo.my.domain 6.1 GENERIC#19 i386 $ ls Thérèse $ ls | od -c 000T h e 314 201 r e 314 200 s e \n 014 $ cp Thérèse Thérèse This copy command is typed as follows: type 'cp ', press tab for ksh to auto-complete the first filename, another space, then use the mouse to copy-paste the first filename into xterm to get the second filename. The cp command works without any error. The result is: $ ls Thérèse Thérèse $ ls | od -c 000T h e 314 201 r e 314 200 s e \n T h 303 251 020r 303 250 s e \n 026 Note how the two filenames look exactly the same but are actually different byte sequences... So it looks like xterm is changing e 314 201 into 303 251 and e 314 200 into 303 250 when copy-pasting... which was rather a surprise to me. I'm pretty sure the problem is with xterm, not with ksh, because the same thing happens with bash (using a similar xterm and using bash through ssh to a Linux machine). Is this normal / expected? For info: $ cat .Xdefaults xterm*background: black xterm*foreground: white xterm*metaSendsEscape: true xterm*multiScroll: true xterm*saveLines:256 xterm*scrollBar:true xterm*scrollKey:true xterm*scrollTtyOutput: false xterm*utf8Title:true xterm*utmpInhibit: true xterm*visualBell: true $ set | egrep -i utf LC_CTYPE=en_US.UTF-8 XTERM_LOCALE=en_US.UTF-8 Thanks, Philippe
Re: Testing IKEv2 with Android devices
On Wed, Nov 29, 2017 at 9:33 AM, Stuart Henderson wrote: > On 2017-11-26, C. L. Martinez wrote: >> >> Ok, it is seems the prolem is that iked(8) does not know how to perform >> Diffie-Hellman group negotiation: >> >> https://marc.info/?l=openbsd-tech&m=151136800328145&w=2 >> >> Am I correct? What is the current status for Tim's fix? > > patrick@ has been following this rabbit hole, try his latest diff. > Thanks Stuart. Are you referring to this one: https://marc.info/?l=openbsd-tech&m=151187345915827&w=2?
sshd hangs when ldap server is offline
Hi, We have been trying to play around with the login_ldap package and after we have configured login.conf, ypldap.conf and added portmap_flags=YES, ypldap_flags=“”, and ypbind_flags=“” to rc.conf.local we have see an issue. If the ldap server is offline, sshd is not able to restart or even start the daemon. We tried to reboot the server and firstly it hangs with yp_first causing RPC errors. If we ^C that in the console, it continues and want to start the sshd daemon, but that just hangs forever. We have been using the guide from http://blogs.helion-prime.com/2009/05/07/authorization-with-ldap-on-openbsd.html yet we skipped the last step of automate execution. If the server is able to reach the ldap server, then everything works fine. Andreas
Re: MacOS High Sierra. Anyone can login as "root" with empty password
Am 29. November 2017 08:36:27 MEZ schrieb Ilya Abimael : >Hello, > >https://news.ycombinator.com/item?id=15800676 > >The mentioned news is _NOT_ OpenBSD related. It just got something in >my mind to ask: You forgot a important detail. The root user is there in all Mac OS X, OS X and macOS versions. It is disabled by default and, it has no password by default. You set the root password if you activate the root account the first time. Which brings the next problem. The first by default created user on a Mac OS X (see above) machine is a administrator. Any administrator could activate the root account and, the most normal users did not create a user for daily jobs. The idea of Apple is, buy it, switch it on and use it. > > >The question: Would it be a good thing to MANDATORY disable any >passwordless login? IMHO a useless question in theese days. In Mac OS X (as you refer to it) you can use the profile manager or parential control to limit things if you really need passwordless accounts like a public kiosk system or for people with disabilities - but there you also have assistive technologies like VoiceOver and Braile support. > >OpenBSD would probably never have similar issue, but maybe it would be >a good mitigation? Search for the discussion about SSH login passwords / keys. > > >Thanks.
Re: Testing IKEv2 with Android devices
On 2017-11-26, C. L. Martinez wrote: > > Ok, it is seems the prolem is that iked(8) does not know how to perform > Diffie-Hellman group negotiation: > > https://marc.info/?l=openbsd-tech&m=151136800328145&w=2 > > Am I correct? What is the current status for Tim's fix? patrick@ has been following this rabbit hole, try his latest diff.
Re: IPSec Flow and SA to unexpected subnet
On 2017-11-27, Tobias Urdin wrote: > Had the same problem with a shitty Netgear on the other end. > > OpenBSD happily accepted the flow with a 0/0 from forcing all traffic to > the destination over that tunnel. Yes, I once found the hard way that you can do this from an OpenBSD client too, I think it was something like "from any to $remote_network". It was a bit tricky to fix as my adsl suddenly became rather busy...
Re: IPSec Flow and SA to unexpected subnet
On 2017-11-27, Paul Suh wrote: > Note the two starred flows that are not listed in my ipsec.conf > configuration. The 172.16.0.0/16 subnet does exist on the Sonicwall end, and > I'm pretty sure that the Sonicwall is requesting that a flow be set up for > that subnet. However, I would think that my OpenBSD router would not create > that flow since it's not in my ipsec.conf. > > Any ideas why it's being created anyway? I won't be in a position to see if > the flow is really live until tomorrow morning. ipsec.conf was added to replace config parts done in isakmpd.conf, that's all. To restrict this side of things you need to learn about keynote and write an isakmpd.policy file. (Yes, it's a pain).
Re: MacOS High Sierra. Anyone can login as "root" with empty password
On 2017-11-29, Ilya Abimael wrote: > The question: Would it be a good thing to MANDATORY disable any passwordless > login? That would be annoying for ssh.
