[Bug 284749] certctl: add support for generating cert.pem CAfiles
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284749
--- Comment #1 from Michael Osipov ---
* There is no OPENSSLDIR ${LOCALBASE}/openssl in base. OpenSSL from ports
should use the truststore from the system. There is an open ticket for this.
* I wouldn't use the term "ca_root_nss-style" in the script at all. Just a
"certificate bundle".
* I wouldn't make it a command, but an option to "rehash" and a env var so an
admin can force it to be generate always when "certctl" is invoked by other
processes which will never invoke your new option/command.
Besides this, my previous statements still hold true:
* All open ports must be reviewed why they review bundle
* Have the CA certs in both forms make little sense in general and likely adds
a small computational overhead.
--
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 #2 from Mel Pilgrim ---
(In reply to Michael Osipov from comment #1)
Re: OPENSSLDIR
I agree, OpenSSL should. And until it does and the unknown number of ports
stop looking for only /usr/local/openssl/cert.pem (like in that rustsec blocker
for 284404), ${LOCALBASE}/openssl will have to exist. Remember, this is about
being compatible with ca_root_nss while unbreaking what it breaks.
Re: "ca_root_nss-style"
Fixed by way of those commands no longer existing because of...
Re: commands vs rehash flags
That's an easy enough change. Revised patch to follow. It does mean that
do_scan runs more than necessary, and that the create and delete flags now have
a last-flag-wins race. But:
- `certctl createbundles` is now `certctl -b rehash`
- `certctl deletebundles` is now `certctl -B rehash`
Re: env var to force generation
I'm a bit unsure what you're asking for. Are you asking for an env var that
makes `certctl rehash` act as if the command was `certctl -b rehash`? If so,
should be it `certctl -b rehash` or `certctl -be rehash` (i.e., should the env
var always create /etc/ssl/cert.pem as well)?
Re: open ports must be reviewed
I agree, but I would like to keep that discussion in the ca_root_nss PR.
Re: CAfile + CApath dubiousness
I agree that having both is a bit nonsensical, but OpenSSL gave use two options
and the world said "yes both at once thank you". That is, if there's a
performance penalty with having both, it's going to happen whether certctl
generates them or ca_root_nss installs them.
--
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 Mel Pilgrim changed: What|Removed |Added Attachment #257429|0 |1 is obsolete|| --- Comment #3 from Mel Pilgrim --- Created attachment 257435 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=257435&action=edit Revised patch adding optional CAfile generation to certctl -- You are receiving this mail because: You are the assignee for the bug.
[Bug 196845] devinfo does not present vital info (compared to sysctl)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196845 --- Comment #2 from Uffe Jakobsen --- (In reply to Mark Linimon from comment #1) I did a test on FreeBSD-14.2 - and the devinfo output now has the missing parts Thanks :-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 174581] man page of recvmsg(2) does not mention return value 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174581 Oleksandr Tymoshenko changed: What|Removed |Added CC||d...@freebsd.org Component|Documentation |Manual Pages Assignee|d...@freebsd.org |b...@freebsd.org --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=571df2c64a3c1af1fe011303ec08e391e887ecbc commit 571df2c64a3c1af1fe011303ec08e391e887ecbc Author: Felix Johnson AuthorDate: 2025-02-13 03:40:59 + Commit: Alexander Ziaee CommitDate: 2025-02-13 03:54:14 + recv.2: Explain how recv functions can return 0 Clarify the RETURN VALUES section with improved structure, the condition of the return value 0, and the setting of errno. PR: 174581 Reviewed by:jhb, ziaee Approved by:mhorne (mentor) Differential Revision: https://reviews.freebsd.org/D48955 lib/libsys/recv.2 | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 254672] netstat -s --libxo json duplicate "shutdown-timer" field
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254672 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|i...@freebsd.org Flags||mfc-stable14?, ||mfc-stable13? --- Comment #2 from Mark Linimon --- ^Triage: assign to committer. Set flags for possible MFC (just close this if not desireable). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284783] Potential licensing issue of source file 'sys/cam/scsi/scsi_all.h'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284783 Bug ID: 284783 Summary: Potential licensing issue of source file 'sys/cam/scsi/scsi_all.h' Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: msl023...@gmail.com When trying to add my ported mfiutil package to Debian, which depends on a small fraction of this file, a Debian FTP Master member pointed out that its license did not explicitly greated the redistribution permission to general public. The license text as of https://cgit.freebsd.org/src/tree/sys/cam/scsi/scsi_all.h?id=2ffd30f7ee15c87ee092cbac6a4438bcb3af923c is: /*- * Largely written by Julian Elischer (jul...@tfs.com) * for TRW Financial Systems. * * TRW Financial Systems, in accordance with their agreement with Carnegie * Mellon University, makes this software available to CMU to distribute * or use in any manner that they see fit as long as this message is kept with * the software. For this reason TFS also grants any other persons or * organisations permission to use or modify this software. * * TFS supplies this software to be publicly redistributed * on the understanding that TFS is not responsible for the correct * functioning of this software in any circumstances. * * Ported to run under 386BSD by Julian Elischer (jul...@tfs.com) Sept 1992 */ Reference to Debian FTP Master member Thorsten Alteholz's interpretation: > according to the TFS-CMU license, the copyright holder (TRW) only allows CMU > to > redistribute this software. > "Any other persons" are only allowed to use or modify it and especially > Debian is > not allowed to redistribute it. Given the ambiguity of the license text, this interpretation reasonable. I believe when the license is written, the copyrighit holder didn't intended to prohibit redistribution of this software by 3rd parties; but with this unfortunate wording, it is unclear whether redistribution it is actually permitted. I'm aware that this license is really old (likely be earlier than Sept 1992 as hinted by the last line), but is it possible to get it clearified somehow? -- 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 Michael Osipov changed: What|Removed |Added CC||micha...@freebsd.org Attachment #257429|0 |1 is patch|| -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284777] usr.sbin/periodic/etc/weekly/340.noid: unhandled newline parsing jail output
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284777
Bug ID: 284777
Summary: usr.sbin/periodic/etc/weekly/340.noid: unhandled
newline parsing jail output
Product: Base System
Version: Unspecified
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: ports.maintai...@evilphi.com
Created attachment 257458
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=257458&action=edit
fix jail output parsing in 340.noid
I was getting this error in the periodic weekly email:
Check for files with an unknown user or group:
find: name=pkgbuild: unknown primary or operator
That's from 340.noid, which appears to not handle jail -e output correctly when
there is more than one jail and path is the last jail variable defined. The
code in question:
28 sep=:
29 OIFS="$IFS"
30 IFS="$sep"
31 for param in $(jail -f "$jail_conf" -e "$sep" 2>/dev/null)
32 do
33 case "$param" in
34 path=*)
35 _p=${param#path=}
36 if [ -z "$_p" -o "$_p" = / ]; then
37 continue
38 fi
39
40 exclude="$exclude -path $_p -prune -or"
[...]
47 rc=$(find -H ${weekly_noid_dirs:-/} \
48 \( $exclude ! -fstype local -prune -or -name \* \) -and \
49 \( -nogroup -o -nouser \) -print | sed 's/^/ /' |
50 tee /dev/stderr | wc -l)
Adding 'echo "_p=$_p"' at line 39 and running 340.noid gives:
# ./340.noid
Check for files with an unknown user or group:
_p=/jails/containers/nginx
name=pkgbuild
_p=/jails/containers/pkgbuild
name=postgres
_p=/jails/containers/postgres
find: name=pkgbuild: unknown primary or operator
This is because I have three jails on my system, and the output of that jail
command is:
# jail -f /etc/jail.conf -e ":"
name=nginx:allow.raw_sockets:allow.sysvipc:exec.clean:exec.start="/bin/sh
/etc/rc":exec.stop="/bin/sh
/etc/rc.shutdown":host.hostname=nginx.amnesiac.local:ip4=inherit:ip6=inherit:mount.devfs:mount.fstab=/jails/etc/fstab.nginx:path=/jails/containers/nginx
name=pkgbuild:allow.raw_sockets:allow.sysvipc:exec.clean:exec.start="/bin/sh
/etc/rc":exec.stop="/bin/sh
/etc/rc.shutdown":host.hostname=pkgbuild.amnesiac.local:ip4=inherit:ip6=inherit:mount.devfs:mount.fstab=/jails/etc/fstab.pkgbuild:path=/jails/containers/pkgbuild
name=postgres:allow.raw_sockets:allow.sysvipc:exec.clean:exec.start="/bin/sh
/etc/rc":exec.stop="/bin/sh
/etc/rc.shutdown":host.hostname=postgres.amnesiac.local:ip4=inherit:ip6=inherit:mount.devfs:mount.fstab=/jails/etc/fstab.postgres:path=/jails/containers/postgres
I'm not sure what the best fix would be, but inserting
_p=${_p%$'\n'*}
after line 35 appears to fix it. Discovered in 13.4-R, but 340.noid appears to
be the same in -CURRENT. Patch against main attached.
Workaround:
This only happens if path is the last variable in a jail -e output line, which
only happens if it's the last variable defined for a jail in /etc/jail.conf.
This bug can be worked around by changing the order of variables in
/etc/jail.conf so that path is not the last variable defined.
--
You are receiving this mail because:
You are the assignee for the bug.
