Re: UTF-8 problem with php-7.4
Hello, Le 24/09/2020 à 19:44, Andrew Hewus Fresh a écrit : On Thu, Sep 24, 2020 at 11:30:35AM +0200, Boudewijn Dijkstra wrote: Op Thu, 24 Sep 2020 02:56:51 +0200 schreef Andrew Hewus Fresh : On Wed, Sep 23, 2020 at 09:11:44AM +0200, Boudewijn Dijkstra wrote: Op Thu, 10 Sep 2020 04:01:30 +0200 schreef Bambero : Hi, It seems that perl regular expressions lost one polish letter (ą): https://www.compart.com/en/unicode/U+0105 I can see this problem only under OpenBSD 6.7 with php-7.4 (same > version of php under linux is OK) Ex.: PHP 7.4.10 or 7.4.5 The same happens with any UTF-8 sequence that ends in 0x85. I guess (a part of) PHP's PCRE code is not in UTF-8 mode, causing triggers onCHAR_NEL (=0x85). I don't know a lot about PHP or the external PCRE library, but my guess would be that php is treating the string as bytes not characters. Can you try using the "u" (PCRE_UTF8) modifier? https://www.php.net/manual/en/reference.pcre.pattern.modifiers.php Indeed with "u" the expected 1 is returned! Now the question is, why is this needed on OpenBSD but not in Linux or Windows? There are many unicode related changes in php 7.4, so I'm sure they fixed something. https://www.php.net/ChangeLog-7.php I would guess that linux and windows both default to a UTF-8 locale, while OpenBSD defaults to the C locale. Does the out put from locale(1) provide you any hints? Do you get any different results testing it with `LC_ALL=en_US.UTF-8`? I don't know enough about php to know how it determines what locale to use, so that may not have any effect, or you may need to adjust something else. The default encoding is UTF-8 but preg_* functions() don't follow default_charset, input_encoding, output_encoding or internal_encoding configs like the multibytes library. You need to add the u modifier explicitly yourself each time you work with an UTF-8 string. No global config flag for that... And don't relay on mb_detect_encoding() it's utterly broken, unless you are sure you are in a case compatible with its limitations. Regards, -- Stéphane Aulery
Re: OpenBSD insecurity rumors from isopenbsdsecu.re
Le 10/05/2020 à 21:00, i...@aulix.com a écrit : Also that said, all mothafuckaaa which keep send posts like this, put your head within your ass and just accept: you are OpenBSD user! Taking into account your earlier kind detailed counter explanation about many mentioned issues and mitigations I would not agree that OpenBSD community is unwelcome, so that issue seems to be not true too :) Btw, does not it look like a PR competition of Linux from USA vs OpenBSD from Canada/London? OpenBSD prohibits USA citizens to work on its crypto? I doubt it, but as I am French I have no opinion on these questions. Serurity is not the only goal of OpenBSD and should not be your only criteria. -Extract from the FAQ About OpenBSD The OpenBSD project produces a freely available, multi-platform 4.4BSD-based UNIX-like operating system. Our goals place emphasis on correctness, security, standardization, and portability. https://www.openbsd.org/faq/faq1.html#WhatIs -- If you are looking for, try the OSes that attracts you and make the choice that suits you (it can be several). Even if a Ferrari is better than a Renault on a theoretical aspect, I prefer my Renault because it is good enough to go to work and will always cost me less. If you made a mistake you can always go back on your choice or even change your mind. With practical knowledge and hindsight you will be in a better position to form an opinion on this subject that worries you. Regards, -- Stéphane Aulery
Re: OpenBSD insecurity rumors from isopenbsdsecu.re
impressive piece of software, one the first seriously hardened allocator, and still the most secure one publicly deployed in production. OBSD +1 W^X [...] Having no memory both writeable and executable is an excellent mitigation against the introduction of new code by an attacker, both in kernel-land and in user-land, forcing attackers to use more convoluted ways to achieve arbitrary code execution. Unfortunately, OpenBSD doesn’t keep track of the mappings, and doesn’t prevent a writeable one from being mapped read-executable, like PaX’ MPROTECT or iOS are doing, as mentioned in WX refinments. Hum. Bad player. W^X "refinement" Maybe a valid point, but this mitigation is fresh. -- Stéphane Aulery
Re: Can I rotate the framebuffer (e.g. using wsdisplay) in OpenBSD?
Le 28/09/2017 à 10:13, Stefan Sperling a écrit : On Thu, Sep 28, 2017 at 12:55:41AM +0200, Stéphane Aulery wrote: Le 27/09/2017 à 17:24, Stefan Sperling a écrit : On Wed, Sep 27, 2017 at 04:11:45PM +0200, Kamil Cholewiński wrote: On Wed, 27 Sep 2017, Francois Pussault wrote: maybe installing a tool like xrandr ? Xrandr works only for X. I've skimmed wscons(4), wsdisplay(4), wsconscfg(8), wsconsctl(8), nothing about rotation... In -current, the console is rotated counter-clockwise if the display isn't already upright: https://marc.info/?l=openbsd-cvs&m=150266331224832&w=2 https://marc.info/?l=openbsd-cvs&m=150300131911666&w=2 This behaviour is hard-coded and cannot be configured. It helps machines which need counter-clockwise rotation, but is not ideal because some machines need clockwise rotation instead. There are plans to auto-detect and use the correct rotation required in the future. And if I use a monitor in portrait orientation ? I have been using a monitor in portrait for many years and was never bothered by the console being the wrong way (X is rotated of course). In a rare situation where I need the console, I can make use of the laws of physics and turn the monitor upright with my hands and arms. This approach seems to work very reliably. I've never seen it fail. It is not the game if you involve the invisible hand! -- Stéphane Aulery
Re: Can I rotate the framebuffer (e.g. using wsdisplay) in OpenBSD?
Le 27/09/2017 à 17:24, Stefan Sperling a écrit : On Wed, Sep 27, 2017 at 04:11:45PM +0200, Kamil Cholewiński wrote: On Wed, 27 Sep 2017, Francois Pussault wrote: maybe installing a tool like xrandr ? Xrandr works only for X. I've skimmed wscons(4), wsdisplay(4), wsconscfg(8), wsconsctl(8), nothing about rotation... In -current, the console is rotated counter-clockwise if the display isn't already upright: https://marc.info/?l=openbsd-cvs&m=150266331224832&w=2 https://marc.info/?l=openbsd-cvs&m=150300131911666&w=2 This behaviour is hard-coded and cannot be configured. It helps machines which need counter-clockwise rotation, but is not ideal because some machines need clockwise rotation instead. There are plans to auto-detect and use the correct rotation required in the future. And if I use a monitor in portrait orientation ? -- Stéphane Aulery
Re: OpenBSD ACER aspire 9300 laptop install panic
Le dimanche 11 septembre 2011 C 12:31:43, Carson Chittom a C)crit : > marc.verwe...@telenet.be writes: > > > I've tried getting access to bug reports from the OpenBSD site but > > whenever I try http://www.openbsd.org/query-pr.html I get a 404 error > > back. Is there another way to query the bugs database? > > My understanding is that the bug tracker is down until further notice, > partially(?) because the software sucked. Nothing else has replaced it > because, as I understand it, everything else sucks *worse*. Or a precursor of the perfect release ! Isn't it? -- StC)phane Aulery
