Re: Case-sensitivity of timezone paths in the installer
Okay, thanks for the clarification. If it's by design, and not all implementations may be case-sensitive, should the installer clarify in case of a user not entering a valid timezone path that paths are case-sensitive? Right now I think it could be made a little clearer that it's looking for an exact match. I know it's not a big deal but changing the error message might make things clearer for some users. Katherine On Sat, May 1, 2021 at 9:55 PM Theo de Raadt wrote: > > Luigi30 wrote: > > > I noticed that timezone paths in the installer step that sets the system > > timezone are case-sensitive to match the paths in /usr/share/zoneinfo. > > (Specifically, it's set_timezone() in > > /usr/src/distrib/miniroot/install.sub.) > > > > It seems like the behavior should be more like: > > > > - Upon entering set_timezone(), it builds its /usr/share/zoneinfo lookup > > table and converts it to lowercase with sed. > > - User enters "America/chicago" or something for the timezone path. > > - The script converts the timezone path to lowercase with sed. > > - The script compares the lowercase path to the /usr/share/zoneinfo table. > > - If there's a match, it uses the properly capitalized path. > > > > As implemented now, the script would only confusingly reply that there > > is no such timezone as America/chicago. > > > > I started working on a fix for this but before I go tilting at windmills, > > is there a technical reason that the script behaves this way? > > Issues with internationalization? Or is it just an oversight? > > I disagree with your assessment and proposal. > > "Do not use names that differ only in case. Although the reference > implementation is case-sensitive, some other implementations are not, > and they would mishandle names differing only in case." > > Timezones are case sensitive. > > We may as well force people to correctly select the name in this > situation, because if they "learn" that lowercase is acceptable in the > installer, they may return to userland and insist that > TZ=America/chicago should work. > > % TZ=America/Chicago date > Sat May 1 21:53:50 CDT 2021 > % TZ=America/chicago date > Sun May 2 02:53:47 GMT 2021 > > As you can see, it does not work.
Case-sensitivity of timezone paths in the installer
Hi, I noticed that timezone paths in the installer step that sets the system timezone are case-sensitive to match the paths in /usr/share/zoneinfo. (Specifically, it's set_timezone() in /usr/src/distrib/miniroot/install.sub.) It seems like the behavior should be more like: - Upon entering set_timezone(), it builds its /usr/share/zoneinfo lookup table and converts it to lowercase with sed. - User enters "America/chicago" or something for the timezone path. - The script converts the timezone path to lowercase with sed. - The script compares the lowercase path to the /usr/share/zoneinfo table. - If there's a match, it uses the properly capitalized path. As implemented now, the script would only confusingly reply that there is no such timezone as America/chicago. I started working on a fix for this but before I go tilting at windmills, is there a technical reason that the script behaves this way? Issues with internationalization? Or is it just an oversight? Katherine
Recent "elliptic curve" -> "supported groups" change in libssl
Hi, As someone with interests in kernel development and a lot of spare time, I want to work on OS patches. I just installed OpenBSD 6.4 in a clean development VM and started building the -current branch from CVS to get up to date with the latest commits. I noticed that the build was failing with an error in usr.bin/openssl/c_sb.c line 703 caused by a missing #define. I traced the cause back to this commit earlier today updating libssl's TLS support for RFC 7919 compliance: https://github.com/openbsd/src/commit/2cdb2b1d3f3f9272c0a1acf5fe1f067f3db09e29#diff-e050d3ba43ebfa12f82b36086dca3ea3 It renames the Elliptic Curves extensions to Supported Groups, including the TLSEXT_TYPE_elliptic_curves #define which became TLSEXT_TYPE_supported_groups. Simple, right? I updated the #define and extname to match the new supported groups name and continued building. Everything was fine and I was able to access HTTPS web pages and retrieve packages. However, when I went to create the diff afterward, I got an error from CVS... -- ssh_dispatch_run_fatal: Connection to 129.128.197.20 port 22: invalid elliptic curve value -- Uh-oh. I'm going to assume that this is connected to the elliptic curve diff. I tried a couple different anoncvs mirrors with no effect. Just wondering if this was a known problem with -current or something hokey going on with my system. Katherine
