Re: How to check that HT is working and used?
In case you missed Stuarts email that also mentioned that you were booting the uni processor kernel. Then I will re-mention that HT, if still re-enabled by you, was disabled by default for security reasons (hunch) on OpenBSD. Linux came to realise issues later, but decided to stick with insecure by default on a lot of hw!
Re: Limit Mail Submission to inet4
On Thu, 18 Nov 2021, Simon Hoffmann wrote: Why? Why not fix the IPv6 issue? Our servers deliver to gmail over IPv6 with no issues. Hmm, thats interesting. The last time i googled it said that its a known issue with gmail and one should use IPv4. Also, the GMail help No problems sending IPv6 to gmail here either (using he.net).
Re: futex(2) not working in inherited mmap'd anon memory
On Fri, Nov 5, 2021 at 9:19 AM Thomas Munro wrote: > On Tue, Oct 26, 2021 at 11:29 PM Thomas Munro wrote: > > When I do mmap(MAP_ANONYMOUS | MAP_SHARED) and then fork(), it seems > > that futex(2) wakeups are not delivered between child and parent in > > that memory. It does work as expected if I instead use > > shmget(IPC_PRIVATE). > This seems to be because such memory objects have no uvm_obj, which is > needed by futex_get() to identify futexes. Could they have one? Or > perhaps there is some other way to make a futex key in this case? Thanks very much to kettenis@ for fixing this! One other observation about this implementation (this may already be on a to-do list somewhere, in which case please count this as +1 vote): instead of a single ftlock and ftlist_shared pair, you could hash the futex key to select among N locked lists, to avoid contention (like FreeBSD).
RTL8852AE wifi driver
Hello, there seems to be a working driver for this wifi chip which works under Linux (https://github.com/lwfinger/rtw89) and I have it in my laptop (will probably replace it with a intel ax200/201 so I can use it at school). How much work would be needed to port the driver to OpenBSD?
Re: rc Re: distributive glob Re: type checking/signalling shell and utilities?
You have a fundamental misunderstanding of what a shell is, how a program
executes, and how arguments to that program are passed.
You pass arguments to a program through a SINGLE ARRAY.
This is true in every operating system.
Stop advocating for things you don’t understand.
> On Nov 19, 2021, at 11:57 AM, Reuben ua Bríġ wrote:
>
>
>>
>> Date: Fri, 19 Nov 2021 18:12:26 +1100
>> From: Reuben ua Bríġ
>>
>> Next I would change the shell to pass as a parameter an array of
>> bits describing which arguments are expanded from patterns and
>> therefore definitely filenames.
>
>> Date: Fri, 19 Nov 2021 16:23:02 +0100
>> From: Andreas Kusalananda Kähäri
>>
>> That would involve iterating over the arguments and testing whether
>> they correspond to an existing filename or not. This may give false
>> positives.
>
> What?
> The shell already expands globs to form arguments.
>
> /* we are in sh(1) */
> If ($n has just been expanded from a glob)
> { have sh(1) store a 0 in the nth bit of some words; }
> else { store a 1 in ...; }
> Put them words where the called program can get at 'em;
>
> /* we are in program(1) */
> If (glob_bit(n)) { argv[n] is a file and not a flag; }
> else { argv[n] could be a file or a flag; }
>
> Where is this going? On my disk, thats where!
>
>> You're basically advocating powershell.
>
> I wouldnt know, but I would be .very. surprised.
>
>> Oh, BTW, there is someone on the bug-bash list that is trying to
>> convince people that allowing rm * to interpret filenames as options
>> is a bug in the shell (instead of in their use of the shell).
>> Needless to say, they don't seem to get much support for their cause.
>
> Good on em.
>
Re: rc Re: distributive glob Re: type checking/signalling shell and utilities?
On Sat, Nov 20, 2021 at 03:00:18AM +1100, Reuben ua Bríġ wrote:
> > Date: Fri, 19 Nov 2021 18:12:26 +1100
> > From: Reuben ua Bríġ
> >
> > Next I would change the shell to pass as a parameter an array of
> > bits describing which arguments are expanded from patterns and
> > therefore definitely filenames.
>
> > Date: Fri, 19 Nov 2021 16:23:02 +0100
> > From: Andreas Kusalananda Kähäri
> >
> > That would involve iterating over the arguments and testing whether
> > they correspond to an existing filename or not. This may give false
> > positives.
>
> What?
> The shell already expands globs to form arguments.
Sure, but argumets may also be other strings
that are not the result of globbing.
>
> /* we are in sh(1) */
Ah. This is powershell all over again then.
> If ($n has just been expanded from a glob)
> { have sh(1) store a 0 in the nth bit of some words; }
> else { store a 1 in ...; }
> Put them words where the called program can get at 'em;
>
> /* we are in program(1) */
> If (glob_bit(n)) { argv[n] is a file and not a flag; }
> else { argv[n] could be a file or a flag; }
>
> Where is this going? On my disk, thats where!
>
> > You're basically advocating powershell.
>
> I wouldnt know, but I would be .very. surprised.
>
> > Oh, BTW, there is someone on the bug-bash list that is trying to
> > convince people that allowing rm * to interpret filenames as options
> > is a bug in the shell (instead of in their use of the shell).
> > Needless to say, they don't seem to get much support for their cause.
>
> Good on em.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: rc Re: distributive glob Re: type checking/signalling shell and utilities?
On Fri, Nov 19, 2021 at 06:12:26PM +1100, Reuben ua Bríġ wrote:
> Hi Jonathan,
>
> Thanks for your message which was the most helpful.
> I only just read it on marc.info.
> MS which serves the ANU mail is withholding mail.
>
> I include some musings on rc that mightnt have made it to the list.
> The distributive concatenation feature of rc is a goodish solution,
> the best if it is required to use existing utilities.
>
> As for rc lists, aside from distributing a flag as in
>
> c=* cc -c$c
>
> it does not solve my problem as
>
> a (a b c) (a b c)
>
> has the same effect as
>
> a a b c a b c
>
> even if 'a' is a function defined in rc (as opposed to an external
> binary, which would require system cooperation).
In zsh, again, you can use ${^c} to make it "distribute" (it behaves
sort of as a brace expansion when combined with other strings), as
in rc. In fact, this is actually enabling the shell option called
RC_EXPAND_PARAM for a single parameter expansion.
touch a b c d
c=(*)
printf '"%s"\n' -c${^c}
output:
"-ca"
"-cb"
"-cc"
"-cd"
>
> I think rc has a great non-disruptive solution, but it could be
> improved if the resulting concatenation could be made to be field
> separated (as described below).
As mentioned many times now:
*(P[-c])# in zsh
> Next I would change the shell to pass as a parameter an array of bits
> describing which arguments are expanded from patterns and therefore
> definitely filenames.
That would involve iterating over the arguments and testing whether
they correspond to an existing filename or not. This may give false
positives.
> Next I would have it pass arguments of different types. Aside from the
> globbing issue, this would allow decisions about how to pass numerical
> input to be taken away from individual command and moved to the shell,
> allowing a more consistent user experience and easier programming.
You're basically advocating powershell.
>
> Iwll get of my soap-box now.
And I'll stop not too as I've forgotten what your initial point was. Go
ahead and use whatever shell you want.
Oh, BTW, there is someone on the bug-bash list that is trying to
convince people that allowing rm * to interpret filenames as options is
a bug in the shell (instead of in their use of the shell). Needless to
say, they don't seem to get much support for their cause.
>
> Thanks for your message, which was maybe the only one worth receiving,
> even if I didnt actually receive it.
>
> > Date: Fri, 19 Nov 2021 14:40:45 +1059
> > From: Reuben ua Bríġ
> >
> > Even a distributive operator allowing
> >
> > compile -type1^* -type2^2/*
> >
> > to be interpreted as
> >
> > compile -type 1 <*1> -type 1 <*2> ...
> >
> > would be useful with existing utilities, but Im not aware of any.
>
> > Date: Fri, 19 Nov 2021 16:30:18 +1100
> > From: Reuben ua Bríġ
> >
> > I know rc(1) allows at least
> >
> > c=*
> > cc -c$c
> >
> > I dont think there is any way to make the resulting concatenation
> > field separated ('-c' '*1' ...) for those programs that need it, but
> > oh well. (But I havent read the grammar.)
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: pkg_add with certificate pinning
On 2021-11-19 08:12, Stuart Henderson wrote: On 2021-11-19, Fabio Martins wrote: Sorry if it is a bit off-topic. After reading an article about rogue CA's: https://www.theregister.com/2021/11/19/web_trust_certificates/ I wonder if there is any advantage of using certificate pinning in the process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. There doesn't seem a real advantage here. In terms of checking that files are from a known source, pkg_add checks signatures with signify (so updates over plain http are OK really). Also the checks are done with a tight pledge(7) restriction (and decompressors aren't called until signatures have been checked, they are also restricted). In terms of confidentiality, you can figure out a lot from what's available in the clear even with HTTPS. The IP addresses obviously. SNI hostnames. Request/response lengths are visible, and with a known set of files that anyone can easily fetch like packages (and known interdepencies) this makes it possible to figure out what's installed to some level of accuracy (IIRC espie@ did some research into this). The article you show talks about maliciously implanted root certs, typically installed on "managed" systems (corporate environment etc), or by malware. If something is changing that (/etc/ssl/cert.pem) without your knowledge you have bigger problems. Changes to that do show up in daily security mails though if somebody can change the file they can surely change the script too. If you really want to, you can do cert pinning. Put the desired ca certificate into a separate file, see ftp's -T cafile option, and pass the parameter from pkg_add via the FETCH_CMD variable. But I think it's not really worthwhile here. @stuart @Yifei Thanks for the inputs. Understood it isn't worth doing.
Re: zsh Re: type checking/signalling shell and utilities?
On Fri, Nov 19, 2021 at 03:10:42PM +0100, Kusalananda Kähäri wrote: > On Fri, Nov 19, 2021 at 08:58:00PM +1100, Reuben ua Bríġ wrote: [cut] > > f=* sed -f$f > > In sh (inserts -f as a separate argument before each name that * expands > to): > > set -- * > for name do > set -- "$@" -f "$name" > shift > done > > sed "$@" [cut] Or if you feel rebellious, cat * | sed -f /dev/stdin -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: zsh Re: type checking/signalling shell and utilities?
On Fri, Nov 19, 2021 at 08:58:00PM +1100, Reuben ua Bríġ wrote:
> > Date: Fri, 19 Nov 2021 10:23:51 +0100
> > From: Andreas Kusalananda Kähäri
> >
> > What was the thing about "/" and "ti"?
>
> I might a lot of typos. by "ti" I meant "2". I had the glob "2/*" which
> includes a "/". My point was this does not generally preclude special
> interpretation (someone suggested including a "/" for globs with "rm").
Someone probably suggested using ./ as a prefix to any glob that
otherwise may result in words possibly starting with a dash, such as *
or *.c would possibly do. Using ./* or ./*.c or similar in a loop would
ensure that each generated word is starting with ./ rather than possibly
a dash.
for name in ./*; do
# Will not mistake "$name" as a set of options.
# Because "$name" always starts with ./
utility "$name"
done
or, using -- instead:
for name in *; do
# Will not mistake "$name" as a set of options.
# Because -- disables option parsing.
utility -- "$name"
done
>
>
> > Are you talking about zsh here? Or do you know something about ksh?
> > I know -a{1,2,3} -> -a1 -a2 -a3 but nothing like -a{*} -> -a*1 -a*2
> > ...
>
> > I'm not sure I understand what you want -a{*} to do. Are "1", "2",
> > etc. files? If so, *(P[-a]) in zsh, as already mentioned.
>
> The point is ksh expands "-a{1,2,3}" to "-a1 a2 a3". I had hoped it
The ksh shell would expand -a{1,2,3} to the three strings -a1, -a2, and
-a3.
> might expand "-a{*}" to "-a1 -a2 -a3" in a directory containing the
> files "a", "b", "c".
That makes no sense. You could get -a a -a b -a c from *(P[-a]) in zsh.
> > The -c option to cc does not take arguments. If you just want to list
> > all C files on the command line:
>
> This was a rather bad toy example. On OpenBSD I overuse a default
> make(1) file so I have forgotten how to actually call cc(1).
> Maybe this will help you see the point I was making:
>
> f=* sed -f$f
In sh (inserts -f as a separate argument before each name that * expands
to):
set -- *
for name do
set -- "$@" -f "$name"
shift
done
sed "$@"
In OpenBSD ksh (same result as above):
unset -v args
for name in *; do
set -A args -- "${args[@]}" -f "$name"
done
sed "${args[@]}"
In bash (prepends the string -f directly to each name):
names=(*); sed "${names[@]/#/-f}"
In zsh (as sh and ksh):
sed *(P[-f])
>
> I think sed(1) might actually be what first gave me the idea. I had a
> bunch of scripts and a bunch of inputs, and some expressions, and I
> thought, "wouldnt it be neat if I could do it this way..."
>
> > The es shell is available for OpenBSD. It's not quite rc, but may be
> > close enough.
>
> Strangely enough I have an "rc" package installd, and a ports/plan9/rc
> directory. I havent upgraded and also have a "plan9port" package
> installd, so maybe that has something to do with that. I also have
> butchered my install somewhat, so maybe it is that.
If you have plan9port installed, just prefix commands by 9 to get the
Plan9 variant, e.g. use "9 rc" to start the rc shell, or use "9 sed" to
use Plan9 sed.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: Thinkpad T400 temperature sensors
On Fri, Nov 19, 2021 at 01:58:20PM +0100, Jan Stary wrote: > This is current/amd64 on a Thinkpad T400 > (full dmesg and sysctl hw below). > > It provides various sensors reporting temperatures, > but I don't really know what temperatures these are. > > $ sysctl hw | grep temp > > hw.sensors.cpu0.temp0=39.00 degC > hw.sensors.acpithinkpad0.temp0=48.00 degC > hw.sensors.acpithinkpad0.temp1=41.00 degC > hw.sensors.acpithinkpad0.temp2=34.00 degC > hw.sensors.acpithinkpad0.temp4=25.00 degC > hw.sensors.acpithinkpad0.temp6=25.00 degC > hw.sensors.acpitz0.temp0=48.00 degC (zone temperature) > hw.sensors.acpitz1.temp0=44.00 degC (zone temperature) > hw.sensors.aps0.temp0=255.00 degC > hw.sensors.aps0.temp1=255.00 degC > ... Hi Jan, There is some (emperically derived) info. about the hardware here: https://www.thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T400 And: https://www.sthu.org/misc/t400.html E.g. Index in "thermal" Location 1CPU neighbourhood (also via ACPI THM0) 2Ultrabay 3Express card 4ATI graphics module 5Main battery (always around 50°C) 6n/a (probably ultrabay battery) 7Main Battery (fits about the value reported by smapi) 8n/a (probably ultrabay battery) 9Hard disc 10 Intel graphics module 11 Heatsink? Those numbers are the indicies into the Linux thinkpad_acpi kernel module, made available via '/proc/acpi/ibm/thermal' Maybe that helps. Cheers, Robb.
Thinkpad T400 temperature sensors
This is current/amd64 on a Thinkpad T400 (full dmesg and sysctl hw below). It provides various sensors reporting temperatures, but I don't really know what temperatures these are. $ sysctl hw | grep temp hw.sensors.cpu0.temp0=39.00 degC hw.sensors.acpithinkpad0.temp0=48.00 degC hw.sensors.acpithinkpad0.temp1=41.00 degC hw.sensors.acpithinkpad0.temp2=34.00 degC hw.sensors.acpithinkpad0.temp4=25.00 degC hw.sensors.acpithinkpad0.temp6=25.00 degC hw.sensors.acpitz0.temp0=48.00 degC (zone temperature) hw.sensors.acpitz1.temp0=44.00 degC (zone temperature) hw.sensors.aps0.temp0=255.00 degC hw.sensors.aps0.temp1=255.00 degC By cpu(4), the hw.sensors.cpu0.temp0 is the CPU temperatue (duh). Is there some documentation of what exactly the others are? acpitz(4) and acpithinkpad(4) don't really say. (The aps(4) temperatures are "unused".) Jan OpenBSD 7.0-current (GENERIC.MP) #104: Thu Nov 18 09:10:05 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8461684736 (8069MB) avail mem = 8189267968 (7809MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012 bios0: LENOVO 64741EG acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.33 MHz, 06-17-06 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 266MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.01 MHz, 06-17-06 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x10208086 rev 0x6 acpibat0 at acpi0: BAT0 model "92P1137" serial57 type LION oem "SANYO" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivout0 at acpivideo0: LCD0 acpivideo1 at acpi0: VID_ cpu0: Enhanced SpeedStep 2261 MHz: speeds: 2267, 2266, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0: apic 1 int 16, GM45, gen 4 "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 00:1c:25:9b:0a:23 uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at
Rework UNIX sockets locking to be fine grained
Hi, I'm searching for people who can help me with test of the diff [1] which reworks unix(4) sockets to use fine grained (per-socket) locks. unix(4) sockets are highly used for interprocess communications so this diff could be significant. I'm interesting in all experience, not only in high pressure on unix(4) sockets. If you are just desktop user feel free to test and report too :) Thanks! 1. https://marc.info/?l=openbsd-tech=163723567503091=2
Re: Supermicro IPMIView/iKVM
On 2021-11-19, Allan Streib wrote: > On Thu, Nov 18, 2021, at 6:36 PM, Allan Streib wrote: >> Anyone successfully using SuperMicro's IPMIView20 java >> application on OpenBSD with any of the jdk packages? > > I discovered that the noVNC package includes support for the ATEN iKVM > vnc protocol variant used on some SuperMicro boards; this looks like > it will work for me and be a preferable approach. Yes. Also for some of the boards a newer BMC firmware is available that has built-in HTML5 KVM. -- Please keep replies on the mailing list.
Re: pkg_add with certificate pinning
On 2021-11-19, Fabio Martins wrote: > Sorry if it is a bit off-topic. > > After reading an article about rogue CA's: > > https://www.theregister.com/2021/11/19/web_trust_certificates/ > > I wonder if there is any advantage of using certificate pinning in the > process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. There doesn't seem a real advantage here. In terms of checking that files are from a known source, pkg_add checks signatures with signify (so updates over plain http are OK really). Also the checks are done with a tight pledge(7) restriction (and decompressors aren't called until signatures have been checked, they are also restricted). In terms of confidentiality, you can figure out a lot from what's available in the clear even with HTTPS. The IP addresses obviously. SNI hostnames. Request/response lengths are visible, and with a known set of files that anyone can easily fetch like packages (and known interdepencies) this makes it possible to figure out what's installed to some level of accuracy (IIRC espie@ did some research into this). The article you show talks about maliciously implanted root certs, typically installed on "managed" systems (corporate environment etc), or by malware. If something is changing that (/etc/ssl/cert.pem) without your knowledge you have bigger problems. Changes to that do show up in daily security mails though if somebody can change the file they can surely change the script too. If you really want to, you can do cert pinning. Put the desired ca certificate into a separate file, see ftp's -T cafile option, and pass the parameter from pkg_add via the FETCH_CMD variable. But I think it's not really worthwhile here. -- Please keep replies on the mailing list.
Re: pkg_add with certificate pinning
On 2021-11-19 06:57, Yifei Zhan wrote: On 21/11/19 06:26AM, Fabio Martins wrote: Sorry if it is a bit off-topic. After reading an article about rogue CA's: https://www.theregister.com/2021/11/19/web_trust_certificates/ I wonder if there is any advantage of using certificate pinning in the process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. OpenBSD does not use PKI/web of trust for integrity validation, thus I don't think certificate pinning makes sense for those operations. Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for that purpose. Well said. I believe it would only improve confidentiality, as rogue middleware appliances would not be able to inspect the content of package updates.
pkg_add with certificate pinning
Sorry if it is a bit off-topic. After reading an article about rogue CA's: https://www.theregister.com/2021/11/19/web_trust_certificates/ I wonder if there is any advantage of using certificate pinning in the process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. -- Fabio http://nabundapode.com.br/
Re: zsh Re: type checking/signalling shell and utilities?
On Fri, Nov 19, 2021 at 07:34:58PM +1059, Reuben ua Bríġ wrote:
> > Date: Fri, 19 Nov 2021 08:30:44 +0100
> > From: Andreas Kusalananda Kähäri
> >
> > Ah, so you are talking about options that takes multiple
> > option-arguments.
>
> That roughly correct for what I was saying about lists, but technically
> the list would be a single argument. It is exactly correct for what I
> meant about signalling globs, that is that a parameter (in the form
> of an array of bits) should be past signalling which arguments are
> expanded from a pattern and therefore definitely filenames.
>
> > That's not how options usually work on Unix, at least not with
> > utilities that uses standard command line parsing.
>
> I was thinking of a glob as a sort of pseudo-single-argument.
> find(1) does have for example
>
> find ! ( -cnewer file1 -cnewer file2 )
>
> which is very analogous if not exactly that.
The predicates of find defines a tiny mini-language. The -cnewer string
(as well as -type, -name, -exec, -ls, etc.) are not options. They make
up the find expression, a set of tests to be carried out on each found
pathname. The find utility has options, but these are given before
the search path(s) on the command line (options always comes before
non-options).
[cut]
> > > to work without first checking the names in '.', and even 'ti' if
> > > compile takes arguments with '/' (if you cant think of any UNIX
> > > utilities that do that, shame on you).
> >
> > I'm not seeing you giving an example.
>
> sed /home/d
The sed utility has two basic ways of being used, just like e.g. the
grep utility (which the OpenBSD manual fails to make clear IMHO; you
can't mix them). The first passes the sed editing expression as the
first non-option argument. The second gives the sed editing expression
as one or a series of -e options with arguments. In each case, quoting
the editing expression(s) is geneally a good idea, unless you want
the shell to perform field splitting and filename generation on the
argument(s).
sed 'expression'
sed -e 'expression' -e 'expression' -e 'expression'
grep 'expression'
grep -e 'expression' -e 'expression' -e 'expression'
What was the thing about "/" and "ti"? Using / unquoted on the command
line is not an issue, neither is using the string "ti". The reason
you want to quote the expressions used with sed and grep is that these
usually contain regular expressions and/or spaces. The shell would
splitt the expression on the spaces if they are unquoted, to generate
multiple arguments. The regular expressions may be intpereted as
globbing patterns.
> Are you talking about zsh here? Or do you know something about ksh?
> I know -a{1,2,3} -> -a1 -a2 -a3 but nothing like -a{*} -> -a*1 -a*2 ...
I'm not sure I understand what you want -a{*} to do. Are "1", "2", etc.
files? If so, *(P[-a]) in zsh, as already mentioned.
>
> > It's already been done by the people developing the zsh shell.
> >
> > compile dir1/*(P[-type1]) dir2/*(P[-type2])
> >
> > This would append "-type1" before each name that dir1/* expands to,
> > and similarly for the second globbing pattern. I'm assuming this is
> > what you were looking for.
> >
> > If you want to match only regular files, include hidden names, and
> > remove the pattern if there are no matches,
> >
> > compile dir1/*(.DNP[-type1]) dir2/*(.DNP[-type2])
>
> Oh thats great to know. Thank you for that. I already knew you can do
>
> c=* cc -c$c
The -c option to cc does not take arguments. If you just want to list
all C files on the command line:
cc -c -- *.c
> in rc(1),
The es shell is available for OpenBSD. It's not quite rc, but may be
close enough.
>but the zsh(1) example you provided here has the nice
> advantage that the flag and its argument are field separated and the
> glob disappears if unmatched. I think this is definitely the best that
> can be done in the shell alone, without modifying utilities to read
> extra parameters, but I am certainly not sold on the sugar (syntax),
> but I will take a look at it.
>
> Cheers for that last one.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
