[Bug 280303] /lib/libc++ requires a new version of /lib/libcxxrt
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280303 Jerry Jacobs changed: What|Removed |Added CC||jerry.jac...@xor-gate.org --- Comment #12 from Jerry Jacobs --- I know this ticket is closed but had similar problem but with transmission. Probably mismatch between pkg and base. I was on:FreeBSD pineapple.srv.xor-gate.org 13.3-RELEASE-p5 FreeBSD 13.3-RELEASE-p5 GENERIC amd64 Error: root@pineapple:/home/jerry # service transmission start Starting transmission. ld-elf.so.1: /lib/libcxxrt.so.1: version CXXABI_1.3.11 required by /usr/local/bin/transmission-daemon not found /usr/local/etc/rc.d/transmission: WARNING: failed to start transmission Fix: $ freebsd-update fetch $ freebsd-update upgrade -r 13.4-RELEASE $ freebsd-update install $ reboot $ freebsd-update install $ uname -a FreeBSD pineapple.srv.xor-gate.org 13.4-RELEASE-p3 FreeBSD 13.4-RELEASE-p3 GENERIC amd64 It also did a pkg error mismatch fix (kernel compat?). Don't have stored the error message. Hope this helps also others in the future when it happens because of pkg+base mismatch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280303] /lib/libc++ requires a new version of /lib/libcxxrt
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280303 --- Comment #13 from Jerry Jacobs --- I know this ticket is closed but had similar problem but with transmission. Probably mismatch between pkg and base. I was on:FreeBSD pineapple.srv.xor-gate.org 13.3-RELEASE-p5 FreeBSD 13.3-RELEASE-p5 GENERIC amd64 Error: root@pineapple:/home/jerry # service transmission start Starting transmission. ld-elf.so.1: /lib/libcxxrt.so.1: version CXXABI_1.3.11 required by /usr/local/bin/transmission-daemon not found /usr/local/etc/rc.d/transmission: WARNING: failed to start transmission Fix: $ freebsd-update fetch $ freebsd-update upgrade -r 13.4-RELEASE $ freebsd-update install $ reboot $ freebsd-update install $ uname -a FreeBSD pineapple.srv.xor-gate.org 13.4-RELEASE-p3 FreeBSD 13.4-RELEASE-p3 GENERIC amd64 It also did a pkg error mismatch fix (kernel compat?). Don't have stored the error message. Hope this helps also others in the future when it happens because of pkg+base mismatch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284892] rc(8) is not clear that /usr/local/etc/rc.d/ files are not run until after $early_late_divider
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284892 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|r...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282328] System fails to boot from ZFS with zio_read errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282328 --- Comment #33 from Aleks --- What should I do now? I can see everything. I can't boot. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282328] System fails to boot from ZFS with zio_read errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282328 --- Comment #32 from Aleks --- everything worked! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284434] ed(1) special replacement with "%" doesn't quite match with man-page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284434 Mark Linimon changed: What|Removed |Added Attachment #257129|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284434] ed(1) special replacement with "%" doesn't quite match with man-page
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284434 Mark Linimon changed: What|Removed |Added Attachment #257130|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284892] rc(8) is not clear that /usr/local/etc/rc.d/ files are not run until after $early_late_divider
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284892
Bug ID: 284892
Summary: rc(8) is not clear that /usr/local/etc/rc.d/ files are
not run until after $early_late_divider
Product: Documentation
Version: Latest
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: Manual Pages
Assignee: b...@freebsd.org
Reporter: jeff+free...@wagsky.com
CC: d...@freebsd.org
The man page leads off with
Typically, the
/usr/local/etc/rc.d/ mechanism is used instead of rc.local these days
but if you want to use rc.local, it is still supported. In this case,
it should source /etc/rc.conf and contain additional custom startup
code for your system. The best way to handle rc.local, however, is to
separate it out into rc.d/ style scripts and place them under
/usr/local/etc/rc.d/.
While this is functional for scripts that run after FILESYSTEMS
($early_late_divider), it does not work for scripts that need to run earlier.
`rcorder /etc/rc.d/* /usr/local/etc/rc.d/my_script` shows the expected order,
based on the BEFORE and REQUIRED statements. However, the reality is that it
will not be run until after FILESYSTEMS.
>From /etc/rc
# Do a first pass to get everything up to $early_late_divider so that
# we can do a second pass that includes $local_startup directories
#
unset system_rc
find_system_scripts
files=`rcorder ${skip} ${skip_firstboot} ${system_rc} 2>/dev/null`
_rc_elem_done=' '
for _rc_elem in ${files}; do
run_rc_script ${_rc_elem} ${_boot}
_rc_elem_done="${_rc_elem_done}${_rc_elem} "
case "$_rc_elem" in
*/${early_late_divider})break ;;
esac
done
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 --- Comment #12 from w...@psr.com --- (In reply to Andriy Gapon from comment #11) > Inclined to close this as 'not a bug'. I agree it's not a bug. However ... > This is not about case sensitivity and, thus, -f flag really. It kind of is. > The manual page already has several references to collation order and > LC_COLLATE. Indeed it does, such as "... are performed lexicographically, according to the current locale's collating rules" said right there in the first paragraph. I had no idea that could mean "including upper/lower case differences not mattering if the remainder of the sort field differs (for locales other than C)". > Maybe they should be more prominent. I don't think that would help. I now understand the collating rules better, you had to rediscover them, they do indeed depend on the locale, etc. Someone who doesn't already know all that isn't going to realize that locale rules (except for C) usually result in case-independent sorting. Unless that's said explicitly, merely saying "it depends" more prominently won't make that apparent. I think the current description of -f suggests that one uses the switch to control case-independent sorting and that, absent -f, one can expect more C-like case-dependent sorting. Except for C locale and sort fields that are identical except for case (level 3), that conclusion is incorrect. Thus I think it merits some kind of comment under -f not to expect that (except for C) OR an explicit comment somewhere that, except for C locale, upper/lower case is less important to sort order than what follows on the line and thus may match case-independently. Just my opinion. I had no idea locale collation rules do what they do, and the only reference to case-(in)dependent sorting was the description under -f, and I came to the wrong conclusion. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 --- Comment #11 from Andriy Gapon --- This is not about case sensitivity and, thus, -f flag really. The manual page already has several references to collation order and LC_COLLATE. Maybe they should be more prominent. In any case, surprising (to us) collation rule are not sort's fault. Inclined to close this as 'not a bug'. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284882] xz Vulnerability issues
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284882 Bug ID: 284882 Summary: xz Vulnerability issues Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: doc...@doctor.nl2k.ab.ca I noticed that the version of xz being used is 5,54 and the current version is 5.6.4 doing a Google Search , This comes up AI Overview The primary difference between xz versions 5.4.5 and 5.6.4 is that 5.6.4 is a newer version with potential security fixes and updates compared to 5.4.5, particularly regarding a critical "backdoor" vulnerability discovered in the 5.6 series of xz utils, which could allow malicious actors to exploit systems using this compression library; therefore, it's strongly recommended to use a version later than 5.6.0 if possible to mitigate this risk. Key points about the difference: Vulnerability: The main concern with older versions like 5.4.5 is the potential presence of a malicious "backdoor" discovered in the 5.6 series, which could enable unauthorized access to systems. Security updates: Version 5.6.4 is likely to include security patches addressing the "backdoor" vulnerability, making it a more secure option. Functionality changes: While security is the primary concern, there could also be minor functional updates or bug fixes introduced between versions 5.4.5 and 5.6.4. URL source https://www.google.com/search?q=differences+between+xz+5.4.5+and+5.6.4&rlz=1C1YTUH_enCA1117CA1118&oq=differences+between+xz+5.4.5+and+5.6.4&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIHCAEQABjvBTIHCAIQABjvBTIKCAMQABiiBBiJBdIBCTQ0Nzg3ajBqNKgCALACAQ&sourceid=chrome&ie=UTF-8 Any concerns? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284883] openssh 9.9p2 security release
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284883 Bug ID: 284883 Summary: openssh 9.9p2 security release Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: doc...@doctor.nl2k.ab.ca Got this this morning OpenSSH 9.9p2 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html Changes since OpenSSH 9.9p1 === This release fixes two security bugs. Security * Fix CVE-2025-26465 - ssh(1) in OpenSSH versions 6.8p1 to 9.9p1 (inclusive) contained a logic error that allowed an on-path attacker (a.k.a MITM) to impersonate any server when the VerifyHostKeyDNS option is enabled. This option is off by default. * Fix CVE-2025-26466 - sshd(8) in OpenSSH versions 9.5p1 to 9.9p1 (inclusive) is vulnerable to a memory/CPU denial-of-service related to the handling of SSH2_MSG_PING packets. This condition may be mitigated using the existing PerSourcePenalties feature. Both vulnerabilities were discovered and demonstrated to be exploitable by the Qualys Security Advisory team. We thank them for their detailed review of OpenSSH. For OpenBSD, fixes to these problems are available as errata; refer to https://www.openbsd.org/errata.html Bugfixes * ssh(1), sshd(8): fix regression in Match directive that caused failures when predicates and their arguments were separated by '=' characters instead of whitespace (bz3739). * sshd(8): fix the "Match invalid-user" predicate, which was matching incorrectly in the initial pass of config evaluation. * ssh(1), sshd(8), ssh-keyscan(1): fix mlkem768x25519-sha256 key exchange on big-endian systems. * Fix a number of build problems on particular operating systems / configurations. Checksums: == - SHA1 (openssh-9.9p2.tar.gz) = edefe960645780dee78059c444d4261667ad3056 - SHA256 (openssh-9.9p2.tar.gz) = karbYD4IzChe3fll4RmdAlhfqU2ZTWyuW0Hhch4hVnM= Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). The PGP key used to sign the releases is available from the mirror sites: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc Reporting Bugs: === - Please read https://www.openssh.com/report.html Security bugs should be reported directly to open...@openssh.com ___ openssh-unix-dev mailing list openssh-unix-...@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Does this affect FreeBSD? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284863] ntpd throws "Address already in use" error with shared IP on multiple interfaces after upgrade from 14.1 to 14.2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284863 --- Comment #2 from Leif Pedersen --- You bet. I reverted to the previous configuration (without "--interface=ena0"), to show that ntpd will not start, and the output from both is empty, of course. ``` $ sockstat -4 -p 123 USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS $ netstat -an | grep 123 ``` After adding "--interface=ena0" back to ntpd_flags, `service start ntpd` is successful, and then here is the output: ``` $ sockstat -4 -p 123 USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root ntpd5200 21 udp4 *:123 *:* root ntpd5200 23 udp4 10.96.16.8:123*:* root ntpd5200 25 udp4 127.0.0.1:123 *:* $ netstat -an | grep 123 udp4 0 0 127.0.0.1.123 *.* udp6 0 0 ::1.123*.* udp4 0 0 10.96.16.8.123 *.* udp6 0 0 fe80::c07:6eff:f.123 *.* udp4 0 0 *.123 *.* udp6 0 0 *.123 *.* ``` -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284883] openssh 9.9p2 security release
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284883 Mark Linimon changed: What|Removed |Added Product|Base System |Security Version|Unspecified |unspecified Assignee|b...@freebsd.org|sect...@freebsd.org Group||freebsd_committer Component|bin |Base -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284882] xz Vulnerability issues
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284882 Mark Linimon changed: What|Removed |Added Product|Base System |Security Group||freebsd_committer Component|bin |Base Assignee|b...@freebsd.org|sect...@freebsd.org Version|Unspecified |unspecified -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 --- Comment #4 from Andriy Gapon --- Okay, I think that this should be some sort of a FAQ now. There is no problem with sort. It's just how the collation weights are defined for 'A' and 'a' inn the respective locales. E.g., for en_US.UTF-8: ;;; ;;; The first two weights are equal which means that during initial comparison of strings 'A' and 'a' would compare equal. If there are any unequal symbols (like '1', '2') they will decide the comparison result. Only if all symbols are equal, then the comparison would proceed to using second weights, then third weights, etc. And by the third weights, 'a' is smaller than 'A'. I am not sure why collation weights are defined that way, but sort certainly just obeys them. TLDR: use C locale for traditional sort order. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 --- Comment #5 from w...@psr.com --- I can accept that that's how the sort program itself works, but I would then argue that the collation weights for 'A' and 'a' being equal in those locales is wrong. IMHO, regardless of the encoding or locale, 'A' and 'a' are not the same and should only have the end result of being treated as the same if -f says to do so. Is there an actual situation in which that's not so? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 --- Comment #8 from w...@psr.com --- (In reply to Andriy Gapon from comment #4) > Okay, I think that this should be some sort of a FAQ now. Or change the sort(1) man page description of: -f, --ignore-case Convert all lowercase characters to their uppercase equivalent before comparison, that is, perform case-independent sorting. to add something like: "Case-independent ordering may also occur as a result of a locale other than C." -- You are receiving this mail because: You are the assignee for the bug.
[Bug 168396] src.conf tunables to enable zlib compression in OpenSSL
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168396 Mark Linimon changed: What|Removed |Added Resolution|--- |Feedback Timeout Status|Open|Closed -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284872] [carp] Missing byte order correction causing certain unicast announcements to have invalid destination MAC address
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284872 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284887] xz Vulnerability issues
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284887 Bug ID: 284887 Summary: xz Vulnerability issues Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: doc...@doctor.nl2k.ab.ca I noticed that the version of xz being used is 5.4.5 and the current version is 5.6.4 CVE-2024-3094 turns up CVE-2024-3094 Detail as found in https://nvd.nist.gov/vuln/detail/cve-2024-3094 IS this a cocern for FreeBSD? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284887] xz Vulnerability issues
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284887 Brooks Davis changed: What|Removed |Added CC||bro...@freebsd.org Resolution|--- |Not Accepted Status|New |Closed --- Comment #1 from Brooks Davis --- https://lists.freebsd.org/archives/freebsd-security/2024-March/000248.html -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284863] ntpd throws "Address already in use" error with shared IP on multiple interfaces after upgrade from 14.1 to 14.2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284863 Dudley Innocent changed: What|Removed |Added CC||dudl...@yahoo.com --- Comment #1 from Dudley Innocent --- Looking to help clarify. Can you please return the results of both "sockstat -4 -p 123" and "netstat -an | grep 123"? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 Andriy Gapon changed: What|Removed |Added Status|New |Open --- Comment #2 from Andriy Gapon --- Can confirm -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 --- Comment #3 from Andriy Gapon --- Also, seems to depend on local settings. Considering this input: With LC_ALL=C.UTF-8 I get: With LC_ALL=en_US.UTF-8 I get: -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 --- Comment #6 from w...@psr.com --- I wouldn't be surprised if the weights were set that way because someone wanted ls (via strcoll(3)) to list files in case-independent order. :-/ :-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 --- Comment #10 from w...@psr.com --- Can an even stronger statement under -f be made, such as: "Primarily for locale C. In other locales, case is already less important than what follows in the sort field." ? I haven't tried to verify that that's true for all locales other than C, though. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 Bob Bishop changed: What|Removed |Added CC||r...@gid.co.uk --- Comment #7 from Bob Bishop --- This document: https://www.unicode.org/reports/tr10/ defines the collation behaviour of Unicode in hideous detail and explains some rationale. TLDR: use C locale for traditional sort order. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284749] certctl: add support for generating cert.pem CAfiles
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284749 --- Comment #15 from Jordan Morningstar --- (In reply to Michael Osipov from comment #14) The first consideration I had was that this can't change how certctl gets used by things that need a "just update the trust store" command. That includes freebsd-update, orchestration scripts, ca_root_nss, etc.. Those can't realistically all be changed in fair time, so the established `certctl rehash` command has to do the right thing whether it's maintaining just CERTDESTDIR, or both that and CERTDESTFILE. With CERTDESTFILE, there's a binary initial state and a binary final state: - Whether or not CERTDESTFILE already exists when `certctl rehash` is run; - Whether or not CERTDESTFILE exists when `certctl rehash` finishes. That means there's four possible operating cases to cover: 1. CERTDESTFILE exists and should continue existing; 2. CERTDESTFILE doesn't exist and should continue not existing; 3. CERTDESTFILE doesn't exist, but must start existing; 4. CERTDESTFILE exists, but must stop existing. The first two cases are the default, "status quo" cases: whatever is or isn't there, maintain that situation. What the current users of `certctl rehash` expect. The "if -e CERTDESTFILE" block in the sweep phase of cmd_rehash does that by setting WANTCERTDESTFILE=1 to signal to the create phase to run create_bundle. If that's all we had to worry about, it wouldn't need the "if WANTCERTDESTFILE != 0" test, but there are two other cases to handle. Case 3 is covered by -b. If CERTDESTFILE doesn't exist, then the "if -e CERTDESTFILE" test fails and the cmd_rehash sweep phase doesn't set WANTCERTDESTFILE=1, but we need it to be =1 so the getopts for -b sets it instead. Case 4 is covered by -B. This is where WANTCERTDESTFILE being ternary comes in. In the default cases, cmd_rehash runs with WANTCERTDESTFILE=-1, meaning nothing has given an explicit instruction either way about the continued existence of CERTDESTFILE. The getopts for -B sets WANTCERTDESTFILE=0, giving that explicit instruction that makes the create phase of cmd_rehash skip running create_bundle even if the "if -e CERTDESTFILE" test passed. That's why the test is "if WANTCERTDESTFILE != 0"--it has to match both 1 and -1. In plain terms, the "!= 0" says "if we haven't been explicitly told not to...". So WANTCERTDESTFILE needs to be able to express both explicit yes and explicit no in addition to the implicit state. The nounset condition means it also needs an initial value that can't be either explicit signal. It could have been an empty string, but empty strings and nounset historically haven't always played nice. An explicit third state value is safer. I chose "-1" because that's the traditional/canonical value for the "don't care" state of a ternary. I feel I should also mention that while cases 3 and 4 do map to many things, they correspond to install and uninstall, respectively, steps in ca_root_nss. It's improper for a port to delete files it didn't install, so ca_root_nss must have certctl do that bit on its behalf. The port must run `certctl rehash` anyway[1], so an easy way to link all this up is just have a couple of flags that can be added to the exec and unexec calls. Note 1: I suspect certctl seeing LOCALBASE/usr/share/certs/ca-root-nss.crt is (part of) why do_scan does its SPLITDIR thing: certctl can pick up the full bundle and dismantle it into individual hashed certificates. That behaviour also makes life easier for users with local certificates, be that a server certificate trust chain, enterprise/appliance CA bundle, or third-party tools that sync to NSS/CCADB directly. The SPLITDIR trick means the user can simply drop those files into /usr/local/etc/ssl/certs without needing to know much about file content interactions. Yes, this isn't what OpenSSL does; but, to me at least, there's better adherence to POLA this way because it "just works". No leaving the user wondering why certctl ignored part of their file, then ultimately tasked with manual splitting. p.s., In writing all this out, I realized "if WANTCERTDESTFILE = -1" in the sweep phase should work as well. I can test and change "!= 0" to "= -1" if you feel that would make the logic easier to understand. p.p.s., I also realized that I used C semantics for WANTCERTDESTFILE (0=false). I can switch it to Bourne semantics (0=true) if you want. It's perhaps the run of the nit litter, but it is a Bourne script. p.p.p.s., I do love how teaching something to others can help find stuff I didn't notice before. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284749] certctl: add support for generating cert.pem CAfiles
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284749 --- Comment #14 from Michael Osipov --- (In reply to Jordan Morningstar from comment #13) Yes, please. ATM I do struggle to understand. I am not saying that is wrong, but confusing. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284864] sort does case-independent sort even without -f or --ignore-case
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284864 --- Comment #9 from w...@psr.com --- (In reply to Bob Bishop from comment #7) > https://www.unicode.org/reports/tr10/ Interesting. Thanks! While the locale I was using was not a Unicode one, its collation tables presumably work the same way. And, according to Andriy in Comment #4, the collation order there is 'a' before 'A', which is the opposite of locale C, explaining the vs. results. Perhaps then the man page addition to the -f description should be more like "Collation order depends on locale where case may be less important than what follows in the sort field." -- You are receiving this mail because: You are the assignee for the bug.
