Hi.
On OpenBSD 7.3, I frequently receive the following lines in 'daemon' and
'messages' log files inside /var/log/ directory;
unwind[47246]: validation failure <181.219.85.209.in-addr.arpa. PTR IN>: No
DNSKEY record for key in-addr.arpa. while building chain of trust
unwind[72140]: validation failure <99.74.250.142.in-addr.arpa. PTR IN>: No
DNSKEY record for key in-addr.arpa. while building chain of trust
What are those messages and is there anything that I should do for this?
Thank you very much.
Friday, June 30, 2023
Re: "ticking" noise when recording audio
Sorry for the delay on this, it has been a busy month. I'm finding some
time to get to this.
I enabled UAUDIO_DEBUG and got some info. Here's what I got from
/var/log/messages when I started sndiod w/ debugging & started
running aucat
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 96000 ->
96000 (index 11)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 96000
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 48000 ->
48000 (index 8)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 96000
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 96000 ->
96000 (index 11)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 96000
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x200, index = 0x202, size = 2
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x100, index = 0x202, size = 1
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 48000 ->
48000 (index 8)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 48000
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 48000 ->
48000 (index 8)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 48000
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x201, index = 0x300, size = 2
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x202, index = 0x300, size = 2
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x100, index = 0x300, size = 1
Jun 30 13:51:22 towerDefense /bsd: uaudio_stream_open: rec: blksz =
1920, rate = 96000, fps = 1000
Jun 30 13:51:22 towerDefense /bsd: uaudio_stream_open: spf = 0x1e00000
in [0x1de2000:0x1e1e000]
Jun 30 13:51:22 towerDefense /bsd: uaudio_stream_open: nframes_max = 11,
nframes_mask = 0, maxpkt = 194
Jun 30 13:51:22 towerDefense /bsd: uaudio_stream_open: safe_blksz =
2048, nxfers = 8
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0x22, req = 0x1,
val = 0x100, index = 0x82, size = 3
Jun 30 13:51:22 towerDefense /bsd: uaudio_trigger: preparing
Jun 30 13:51:22 towerDefense /bsd: uaudio_trigger: starting
Jun 30 13:51:22 towerDefense /bsd: uaudio2: 2 null frames out of 11:
incomplete record xfer
Jun 30 13:51:23 towerDefense /bsd: uaudio2: 1 null frames out of 10:
incomplete record xfer
Jun 30 13:51:23 towerDefense last message repeated 2 times
Jun 30 13:51:23 towerDefense /bsd: uaudio_stream_open: play: blksz =
1920, rate = 48000, fps = 1000
Jun 30 13:51:23 towerDefense /bsd: uaudio_stream_open: spf = 0xf00000 in
[0xef1000:0xf0f000]
Jun 30 13:51:23 towerDefense /bsd: uaudio_stream_open: nframes_max = 11,
nframes_mask = 0, maxpkt = 196
Jun 30 13:51:23 towerDefense /bsd: uaudio_stream_open: safe_blksz =
2048, nxfers = 8
Jun 30 13:51:23 towerDefense /bsd: uaudio_req: type = 0x22, req = 0x1,
val = 0x100, index = 0x1, size = 3
Jun 30 13:51:23 towerDefense /bsd: uaudio_trigger: preparing
Jun 30 13:51:23 towerDefense /bsd: uaudio_trigger: starting
Jun 30 13:51:23 towerDefense /bsd: uaudio2: 1 null frames out of 10:
incomplete record xfer
At the same time, here's the debug output from sndiod
sndiod -dd -f rsnd/0 -F rsnd/1 -f rsnd/3 -f rsnd/2
snd0.default: rec=0:1 play=0:1 vol=8388608 dup
snd0.0: rec=0:1 play=0:1 vol=8388608 dup
snd1.1: rec=0:1 play=0:1 vol=8388608 dup
snd2.2: rec=0:1 play=0:1 vol=8388608 dup
snd3.3: rec=0:1 play=0:1 vol=8388608 dup
default/server.device=0:0 at 1 -> opt_dev:default/0: added
default/server.device=1:1 at 2 -> opt_dev:default/1: added
default/server.device=2:0 at 3 -> opt_dev:default/2: added
default/server.device=3:0 at 4 -> opt_dev:default/3: added
app/aucat0.level=127 at 5 -> slot_level:aucat0: added
warning, device opened in rec-only mode
2/input0.level=104 at 6 -> hw:2/64: added
2/input0.mute=0 at 7 -> hw:2/96: added
snd2: software master level control enabled
2/output.level=127 at 8 -> dev_master:2: added
snd2: 96000Hz, s16le, rec 0:0, 16 blocks of 960 frames
app/aucat1.level=127 at 9 -> slot_level:aucat1: added
warning, device opened in play-only mode
1/output0.level=255 at 10 -> hw:1/0: added
1/output1.level=255 at 11 -> hw:1/1: added
1/output0.mute=0 at 12 -> hw:1/32: added
1/output1.mute=0 at 13 -> hw:1/33: added
snd1: 48000Hz, s16le, play 0:1, 16 blocks of 480 frames
snd2: device started
aucat0: attached at -7680 + 0/480
aucat0: 48000Hz, s24le4lsb, rec 0:1, 20 blocks of 480 frames
aucat1: 48000Hz, s24le4lsb, play 0:1, 20 blocks of 480 frames
snd1: device started
aucat1: attached at -7680 + 0/480
aucat0: detached at 0 + 0/960
snd2: device stopped
2/output.level=127 at 8 -> dev_master:2: removed
snd1: device stopped
snd1: software master level control enabled
1/output.level=127 at 10 -> dev_master:1: added
1/output.level=127 at 10 -> dev_master:1: removed
Courtney
On 6/2/23 02:39, Alexandre Ratchov wrote:
> On Thu, Jun 01, 2023 at 11:35:24AM -0700, Courtney Hicks wrote:
>> I hope this reaches you. I think my mail server is having troubles
>> communicating with the mailing list. I changed the rate and buffer
>> size using aucat, not sndiod, and that changed the rate. I have
>> the .wav attached. Also of note, I pasted the wrong aucat command
>> I ran. It should be
>>
>> $ aucat -f snd/1 -o - | aucat -i -
>> or
>> $ aucat -f snd/1 -o output.wav
>>
>> Courtney
>>
> To debug this, you really need to change sndiod options. There is
> buffering at every software (and hardware) layer and we need to tweak
> the uaudio(4) operating mode (I'm suspecting the driver, which is the
> only layer whick behavior depends on the hardware in use).
>
> To do so, I'd suggest to stop sndiod(8) and run in on a terminal with
> the '-dd' options. This allows to quickly tweak the device modes. Example:
>
> $ doas sndiod -dd -z 256 -f rsnd/1
> ^C
> $ doas sndiod -dd -z 320 -r 16000 -f rsnd/1
> ^C
> ...
>
> FWIW, you can see the hardware operating mode by running this command
> while the device is recording:
>
> $ doas audioctl -f /dev/audioctl1
> name=envy0
> mode=play,record
> pause=0
> active=1
> nblks=2
> blksz=240
> rate=48000
> encoding=s24le4msb
> play.channels=2
> play.bytes=5464320
> play.errors=0
> record.channels=2
> record.bytes=5464320
> record.errors=0
>
> Unless this shows what's going on, the next move will be to build a
> kernel with UAUDIO_DEBUG and see if there are warnings on the console.
>
time to get to this.
I enabled UAUDIO_DEBUG and got some info. Here's what I got from
/var/log/messages when I started sndiod w/ debugging & started
running aucat
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 96000 ->
96000 (index 11)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 96000
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 48000 ->
48000 (index 8)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 96000
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 96000 ->
96000 (index 11)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 96000
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x200, index = 0x202, size = 2
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x100, index = 0x202, size = 1
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 48000 ->
48000 (index 8)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 48000
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate 48000 ->
48000 (index 8)
Jun 30 13:51:22 towerDefense /bsd: uaudio_set_params: rate = 48000
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x201, index = 0x300, size = 2
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x202, index = 0x300, size = 2
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0xa1, req = 0x81,
val = 0x100, index = 0x300, size = 1
Jun 30 13:51:22 towerDefense /bsd: uaudio_stream_open: rec: blksz =
1920, rate = 96000, fps = 1000
Jun 30 13:51:22 towerDefense /bsd: uaudio_stream_open: spf = 0x1e00000
in [0x1de2000:0x1e1e000]
Jun 30 13:51:22 towerDefense /bsd: uaudio_stream_open: nframes_max = 11,
nframes_mask = 0, maxpkt = 194
Jun 30 13:51:22 towerDefense /bsd: uaudio_stream_open: safe_blksz =
2048, nxfers = 8
Jun 30 13:51:22 towerDefense /bsd: uaudio_req: type = 0x22, req = 0x1,
val = 0x100, index = 0x82, size = 3
Jun 30 13:51:22 towerDefense /bsd: uaudio_trigger: preparing
Jun 30 13:51:22 towerDefense /bsd: uaudio_trigger: starting
Jun 30 13:51:22 towerDefense /bsd: uaudio2: 2 null frames out of 11:
incomplete record xfer
Jun 30 13:51:23 towerDefense /bsd: uaudio2: 1 null frames out of 10:
incomplete record xfer
Jun 30 13:51:23 towerDefense last message repeated 2 times
Jun 30 13:51:23 towerDefense /bsd: uaudio_stream_open: play: blksz =
1920, rate = 48000, fps = 1000
Jun 30 13:51:23 towerDefense /bsd: uaudio_stream_open: spf = 0xf00000 in
[0xef1000:0xf0f000]
Jun 30 13:51:23 towerDefense /bsd: uaudio_stream_open: nframes_max = 11,
nframes_mask = 0, maxpkt = 196
Jun 30 13:51:23 towerDefense /bsd: uaudio_stream_open: safe_blksz =
2048, nxfers = 8
Jun 30 13:51:23 towerDefense /bsd: uaudio_req: type = 0x22, req = 0x1,
val = 0x100, index = 0x1, size = 3
Jun 30 13:51:23 towerDefense /bsd: uaudio_trigger: preparing
Jun 30 13:51:23 towerDefense /bsd: uaudio_trigger: starting
Jun 30 13:51:23 towerDefense /bsd: uaudio2: 1 null frames out of 10:
incomplete record xfer
At the same time, here's the debug output from sndiod
sndiod -dd -f rsnd/0 -F rsnd/1 -f rsnd/3 -f rsnd/2
snd0.default: rec=0:1 play=0:1 vol=8388608 dup
snd0.0: rec=0:1 play=0:1 vol=8388608 dup
snd1.1: rec=0:1 play=0:1 vol=8388608 dup
snd2.2: rec=0:1 play=0:1 vol=8388608 dup
snd3.3: rec=0:1 play=0:1 vol=8388608 dup
default/server.device=0:0 at 1 -> opt_dev:default/0: added
default/server.device=1:1 at 2 -> opt_dev:default/1: added
default/server.device=2:0 at 3 -> opt_dev:default/2: added
default/server.device=3:0 at 4 -> opt_dev:default/3: added
app/aucat0.level=127 at 5 -> slot_level:aucat0: added
warning, device opened in rec-only mode
2/input0.level=104 at 6 -> hw:2/64: added
2/input0.mute=0 at 7 -> hw:2/96: added
snd2: software master level control enabled
2/output.level=127 at 8 -> dev_master:2: added
snd2: 96000Hz, s16le, rec 0:0, 16 blocks of 960 frames
app/aucat1.level=127 at 9 -> slot_level:aucat1: added
warning, device opened in play-only mode
1/output0.level=255 at 10 -> hw:1/0: added
1/output1.level=255 at 11 -> hw:1/1: added
1/output0.mute=0 at 12 -> hw:1/32: added
1/output1.mute=0 at 13 -> hw:1/33: added
snd1: 48000Hz, s16le, play 0:1, 16 blocks of 480 frames
snd2: device started
aucat0: attached at -7680 + 0/480
aucat0: 48000Hz, s24le4lsb, rec 0:1, 20 blocks of 480 frames
aucat1: 48000Hz, s24le4lsb, play 0:1, 20 blocks of 480 frames
snd1: device started
aucat1: attached at -7680 + 0/480
aucat0: detached at 0 + 0/960
snd2: device stopped
2/output.level=127 at 8 -> dev_master:2: removed
snd1: device stopped
snd1: software master level control enabled
1/output.level=127 at 10 -> dev_master:1: added
1/output.level=127 at 10 -> dev_master:1: removed
Courtney
On 6/2/23 02:39, Alexandre Ratchov wrote:
> On Thu, Jun 01, 2023 at 11:35:24AM -0700, Courtney Hicks wrote:
>> I hope this reaches you. I think my mail server is having troubles
>> communicating with the mailing list. I changed the rate and buffer
>> size using aucat, not sndiod, and that changed the rate. I have
>> the .wav attached. Also of note, I pasted the wrong aucat command
>> I ran. It should be
>>
>> $ aucat -f snd/1 -o - | aucat -i -
>> or
>> $ aucat -f snd/1 -o output.wav
>>
>> Courtney
>>
> To debug this, you really need to change sndiod options. There is
> buffering at every software (and hardware) layer and we need to tweak
> the uaudio(4) operating mode (I'm suspecting the driver, which is the
> only layer whick behavior depends on the hardware in use).
>
> To do so, I'd suggest to stop sndiod(8) and run in on a terminal with
> the '-dd' options. This allows to quickly tweak the device modes. Example:
>
> $ doas sndiod -dd -z 256 -f rsnd/1
> ^C
> $ doas sndiod -dd -z 320 -r 16000 -f rsnd/1
> ^C
> ...
>
> FWIW, you can see the hardware operating mode by running this command
> while the device is recording:
>
> $ doas audioctl -f /dev/audioctl1
> name=envy0
> mode=play,record
> pause=0
> active=1
> nblks=2
> blksz=240
> rate=48000
> encoding=s24le4msb
> play.channels=2
> play.bytes=5464320
> play.errors=0
> record.channels=2
> record.bytes=5464320
> record.errors=0
>
> Unless this shows what's going on, the next move will be to build a
> kernel with UAUDIO_DEBUG and see if there are warnings on the console.
>
Re: lang/* BTI breakage
Christian Weisgerber:
> Since BTI affects any and all compilers that generate executable code,
> I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> list of failures:
After the jdk and sbcl updates:
lang/crystal
lang/fpc
lang/gcc/11
lang/ghc
lang/go # also fails on CPUs with advanced xsave
lang/gprolog
lang/ldc
lang/mono
lang/ocaml
--
Christian "naddy" Weisgerber naddy@mips.inka.de
> Since BTI affects any and all compilers that generate executable code,
> I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> list of failures:
After the jdk and sbcl updates:
lang/crystal
lang/fpc
lang/gcc/11
lang/ghc
lang/go # also fails on CPUs with advanced xsave
lang/gprolog
lang/ldc
lang/mono
lang/ocaml
--
Christian "naddy" Weisgerber naddy@mips.inka.de
APCI on old Thinkpad
I have an old thinkpad - really old
On booting it stops when listing the acpi sleep states and does nothing
more. This is dmesg:
OpenBSD 7.3 (GENERIC) #660: Sat Mar 25 11:17:44 MDT 2023
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 200753152 (191MB)
avail mem = 179949568 (171MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 11/01/99, BIOS32 rev. 0 @ 0xfd840, SMBIOS rev. 2.2 @ 0xe0010 (35 entries)
bios0: vendor IBM version "IMET56WW" date 11/01/99
bios0: IBM 26443AG
acpi at bios0: ACPI 1.0
acpi0: sleep states S0 S1 S3 S4 S5
It can boot when disabling acpi (see dmesg below).
But then I can't zzz/ZZZ.
Ist there something other I can than disabling acpi?
Or is this old device simply not supported any more?
OpenBSD 7.3 (GENERIC) #660: Sat Mar 25 11:17:44 MDT 2023
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 200753152 (191MB)
avail mem = 179949568 (171MB)
User Kernel Config
UKC> disable acpi
526 acpi0 disabled
UKC> quit
Continuing...
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 11/01/99, BIOS32 rev. 0 @ 0xfd840, SMBIOS rev. 2.2 @ 0xe0010 (35 entries)
bios0: vendor IBM version "IMET56WW" date 11/01/99
bios0: IBM 26443AG
acpi at bios0 function 0x0 not configured
apm0 at bios0: Power Management spec V1.2
pcibios0 at bios0: rev 2.1 @ 0xfd7d0/0x830
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdef0/192 (10 entries)
pcibios0: PCI Interrupt Router at 000:06:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #9 is the last bus
bios0: ROM list: 0xc0000/0xc000
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel Celeron ("GenuineIntel" 686-class, 256KB L2 cache) 366 MHz, 06-06-0a
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xf8000000, size 0x4000000
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "Neomagic Magicgraph NM2200" rev 0x20
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
cbb0 at pci0 dev 2 function 0 "TI PCI1450 CardBus" rev 0x03: irq 11
cbb1 at pci0 dev 2 function 1 "TI PCI1450 CardBus" rev 0x03: irq 11
clcs0 at pci0 dev 5 function 0 "Cirrus Logic CS4280/46xx CrystalClear" rev 0x01: irq 11
ac97: codec id 0x43525903 (Cirrus Logic CS4297 rev 3)
ac97: codec features headphone, 18 bit DAC, 18 bit ADC, No 3D Stereo
pcib0 at pci0 dev 6 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 6 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <IBM-DBCA-204860>
wd0: 16-sector PIO, LBA, 3909MB, 8007552 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <TOSHIBA, CD-ROM XM-1902B, 1717> removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 6 function 2 "Intel 82371AB USB" rev 0x01: irq 11
piixpm0 at pci0 dev 6 function 3 "Intel 82371AB Power" rev 0x02: SMI
iic0 at piixpm0
"AT&T/Lucent LTMODEM" rev 0x01 at pci0 dev 7 function 0 not configured
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 7 device 0 cacheline 0x8, lattimer 0xb0
pcmcia0 at cardslot0
cbb1: bad Vcc request. sock_ctrl 0x0, sock_status 0x30000b20
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 9 device 0 cacheline 0x8, lattimer 0xb0
pcmcia1 at cardslot1
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt2 at isa0 port 0x3bc/4: polled
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
cbb1: bad Vcc request. sock_ctrl 0x30, sock_status 0x30000b20
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (bdf7ab95ec79e5e9.a) swap on wd0b dump on wd0b
rl0 at cardbus1 dev 0 function 0 "D-Link DFE-690TXD" rev 0x10: irq 11, address 00:11:95:5a:f8:7a
rlphy0 at rl0 phy 0: RTL internal PHY
clcs0: firmware loaded
audio0 at clcs0
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
On booting it stops when listing the acpi sleep states and does nothing
more. This is dmesg:
OpenBSD 7.3 (GENERIC) #660: Sat Mar 25 11:17:44 MDT 2023
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 200753152 (191MB)
avail mem = 179949568 (171MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 11/01/99, BIOS32 rev. 0 @ 0xfd840, SMBIOS rev. 2.2 @ 0xe0010 (35 entries)
bios0: vendor IBM version "IMET56WW" date 11/01/99
bios0: IBM 26443AG
acpi at bios0: ACPI 1.0
acpi0: sleep states S0 S1 S3 S4 S5
It can boot when disabling acpi (see dmesg below).
But then I can't zzz/ZZZ.
Ist there something other I can than disabling acpi?
Or is this old device simply not supported any more?
OpenBSD 7.3 (GENERIC) #660: Sat Mar 25 11:17:44 MDT 2023
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 200753152 (191MB)
avail mem = 179949568 (171MB)
User Kernel Config
UKC> disable acpi
526 acpi0 disabled
UKC> quit
Continuing...
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 11/01/99, BIOS32 rev. 0 @ 0xfd840, SMBIOS rev. 2.2 @ 0xe0010 (35 entries)
bios0: vendor IBM version "IMET56WW" date 11/01/99
bios0: IBM 26443AG
acpi at bios0 function 0x0 not configured
apm0 at bios0: Power Management spec V1.2
pcibios0 at bios0: rev 2.1 @ 0xfd7d0/0x830
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdef0/192 (10 entries)
pcibios0: PCI Interrupt Router at 000:06:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #9 is the last bus
bios0: ROM list: 0xc0000/0xc000
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel Celeron ("GenuineIntel" 686-class, 256KB L2 cache) 366 MHz, 06-06-0a
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xf8000000, size 0x4000000
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "Neomagic Magicgraph NM2200" rev 0x20
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
cbb0 at pci0 dev 2 function 0 "TI PCI1450 CardBus" rev 0x03: irq 11
cbb1 at pci0 dev 2 function 1 "TI PCI1450 CardBus" rev 0x03: irq 11
clcs0 at pci0 dev 5 function 0 "Cirrus Logic CS4280/46xx CrystalClear" rev 0x01: irq 11
ac97: codec id 0x43525903 (Cirrus Logic CS4297 rev 3)
ac97: codec features headphone, 18 bit DAC, 18 bit ADC, No 3D Stereo
pcib0 at pci0 dev 6 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 6 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <IBM-DBCA-204860>
wd0: 16-sector PIO, LBA, 3909MB, 8007552 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <TOSHIBA, CD-ROM XM-1902B, 1717> removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 6 function 2 "Intel 82371AB USB" rev 0x01: irq 11
piixpm0 at pci0 dev 6 function 3 "Intel 82371AB Power" rev 0x02: SMI
iic0 at piixpm0
"AT&T/Lucent LTMODEM" rev 0x01 at pci0 dev 7 function 0 not configured
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 7 device 0 cacheline 0x8, lattimer 0xb0
pcmcia0 at cardslot0
cbb1: bad Vcc request. sock_ctrl 0x0, sock_status 0x30000b20
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 9 device 0 cacheline 0x8, lattimer 0xb0
pcmcia1 at cardslot1
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt2 at isa0 port 0x3bc/4: polled
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
cbb1: bad Vcc request. sock_ctrl 0x30, sock_status 0x30000b20
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (bdf7ab95ec79e5e9.a) swap on wd0b dump on wd0b
rl0 at cardbus1 dev 0 function 0 "D-Link DFE-690TXD" rev 0x10: irq 11, address 00:11:95:5a:f8:7a
rlphy0 at rl0 phy 0: RTL internal PHY
clcs0: firmware loaded
audio0 at clcs0
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
Re: lang/* BTI breakage
Hi,
On Thu, Jun 29, 2023 at 10:55:34PM -0700, Greg Steuck wrote:
> Christian Weisgerber <naddy@mips.inka.de> writes:
>
> > Since BTI affects any and all compilers that generate executable code,
> > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> > list of failures:
> >
> > devel/jdk/1.8 # needs new bootstrap
> > lang/crystal
> > lang/fpc
> > lang/gcc/11
> > lang/ghc
>
> Naturally, as kili@ suspected, we need a new bootstrap with the right
> flags plumbed through. Unfortunately I don't have access to the hardware
> with this feature.
Same here. Could someone be so kind to try the diff below? It uses a
bootstrap I built from lang/ghc-8.10.7 with similar changes.
If it works, I'll commit both (lang/ghc and lang/ghc-8.10.7) and also
look to integrate Gregs work getting rid of USE_NOEXECONLY.
Ciao,
Kili
Index: Makefile
===================================================================
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.211
diff -u -p -r1.211 Makefile
--- Makefile 17 Mar 2023 10:40:44 -0000 1.211
+++ Makefile 30 Jun 2023 19:05:02 -0000
@@ -11,14 +11,16 @@ NO_CCACHE = Yes
# Upstream bug: https://gitlab.haskell.org/ghc/ghc/-/issues/22782
USE_NOEXECONLY = Yes
+USE_NOBTCFI = Yes
+
GHC_VERSION = 9.2.7
-REVISION = 1
+REVISION = 2
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
# Version of the precompiled binaries
-BIN_VER = 8.10.7.20230316
+BIN_VER = 8.10.7.20230613
# lang/python needed for regression tests.
MODULES = lang/python
@@ -114,7 +116,8 @@ CONFIGURE_ARGS += --with-ffi-includes=${
CONFIGURE_ENV += SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
-GHC_CC_OPTS = -Wl,--no-execute-only -Qunused-arguments
+GHC_CC_OPTS = -Wl,--no-execute-only -Qunused-arguments \
+ -Wl,-z,nobtcfi
CONFIGURE_ENV += CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
CONF_GCC_LINKER_OPTS_STAGE1="${GHC_CC_OPTS}" \
CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}" \
Index: distinfo
===================================================================
RCS file: /cvs/ports/lang/ghc/distinfo,v
retrieving revision 1.67
diff -u -p -r1.67 distinfo
--- distinfo 17 Mar 2023 10:40:44 -0000 1.67
+++ distinfo 30 Jun 2023 19:05:02 -0000
@@ -1,8 +1,8 @@
-SHA256 (ghc/ghc-8.10.7.20230316-amd64-unknown-openbsd.tar.xz) = rj7ePY2zwgajLYmuRTyGi+TaJVFnE13TdaNpmPjEd1I=
-SHA256 (ghc/ghc-8.10.7.20230316-shlibs-amd64.tar.gz) = 8QVqNJq6XGI+Xw9Hdf4uMDAeYY9V97U0DDJFPePDe2U=
+SHA256 (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) = /QCac6kB92pFCO9fzn90h/bFJysRl8GUQjOHBVA/5SA=
+SHA256 (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) = LpQDN0fV+YASghLoGTjn0yzEeuYPNW9gtUasieUgu+g=
SHA256 (ghc/ghc-9.2.7-src.tar.xz) = olNWehe3NKTA3Q/6KW0zwqW1pUp335iIBqKh4cp+iLg=
SHA256 (ghc/ghc-9.2.7-testsuite.tar.xz) = JJSvF12xtiODaWBBo/N+s2VPyN9R8SifTygu6GsJ+1A=
-SIZE (ghc/ghc-8.10.7.20230316-amd64-unknown-openbsd.tar.xz) = 48940296
-SIZE (ghc/ghc-8.10.7.20230316-shlibs-amd64.tar.gz) = 2923557
+SIZE (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) = 48998912
+SIZE (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) = 2941676
SIZE (ghc/ghc-9.2.7-src.tar.xz) = 24610432
SIZE (ghc/ghc-9.2.7-testsuite.tar.xz) = 3219572
On Thu, Jun 29, 2023 at 10:55:34PM -0700, Greg Steuck wrote:
> Christian Weisgerber <naddy@mips.inka.de> writes:
>
> > Since BTI affects any and all compilers that generate executable code,
> > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> > list of failures:
> >
> > devel/jdk/1.8 # needs new bootstrap
> > lang/crystal
> > lang/fpc
> > lang/gcc/11
> > lang/ghc
>
> Naturally, as kili@ suspected, we need a new bootstrap with the right
> flags plumbed through. Unfortunately I don't have access to the hardware
> with this feature.
Same here. Could someone be so kind to try the diff below? It uses a
bootstrap I built from lang/ghc-8.10.7 with similar changes.
If it works, I'll commit both (lang/ghc and lang/ghc-8.10.7) and also
look to integrate Gregs work getting rid of USE_NOEXECONLY.
Ciao,
Kili
Index: Makefile
===================================================================
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.211
diff -u -p -r1.211 Makefile
--- Makefile 17 Mar 2023 10:40:44 -0000 1.211
+++ Makefile 30 Jun 2023 19:05:02 -0000
@@ -11,14 +11,16 @@ NO_CCACHE = Yes
# Upstream bug: https://gitlab.haskell.org/ghc/ghc/-/issues/22782
USE_NOEXECONLY = Yes
+USE_NOBTCFI = Yes
+
GHC_VERSION = 9.2.7
-REVISION = 1
+REVISION = 2
DISTNAME = ghc-${GHC_VERSION}
CATEGORIES = lang devel
HOMEPAGE = https://www.haskell.org/ghc/
# Version of the precompiled binaries
-BIN_VER = 8.10.7.20230316
+BIN_VER = 8.10.7.20230613
# lang/python needed for regression tests.
MODULES = lang/python
@@ -114,7 +116,8 @@ CONFIGURE_ARGS += --with-ffi-includes=${
CONFIGURE_ENV += SPHINXBUILD=${LOCALBASE}/bin/sphinx-build${MODPY_BIN_SUFFIX}
-GHC_CC_OPTS = -Wl,--no-execute-only -Qunused-arguments
+GHC_CC_OPTS = -Wl,--no-execute-only -Qunused-arguments \
+ -Wl,-z,nobtcfi
CONFIGURE_ENV += CONF_GCC_LINKER_OPTS_STAGE0="${GHC_CC_OPTS}" \
CONF_GCC_LINKER_OPTS_STAGE1="${GHC_CC_OPTS}" \
CONF_GCC_LINKER_OPTS_STAGE2="${GHC_CC_OPTS}" \
Index: distinfo
===================================================================
RCS file: /cvs/ports/lang/ghc/distinfo,v
retrieving revision 1.67
diff -u -p -r1.67 distinfo
--- distinfo 17 Mar 2023 10:40:44 -0000 1.67
+++ distinfo 30 Jun 2023 19:05:02 -0000
@@ -1,8 +1,8 @@
-SHA256 (ghc/ghc-8.10.7.20230316-amd64-unknown-openbsd.tar.xz) = rj7ePY2zwgajLYmuRTyGi+TaJVFnE13TdaNpmPjEd1I=
-SHA256 (ghc/ghc-8.10.7.20230316-shlibs-amd64.tar.gz) = 8QVqNJq6XGI+Xw9Hdf4uMDAeYY9V97U0DDJFPePDe2U=
+SHA256 (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) = /QCac6kB92pFCO9fzn90h/bFJysRl8GUQjOHBVA/5SA=
+SHA256 (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) = LpQDN0fV+YASghLoGTjn0yzEeuYPNW9gtUasieUgu+g=
SHA256 (ghc/ghc-9.2.7-src.tar.xz) = olNWehe3NKTA3Q/6KW0zwqW1pUp335iIBqKh4cp+iLg=
SHA256 (ghc/ghc-9.2.7-testsuite.tar.xz) = JJSvF12xtiODaWBBo/N+s2VPyN9R8SifTygu6GsJ+1A=
-SIZE (ghc/ghc-8.10.7.20230316-amd64-unknown-openbsd.tar.xz) = 48940296
-SIZE (ghc/ghc-8.10.7.20230316-shlibs-amd64.tar.gz) = 2923557
+SIZE (ghc/ghc-8.10.7.20230613-amd64-unknown-openbsd.tar.xz) = 48998912
+SIZE (ghc/ghc-8.10.7.20230613-shlibs-amd64.tar.gz) = 2941676
SIZE (ghc/ghc-9.2.7-src.tar.xz) = 24610432
SIZE (ghc/ghc-9.2.7-testsuite.tar.xz) = 3219572
Re: emulators/retroarch breakage
Ryan Freeman writes:
> Attached another diff with the REVISION bump as there was another bump
> for turning off FLAC since you originally posted:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/emulators/retroarch/Makefile?rev=1.26&content-type=text/plain
Thanks for testing and the fresh diff. I have committed it since it
unbreaks the build.
> Attached another diff with the REVISION bump as there was another bump
> for turning off FLAC since you originally posted:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/emulators/retroarch/Makefile?rev=1.26&content-type=text/plain
Thanks for testing and the fresh diff. I have committed it since it
unbreaks the build.
Re: x11/stumpwm: few adjustments after lang/sbcl update
On Fri, Jun 30, 2023, at 20:36, Sebastien Marie wrote:
> Hi,
>
> As lang/sbcl has been updated to 2.3.6, the compression method changed
> from libz
> to libzstd.
>
> As stumpwm is built using sbcl, the port needs few adjustments to add
> LIB_DEPENDS on zstd, and updated WANTLIB.
>
> Comments or OK ?
> --
> Sebastien Marie
>
> diff /home/semarie/repos/openbsd/ports
> commit - f2b2271db0cce22f098315362598c10c5db64ead
> path + /home/semarie/repos/openbsd/ports
> blob - 1fe35715ef106358692d35766dd50025d89563b0
> file + x11/stumpwm/Makefile
> --- x11/stumpwm/Makefile
> +++ x11/stumpwm/Makefile
> @@ -2,6 +2,7 @@ DISTNAME= stumpwm-${VERSION}
>
> VERSION= 22.11
> DISTNAME= stumpwm-${VERSION}
> +REVISION= 0
>
> CATEGORIES= x11
>
> @@ -12,7 +13,7 @@ WANTLIB += c m pthread util z
> # GPLv2
> PERMIT_PACKAGE= Yes
>
> -WANTLIB += c m pthread util z
> +WANTLIB += c m pthread util zstd
>
> MASTER_SITES= https://github.com/stumpwm/stumpwm/archive/
> MASTER_SITES0= https://github.com/edicl/cl-ppcre/archive/
> @@ -26,6 +27,7 @@ BUILD_DEPENDS= lang/sbcl,threads \
>
> BUILD_DEPENDS= lang/sbcl,threads \
> print/texinfo
> +LIB_DEPENDS= archivers/zstd
>
> AUTOCONF_VERSION= 2.69
> CONFIGURE_STYLE= autoconf no-autoheader
Looks good to me.
Timo
> Hi,
>
> As lang/sbcl has been updated to 2.3.6, the compression method changed
> from libz
> to libzstd.
>
> As stumpwm is built using sbcl, the port needs few adjustments to add
> LIB_DEPENDS on zstd, and updated WANTLIB.
>
> Comments or OK ?
> --
> Sebastien Marie
>
> diff /home/semarie/repos/openbsd/ports
> commit - f2b2271db0cce22f098315362598c10c5db64ead
> path + /home/semarie/repos/openbsd/ports
> blob - 1fe35715ef106358692d35766dd50025d89563b0
> file + x11/stumpwm/Makefile
> --- x11/stumpwm/Makefile
> +++ x11/stumpwm/Makefile
> @@ -2,6 +2,7 @@ DISTNAME= stumpwm-${VERSION}
>
> VERSION= 22.11
> DISTNAME= stumpwm-${VERSION}
> +REVISION= 0
>
> CATEGORIES= x11
>
> @@ -12,7 +13,7 @@ WANTLIB += c m pthread util z
> # GPLv2
> PERMIT_PACKAGE= Yes
>
> -WANTLIB += c m pthread util z
> +WANTLIB += c m pthread util zstd
>
> MASTER_SITES= https://github.com/stumpwm/stumpwm/archive/
> MASTER_SITES0= https://github.com/edicl/cl-ppcre/archive/
> @@ -26,6 +27,7 @@ BUILD_DEPENDS= lang/sbcl,threads \
>
> BUILD_DEPENDS= lang/sbcl,threads \
> print/texinfo
> +LIB_DEPENDS= archivers/zstd
>
> AUTOCONF_VERSION= 2.69
> CONFIGURE_STYLE= autoconf no-autoheader
Looks good to me.
Timo
Re: lang/sbcl: update to 2.3.6 (latest) and take MAINTAINER
On Fri, Jun 30, 2023 at 07:34:05PM +0200, developer@robert-palm.de wrote:
> Zitat von Sebastien Marie <semarie@online.fr>:
> >
> > The port is buildable on wider architectures range.
> >
>
> Thank you. Will it be available for RISC V, too ?
>
yes, riscv64 should have it.
I know sbcl has code for it, but as I don't have access to a riscv64 host to
check that it build fine on OpenBSD.
The bootstrapping is done natively using lang/ecl (which is C code).
I have only tested aarch64 (arm64) and it was fine.
--
Sebastien Marie
> Zitat von Sebastien Marie <semarie@online.fr>:
> >
> > The port is buildable on wider architectures range.
> >
>
> Thank you. Will it be available for RISC V, too ?
>
yes, riscv64 should have it.
I know sbcl has code for it, but as I don't have access to a riscv64 host to
check that it build fine on OpenBSD.
The bootstrapping is done natively using lang/ecl (which is C code).
I have only tested aarch64 (arm64) and it was fine.
--
Sebastien Marie
x11/stumpwm: few adjustments after lang/sbcl update
Hi,
As lang/sbcl has been updated to 2.3.6, the compression method changed from libz
to libzstd.
As stumpwm is built using sbcl, the port needs few adjustments to add
LIB_DEPENDS on zstd, and updated WANTLIB.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - f2b2271db0cce22f098315362598c10c5db64ead
path + /home/semarie/repos/openbsd/ports
blob - 1fe35715ef106358692d35766dd50025d89563b0
file + x11/stumpwm/Makefile
--- x11/stumpwm/Makefile
+++ x11/stumpwm/Makefile
@@ -2,6 +2,7 @@ DISTNAME= stumpwm-${VERSION}
VERSION= 22.11
DISTNAME= stumpwm-${VERSION}
+REVISION= 0
CATEGORIES= x11
@@ -12,7 +13,7 @@ WANTLIB += c m pthread util z
# GPLv2
PERMIT_PACKAGE= Yes
-WANTLIB += c m pthread util z
+WANTLIB += c m pthread util zstd
MASTER_SITES= https://github.com/stumpwm/stumpwm/archive/
MASTER_SITES0= https://github.com/edicl/cl-ppcre/archive/
@@ -26,6 +27,7 @@ BUILD_DEPENDS= lang/sbcl,threads \
BUILD_DEPENDS= lang/sbcl,threads \
print/texinfo
+LIB_DEPENDS= archivers/zstd
AUTOCONF_VERSION= 2.69
CONFIGURE_STYLE= autoconf no-autoheader
As lang/sbcl has been updated to 2.3.6, the compression method changed from libz
to libzstd.
As stumpwm is built using sbcl, the port needs few adjustments to add
LIB_DEPENDS on zstd, and updated WANTLIB.
Comments or OK ?
--
Sebastien Marie
diff /home/semarie/repos/openbsd/ports
commit - f2b2271db0cce22f098315362598c10c5db64ead
path + /home/semarie/repos/openbsd/ports
blob - 1fe35715ef106358692d35766dd50025d89563b0
file + x11/stumpwm/Makefile
--- x11/stumpwm/Makefile
+++ x11/stumpwm/Makefile
@@ -2,6 +2,7 @@ DISTNAME= stumpwm-${VERSION}
VERSION= 22.11
DISTNAME= stumpwm-${VERSION}
+REVISION= 0
CATEGORIES= x11
@@ -12,7 +13,7 @@ WANTLIB += c m pthread util z
# GPLv2
PERMIT_PACKAGE= Yes
-WANTLIB += c m pthread util z
+WANTLIB += c m pthread util zstd
MASTER_SITES= https://github.com/stumpwm/stumpwm/archive/
MASTER_SITES0= https://github.com/edicl/cl-ppcre/archive/
@@ -26,6 +27,7 @@ BUILD_DEPENDS= lang/sbcl,threads \
BUILD_DEPENDS= lang/sbcl,threads \
print/texinfo
+LIB_DEPENDS= archivers/zstd
AUTOCONF_VERSION= 2.69
CONFIGURE_STYLE= autoconf no-autoheader
Re: lang/sbcl: update to 2.3.6 (latest) and take MAINTAINER
Zitat von Sebastien Marie <semarie@online.fr>:
> Hi,
>
> With latest changes on ecl, we are able to update sbcl to latest
> version (2.3.6).
>
> As maintainer systematically timeout since several years now, I am
> taking over
> the maintainership (and no reply on private mail asking about
> continuing or not
> to maintain lang/sbcl).
>
> I have mostly rewritten the port to ease testing building it with several
> bootstraps (ecl, clisp, sbcl) on one architecture, and drop some historical
> parts.
>
> Regarding the way to build sbcl, it defaults to using lang/ecl (which is
> portable as written in C), and use clisp for some archs only (amd64
> and powerpc,
> as currently) as it is more fast.
>
>
> The mail includes:
> - a proper tarball (as for a new port)
> - a diff (for braves diff readers)
>
> I tested:
> - on amd64, building with clisp (default), ecl and sbcl (2.2.5p0 and 2.3.6)
> - on aarch64, building with ecl, and sbcl (2.3.6)
> - all dependencies are still building on amd64
>
> The port is buildable on wider architectures range.
>
> Comments or OK ?
> --
> Sebastien Marie
Thank you. Will it be available for RISC V, too ?
> Hi,
>
> With latest changes on ecl, we are able to update sbcl to latest
> version (2.3.6).
>
> As maintainer systematically timeout since several years now, I am
> taking over
> the maintainership (and no reply on private mail asking about
> continuing or not
> to maintain lang/sbcl).
>
> I have mostly rewritten the port to ease testing building it with several
> bootstraps (ecl, clisp, sbcl) on one architecture, and drop some historical
> parts.
>
> Regarding the way to build sbcl, it defaults to using lang/ecl (which is
> portable as written in C), and use clisp for some archs only (amd64
> and powerpc,
> as currently) as it is more fast.
>
>
> The mail includes:
> - a proper tarball (as for a new port)
> - a diff (for braves diff readers)
>
> I tested:
> - on amd64, building with clisp (default), ecl and sbcl (2.2.5p0 and 2.3.6)
> - on aarch64, building with ecl, and sbcl (2.3.6)
> - all dependencies are still building on amd64
>
> The port is buildable on wider architectures range.
>
> Comments or OK ?
> --
> Sebastien Marie
Thank you. Will it be available for RISC V, too ?
Re: lang/* BTI breakage - lang/sbcl
Zitat von Theo de Raadt <deraadt@openbsd.org>:
> Sebastien Marie <semarie@online.fr> wrote:
>
>> sbcl compilation works by generating native code inside live
>> managed memory, and
>> permits to save the whole memory image to a file.
>>
>> it is why the binary currently also needs WX and RX memory (I
>> intent to work a
>> bit on it if possible).
>>
>> When generating an executable, it is copying /usr/local/bin/sbcl
>> binary as base,
>> and append the (optionally compressed) memory image to the file, to create a
>> standalone executable.
>>
>> When the output file is executed, it is reading its own image, loads it in
>> memory, and use an entrypoint for loaded code.
>>
>> So the generated file has all the flags it needs to run (because copied from
>> /usr/local/bin/sbcl binary).
>
> It is ridiculous.
>
> Even emacs stopped doing that.
Out of interest - what exactly? What changed in Emacs? Thanks.
> Sebastien Marie <semarie@online.fr> wrote:
>
>> sbcl compilation works by generating native code inside live
>> managed memory, and
>> permits to save the whole memory image to a file.
>>
>> it is why the binary currently also needs WX and RX memory (I
>> intent to work a
>> bit on it if possible).
>>
>> When generating an executable, it is copying /usr/local/bin/sbcl
>> binary as base,
>> and append the (optionally compressed) memory image to the file, to create a
>> standalone executable.
>>
>> When the output file is executed, it is reading its own image, loads it in
>> memory, and use an entrypoint for loaded code.
>>
>> So the generated file has all the flags it needs to run (because copied from
>> /usr/local/bin/sbcl binary).
>
> It is ridiculous.
>
> Even emacs stopped doing that.
Out of interest - what exactly? What changed in Emacs? Thanks.
[new] lang/nickel
hi, this is a port for nickel, a language using contracts to generate
validated configuration files, it's meant to be easy to extend while
allow the developers to enforce a lot of check in the inputs to ensure
the insert data will be valid
if you are curious, I gathered a few links
announcement for 1.0.0:
https://www.tweag.io/blog/2023-05-17-nickel-1.0-release/
announcing 1.0.0 + tutorial in video:
https://www.youtube.com/watch?v=DzuoYmA2pd4
a tutorial (that I wrote):
https://nickel-lang.org/user-manual/tutorial
validated configuration files, it's meant to be easy to extend while
allow the developers to enforce a lot of check in the inputs to ensure
the insert data will be valid
if you are curious, I gathered a few links
announcement for 1.0.0:
https://www.tweag.io/blog/2023-05-17-nickel-1.0-release/
announcing 1.0.0 + tutorial in video:
https://www.youtube.com/watch?v=DzuoYmA2pd4
a tutorial (that I wrote):
https://nickel-lang.org/user-manual/tutorial
Re: Immutable Page Protections
Justin Handville <nanolith@gmail.com> wrote:
> > pledge does not drop access to system calls. It blocks the *action*
> > of it, inside the kernel. You are muddling things together far too much.
>
> That's a matter of semantics. The point is that pledge reduces attack surface by
> reducing what a program is capable of doing at the system level. Dropping code
> segments is just another mitigation.
It is not. A ROP attacker will still find gadgets they want to use in
the huge % of your text segment that remains.
> > You will need to argue that I am wrong before you go any further.
>
> It doesn't matter. I'm not interested in a debate.
Nor am I.
> > pledge does not drop access to system calls. It blocks the *action*
> > of it, inside the kernel. You are muddling things together far too much.
>
> That's a matter of semantics. The point is that pledge reduces attack surface by
> reducing what a program is capable of doing at the system level. Dropping code
> segments is just another mitigation.
It is not. A ROP attacker will still find gadgets they want to use in
the huge % of your text segment that remains.
> > You will need to argue that I am wrong before you go any further.
>
> It doesn't matter. I'm not interested in a debate.
Nor am I.
Re: Immutable Page Protections
Theo de Raadt <deraadt@openbsd.org> wrote:
> going to use the other 95% of your text segment which, due to static-linking,
> you have placed at very convenient fixed-offset locations relative to whatever
> bug they find to exercise.
The static linking example is a bit of a red herring. Even if the program were
dynamically linked, dropping code that will never be used again is useful, at
least to me.
> You are confusing mechanism. pledge blocks the operation in the kernel,
> not in the address space. You think you can block the operation in the
I was just pointing out the similarity between dropping access to system calls
at the kernel level and dropping large application features no longer needed.
Perhaps I should have worded it better.
> Please don't talk to me about ASLR when you are making a static binary
> that has libc.a pieces at fixed offsets inside it.
That example is irrelevant, and just how I came to modifying uvm_map.c to
ratchet down protection bits. The idea is applicable to dynamically linked
applications as well.
> pledge does not drop access to system calls. It blocks the *action*
> of it, inside the kernel. You are muddling things together far too much.
That's a matter of semantics. The point is that pledge reduces attack surface by
reducing what a program is capable of doing at the system level. Dropping code
segments is just another mitigation.
> You will need to argue that I am wrong before you go any further.
It doesn't matter. I'm not interested in a debate. The point of the thread was
just to describe the situation and how ratcheting down protection bits solves
it, in case the bit ratcheting idea might be useful. I honestly don't care who
is right or wrong, or whether the feature is upstreamed. Take it or leave it. I
can always patch the kernel as I see fit. It's no problem for me. That's the
beauty of open source, and I thank you and your team for making that possible.
You don't see the utility of such a feature. Very well. Thanks for your
consideration.
- Justin
On Fri, Jun 30, 2023 at 11:46 AM Theo de Raadt <deraadt@openbsd.org> wrote:
>
> Justin Handville <nanolith@gmail.com> wrote:
>
> > Theo de Raadt <deraadt@openbsd.org> wrote:
> >
> > > > It's a cheap defense in depth protection that simplifies my use
> > > > case.
> >
> > > But I don't see a real security benefit of what you are trying to do.
> >
> > There may not be. At this point, it's more idiomatic. Don't need code?
> > Don't keep it. It's an experimental feature. I'm not too broken up if I
> > can't use it anymore. I'll find other ways, and I can always just patch
> > the kernel.
>
> I think you are confused by something.
>
> Attackers won't use the text you are unmapping, their method will use
> the text you have not unmapped.
>
> You will need to argue that I am wrong before you go any further.
>
> > I arrived at this feature because it's similar to a technique in
> > firmware, where code access can be trivially narrowed with an MPU. The
> > threat there is easier to perceive, since often there isn't a well
> > defined kernel in which access to hardware or cryptography can be
> > encapsulated with better guarded entry points.
>
> That argument holds no water with me.
>
> > I think that the immutable flag feature is useful, and I think that
> > making it automatic is a great security mitigation. I'm just curious
> > whether a feature like drop_this_init_code_I_will_never_call_again()
> > would also be useful.
>
> Attackers won't use the text you are unmapping, their method will use
> the text you have not unmapped.
>
> > Pledge and unveil can limit the impact of system calls, but within the
> > program itself, attackers can find unintended ways of using code.
>
> AGAIN: Attackers won't use the text you are unmapping, their method will use
> the text you have not unmapped. That is what they do with ROP. You are
> probably capable of removing 5% of your text segment, but the attacker is
> going to use the other 95% of your text segment which, due to static-linking,
> you have placed at very convenient fixed-offset locations relative to whatever
> bug they find to exercise.
>
> > One
> > salient example I can think of where this may be dangerous is in a more
> > dynamic language where eval() or the code generator is needed at
> > startup, but is no longer needed after the program enters steady state.
> > We've seen plenty of attacks, like Log4J, where sloppy features can be
> > used to exploit a naked eval(). Certainly, one solution is to limit what
> > libraries are being used. But, another is to go a la carte as with
> > pledge, and say, "I no longer need eval(), so drop it."
>
> You are confusing mechanism. pledge blocks the operation in the kernel,
> not in the address space. You think you can block the operation in the
> existing operating system. A ROP attacker will perform his operations
> without caring about the code you have unmapped, because they will use
> the large swaths of text-segment you have left mapped because you need it,
> and still contains a vast amount of gadgetry. And since you are using
> static linking to know where your to-be-unmapped pieces are, you have
> conveniently given the attacker fixed-offset locations for the gadgets.
>
> I think you have it all backwards.
>
> > Yes, dynamic languages are an entirely other can of worms, and they
> > often have other ways to drop code. But, I think an argument could be
> > made for this being useful in a static C/C++ program. Init code and
> > other run-once code is still callable, which means that it's ripe for
> > gadgets. ASLR and other mitigations make this harder, but not impossible
> > as we've seen with various attacks to bypass these mitigations. It's
> > much harder to exploit what no longer exists...
>
> Please don't talk to me about ASLR when you are making a static binary
> that has libc.a pieces at fixed offsets inside it.
> >
> > > I'll think about it a bit. But I am very much not convinced that those
> > > text segments you have lying around are a real risk.
> >
> > That's the point of the thread. It's just food for thought. I know that
> > features that OpenBSD develop often pop up in other operating systems.
>
> > Dropping code, at least to me, seems like a natural progression of
> > dropping access to system calls.
>
> pledge does not drop access to system calls. It blocks the *action*
> of it, inside the kernel. You are muddling things together far too much.
>
> going to use the other 95% of your text segment which, due to static-linking,
> you have placed at very convenient fixed-offset locations relative to whatever
> bug they find to exercise.
The static linking example is a bit of a red herring. Even if the program were
dynamically linked, dropping code that will never be used again is useful, at
least to me.
> You are confusing mechanism. pledge blocks the operation in the kernel,
> not in the address space. You think you can block the operation in the
I was just pointing out the similarity between dropping access to system calls
at the kernel level and dropping large application features no longer needed.
Perhaps I should have worded it better.
> Please don't talk to me about ASLR when you are making a static binary
> that has libc.a pieces at fixed offsets inside it.
That example is irrelevant, and just how I came to modifying uvm_map.c to
ratchet down protection bits. The idea is applicable to dynamically linked
applications as well.
> pledge does not drop access to system calls. It blocks the *action*
> of it, inside the kernel. You are muddling things together far too much.
That's a matter of semantics. The point is that pledge reduces attack surface by
reducing what a program is capable of doing at the system level. Dropping code
segments is just another mitigation.
> You will need to argue that I am wrong before you go any further.
It doesn't matter. I'm not interested in a debate. The point of the thread was
just to describe the situation and how ratcheting down protection bits solves
it, in case the bit ratcheting idea might be useful. I honestly don't care who
is right or wrong, or whether the feature is upstreamed. Take it or leave it. I
can always patch the kernel as I see fit. It's no problem for me. That's the
beauty of open source, and I thank you and your team for making that possible.
You don't see the utility of such a feature. Very well. Thanks for your
consideration.
- Justin
On Fri, Jun 30, 2023 at 11:46 AM Theo de Raadt <deraadt@openbsd.org> wrote:
>
> Justin Handville <nanolith@gmail.com> wrote:
>
> > Theo de Raadt <deraadt@openbsd.org> wrote:
> >
> > > > It's a cheap defense in depth protection that simplifies my use
> > > > case.
> >
> > > But I don't see a real security benefit of what you are trying to do.
> >
> > There may not be. At this point, it's more idiomatic. Don't need code?
> > Don't keep it. It's an experimental feature. I'm not too broken up if I
> > can't use it anymore. I'll find other ways, and I can always just patch
> > the kernel.
>
> I think you are confused by something.
>
> Attackers won't use the text you are unmapping, their method will use
> the text you have not unmapped.
>
> You will need to argue that I am wrong before you go any further.
>
> > I arrived at this feature because it's similar to a technique in
> > firmware, where code access can be trivially narrowed with an MPU. The
> > threat there is easier to perceive, since often there isn't a well
> > defined kernel in which access to hardware or cryptography can be
> > encapsulated with better guarded entry points.
>
> That argument holds no water with me.
>
> > I think that the immutable flag feature is useful, and I think that
> > making it automatic is a great security mitigation. I'm just curious
> > whether a feature like drop_this_init_code_I_will_never_call_again()
> > would also be useful.
>
> Attackers won't use the text you are unmapping, their method will use
> the text you have not unmapped.
>
> > Pledge and unveil can limit the impact of system calls, but within the
> > program itself, attackers can find unintended ways of using code.
>
> AGAIN: Attackers won't use the text you are unmapping, their method will use
> the text you have not unmapped. That is what they do with ROP. You are
> probably capable of removing 5% of your text segment, but the attacker is
> going to use the other 95% of your text segment which, due to static-linking,
> you have placed at very convenient fixed-offset locations relative to whatever
> bug they find to exercise.
>
> > One
> > salient example I can think of where this may be dangerous is in a more
> > dynamic language where eval() or the code generator is needed at
> > startup, but is no longer needed after the program enters steady state.
> > We've seen plenty of attacks, like Log4J, where sloppy features can be
> > used to exploit a naked eval(). Certainly, one solution is to limit what
> > libraries are being used. But, another is to go a la carte as with
> > pledge, and say, "I no longer need eval(), so drop it."
>
> You are confusing mechanism. pledge blocks the operation in the kernel,
> not in the address space. You think you can block the operation in the
> existing operating system. A ROP attacker will perform his operations
> without caring about the code you have unmapped, because they will use
> the large swaths of text-segment you have left mapped because you need it,
> and still contains a vast amount of gadgetry. And since you are using
> static linking to know where your to-be-unmapped pieces are, you have
> conveniently given the attacker fixed-offset locations for the gadgets.
>
> I think you have it all backwards.
>
> > Yes, dynamic languages are an entirely other can of worms, and they
> > often have other ways to drop code. But, I think an argument could be
> > made for this being useful in a static C/C++ program. Init code and
> > other run-once code is still callable, which means that it's ripe for
> > gadgets. ASLR and other mitigations make this harder, but not impossible
> > as we've seen with various attacks to bypass these mitigations. It's
> > much harder to exploit what no longer exists...
>
> Please don't talk to me about ASLR when you are making a static binary
> that has libc.a pieces at fixed offsets inside it.
> >
> > > I'll think about it a bit. But I am very much not convinced that those
> > > text segments you have lying around are a real risk.
> >
> > That's the point of the thread. It's just food for thought. I know that
> > features that OpenBSD develop often pop up in other operating systems.
>
> > Dropping code, at least to me, seems like a natural progression of
> > dropping access to system calls.
>
> pledge does not drop access to system calls. It blocks the *action*
> of it, inside the kernel. You are muddling things together far too much.
>
Re: Immutable Page Protections
Justin Handville <nanolith@gmail.com> wrote:
> Theo de Raadt <deraadt@openbsd.org> wrote:
>
> > > It's a cheap defense in depth protection that simplifies my use
> > > case.
>
> > But I don't see a real security benefit of what you are trying to do.
>
> There may not be. At this point, it's more idiomatic. Don't need code?
> Don't keep it. It's an experimental feature. I'm not too broken up if I
> can't use it anymore. I'll find other ways, and I can always just patch
> the kernel.
I think you are confused by something.
Attackers won't use the text you are unmapping, their method will use
the text you have not unmapped.
You will need to argue that I am wrong before you go any further.
> I arrived at this feature because it's similar to a technique in
> firmware, where code access can be trivially narrowed with an MPU. The
> threat there is easier to perceive, since often there isn't a well
> defined kernel in which access to hardware or cryptography can be
> encapsulated with better guarded entry points.
That argument holds no water with me.
> I think that the immutable flag feature is useful, and I think that
> making it automatic is a great security mitigation. I'm just curious
> whether a feature like drop_this_init_code_I_will_never_call_again()
> would also be useful.
Attackers won't use the text you are unmapping, their method will use
the text you have not unmapped.
> Pledge and unveil can limit the impact of system calls, but within the
> program itself, attackers can find unintended ways of using code.
AGAIN: Attackers won't use the text you are unmapping, their method will use
the text you have not unmapped. That is what they do with ROP. You are
probably capable of removing 5% of your text segment, but the attacker is
going to use the other 95% of your text segment which, due to static-linking,
you have placed at very convenient fixed-offset locations relative to whatever
bug they find to exercise.
> One
> salient example I can think of where this may be dangerous is in a more
> dynamic language where eval() or the code generator is needed at
> startup, but is no longer needed after the program enters steady state.
> We've seen plenty of attacks, like Log4J, where sloppy features can be
> used to exploit a naked eval(). Certainly, one solution is to limit what
> libraries are being used. But, another is to go a la carte as with
> pledge, and say, "I no longer need eval(), so drop it."
You are confusing mechanism. pledge blocks the operation in the kernel,
not in the address space. You think you can block the operation in the
existing operating system. A ROP attacker will perform his operations
without caring about the code you have unmapped, because they will use
the large swaths of text-segment you have left mapped because you need it,
and still contains a vast amount of gadgetry. And since you are using
static linking to know where your to-be-unmapped pieces are, you have
conveniently given the attacker fixed-offset locations for the gadgets.
I think you have it all backwards.
> Yes, dynamic languages are an entirely other can of worms, and they
> often have other ways to drop code. But, I think an argument could be
> made for this being useful in a static C/C++ program. Init code and
> other run-once code is still callable, which means that it's ripe for
> gadgets. ASLR and other mitigations make this harder, but not impossible
> as we've seen with various attacks to bypass these mitigations. It's
> much harder to exploit what no longer exists...
Please don't talk to me about ASLR when you are making a static binary
that has libc.a pieces at fixed offsets inside it.
>
> > I'll think about it a bit. But I am very much not convinced that those
> > text segments you have lying around are a real risk.
>
> That's the point of the thread. It's just food for thought. I know that
> features that OpenBSD develop often pop up in other operating systems.
> Dropping code, at least to me, seems like a natural progression of
> dropping access to system calls.
pledge does not drop access to system calls. It blocks the *action*
of it, inside the kernel. You are muddling things together far too much.
> Theo de Raadt <deraadt@openbsd.org> wrote:
>
> > > It's a cheap defense in depth protection that simplifies my use
> > > case.
>
> > But I don't see a real security benefit of what you are trying to do.
>
> There may not be. At this point, it's more idiomatic. Don't need code?
> Don't keep it. It's an experimental feature. I'm not too broken up if I
> can't use it anymore. I'll find other ways, and I can always just patch
> the kernel.
I think you are confused by something.
Attackers won't use the text you are unmapping, their method will use
the text you have not unmapped.
You will need to argue that I am wrong before you go any further.
> I arrived at this feature because it's similar to a technique in
> firmware, where code access can be trivially narrowed with an MPU. The
> threat there is easier to perceive, since often there isn't a well
> defined kernel in which access to hardware or cryptography can be
> encapsulated with better guarded entry points.
That argument holds no water with me.
> I think that the immutable flag feature is useful, and I think that
> making it automatic is a great security mitigation. I'm just curious
> whether a feature like drop_this_init_code_I_will_never_call_again()
> would also be useful.
Attackers won't use the text you are unmapping, their method will use
the text you have not unmapped.
> Pledge and unveil can limit the impact of system calls, but within the
> program itself, attackers can find unintended ways of using code.
AGAIN: Attackers won't use the text you are unmapping, their method will use
the text you have not unmapped. That is what they do with ROP. You are
probably capable of removing 5% of your text segment, but the attacker is
going to use the other 95% of your text segment which, due to static-linking,
you have placed at very convenient fixed-offset locations relative to whatever
bug they find to exercise.
> One
> salient example I can think of where this may be dangerous is in a more
> dynamic language where eval() or the code generator is needed at
> startup, but is no longer needed after the program enters steady state.
> We've seen plenty of attacks, like Log4J, where sloppy features can be
> used to exploit a naked eval(). Certainly, one solution is to limit what
> libraries are being used. But, another is to go a la carte as with
> pledge, and say, "I no longer need eval(), so drop it."
You are confusing mechanism. pledge blocks the operation in the kernel,
not in the address space. You think you can block the operation in the
existing operating system. A ROP attacker will perform his operations
without caring about the code you have unmapped, because they will use
the large swaths of text-segment you have left mapped because you need it,
and still contains a vast amount of gadgetry. And since you are using
static linking to know where your to-be-unmapped pieces are, you have
conveniently given the attacker fixed-offset locations for the gadgets.
I think you have it all backwards.
> Yes, dynamic languages are an entirely other can of worms, and they
> often have other ways to drop code. But, I think an argument could be
> made for this being useful in a static C/C++ program. Init code and
> other run-once code is still callable, which means that it's ripe for
> gadgets. ASLR and other mitigations make this harder, but not impossible
> as we've seen with various attacks to bypass these mitigations. It's
> much harder to exploit what no longer exists...
Please don't talk to me about ASLR when you are making a static binary
that has libc.a pieces at fixed offsets inside it.
>
> > I'll think about it a bit. But I am very much not convinced that those
> > text segments you have lying around are a real risk.
>
> That's the point of the thread. It's just food for thought. I know that
> features that OpenBSD develop often pop up in other operating systems.
> Dropping code, at least to me, seems like a natural progression of
> dropping access to system calls.
pledge does not drop access to system calls. It blocks the *action*
of it, inside the kernel. You are muddling things together far too much.
Re: Immutable Page Protections
Theo de Raadt <deraadt@openbsd.org> wrote:
> > It's a cheap defense in depth protection that simplifies my use
> > case.
> But I don't see a real security benefit of what you are trying to do.
There may not be. At this point, it's more idiomatic. Don't need code?
Don't keep it. It's an experimental feature. I'm not too broken up if I
can't use it anymore. I'll find other ways, and I can always just patch
the kernel.
I arrived at this feature because it's similar to a technique in
firmware, where code access can be trivially narrowed with an MPU. The
threat there is easier to perceive, since often there isn't a well
defined kernel in which access to hardware or cryptography can be
encapsulated with better guarded entry points.
> Because then programs need active code to do so. Where will those calls
> be? Today, the kernel does it automatically before the program runs.
> You want to do it at c runtime startup? It would be the same. Or you
> want programs to have to do it themselves? Like, lock_my_text_segment()
> called from inside main? That really doesn't make sense.
I think that the immutable flag feature is useful, and I think that
making it automatic is a great security mitigation. I'm just curious
whether a feature like drop_this_init_code_I_will_never_call_again()
would also be useful.
Pledge and unveil can limit the impact of system calls, but within the
program itself, attackers can find unintended ways of using code. One
salient example I can think of where this may be dangerous is in a more
dynamic language where eval() or the code generator is needed at
startup, but is no longer needed after the program enters steady state.
We've seen plenty of attacks, like Log4J, where sloppy features can be
used to exploit a naked eval(). Certainly, one solution is to limit what
libraries are being used. But, another is to go a la carte as with
pledge, and say, "I no longer need eval(), so drop it."
Yes, dynamic languages are an entirely other can of worms, and they
often have other ways to drop code. But, I think an argument could be
made for this being useful in a static C/C++ program. Init code and
other run-once code is still callable, which means that it's ripe for
gadgets. ASLR and other mitigations make this harder, but not impossible
as we've seen with various attacks to bypass these mitigations. It's
much harder to exploit what no longer exists...
> I'll think about it a bit. But I am very much not convinced that those
> text segments you have lying around are a real risk.
That's the point of the thread. It's just food for thought. I know that
features that OpenBSD develop often pop up in other operating systems.
Dropping code, at least to me, seems like a natural progression of
dropping access to system calls.
- Justin
On Fri, Jun 30, 2023 at 8:58 AM Theo de Raadt <deraadt@openbsd.org> wrote:
>
> Justin Handville <nanolith@gmail.com> wrote:
>
> > I'm assuming that misc@ is probably the best place for this e-mail,
> > although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
> > long ago, and I noticed that a daemon I had written was no longer
> > working properly. For reasons that are probably too much to get into
> > here, I statically link the daemon. It's a single binary that makes use
> > of pledge / unveil, and privilege separation. This all works fine. It
> > also has another trick, which unfortunately no longer works in 7.3.
> >
> > To reduce the code footprint of this daemon as well as the potential
> > gadget attack surface, I have it drop any code that it will no longer
> > execute. This happens after fork / exec on a child, and also after
> > initialization code executes before the child process enters its steady
> > state. This is trivially done by grouping functions into custom page
> > aligned sections in the ELF binary, and running mprotect on these
> > sections with PROT_NONE. I considered munmap as well as other tricks,
> > but so far, this seems to be the most portable way to handle this trick
> > that I could think of between BSD and Linux. I'm sure others are more
> > clever. It's a cheap defense in depth protection that simplifies my use
> > case.
> >
> > As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> > trick no longer works. Given that my trick is a total hack, I'm not too
> > broken up about it. Of course, this change led me to doing some poking
> > around.
>
> Sorry.
>
> But I don't see a real security benefit of what you are trying to do.
>
> > I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> > Chrome to drop the write flag for a region for userland compatibility.
> > That makes sense as a temporary measure. I'm wondering, however, if it
> > might not make sense to think about this functionality differently.
> > Instead of immutable memory regions, why can't we consider a more
> > pledge-like ratcheting for memory regions, where bits can be removed,
> > but never added back? How does this impact the gadget attack surface
> > that led to the immutable flag being considered to begin with?
>
> Because then programs need active code to do so. Where will those calls
> be? Today, the kernel does it automatically before the program runs.
> You want to do it at c runtime startup? It would be the same. Or you
> want programs to have to do it themselves? Like, lock_my_text_segment()
> called from inside main? That really doesn't make sense.
>
>
> > For the time being, I extended the exception in uvm_map.c on my own
> > OpenBSD systems to allow immutable regions to be stripped of all
> > protection flags with a call to mprotect. So, in addition to allowing RW
> > to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> > PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> > option for patching for now.
>
> The ratchet-down piece in uvm will eventually be deleted, when we return
> to review the entire corpus of software behaviour. We left that small
> piece of behaviour due to a v8/chrome requirement, and were a bit
> fearfull that other software also had such requirements, but were short
> on doing a complete ecosystem review at the time. So if anything, this
> is going to become more strict, not less strict.
>
> > Of course, this further breaks the
> > definition of "immutable", but at least immutable regions can only have
> > protection bits removed.
>
> To me, it is unclear if permission lowering lacks a bad failure mode.
> There are a scary number of programs with sigsegv handlers, trying to
> cope with unexpected behaviours in "clever ways". If you demote permissions,
> you can get into that fragile rarely tested code, so I'm going to claim
> permission reduction might not be safe.
>
> > My reason for mailing misc@ is just to bring up this data point from a
> > single user. I'm certain that the OpenBSD developers have reasons for
> > preferring a pure immutable flag, but having a mechanism for ratcheting
> > down protections is useful at least for me, and is apparently useful
> > enough in userland going from RW to R, that an exception was carved out
> > for now. Of course, I'm more than happy to work with the developers to
> > come up with a plan for upstreaming this feature if it's something
> > useful. If not, I have no problem adding it to my personal list of
> > patches I maintain that I doubt anyone else would want or need.
>
> I'll think about it a bit. But I am very much not convinced that those
> text segments you have lying around are a real risk.
> > It's a cheap defense in depth protection that simplifies my use
> > case.
> But I don't see a real security benefit of what you are trying to do.
There may not be. At this point, it's more idiomatic. Don't need code?
Don't keep it. It's an experimental feature. I'm not too broken up if I
can't use it anymore. I'll find other ways, and I can always just patch
the kernel.
I arrived at this feature because it's similar to a technique in
firmware, where code access can be trivially narrowed with an MPU. The
threat there is easier to perceive, since often there isn't a well
defined kernel in which access to hardware or cryptography can be
encapsulated with better guarded entry points.
> Because then programs need active code to do so. Where will those calls
> be? Today, the kernel does it automatically before the program runs.
> You want to do it at c runtime startup? It would be the same. Or you
> want programs to have to do it themselves? Like, lock_my_text_segment()
> called from inside main? That really doesn't make sense.
I think that the immutable flag feature is useful, and I think that
making it automatic is a great security mitigation. I'm just curious
whether a feature like drop_this_init_code_I_will_never_call_again()
would also be useful.
Pledge and unveil can limit the impact of system calls, but within the
program itself, attackers can find unintended ways of using code. One
salient example I can think of where this may be dangerous is in a more
dynamic language where eval() or the code generator is needed at
startup, but is no longer needed after the program enters steady state.
We've seen plenty of attacks, like Log4J, where sloppy features can be
used to exploit a naked eval(). Certainly, one solution is to limit what
libraries are being used. But, another is to go a la carte as with
pledge, and say, "I no longer need eval(), so drop it."
Yes, dynamic languages are an entirely other can of worms, and they
often have other ways to drop code. But, I think an argument could be
made for this being useful in a static C/C++ program. Init code and
other run-once code is still callable, which means that it's ripe for
gadgets. ASLR and other mitigations make this harder, but not impossible
as we've seen with various attacks to bypass these mitigations. It's
much harder to exploit what no longer exists...
> I'll think about it a bit. But I am very much not convinced that those
> text segments you have lying around are a real risk.
That's the point of the thread. It's just food for thought. I know that
features that OpenBSD develop often pop up in other operating systems.
Dropping code, at least to me, seems like a natural progression of
dropping access to system calls.
- Justin
On Fri, Jun 30, 2023 at 8:58 AM Theo de Raadt <deraadt@openbsd.org> wrote:
>
> Justin Handville <nanolith@gmail.com> wrote:
>
> > I'm assuming that misc@ is probably the best place for this e-mail,
> > although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
> > long ago, and I noticed that a daemon I had written was no longer
> > working properly. For reasons that are probably too much to get into
> > here, I statically link the daemon. It's a single binary that makes use
> > of pledge / unveil, and privilege separation. This all works fine. It
> > also has another trick, which unfortunately no longer works in 7.3.
> >
> > To reduce the code footprint of this daemon as well as the potential
> > gadget attack surface, I have it drop any code that it will no longer
> > execute. This happens after fork / exec on a child, and also after
> > initialization code executes before the child process enters its steady
> > state. This is trivially done by grouping functions into custom page
> > aligned sections in the ELF binary, and running mprotect on these
> > sections with PROT_NONE. I considered munmap as well as other tricks,
> > but so far, this seems to be the most portable way to handle this trick
> > that I could think of between BSD and Linux. I'm sure others are more
> > clever. It's a cheap defense in depth protection that simplifies my use
> > case.
> >
> > As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> > trick no longer works. Given that my trick is a total hack, I'm not too
> > broken up about it. Of course, this change led me to doing some poking
> > around.
>
> Sorry.
>
> But I don't see a real security benefit of what you are trying to do.
>
> > I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> > Chrome to drop the write flag for a region for userland compatibility.
> > That makes sense as a temporary measure. I'm wondering, however, if it
> > might not make sense to think about this functionality differently.
> > Instead of immutable memory regions, why can't we consider a more
> > pledge-like ratcheting for memory regions, where bits can be removed,
> > but never added back? How does this impact the gadget attack surface
> > that led to the immutable flag being considered to begin with?
>
> Because then programs need active code to do so. Where will those calls
> be? Today, the kernel does it automatically before the program runs.
> You want to do it at c runtime startup? It would be the same. Or you
> want programs to have to do it themselves? Like, lock_my_text_segment()
> called from inside main? That really doesn't make sense.
>
>
> > For the time being, I extended the exception in uvm_map.c on my own
> > OpenBSD systems to allow immutable regions to be stripped of all
> > protection flags with a call to mprotect. So, in addition to allowing RW
> > to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> > PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> > option for patching for now.
>
> The ratchet-down piece in uvm will eventually be deleted, when we return
> to review the entire corpus of software behaviour. We left that small
> piece of behaviour due to a v8/chrome requirement, and were a bit
> fearfull that other software also had such requirements, but were short
> on doing a complete ecosystem review at the time. So if anything, this
> is going to become more strict, not less strict.
>
> > Of course, this further breaks the
> > definition of "immutable", but at least immutable regions can only have
> > protection bits removed.
>
> To me, it is unclear if permission lowering lacks a bad failure mode.
> There are a scary number of programs with sigsegv handlers, trying to
> cope with unexpected behaviours in "clever ways". If you demote permissions,
> you can get into that fragile rarely tested code, so I'm going to claim
> permission reduction might not be safe.
>
> > My reason for mailing misc@ is just to bring up this data point from a
> > single user. I'm certain that the OpenBSD developers have reasons for
> > preferring a pure immutable flag, but having a mechanism for ratcheting
> > down protections is useful at least for me, and is apparently useful
> > enough in userland going from RW to R, that an exception was carved out
> > for now. Of course, I'm more than happy to work with the developers to
> > come up with a plan for upstreaming this feature if it's something
> > useful. If not, I have no problem adding it to my personal list of
> > patches I maintain that I doubt anyone else would want or need.
>
> I'll think about it a bit. But I am very much not convinced that those
> text segments you have lying around are a real risk.
Re: Immutable Page Protections
Justin Handville <nanolith@gmail.com> wrote:
> Dave Voutila <dv@sisu.io> wrote:
>
> > Have you considered a libexec approach instead? If the goal is to keep a
> > child process having only the executable pages it needs for operations,
> > why not split up the program design instead of mucking with ELF stuff?
> > That surely has to be even more portable.
>
> I have. There are other reasons for preferring a single static binary. I
> agree that playing with ELF sections is problematic. But, on most
> systems I use, this works. It's no worse than assumptions made for GC,
> dynamic code generation, or fibers on most platforms. Of course, like
> each of these assumptions, it's not guaranteed and, as with what
> happened with 7.3, is likely to go away at any time.
A single static binary has no internal random linking, so ROP attack
methods are easy. Your binary probably has more syscall stubs than you
expect, due to initialzation code and path-not-taken inside higher-level
library functions. And you cannot reasonably displace those for hiding.
Then if you go dynamic, you have all the stubs at random locations and
cannot unmap the real attack surface, but no... you prefer to have fewer
but at fixed known offsets.
Even then, an attacker is not going to use your unmapped text. They always
use ROP on top of lower level primitives.
I think your belief in how people attack code is misplaced. I do not
think this idea is useful in general, so I don't think we should bend
over to support it.
> Dave Voutila <dv@sisu.io> wrote:
>
> > Have you considered a libexec approach instead? If the goal is to keep a
> > child process having only the executable pages it needs for operations,
> > why not split up the program design instead of mucking with ELF stuff?
> > That surely has to be even more portable.
>
> I have. There are other reasons for preferring a single static binary. I
> agree that playing with ELF sections is problematic. But, on most
> systems I use, this works. It's no worse than assumptions made for GC,
> dynamic code generation, or fibers on most platforms. Of course, like
> each of these assumptions, it's not guaranteed and, as with what
> happened with 7.3, is likely to go away at any time.
A single static binary has no internal random linking, so ROP attack
methods are easy. Your binary probably has more syscall stubs than you
expect, due to initialzation code and path-not-taken inside higher-level
library functions. And you cannot reasonably displace those for hiding.
Then if you go dynamic, you have all the stubs at random locations and
cannot unmap the real attack surface, but no... you prefer to have fewer
but at fixed known offsets.
Even then, an attacker is not going to use your unmapped text. They always
use ROP on top of lower level primitives.
I think your belief in how people attack code is misplaced. I do not
think this idea is useful in general, so I don't think we should bend
over to support it.
Re: Immutable Page Protections
Dave Voutila <dv@sisu.io> wrote:
> Have you considered a libexec approach instead? If the goal is to keep a
> child process having only the executable pages it needs for operations,
> why not split up the program design instead of mucking with ELF stuff?
> That surely has to be even more portable.
I have. There are other reasons for preferring a single static binary. I
agree that playing with ELF sections is problematic. But, on most
systems I use, this works. It's no worse than assumptions made for GC,
dynamic code generation, or fibers on most platforms. Of course, like
each of these assumptions, it's not guaranteed and, as with what
happened with 7.3, is likely to go away at any time.
It's fine. I have plenty of kernel patches I use on most OSes. I'll
probably just flesh this one out with its own system call and
alternative mode for ld.so. I just figured it was useful to point out
that at least one person is using this pattern.
- Justin
On Fri, Jun 30, 2023 at 8:03 AM Dave Voutila <dv@sisu.io> wrote:
>
>
> Justin Handville <nanolith@gmail.com> writes:
>
> > I'm assuming that misc@ is probably the best place for this e-mail,
> > although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
> > long ago, and I noticed that a daemon I had written was no longer
> > working properly. For reasons that are probably too much to get into
> > here, I statically link the daemon. It's a single binary that makes use
> > of pledge / unveil, and privilege separation. This all works fine. It
> > also has another trick, which unfortunately no longer works in 7.3.
> >
> > To reduce the code footprint of this daemon as well as the potential
> > gadget attack surface, I have it drop any code that it will no longer
> > execute. This happens after fork / exec on a child, and also after
> > initialization code executes before the child process enters its steady
> > state. This is trivially done by grouping functions into custom page
> > aligned sections in the ELF binary, and running mprotect on these
> > sections with PROT_NONE. I considered munmap as well as other tricks,
> > but so far, this seems to be the most portable way to handle this trick
> > that I could think of between BSD and Linux. I'm sure others are more
> > clever. It's a cheap defense in depth protection that simplifies my use
> > case.
>
> Have you considered a libexec approach instead? If the goal is to keep a
> child process having only the executable pages it needs for operations,
> why not split up the program design instead of mucking with ELF stuff?
> That surely has to be even more portable.
>
> >
> > As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> > trick no longer works. Given that my trick is a total hack, I'm not too
> > broken up about it. Of course, this change led me to doing some poking
> > around.
> >
> > I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> > Chrome to drop the write flag for a region for userland compatibility.
> > That makes sense as a temporary measure. I'm wondering, however, if it
> > might not make sense to think about this functionality differently.
> > Instead of immutable memory regions, why can't we consider a more
> > pledge-like ratcheting for memory regions, where bits can be removed,
> > but never added back? How does this impact the gadget attack surface
> > that led to the immutable flag being considered to begin with?
> >
> > For the time being, I extended the exception in uvm_map.c on my own
> > OpenBSD systems to allow immutable regions to be stripped of all
> > protection flags with a call to mprotect. So, in addition to allowing RW
> > to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> > PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> > option for patching for now. Of course, this further breaks the
> > definition of "immutable", but at least immutable regions can only have
> > protection bits removed.
> >
> > My reason for mailing misc@ is just to bring up this data point from a
> > single user. I'm certain that the OpenBSD developers have reasons for
> > preferring a pure immutable flag, but having a mechanism for ratcheting
> > down protections is useful at least for me, and is apparently useful
> > enough in userland going from RW to R, that an exception was carved out
> > for now. Of course, I'm more than happy to work with the developers to
> > come up with a plan for upstreaming this feature if it's something
> > useful. If not, I have no problem adding it to my personal list of
> > patches I maintain that I doubt anyone else would want or need.
> >
> > - Justin
> Have you considered a libexec approach instead? If the goal is to keep a
> child process having only the executable pages it needs for operations,
> why not split up the program design instead of mucking with ELF stuff?
> That surely has to be even more portable.
I have. There are other reasons for preferring a single static binary. I
agree that playing with ELF sections is problematic. But, on most
systems I use, this works. It's no worse than assumptions made for GC,
dynamic code generation, or fibers on most platforms. Of course, like
each of these assumptions, it's not guaranteed and, as with what
happened with 7.3, is likely to go away at any time.
It's fine. I have plenty of kernel patches I use on most OSes. I'll
probably just flesh this one out with its own system call and
alternative mode for ld.so. I just figured it was useful to point out
that at least one person is using this pattern.
- Justin
On Fri, Jun 30, 2023 at 8:03 AM Dave Voutila <dv@sisu.io> wrote:
>
>
> Justin Handville <nanolith@gmail.com> writes:
>
> > I'm assuming that misc@ is probably the best place for this e-mail,
> > although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
> > long ago, and I noticed that a daemon I had written was no longer
> > working properly. For reasons that are probably too much to get into
> > here, I statically link the daemon. It's a single binary that makes use
> > of pledge / unveil, and privilege separation. This all works fine. It
> > also has another trick, which unfortunately no longer works in 7.3.
> >
> > To reduce the code footprint of this daemon as well as the potential
> > gadget attack surface, I have it drop any code that it will no longer
> > execute. This happens after fork / exec on a child, and also after
> > initialization code executes before the child process enters its steady
> > state. This is trivially done by grouping functions into custom page
> > aligned sections in the ELF binary, and running mprotect on these
> > sections with PROT_NONE. I considered munmap as well as other tricks,
> > but so far, this seems to be the most portable way to handle this trick
> > that I could think of between BSD and Linux. I'm sure others are more
> > clever. It's a cheap defense in depth protection that simplifies my use
> > case.
>
> Have you considered a libexec approach instead? If the goal is to keep a
> child process having only the executable pages it needs for operations,
> why not split up the program design instead of mucking with ELF stuff?
> That surely has to be even more portable.
>
> >
> > As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> > trick no longer works. Given that my trick is a total hack, I'm not too
> > broken up about it. Of course, this change led me to doing some poking
> > around.
> >
> > I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> > Chrome to drop the write flag for a region for userland compatibility.
> > That makes sense as a temporary measure. I'm wondering, however, if it
> > might not make sense to think about this functionality differently.
> > Instead of immutable memory regions, why can't we consider a more
> > pledge-like ratcheting for memory regions, where bits can be removed,
> > but never added back? How does this impact the gadget attack surface
> > that led to the immutable flag being considered to begin with?
> >
> > For the time being, I extended the exception in uvm_map.c on my own
> > OpenBSD systems to allow immutable regions to be stripped of all
> > protection flags with a call to mprotect. So, in addition to allowing RW
> > to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> > PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> > option for patching for now. Of course, this further breaks the
> > definition of "immutable", but at least immutable regions can only have
> > protection bits removed.
> >
> > My reason for mailing misc@ is just to bring up this data point from a
> > single user. I'm certain that the OpenBSD developers have reasons for
> > preferring a pure immutable flag, but having a mechanism for ratcheting
> > down protections is useful at least for me, and is apparently useful
> > enough in userland going from RW to R, that an exception was carved out
> > for now. Of course, I'm more than happy to work with the developers to
> > come up with a plan for upstreaming this feature if it's something
> > useful. If not, I have no problem adding it to my personal list of
> > patches I maintain that I doubt anyone else would want or need.
> >
> > - Justin
Re: lang/* BTI breakage - lang/sbcl
Sebastien Marie <semarie@online.fr> wrote:
> sbcl compilation works by generating native code inside live managed memory, and
> permits to save the whole memory image to a file.
>
> it is why the binary currently also needs WX and RX memory (I intent to work a
> bit on it if possible).
>
> When generating an executable, it is copying /usr/local/bin/sbcl binary as base,
> and append the (optionally compressed) memory image to the file, to create a
> standalone executable.
>
> When the output file is executed, it is reading its own image, loads it in
> memory, and use an entrypoint for loaded code.
>
> So the generated file has all the flags it needs to run (because copied from
> /usr/local/bin/sbcl binary).
It is ridiculous.
Even emacs stopped doing that.
> sbcl compilation works by generating native code inside live managed memory, and
> permits to save the whole memory image to a file.
>
> it is why the binary currently also needs WX and RX memory (I intent to work a
> bit on it if possible).
>
> When generating an executable, it is copying /usr/local/bin/sbcl binary as base,
> and append the (optionally compressed) memory image to the file, to create a
> standalone executable.
>
> When the output file is executed, it is reading its own image, loads it in
> memory, and use an entrypoint for loaded code.
>
> So the generated file has all the flags it needs to run (because copied from
> /usr/local/bin/sbcl binary).
It is ridiculous.
Even emacs stopped doing that.
Re: Immutable Page Protections
Justin Handville <nanolith@gmail.com> wrote:
> I'm assuming that misc@ is probably the best place for this e-mail,
> although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
> long ago, and I noticed that a daemon I had written was no longer
> working properly. For reasons that are probably too much to get into
> here, I statically link the daemon. It's a single binary that makes use
> of pledge / unveil, and privilege separation. This all works fine. It
> also has another trick, which unfortunately no longer works in 7.3.
>
> To reduce the code footprint of this daemon as well as the potential
> gadget attack surface, I have it drop any code that it will no longer
> execute. This happens after fork / exec on a child, and also after
> initialization code executes before the child process enters its steady
> state. This is trivially done by grouping functions into custom page
> aligned sections in the ELF binary, and running mprotect on these
> sections with PROT_NONE. I considered munmap as well as other tricks,
> but so far, this seems to be the most portable way to handle this trick
> that I could think of between BSD and Linux. I'm sure others are more
> clever. It's a cheap defense in depth protection that simplifies my use
> case.
>
> As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> trick no longer works. Given that my trick is a total hack, I'm not too
> broken up about it. Of course, this change led me to doing some poking
> around.
Sorry.
But I don't see a real security benefit of what you are trying to do.
> I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> Chrome to drop the write flag for a region for userland compatibility.
> That makes sense as a temporary measure. I'm wondering, however, if it
> might not make sense to think about this functionality differently.
> Instead of immutable memory regions, why can't we consider a more
> pledge-like ratcheting for memory regions, where bits can be removed,
> but never added back? How does this impact the gadget attack surface
> that led to the immutable flag being considered to begin with?
Because then programs need active code to do so. Where will those calls
be? Today, the kernel does it automatically before the program runs.
You want to do it at c runtime startup? It would be the same. Or you
want programs to have to do it themselves? Like, lock_my_text_segment()
called from inside main? That really doesn't make sense.
> For the time being, I extended the exception in uvm_map.c on my own
> OpenBSD systems to allow immutable regions to be stripped of all
> protection flags with a call to mprotect. So, in addition to allowing RW
> to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> option for patching for now.
The ratchet-down piece in uvm will eventually be deleted, when we return
to review the entire corpus of software behaviour. We left that small
piece of behaviour due to a v8/chrome requirement, and were a bit
fearfull that other software also had such requirements, but were short
on doing a complete ecosystem review at the time. So if anything, this
is going to become more strict, not less strict.
> Of course, this further breaks the
> definition of "immutable", but at least immutable regions can only have
> protection bits removed.
To me, it is unclear if permission lowering lacks a bad failure mode.
There are a scary number of programs with sigsegv handlers, trying to
cope with unexpected behaviours in "clever ways". If you demote permissions,
you can get into that fragile rarely tested code, so I'm going to claim
permission reduction might not be safe.
> My reason for mailing misc@ is just to bring up this data point from a
> single user. I'm certain that the OpenBSD developers have reasons for
> preferring a pure immutable flag, but having a mechanism for ratcheting
> down protections is useful at least for me, and is apparently useful
> enough in userland going from RW to R, that an exception was carved out
> for now. Of course, I'm more than happy to work with the developers to
> come up with a plan for upstreaming this feature if it's something
> useful. If not, I have no problem adding it to my personal list of
> patches I maintain that I doubt anyone else would want or need.
I'll think about it a bit. But I am very much not convinced that those
text segments you have lying around are a real risk.
> I'm assuming that misc@ is probably the best place for this e-mail,
> although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
> long ago, and I noticed that a daemon I had written was no longer
> working properly. For reasons that are probably too much to get into
> here, I statically link the daemon. It's a single binary that makes use
> of pledge / unveil, and privilege separation. This all works fine. It
> also has another trick, which unfortunately no longer works in 7.3.
>
> To reduce the code footprint of this daemon as well as the potential
> gadget attack surface, I have it drop any code that it will no longer
> execute. This happens after fork / exec on a child, and also after
> initialization code executes before the child process enters its steady
> state. This is trivially done by grouping functions into custom page
> aligned sections in the ELF binary, and running mprotect on these
> sections with PROT_NONE. I considered munmap as well as other tricks,
> but so far, this seems to be the most portable way to handle this trick
> that I could think of between BSD and Linux. I'm sure others are more
> clever. It's a cheap defense in depth protection that simplifies my use
> case.
>
> As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> trick no longer works. Given that my trick is a total hack, I'm not too
> broken up about it. Of course, this change led me to doing some poking
> around.
Sorry.
But I don't see a real security benefit of what you are trying to do.
> I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> Chrome to drop the write flag for a region for userland compatibility.
> That makes sense as a temporary measure. I'm wondering, however, if it
> might not make sense to think about this functionality differently.
> Instead of immutable memory regions, why can't we consider a more
> pledge-like ratcheting for memory regions, where bits can be removed,
> but never added back? How does this impact the gadget attack surface
> that led to the immutable flag being considered to begin with?
Because then programs need active code to do so. Where will those calls
be? Today, the kernel does it automatically before the program runs.
You want to do it at c runtime startup? It would be the same. Or you
want programs to have to do it themselves? Like, lock_my_text_segment()
called from inside main? That really doesn't make sense.
> For the time being, I extended the exception in uvm_map.c on my own
> OpenBSD systems to allow immutable regions to be stripped of all
> protection flags with a call to mprotect. So, in addition to allowing RW
> to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> option for patching for now.
The ratchet-down piece in uvm will eventually be deleted, when we return
to review the entire corpus of software behaviour. We left that small
piece of behaviour due to a v8/chrome requirement, and were a bit
fearfull that other software also had such requirements, but were short
on doing a complete ecosystem review at the time. So if anything, this
is going to become more strict, not less strict.
> Of course, this further breaks the
> definition of "immutable", but at least immutable regions can only have
> protection bits removed.
To me, it is unclear if permission lowering lacks a bad failure mode.
There are a scary number of programs with sigsegv handlers, trying to
cope with unexpected behaviours in "clever ways". If you demote permissions,
you can get into that fragile rarely tested code, so I'm going to claim
permission reduction might not be safe.
> My reason for mailing misc@ is just to bring up this data point from a
> single user. I'm certain that the OpenBSD developers have reasons for
> preferring a pure immutable flag, but having a mechanism for ratcheting
> down protections is useful at least for me, and is apparently useful
> enough in userland going from RW to R, that an exception was carved out
> for now. Of course, I'm more than happy to work with the developers to
> come up with a plan for upstreaming this feature if it's something
> useful. If not, I have no problem adding it to my personal list of
> patches I maintain that I doubt anyone else would want or need.
I'll think about it a bit. But I am very much not convinced that those
text segments you have lying around are a real risk.
Re: encrypted_hdd_data_recovery(OpenBSD_7.3)
Thanks NIck,
How do I exactly try to unlock the disk with bioctl command?
I do not have the appropriate disk to try to rebuild it.
I am trying it from openbsd 6.9 bootable usb. The encrypted hdd was 7.3.
Please.
Thanks in advance
On Sat, Jun 17, 2023 at 4:33 PM Nick Holland <nick@holland-consulting.net>
wrote:
> On 6/17/23 08:40, soko.tica wrote:
> > Hello list,
> >
> > I have managed to screw by
> > #fsck_ffs /dev/sd1a
> >
> > the root partition of my unmounted HDD (OpenBSD 7.3 stable, possibly not
> > fully updated). It crashed during boot due to the power outage, than it
> was
> > unable to boot and required fsck_ffs, and I answered 'F' to the 'Fyn'
> > prompt.
> >
> > Here is the present status of it (it is sd0 in this sequence).
> > ===
> > Script started on Sat Jun 17 12:26:43 2023
> > think# disklabel sd0
> >
> > # /dev/rsd0c:
> > type: SCSI
> > disk: SCSI disk
> > label: HGST HTS725050A7
> > duid: 35e70751b7e36f98
> > flags:
> > bytes/sector: 512
> > sectors/track: 63
> > tracks/cylinder: 255
> > sectors/cylinder: 16065
> > cylinders: 60801
> > total sectors: 976773168
> > boundstart: 64
> > boundend: 976768065
> > drivedata: 0
> >
> > 16 partitions:
> > # size offset fstype [fsize bsize cpg]
> > a: 976768001 64 RAID
> > c: 976773168 0 unused
> > think# ^D
> >
> >
> > Script done on Sat Jun 17 12:26:54 2023
> > ===
>
> this is as I'd expect. but you aren't showing what happens
> when you try to unlock it I understand you have a problem,
> but you haven't told us what it is.
>
> If you have a problem when unlocking the disk with the bioctl
> command, you probably aren't going to get your data back.
>
> If you can get the drive unlocked and available as another
> logical drive, you will probably have to fsck each partition
> within it. Hopefully any horrible problems here would be
> contained to individual partitions, and you can pull data off
> the rest.
> ...
>
> > Naturally, there is data there, and naturally, I have no backup of it. Of
> > course I do know the passphrase, it is my hdd.
>
> this is what we call a learning experience.
>
> > If there is any chance to recover it, please let me know.
>
> chance, maybe. But almost by design, encrypted storage is more
> fragile than unencrypted storage.
>
> Nick.
>
>
How do I exactly try to unlock the disk with bioctl command?
I do not have the appropriate disk to try to rebuild it.
I am trying it from openbsd 6.9 bootable usb. The encrypted hdd was 7.3.
Please.
Thanks in advance
On Sat, Jun 17, 2023 at 4:33 PM Nick Holland <nick@holland-consulting.net>
wrote:
> On 6/17/23 08:40, soko.tica wrote:
> > Hello list,
> >
> > I have managed to screw by
> > #fsck_ffs /dev/sd1a
> >
> > the root partition of my unmounted HDD (OpenBSD 7.3 stable, possibly not
> > fully updated). It crashed during boot due to the power outage, than it
> was
> > unable to boot and required fsck_ffs, and I answered 'F' to the 'Fyn'
> > prompt.
> >
> > Here is the present status of it (it is sd0 in this sequence).
> > ===
> > Script started on Sat Jun 17 12:26:43 2023
> > think# disklabel sd0
> >
> > # /dev/rsd0c:
> > type: SCSI
> > disk: SCSI disk
> > label: HGST HTS725050A7
> > duid: 35e70751b7e36f98
> > flags:
> > bytes/sector: 512
> > sectors/track: 63
> > tracks/cylinder: 255
> > sectors/cylinder: 16065
> > cylinders: 60801
> > total sectors: 976773168
> > boundstart: 64
> > boundend: 976768065
> > drivedata: 0
> >
> > 16 partitions:
> > # size offset fstype [fsize bsize cpg]
> > a: 976768001 64 RAID
> > c: 976773168 0 unused
> > think# ^D
> >
> >
> > Script done on Sat Jun 17 12:26:54 2023
> > ===
>
> this is as I'd expect. but you aren't showing what happens
> when you try to unlock it I understand you have a problem,
> but you haven't told us what it is.
>
> If you have a problem when unlocking the disk with the bioctl
> command, you probably aren't going to get your data back.
>
> If you can get the drive unlocked and available as another
> logical drive, you will probably have to fsck each partition
> within it. Hopefully any horrible problems here would be
> contained to individual partitions, and you can pull data off
> the rest.
> ...
>
> > Naturally, there is data there, and naturally, I have no backup of it. Of
> > course I do know the passphrase, it is my hdd.
>
> this is what we call a learning experience.
>
> > If there is any chance to recover it, please let me know.
>
> chance, maybe. But almost by design, encrypted storage is more
> fragile than unencrypted storage.
>
> Nick.
>
>
Re: Immutable Page Protections
Justin Handville <nanolith@gmail.com> writes:
> I'm assuming that misc@ is probably the best place for this e-mail,
> although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
> long ago, and I noticed that a daemon I had written was no longer
> working properly. For reasons that are probably too much to get into
> here, I statically link the daemon. It's a single binary that makes use
> of pledge / unveil, and privilege separation. This all works fine. It
> also has another trick, which unfortunately no longer works in 7.3.
>
> To reduce the code footprint of this daemon as well as the potential
> gadget attack surface, I have it drop any code that it will no longer
> execute. This happens after fork / exec on a child, and also after
> initialization code executes before the child process enters its steady
> state. This is trivially done by grouping functions into custom page
> aligned sections in the ELF binary, and running mprotect on these
> sections with PROT_NONE. I considered munmap as well as other tricks,
> but so far, this seems to be the most portable way to handle this trick
> that I could think of between BSD and Linux. I'm sure others are more
> clever. It's a cheap defense in depth protection that simplifies my use
> case.
Have you considered a libexec approach instead? If the goal is to keep a
child process having only the executable pages it needs for operations,
why not split up the program design instead of mucking with ELF stuff?
That surely has to be even more portable.
>
> As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> trick no longer works. Given that my trick is a total hack, I'm not too
> broken up about it. Of course, this change led me to doing some poking
> around.
>
> I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> Chrome to drop the write flag for a region for userland compatibility.
> That makes sense as a temporary measure. I'm wondering, however, if it
> might not make sense to think about this functionality differently.
> Instead of immutable memory regions, why can't we consider a more
> pledge-like ratcheting for memory regions, where bits can be removed,
> but never added back? How does this impact the gadget attack surface
> that led to the immutable flag being considered to begin with?
>
> For the time being, I extended the exception in uvm_map.c on my own
> OpenBSD systems to allow immutable regions to be stripped of all
> protection flags with a call to mprotect. So, in addition to allowing RW
> to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> option for patching for now. Of course, this further breaks the
> definition of "immutable", but at least immutable regions can only have
> protection bits removed.
>
> My reason for mailing misc@ is just to bring up this data point from a
> single user. I'm certain that the OpenBSD developers have reasons for
> preferring a pure immutable flag, but having a mechanism for ratcheting
> down protections is useful at least for me, and is apparently useful
> enough in userland going from RW to R, that an exception was carved out
> for now. Of course, I'm more than happy to work with the developers to
> come up with a plan for upstreaming this feature if it's something
> useful. If not, I have no problem adding it to my personal list of
> patches I maintain that I doubt anyone else would want or need.
>
> - Justin
> I'm assuming that misc@ is probably the best place for this e-mail,
> although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
> long ago, and I noticed that a daemon I had written was no longer
> working properly. For reasons that are probably too much to get into
> here, I statically link the daemon. It's a single binary that makes use
> of pledge / unveil, and privilege separation. This all works fine. It
> also has another trick, which unfortunately no longer works in 7.3.
>
> To reduce the code footprint of this daemon as well as the potential
> gadget attack surface, I have it drop any code that it will no longer
> execute. This happens after fork / exec on a child, and also after
> initialization code executes before the child process enters its steady
> state. This is trivially done by grouping functions into custom page
> aligned sections in the ELF binary, and running mprotect on these
> sections with PROT_NONE. I considered munmap as well as other tricks,
> but so far, this seems to be the most portable way to handle this trick
> that I could think of between BSD and Linux. I'm sure others are more
> clever. It's a cheap defense in depth protection that simplifies my use
> case.
Have you considered a libexec approach instead? If the goal is to keep a
child process having only the executable pages it needs for operations,
why not split up the program design instead of mucking with ELF stuff?
That surely has to be even more portable.
>
> As of OpenBSD 7.3, when the immutable flag entered mainstream, this
> trick no longer works. Given that my trick is a total hack, I'm not too
> broken up about it. Of course, this change led me to doing some poking
> around.
>
> I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
> Chrome to drop the write flag for a region for userland compatibility.
> That makes sense as a temporary measure. I'm wondering, however, if it
> might not make sense to think about this functionality differently.
> Instead of immutable memory regions, why can't we consider a more
> pledge-like ratcheting for memory regions, where bits can be removed,
> but never added back? How does this impact the gadget attack surface
> that led to the immutable flag being considered to begin with?
>
> For the time being, I extended the exception in uvm_map.c on my own
> OpenBSD systems to allow immutable regions to be stripped of all
> protection flags with a call to mprotect. So, in addition to allowing RW
> to R, if the region is any combination of PROT_READ, PROT_WRITE, or
> PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
> option for patching for now. Of course, this further breaks the
> definition of "immutable", but at least immutable regions can only have
> protection bits removed.
>
> My reason for mailing misc@ is just to bring up this data point from a
> single user. I'm certain that the OpenBSD developers have reasons for
> preferring a pure immutable flag, but having a mechanism for ratcheting
> down protections is useful at least for me, and is apparently useful
> enough in userland going from RW to R, that an exception was carved out
> for now. Of course, I'm more than happy to work with the developers to
> come up with a plan for upstreaming this feature if it's something
> useful. If not, I have no problem adding it to my personal list of
> patches I maintain that I doubt anyone else would want or need.
>
> - Justin
Re: lang/sbcl: update to 2.3.6 (latest) and take MAINTAINER
On Fri, Jun 30, 2023 at 01:37:48PM +0200, solene wrote:
>
> I don't know if this is expected, I wanted to try to build sbcl using
> ecl on amd64 because I don't have any other arch to try the build with
> ecl, but it's not working, I attached the build log
> ===> lang/sbcl
> ===> Building from scratch sbcl-2.3.6p0
> ===> sbcl-2.3.6p0 depends on: ecl-* -> ecl-21.2.1
the ecl version isn't the latest in -current. you need ecl-21.2.1p0 which
contains a backport to be able to build recent sbcl.
the p0 version was commited yesterday.
> ===> sbcl-2.3.6p0 depends on: texinfo-* -> texinfo-6.5p4
> ===> sbcl-2.3.6p0 depends on: gmake-* -> gmake-4.4.1
> ===> sbcl-2.3.6p0 depends on: dwz-* -> dwz-0.15
> ===> sbcl-2.3.6p0 depends on: bzip2-* -> bzip2-1.0.8p0
> ===> sbcl-2.3.6p0 depends on: zstd-* -> zstd-1.5.5
> ===> Verifying specs: c m util zstd
> ===> found c.97.0 m.10.1 util.17.0 zstd.6.3
thanks for testing it.
--
Sebastien Marie
>
> I don't know if this is expected, I wanted to try to build sbcl using
> ecl on amd64 because I don't have any other arch to try the build with
> ecl, but it's not working, I attached the build log
> ===> lang/sbcl
> ===> Building from scratch sbcl-2.3.6p0
> ===> sbcl-2.3.6p0 depends on: ecl-* -> ecl-21.2.1
the ecl version isn't the latest in -current. you need ecl-21.2.1p0 which
contains a backport to be able to build recent sbcl.
the p0 version was commited yesterday.
> ===> sbcl-2.3.6p0 depends on: texinfo-* -> texinfo-6.5p4
> ===> sbcl-2.3.6p0 depends on: gmake-* -> gmake-4.4.1
> ===> sbcl-2.3.6p0 depends on: dwz-* -> dwz-0.15
> ===> sbcl-2.3.6p0 depends on: bzip2-* -> bzip2-1.0.8p0
> ===> sbcl-2.3.6p0 depends on: zstd-* -> zstd-1.5.5
> ===> Verifying specs: c m util zstd
> ===> found c.97.0 m.10.1 util.17.0 zstd.6.3
thanks for testing it.
--
Sebastien Marie
Re: lang/* BTI breakage - lang/sbcl
On Fri, Jun 30, 2023 at 10:21:30AM +0100, Stuart Henderson wrote:
> On 2023/06/30 06:47, Sebastien Marie wrote:
> > On Thu, Jun 29, 2023 at 11:19:50PM +0200, Christian Weisgerber wrote:
> > > Since BTI affects any and all compilers that generate executable code,
> > > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> > > list of failures:
> > >
> > > [...]
> > > lang/sbcl
> >
> > the 2.3.6 update (already on ports@) adresses it by using USE_NOBTCFI.
>
> I'm ok with that update and taking maintainer FWIW (but I don't run lisp
> things myself).
>
> I guess it also needs a patch to sbcl itself to use nobtcfi when linking
> though, so that sbcl-compiled code also works at runtime? (Or an equivalent
> if it doesn't use the system linker).
>
sbcl compilation works by generating native code inside live managed memory, and
permits to save the whole memory image to a file.
it is why the binary currently also needs WX and RX memory (I intent to work a
bit on it if possible).
When generating an executable, it is copying /usr/local/bin/sbcl binary as base,
and append the (optionally compressed) memory image to the file, to create a
standalone executable.
When the output file is executed, it is reading its own image, loads it in
memory, and use an entrypoint for loaded code.
So the generated file has all the flags it needs to run (because copied from
/usr/local/bin/sbcl binary).
--
Sebastien Marie
> On 2023/06/30 06:47, Sebastien Marie wrote:
> > On Thu, Jun 29, 2023 at 11:19:50PM +0200, Christian Weisgerber wrote:
> > > Since BTI affects any and all compilers that generate executable code,
> > > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> > > list of failures:
> > >
> > > [...]
> > > lang/sbcl
> >
> > the 2.3.6 update (already on ports@) adresses it by using USE_NOBTCFI.
>
> I'm ok with that update and taking maintainer FWIW (but I don't run lisp
> things myself).
>
> I guess it also needs a patch to sbcl itself to use nobtcfi when linking
> though, so that sbcl-compiled code also works at runtime? (Or an equivalent
> if it doesn't use the system linker).
>
sbcl compilation works by generating native code inside live managed memory, and
permits to save the whole memory image to a file.
it is why the binary currently also needs WX and RX memory (I intent to work a
bit on it if possible).
When generating an executable, it is copying /usr/local/bin/sbcl binary as base,
and append the (optionally compressed) memory image to the file, to create a
standalone executable.
When the output file is executed, it is reading its own image, loads it in
memory, and use an entrypoint for loaded code.
So the generated file has all the flags it needs to run (because copied from
/usr/local/bin/sbcl binary).
--
Sebastien Marie
Port Request
Hello OpenBSD Devs! I want to make a request, can you guys please try to port ytfzf to OBSD. I used it a lot on GNU/linux, and I would greatly appreciate if you guys could. Thank You
Re: lang/* BTI breakage - lang/sbcl
On 2023/06/30 06:47, Sebastien Marie wrote:
> On Thu, Jun 29, 2023 at 11:19:50PM +0200, Christian Weisgerber wrote:
> > Since BTI affects any and all compilers that generate executable code,
> > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> > list of failures:
> >
> > [...]
> > lang/sbcl
>
> the 2.3.6 update (already on ports@) adresses it by using USE_NOBTCFI.
I'm ok with that update and taking maintainer FWIW (but I don't run lisp
things myself).
I guess it also needs a patch to sbcl itself to use nobtcfi when linking
though, so that sbcl-compiled code also works at runtime? (Or an equivalent
if it doesn't use the system linker).
> On Thu, Jun 29, 2023 at 11:19:50PM +0200, Christian Weisgerber wrote:
> > Since BTI affects any and all compilers that generate executable code,
> > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> > list of failures:
> >
> > [...]
> > lang/sbcl
>
> the 2.3.6 update (already on ports@) adresses it by using USE_NOBTCFI.
I'm ok with that update and taking maintainer FWIW (but I don't run lisp
things myself).
I guess it also needs a patch to sbcl itself to use nobtcfi when linking
though, so that sbcl-compiled code also works at runtime? (Or an equivalent
if it doesn't use the system linker).
Re: BGP Router Hardware Suggestions
On 2023-06-29, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote:
> We are about to discover the joys of upstream BGP routing :-P The
> current plan is to use a pair of OpenBSD+bgpd hosts as the routers.
>
> Each host will require 4x10gig ports (SFP+). One of those links
> (to AWS) will be close to saturated, along with the downlink to our
> switches. The other two will only need to carry ~1Gb/s of traffic.
>
> We are pretty much a Supermicro shop, and I'm wondering if anyone
> out there is running a similar setup on SM hardware. My main concern
> is finding NICs that will let us squeeze every last drop of bandwidth
> on the 10gig links.
I don't need full 10G and haven't benchmarked anything recently, but
Hrvoje has done a lot of testing in this area, see comments at
https://marc.info/?l=openbsd-misc&m=167665861931266&w=2
For servers, look at the AMD boards e.g. M11SDV-based systems like
https://www.supermicro.com/Aplus/system/Embedded/AS-5019D-FTN4.cfm
Sadly Supermicro seem to have stopped doing boards with 4x fibre
module slots, so you'll be stuck with needing PCIe NICs for the
newer boards. (Newer xeon d boards have 2xSFP28 plus copper;
networking on their AMD boards tend to be copper only).
I would probably favour ix(4) i.e. X520 (for one thing, firmware is less
of a moving target..)
> I did run some brief ttcp tests on a pair of SM 1Us (don't have the
> model number handy, maybe 5018-FTN4s?) with add-in Intel cards
> (550s?) and was able to get 700 MBytes/s of throughput. This would
> have been circa the 6.7 or 6.8 releases.
A lot changed since then. See some stats over time at
http://bluhm.genua.de/perform/results/perform.html
(especially forwarding tests).
Don't test packet generation on the box itself if you care about
forwarding. Generate packets elsewhere and pass them through
the device under test.
> We are about to discover the joys of upstream BGP routing :-P The
> current plan is to use a pair of OpenBSD+bgpd hosts as the routers.
>
> Each host will require 4x10gig ports (SFP+). One of those links
> (to AWS) will be close to saturated, along with the downlink to our
> switches. The other two will only need to carry ~1Gb/s of traffic.
>
> We are pretty much a Supermicro shop, and I'm wondering if anyone
> out there is running a similar setup on SM hardware. My main concern
> is finding NICs that will let us squeeze every last drop of bandwidth
> on the 10gig links.
I don't need full 10G and haven't benchmarked anything recently, but
Hrvoje has done a lot of testing in this area, see comments at
https://marc.info/?l=openbsd-misc&m=167665861931266&w=2
For servers, look at the AMD boards e.g. M11SDV-based systems like
https://www.supermicro.com/Aplus/system/Embedded/AS-5019D-FTN4.cfm
Sadly Supermicro seem to have stopped doing boards with 4x fibre
module slots, so you'll be stuck with needing PCIe NICs for the
newer boards. (Newer xeon d boards have 2xSFP28 plus copper;
networking on their AMD boards tend to be copper only).
I would probably favour ix(4) i.e. X520 (for one thing, firmware is less
of a moving target..)
> I did run some brief ttcp tests on a pair of SM 1Us (don't have the
> model number handy, maybe 5018-FTN4s?) with add-in Intel cards
> (550s?) and was able to get 700 MBytes/s of throughput. This would
> have been circa the 6.7 or 6.8 releases.
A lot changed since then. See some stats over time at
http://bluhm.genua.de/perform/results/perform.html
(especially forwarding tests).
Don't test packet generation on the box itself if you care about
forwarding. Generate packets elsewhere and pass them through
the device under test.
Re: BGP Router Hardware Suggestions
29 Jun 2023, 23:57 by lyndon@orthanc.ca:
> We are about to discover the joys of upstream BGP routing :-P The
> current plan is to use a pair of OpenBSD+bgpd hosts as the routers.
>
> Each host will require 4x10gig ports (SFP+). One of those links
> (to AWS) will be close to saturated, along with the downlink to our
> switches. The other two will only need to carry ~1Gb/s of traffic.
>
> We are pretty much a Supermicro shop, and I'm wondering if anyone
> out there is running a similar setup on SM hardware. My main concern
> is finding NICs that will let us squeeze every last drop of bandwidth
> on the 10gig links.
>
I have had excellent luck on 1g using HotLava (https://www.hotlavasystems.com/) cards which are Intel based but custom design.
I am currently working on upgrading parts of my network to 10g, also using HotLava, but sadly the OpenBSD devs need to update the ixl drivers to match the newer Intel API because at the moment stuff like "ifconfig ixl sff" returns nothing when it should return transciever DOM data.
> We are about to discover the joys of upstream BGP routing :-P The
> current plan is to use a pair of OpenBSD+bgpd hosts as the routers.
>
> Each host will require 4x10gig ports (SFP+). One of those links
> (to AWS) will be close to saturated, along with the downlink to our
> switches. The other two will only need to carry ~1Gb/s of traffic.
>
> We are pretty much a Supermicro shop, and I'm wondering if anyone
> out there is running a similar setup on SM hardware. My main concern
> is finding NICs that will let us squeeze every last drop of bandwidth
> on the 10gig links.
>
I have had excellent luck on 1g using HotLava (https://www.hotlavasystems.com/) cards which are Intel based but custom design.
I am currently working on upgrading parts of my network to 10g, also using HotLava, but sadly the OpenBSD devs need to update the ixl drivers to match the newer Intel API because at the moment stuff like "ifconfig ixl sff" returns nothing when it should return transciever DOM data.
Immutable Page Protections
I'm assuming that misc@ is probably the best place for this e-mail,
although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
long ago, and I noticed that a daemon I had written was no longer
working properly. For reasons that are probably too much to get into
here, I statically link the daemon. It's a single binary that makes use
of pledge / unveil, and privilege separation. This all works fine. It
also has another trick, which unfortunately no longer works in 7.3.
To reduce the code footprint of this daemon as well as the potential
gadget attack surface, I have it drop any code that it will no longer
execute. This happens after fork / exec on a child, and also after
initialization code executes before the child process enters its steady
state. This is trivially done by grouping functions into custom page
aligned sections in the ELF binary, and running mprotect on these
sections with PROT_NONE. I considered munmap as well as other tricks,
but so far, this seems to be the most portable way to handle this trick
that I could think of between BSD and Linux. I'm sure others are more
clever. It's a cheap defense in depth protection that simplifies my use
case.
As of OpenBSD 7.3, when the immutable flag entered mainstream, this
trick no longer works. Given that my trick is a total hack, I'm not too
broken up about it. Of course, this change led me to doing some poking
around.
I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
Chrome to drop the write flag for a region for userland compatibility.
That makes sense as a temporary measure. I'm wondering, however, if it
might not make sense to think about this functionality differently.
Instead of immutable memory regions, why can't we consider a more
pledge-like ratcheting for memory regions, where bits can be removed,
but never added back? How does this impact the gadget attack surface
that led to the immutable flag being considered to begin with?
For the time being, I extended the exception in uvm_map.c on my own
OpenBSD systems to allow immutable regions to be stripped of all
protection flags with a call to mprotect. So, in addition to allowing RW
to R, if the region is any combination of PROT_READ, PROT_WRITE, or
PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
option for patching for now. Of course, this further breaks the
definition of "immutable", but at least immutable regions can only have
protection bits removed.
My reason for mailing misc@ is just to bring up this data point from a
single user. I'm certain that the OpenBSD developers have reasons for
preferring a pure immutable flag, but having a mechanism for ratcheting
down protections is useful at least for me, and is apparently useful
enough in userland going from RW to R, that an exception was carved out
for now. Of course, I'm more than happy to work with the developers to
come up with a plan for upstreaming this feature if it's something
useful. If not, I have no problem adding it to my personal list of
patches I maintain that I doubt anyone else would want or need.
- Justin
although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so
long ago, and I noticed that a daemon I had written was no longer
working properly. For reasons that are probably too much to get into
here, I statically link the daemon. It's a single binary that makes use
of pledge / unveil, and privilege separation. This all works fine. It
also has another trick, which unfortunately no longer works in 7.3.
To reduce the code footprint of this daemon as well as the potential
gadget attack surface, I have it drop any code that it will no longer
execute. This happens after fork / exec on a child, and also after
initialization code executes before the child process enters its steady
state. This is trivially done by grouping functions into custom page
aligned sections in the ELF binary, and running mprotect on these
sections with PROT_NONE. I considered munmap as well as other tricks,
but so far, this seems to be the most portable way to handle this trick
that I could think of between BSD and Linux. I'm sure others are more
clever. It's a cheap defense in depth protection that simplifies my use
case.
As of OpenBSD 7.3, when the immutable flag entered mainstream, this
trick no longer works. Given that my trick is a total hack, I'm not too
broken up about it. Of course, this change led me to doing some poking
around.
I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow
Chrome to drop the write flag for a region for userland compatibility.
That makes sense as a temporary measure. I'm wondering, however, if it
might not make sense to think about this functionality differently.
Instead of immutable memory regions, why can't we consider a more
pledge-like ratcheting for memory regions, where bits can be removed,
but never added back? How does this impact the gadget attack surface
that led to the immutable flag being considered to begin with?
For the time being, I extended the exception in uvm_map.c on my own
OpenBSD systems to allow immutable regions to be stripped of all
protection flags with a call to mprotect. So, in addition to allowing RW
to R, if the region is any combination of PROT_READ, PROT_WRITE, or
PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer
option for patching for now. Of course, this further breaks the
definition of "immutable", but at least immutable regions can only have
protection bits removed.
My reason for mailing misc@ is just to bring up this data point from a
single user. I'm certain that the OpenBSD developers have reasons for
preferring a pure immutable flag, but having a mechanism for ratcheting
down protections is useful at least for me, and is apparently useful
enough in userland going from RW to R, that an exception was carved out
for now. Of course, I'm more than happy to work with the developers to
come up with a plan for upstreaming this feature if it's something
useful. If not, I have no problem adding it to my personal list of
patches I maintain that I doubt anyone else would want or need.
- Justin
Thursday, June 29, 2023
Re: lang/* BTI breakage - lang/sbcl
On Thu, Jun 29, 2023 at 11:19:50PM +0200, Christian Weisgerber wrote:
> Since BTI affects any and all compilers that generate executable code,
> I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> list of failures:
>
> [...]
> lang/sbcl
the 2.3.6 update (already on ports@) adresses it by using USE_NOBTCFI.
--
Sebastien Marie
> Since BTI affects any and all compilers that generate executable code,
> I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> list of failures:
>
> [...]
> lang/sbcl
the 2.3.6 update (already on ports@) adresses it by using USE_NOBTCFI.
--
Sebastien Marie
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org
started on Tue Jun 27 10:49:45 MDT 2023
finished at Thu Jun 29 20:34:44 MDT 2023
lasted 2D09h44m
done with kern.version=OpenBSD 7.3-current (GENERIC.MP) #2176: Tue Jun 27 03:12:23 MDT 2023
built packages:11674
Jun 27:3093
Jun 28:1043
Jun 29:7537
critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2023-06-27/summary.log
build failures: 2
http://build-failures.rhaalovely.net/aarch64/2023-06-27/games/lwjgl3.log
http://build-failures.rhaalovely.net/aarch64/2023-06-27/x11/mate/utils.log
recurrent failures
failures/games/lwjgl3.log
failures/x11/mate/utils.log
new failures
+++ ls-failures Thu Jun 29 20:34:56 2023
resolved failures
--- ../old/aarch64/last//ls-failures Sat Jun 24 00:39:47 2023
-failures/devel/quirks.log
started on Tue Jun 27 10:49:45 MDT 2023
finished at Thu Jun 29 20:34:44 MDT 2023
lasted 2D09h44m
done with kern.version=OpenBSD 7.3-current (GENERIC.MP) #2176: Tue Jun 27 03:12:23 MDT 2023
built packages:11674
Jun 27:3093
Jun 28:1043
Jun 29:7537
critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2023-06-27/summary.log
build failures: 2
http://build-failures.rhaalovely.net/aarch64/2023-06-27/games/lwjgl3.log
http://build-failures.rhaalovely.net/aarch64/2023-06-27/x11/mate/utils.log
recurrent failures
failures/games/lwjgl3.log
failures/x11/mate/utils.log
new failures
+++ ls-failures Thu Jun 29 20:34:56 2023
resolved failures
--- ../old/aarch64/last//ls-failures Sat Jun 24 00:39:47 2023
-failures/devel/quirks.log
[update] security/osv-scanner to 1.3.5
diff refs/heads/master refs/heads/osv
commit - 20cf8735fbeddad90caa5253fa7cc06119f78a1e
commit + 19c94d7e61976ab21392163b018b5081557a7220
blob - afe7fd52e81fcf10048eac96797eedb68742f382
blob + 8d963684c86100d69c2a38e10b5952792241f864
--- security/osv-scanner/Makefile
+++ security/osv-scanner/Makefile
@@ -6,7 +6,7 @@ V = 1.3.4
COMMENT = scan your project's dependencies for vulnerabilities
-V = 1.3.4
+V = 1.3.5
MODGO_MODNAME = github.com/google/osv-scanner
MODGO_VERSION = v${V}
blob - 47d5658a20dd0904121303af1199b07dd7054dd0
blob + c6c5dfd352836e3e4985f7e1cc0c7db2e0b684f6
--- security/osv-scanner/distinfo
+++ security/osv-scanner/distinfo
@@ -1,7 +1,6 @@
SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.mod) = KAIbQYClnDmTYHqVsY4jDdC8a+pSQv/o6ou/tPT3tNc=
-SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.2.1.mod) = JnfIL+dPIDdyiJpagBr7Mp2VF1UId92ssXIZFpurPt0=
-SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.0.mod) = JnfIL+dPIDdyiJpagBr7Mp2VF1UId92ssXIZFpurPt0=
-SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.0.zip) = z0XD4hoU47CW1crqHllrzjH+QY0ZeSPzR5H+wnw0AGc=
+SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.2.mod) = JnfIL+dPIDdyiJpagBr7Mp2VF1UId92ssXIZFpurPt0=
+SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.2.zip) = XeJGoMtMJW8/1dDbigihFPWK8MLhk7vwrZASEErbtrI=
SHA256 (go_modules/github.com/!cyclone!d!x/cyclonedx-go/@v/v0.7.1.mod) = uqvhVbf1hOh1/U4bvuiQTjf0qn4QJl1WfdKYiAY/5oM=
SHA256 (go_modules/github.com/!cyclone!d!x/cyclonedx-go/@v/v0.7.1.zip) = +D2ExgswC7p36y6FOYnFDHq/mMWWIPtaC24x2gd3aAU=
SHA256 (go_modules/github.com/!microsoft/go-winio/@v/v0.5.2.mod) = Gbj76dRBkni7Hp0M8v1a7IeeQoKcU7o+/VZWuNGzWuc=
@@ -47,6 +46,10 @@ SHA256 (go_modules/github.com/golang/groupcache/@v/v0.
SHA256 (go_modules/github.com/go-git/go-git-fixtures/v4/@v/v4.3.2-0.20230305113008-0c11038e723f.zip) = VGUYT34LRmv9QlPdoE+76oPV2/QE59cfT/oUXXXXFGM=
SHA256 (go_modules/github.com/go-git/go-git/v5/@v/v5.7.0.mod) = hiQXhmzSVCgs8EoVW8rKHPV6gygpVO/hjETig3U7q90=
SHA256 (go_modules/github.com/go-git/go-git/v5/@v/v5.7.0.zip) = ffddu8q13gz+0DHENq4BeKF9l9cS998vbCSVOXPPBfw=
+SHA256 (go_modules/github.com/goark/errs/@v/v1.1.0.mod) = HdP0dfT4+GCMG+9lWyqNew4gr5jOusFXVZMrCapncEY=
+SHA256 (go_modules/github.com/goark/errs/@v/v1.1.0.zip) = i43JhykUlVOpgvOs4Xa3KJKpCCY6SiUpGux+Bz2ThBc=
+SHA256 (go_modules/github.com/goark/go-cvss/@v/v1.6.6.mod) = YOdemKeD2deEmjJAzwBtcCovyubv4HpxBv8bG+zMNn4=
+SHA256 (go_modules/github.com/goark/go-cvss/@v/v1.6.6.zip) = IkqCKDAhSMFmO5wZpleYQrJtjQD4xAqN24U7fvVpKOs=
SHA256 (go_modules/github.com/golang/groupcache/@v/v0.0.0-20210331224755-41bb18bfe9da.mod) = URfiu4bxzHzHSJ+fJYD6F7LvHjoKNGv2TtgGPKe4dmM=
SHA256 (go_modules/github.com/golang/groupcache/@v/v0.0.0-20210331224755-41bb18bfe9da.zip) = snA06PwBNidUPhrQmM/GUynyiW3z2lzzJmzJFm+T86U=
SHA256 (go_modules/github.com/google/go-cmdtest/@v/v0.4.1-0.20220921163831-55ab3332a786.mod) = YBCCwe/4ls1GJ8PCPRVrWD+85CRh5UhHNLZGe5ZOtk0=
@@ -83,8 +86,8 @@ SHA256 (go_modules/github.com/package-url/packageurl-g
SHA256 (go_modules/github.com/mmcloughlin/avo/@v/v0.5.0.zip) = Yr553IwOXt9NTTmAFiMbtK2jCxnkmd30q5OF9Lb5FCo=
SHA256 (go_modules/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.mod) = jxQBiQgBFlu9PaF1jGyWQ48SqjJIZmrBWBwYqGQkTUc=
SHA256 (go_modules/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.zip) = LctwU/rxHCjK19hPz6Pdf5Pj0jaznYPP8JNPaR+GDXo=
-SHA256 (go_modules/github.com/package-url/packageurl-go/@v/v0.1.0.mod) = dRewXBS0JZJtI9XFqlk5cMumXf0FYeZSFfUOetMSct8=
-SHA256 (go_modules/github.com/package-url/packageurl-go/@v/v0.1.0.zip) = jUeNIwh+x3V5lx5eKmWuYNZypreYIFw+CGSJPEzu0G4=
+SHA256 (go_modules/github.com/package-url/packageurl-go/@v/v0.1.1.mod) = WtMu4++y8MyV5RLpaxj2GWiBXwXLTpBVYacq5IyrWtE=
+SHA256 (go_modules/github.com/package-url/packageurl-go/@v/v0.1.1.zip) = E4RHGgDw4CbF5F2fzMDaNj6UIyZ875M5jbFvzyS9uGA=
SHA256 (go_modules/github.com/pjbgf/sha1cd/@v/v0.3.0.mod) = 8Qo2tGIntPuz5pD2zHJtlGR18xZp7rxSxK1bLombToA=
SHA256 (go_modules/github.com/pjbgf/sha1cd/@v/v0.3.0.zip) = rP7pbdL+jmrgiumGRQSDCknSNddMKrk996XfopqQpGE=
SHA256 (go_modules/github.com/pkg/diff/@v/v0.0.0-20210226163009-20ebb0f2a09e.mod) = XVuUVOLQIK8MdgNWjoaQS5m+/E1dZ8OoUF9hIVib0R8=
@@ -110,8 +113,8 @@ SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.
SHA256 (go_modules/github.com/spdx/gordf/@v/v0.0.0-20201111095634-7098f93598fb.mod) = eKUongYQUXmwBVYtvFiYMNLnHrFgrEUV5RiQ5fFMgYk=
SHA256 (go_modules/github.com/spdx/gordf/@v/v0.0.0-20221230105357-b735bd5aac89.mod) = eKUongYQUXmwBVYtvFiYMNLnHrFgrEUV5RiQ5fFMgYk=
SHA256 (go_modules/github.com/spdx/gordf/@v/v0.0.0-20221230105357-b735bd5aac89.zip) = XxsMQLKthYlrDa14n8WZRd/FR93bivyiABl27UQYdtw=
-SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.5.1.mod) = aSS5w8etG/mpXeTWSCwA/py3oIFpSkd2j0LCXlGv0xI=
-SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.5.1.zip) = XBe+mI+YJL60OtZP39qf/Ft4BwjUVlUXCbA5a+rjnnY=
+SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.5.2.mod) = 1AmtiCKBeI7KM6dD7wYyS8c15GYS3AQ+x23Ucj8SHfc=
+SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.5.2.zip) = a1+qOzY53gmg8Eu5YD8+o4DXca+RSN/zhDRbRYXhR3E=
SHA256 (go_modules/github.com/stretchr/objx/@v/v0.1.0.mod) = E1A1TVLSKHpiM27MDVYjLUxHaZr5u6ScZ8K0glTamPE=
SHA256 (go_modules/github.com/stretchr/objx/@v/v0.4.0.mod) = MbL9ze6HDw9hv/r6+5YiCWflvKCKdqkg1XQhb8H5E1U=
SHA256 (go_modules/github.com/stretchr/objx/@v/v0.5.0.mod) = yzJlQO/LEnSm5Olw1/yd4ugGLwigWPwpbYWQJeYugHo=
@@ -122,10 +125,10 @@ SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8
SHA256 (go_modules/github.com/stretchr/testify/@v/v1.7.4.mod) = 4HYHTBVgrR3amLiwD+pjCMS2zNBt3QiNIttGJu1o9zg=
SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.0.mod) = 4HYHTBVgrR3amLiwD+pjCMS2zNBt3QiNIttGJu1o9zg=
SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.2.mod) = rxpdyzMazno/n8G11+7pwLyCtKKhgv5M7CrdIX4oU9Y=
-SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.3.mod) = BeJs0GkoWjPPKvRv2s3vVp1a4YXnljp2wBeDKPaOl/k=
-SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.3.zip) = pL+MgUt9wD59Kkt2/A9objjwxrmPxhr+RCLwWYN3lSg=
-SHA256 (go_modules/github.com/urfave/cli/v2/@v/v2.25.5.mod) = vrUO54Wf55rTJgt1onaRXPZpTqf1UBuI9VD4q7RpqU0=
-SHA256 (go_modules/github.com/urfave/cli/v2/@v/v2.25.5.zip) = SgOQiR/xUzTfXM39qLIflUHKwQl03sxUMCo+igF+ahw=
+SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.4.mod) = BeJs0GkoWjPPKvRv2s3vVp1a4YXnljp2wBeDKPaOl/k=
+SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.4.zip) = 4gbart4L0D3gYL3765hKwsSbgwWHU//8k/4MIg6odTI=
+SHA256 (go_modules/github.com/urfave/cli/v2/@v/v2.25.7.mod) = XD3aJw3iuXT/2n/bvxItJJk7suwFeFtP+RROdhfqxBU=
+SHA256 (go_modules/github.com/urfave/cli/v2/@v/v2.25.7.zip) = EJQbJGidfJU6eLbRlqA+BCdOAS0n1PKX/oRM9YIhqGw=
SHA256 (go_modules/github.com/xanzy/ssh-agent/@v/v0.3.3.mod) = HOHMUJiJtzjB9j2/zFrVIs62MnLZ3v9u73SZ7TAaoSU=
SHA256 (go_modules/github.com/xanzy/ssh-agent/@v/v0.3.3.zip) = GahsJiOyDMmGh73diePwI9sMpRyLyeOLmtnFblt9EQ0=
SHA256 (go_modules/github.com/xrash/smetrics/@v/v0.0.0-20201216005158-039620a65673.mod) = Kz9hJyfgYrwlZDq5c5S7f0F6KXqf9lIqDxjs93h38EI=
@@ -135,16 +138,17 @@ SHA256 (go_modules/golang.org/x/crypto/@v/v0.3.1-0.202
SHA256 (go_modules/golang.org/x/crypto/@v/v0.0.0-20190308221718-c2843e01d9a2.mod) = M+0HClpm4JYGhaxThkQOG1mJnnTYo4oRgGhecqIZXe0=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.0.0-20210921155107-089bfa567519.mod) = zWMRYSoqpNDX4DxBs6ofvC1fiVqz9hCJ+rgL/p+PVIU=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.0.0-20220622213112-05595931fe9d.mod) = ryyI7r/wPjoq/ssbA2afxU6dEiyI97Ls/tBR7F28i7s=
+SHA256 (go_modules/golang.org/x/crypto/@v/v0.10.0.mod) = LAC5Gxo4OLTluAFtx+6AEL7pCK+ErVH30bgs956frN0=
+SHA256 (go_modules/golang.org/x/crypto/@v/v0.10.0.zip) = Lk+bct9vSAp0RIOxTWuMutmP8GY5mXmsdP8dxbdOm+w=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.3.1-0.20221117191849-2c476679df9a.mod) = t5UQb4uN637XdSOoHeAatGAfDwOBNTkYRX0teK2ePOk=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.7.0.mod) = yJ/iLnPawmoAplasEf9MbhprbNKrzFftzazew/va2C0=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.8.0.mod) = XUhSCyhK7tyyTEqDKJShagfQmOyRKjYjd1DFFIlNKOg=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.9.0.mod) = nSAXdDfn8DoYKFjPQHQ6ImKD1dQRrVyFp5TiS6AiYLE=
-SHA256 (go_modules/golang.org/x/crypto/@v/v0.9.0.zip) = Zy68kWdAoEDV9UcrR34dGJjgawxsClqCC2VJW7sTPoI=
SHA256 (go_modules/golang.org/x/exp/@v/v0.0.0-20220722155223-a9213eeb770e.mod) = KqbbzGUyHHFTSmOE7NZqsrIERkRKV3BwZjFFGY3Rnas=
SHA256 (go_modules/golang.org/x/exp/@v/v0.0.0-20230522175609-2e198f4a06a1.mod) = EF8h/6AuHlv/paPw/lAoL4JDRLRXLLlG+MRWK0JUfWc=
SHA256 (go_modules/golang.org/x/exp/@v/v0.0.0-20230522175609-2e198f4a06a1.zip) = r5TnnT1zOBgxMKsXwSm3NTjTcs6rYCz7Z4eABdiSSsg=
-SHA256 (go_modules/golang.org/x/mod/@v/v0.10.0.mod) = YkVnRZxumUesSr3gtwNO5h3Ltqk3P1lwCUwLs+gSGWQ=
-SHA256 (go_modules/golang.org/x/mod/@v/v0.10.0.zip) = +HZHOsJ/HG47D/+XHIT7689nDbCz6PKB4DFJ/PY2/iU=
+SHA256 (go_modules/golang.org/x/mod/@v/v0.11.0.mod) = YkVnRZxumUesSr3gtwNO5h3Ltqk3P1lwCUwLs+gSGWQ=
+SHA256 (go_modules/golang.org/x/mod/@v/v0.11.0.zip) = NkGYkwzH9GuluxwJh9CJpVeqC0Bvjv7ASQdEpFTfAKU=
SHA256 (go_modules/golang.org/x/mod/@v/v0.6.0-dev.0.20220419223038-86c51ed26bb4.mod) = QtGQI/+PLq5wC8VJXzcezZmKItGbqYXQr19pkAslQIM=
SHA256 (go_modules/golang.org/x/mod/@v/v0.6.0.mod) = mfQKUOjWDCWZrEXGzix21VSoQorNE8LGikk/ymGbT6g=
SHA256 (go_modules/golang.org/x/mod/@v/v0.8.0.mod) = YkVnRZxumUesSr3gtwNO5h3Ltqk3P1lwCUwLs+gSGWQ=
@@ -153,14 +157,15 @@ SHA256 (go_modules/golang.org/x/net/@v/v0.10.0.zip) =
SHA256 (go_modules/golang.org/x/net/@v/v0.0.0-20211112202133-69e39bad7dc2.mod) = +pFfXQIs+wy4Zaou4306d0G0BvhOtKg3hi4pzGmrTvQ=
SHA256 (go_modules/golang.org/x/net/@v/v0.0.0-20220722155237-a158d28d115b.mod) = sxXFJkfS2i925c2502fh1nJ3hCNqm/+2EhkrGbEKEo0=
SHA256 (go_modules/golang.org/x/net/@v/v0.10.0.mod) = 07fiNv8J5jIr5IkXAhbgGNMiGGLxoFPctj5T6rhTPBc=
-SHA256 (go_modules/golang.org/x/net/@v/v0.10.0.zip) = +S+bJlUiam0BWvenYnmhH7VWeOQQuFGxWPyEZUb4BzM=
+SHA256 (go_modules/golang.org/x/net/@v/v0.11.0.mod) = DWuyXbLvxAvNvMtxZoT1ihVALyKzQpCY18uFDyIirWE=
+SHA256 (go_modules/golang.org/x/net/@v/v0.11.0.zip) = XZfbCzQ2dFKUmxsEGUtHpmPLsIUvQNEZul2RDMwSRlc=
SHA256 (go_modules/golang.org/x/net/@v/v0.6.0.mod) = Qex26iFy8+4wMeOPmlNZOaWE1rs170gIVP3LjCAmcBs=
SHA256 (go_modules/golang.org/x/net/@v/v0.8.0.mod) = 6275vWQFrOPZnkOB0CVs5B+Dxm0aILTigwpMd2JF9xo=
SHA256 (go_modules/golang.org/x/sync/@v/v0.0.0-20190423024810-112230192c58.mod) = Qh9hOWhtWJHz3FpWPQmVeA0yefZcrU0iXOpSaGeUFhw=
SHA256 (go_modules/golang.org/x/sync/@v/v0.0.0-20220722155255-886fb9371eb4.mod) = Qh9hOWhtWJHz3FpWPQmVeA0yefZcrU0iXOpSaGeUFhw=
SHA256 (go_modules/golang.org/x/sync/@v/v0.1.0.mod) = Qh9hOWhtWJHz3FpWPQmVeA0yefZcrU0iXOpSaGeUFhw=
-SHA256 (go_modules/golang.org/x/sync/@v/v0.2.0.mod) = Qh9hOWhtWJHz3FpWPQmVeA0yefZcrU0iXOpSaGeUFhw=
-SHA256 (go_modules/golang.org/x/sync/@v/v0.2.0.zip) = 7g30Vy3XNmV2eWT/gJsS8NQeOgdAIg1E1BihmYmgNjs=
+SHA256 (go_modules/golang.org/x/sync/@v/v0.3.0.mod) = 7Q/wxQgadUz8vnaMvPYMY5dbNddufXuZxayb+m2YKFE=
+SHA256 (go_modules/golang.org/x/sync/@v/v0.3.0.zip) = GHDnoZb3EZ1Mbtun3pzfxJ7hPIy3kh86lHVoFxxhUuA=
SHA256 (go_modules/golang.org/x/sys/@v/v0.0.0-20190215142949-d0b11bdaac8a.mod) = iWkRXko5EIhIMk55ob2KhEUjDm46rMvp+AV/tQ//yME=
SHA256 (go_modules/golang.org/x/sys/@v/v0.0.0-20191026070338-33540a1f6037.mod) = GBl56L1X0tngZBgtqGyaYRGqaXVeiI8IQx7OR0Kuw0M=
SHA256 (go_modules/golang.org/x/sys/@v/v0.0.0-20201119102817-f84b799fce68.mod) = GBl56L1X0tngZBgtqGyaYRGqaXVeiI8IQx7OR0Kuw0M=
@@ -177,29 +182,32 @@ SHA256 (go_modules/golang.org/x/sys/@v/v0.8.0.zip) = J
SHA256 (go_modules/golang.org/x/sys/@v/v0.6.0.mod) = 8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
SHA256 (go_modules/golang.org/x/sys/@v/v0.7.0.mod) = 8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
SHA256 (go_modules/golang.org/x/sys/@v/v0.8.0.mod) = 8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
-SHA256 (go_modules/golang.org/x/sys/@v/v0.8.0.zip) = JYizpkWDg5DjQfEAf4Z59eERe11ayUZ++DLRSLIhmjg=
+SHA256 (go_modules/golang.org/x/sys/@v/v0.9.0.mod) = 8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
+SHA256 (go_modules/golang.org/x/sys/@v/v0.9.0.zip) = OzfIdTTrq/nRpg7wPaFoBfEpNAi8r4t8u6nWRu2gfX8=
SHA256 (go_modules/golang.org/x/term/@v/v0.0.0-20201126162022-7de9c90e9dd1.mod) = TLqxT3cGdxsnHZlaGzzBMf5aJGqtx+5tG6bwvYlHgfo=
SHA256 (go_modules/golang.org/x/term/@v/v0.0.0-20210927222741-03fcf44c2211.mod) = dAeU4pFPXMh+JWVsWEMiKyxlZlghIF9FYyoEd8jT95s=
SHA256 (go_modules/golang.org/x/term/@v/v0.5.0.mod) = DW9YIoqtwaZSjmdV2gGFFlZuOuXFIB963hdz9W+o2TQ=
SHA256 (go_modules/golang.org/x/term/@v/v0.6.0.mod) = ZDWbnGU3CEePAgcpiFBE/z2ABxhtnUQRJf6HSBfnEgE=
-SHA256 (go_modules/golang.org/x/term/@v/v0.8.0.mod) = XTYtaoNFP3Akcl6CTAXFlJYk749MsT9dfj1Lfxygsyc=
-SHA256 (go_modules/golang.org/x/term/@v/v0.8.0.zip) = GWHf6lnOUx4tbmoyKHgfWViyfG2dnAmTL1/8VMTZzfk=
+SHA256 (go_modules/golang.org/x/term/@v/v0.9.0.mod) = Wi2XadlxLw3n6DPKDO5iWibh8vvt+sp0huFBzs9+CUw=
+SHA256 (go_modules/golang.org/x/term/@v/v0.9.0.zip) = tObSrJdzJiXu5YH0f+SiEl3YZo/ihXlLrBqaGn/T8eM=
+SHA256 (go_modules/golang.org/x/text/@v/v0.10.0.mod) = FR5qGDlJHEtQ3+nDNFHwYyjVUYvY7koAYd4Ct60zL7I=
+SHA256 (go_modules/golang.org/x/text/@v/v0.10.0.zip) = U+Txr0Nx547HF/oaKRnrn7+xskx0NVTP0AXuQ2OIzuI=
SHA256 (go_modules/golang.org/x/text/@v/v0.3.0.mod) = NoedWG/YAB6E2oeHGQoR5PeHSeKoHf6Lm2kxiZ//Mc8=
SHA256 (go_modules/golang.org/x/text/@v/v0.3.3.mod) = +7eojtFAUV55Dsp6EP/TGcl4axHGpsfln4D3+ze7RUI=
SHA256 (go_modules/golang.org/x/text/@v/v0.3.6.mod) = +7eojtFAUV55Dsp6EP/TGcl4axHGpsfln4D3+ze7RUI=
SHA256 (go_modules/golang.org/x/text/@v/v0.3.7.mod) = xF1mkIlCe8RjXQexhfm5aAMy0cSMdbPEnLcVuBoEpbA=
+SHA256 (go_modules/golang.org/x/text/@v/v0.6.0.mod) = FZKedvzgSupMkqNUQmu0M3BoRkWk7gPy510MLrFGYwQ=
SHA256 (go_modules/golang.org/x/text/@v/v0.7.0.mod) = FZKedvzgSupMkqNUQmu0M3BoRkWk7gPy510MLrFGYwQ=
SHA256 (go_modules/golang.org/x/text/@v/v0.8.0.mod) = Q29ZLne1k7AvvqN04jrTNpyGI/8NKckd594eZnLbmkE=
SHA256 (go_modules/golang.org/x/text/@v/v0.9.0.mod) = Q29ZLne1k7AvvqN04jrTNpyGI/8NKckd594eZnLbmkE=
-SHA256 (go_modules/golang.org/x/text/@v/v0.9.0.zip) = wcvmhOrwHAU78SMnOGl9EEAyelyK1i2t/JULWF0bTKo=
SHA256 (go_modules/golang.org/x/tools/@v/v0.0.0-20180917221912-90fa682c2a6e.mod) = oOAvBnj+Ytw8S0vHf6kSybcN4Q+p988veq0DNzkrUq8=
SHA256 (go_modules/golang.org/x/tools/@v/v0.0.0-20191119224855-298f0cb1881e.mod) = iNR5Jl+Ib15ZjXbAA9DyV7QtvxuJXYIKErWrCzUBrKE=
SHA256 (go_modules/golang.org/x/tools/@v/v0.1.12.mod) = KouTZYmPCCL6zmW6CJoTU+aKZdNC8wDKMXzOzN5kIfM=
+SHA256 (go_modules/golang.org/x/tools/@v/v0.10.0.mod) = 83xvC/JvN9AkgWmxwNeUXs3cgkxG8BRg83gnzpWr62w=
+SHA256 (go_modules/golang.org/x/tools/@v/v0.10.0.zip) = Vi8l5nSqtJ8Aoj7B/LRqV7Cp0nKH6pqIWIbJlDBtnBQ=
SHA256 (go_modules/golang.org/x/tools/@v/v0.2.0.mod) = nJteYq9p8rEAKc4SlE3Ig08SJqg7skPpoNvzfguxhro=
SHA256 (go_modules/golang.org/x/tools/@v/v0.6.0.mod) = gw7Xjc0+mSfEEuJkEjAwhEd0nVE9MQJNJ24kQ7IBZgk=
SHA256 (go_modules/golang.org/x/tools/@v/v0.6.1-0.20230217175706-3102dad5faf9.mod) = gw7Xjc0+mSfEEuJkEjAwhEd0nVE9MQJNJ24kQ7IBZgk=
-SHA256 (go_modules/golang.org/x/tools/@v/v0.9.3.mod) = FBIGSEXOBF727VKe3jyzqLyO1KKnwrfU+WeAfXyVhVE=
-SHA256 (go_modules/golang.org/x/tools/@v/v0.9.3.zip) = R4itEpHgywRBiPnzGmMHBu3FL6BwtcEDZpd8l/Djyp0=
SHA256 (go_modules/golang.org/x/vuln/@v/v0.0.0-20230303230808-d3042fecc4e3.mod) = 7Myv1lmpCaM+E9+f7Z3rH0tCHyldsvRHWsUS/3jHXPA=
SHA256 (go_modules/golang.org/x/vuln/@v/v0.0.0-20230303230808-d3042fecc4e3.zip) = NaXn5o77jm6373+pQn8hnIDgLEBR121/xPCAu8zUnDQ=
SHA256 (go_modules/golang.org/x/xerrors/@v/v0.0.0-20190717185122-a985d3407aa7.mod) = ql4+ybt7n2gWCe+sAZ2d4ae6dxkkj/Hqon54iC2z1/U=
@@ -223,11 +231,10 @@ SHA256 (osv-scanner-v1.3.4.zip) = Gw6USdnJ/lZw1JbiyGC1
SHA256 (go_modules/mvdan.cc/unparam/@v/v0.0.0-20211214103731-d0ef000c54e5.zip) = qr8FBOW0Bnhdr9xPH2NT3FTWZzrMefnXAcnCEvD/yII=
SHA256 (go_modules/sigs.k8s.io/yaml/@v/v1.3.0.mod) = L8eybun2ctl7QvpvJfWxWlWYK7usaZYdduux0DbRUAE=
SHA256 (go_modules/sigs.k8s.io/yaml/@v/v1.3.0.zip) = qsiNpVHCpRK2Qss1ZYvz3IYllaNWa9hA6/GOSALx/Mk=
-SHA256 (osv-scanner-v1.3.4.zip) = Gw6USdnJ/lZw1JbiyGC1JU037NazzmwSzdvFGLUVu+4=
+SHA256 (osv-scanner-v1.3.5.zip) = Qe3X+OdYJk3BBTqXNEY0F9P/Q5ib+grl9XzoeYECpOM=
SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.mod) = 34
-SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.2.1.mod) = 43
-SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.0.mod) = 43
-SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.0.zip) = 292624
+SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.2.mod) = 43
+SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.2.zip) = 303020
SIZE (go_modules/github.com/!cyclone!d!x/cyclonedx-go/@v/v0.7.1.mod) = 289
SIZE (go_modules/github.com/!cyclone!d!x/cyclonedx-go/@v/v0.7.1.zip) = 190030
SIZE (go_modules/github.com/!microsoft/go-winio/@v/v0.5.2.mod) = 147
@@ -273,6 +280,10 @@ SIZE (go_modules/github.com/golang/groupcache/@v/v0.0.
SIZE (go_modules/github.com/go-git/go-git-fixtures/v4/@v/v4.3.2-0.20230305113008-0c11038e723f.zip) = 98071761
SIZE (go_modules/github.com/go-git/go-git/v5/@v/v5.7.0.mod) = 1458
SIZE (go_modules/github.com/go-git/go-git/v5/@v/v5.7.0.zip) = 690957
+SIZE (go_modules/github.com/goark/errs/@v/v1.1.0.mod) = 38
+SIZE (go_modules/github.com/goark/errs/@v/v1.1.0.zip) = 17313
+SIZE (go_modules/github.com/goark/go-cvss/@v/v1.6.6.mod) = 110
+SIZE (go_modules/github.com/goark/go-cvss/@v/v1.6.6.zip) = 124320
SIZE (go_modules/github.com/golang/groupcache/@v/v0.0.0-20210331224755-41bb18bfe9da.mod) = 36
SIZE (go_modules/github.com/golang/groupcache/@v/v0.0.0-20210331224755-41bb18bfe9da.zip) = 39744
SIZE (go_modules/github.com/google/go-cmdtest/@v/v0.4.1-0.20220921163831-55ab3332a786.mod) = 126
@@ -309,8 +320,8 @@ SIZE (go_modules/github.com/package-url/packageurl-go/
SIZE (go_modules/github.com/mmcloughlin/avo/@v/v0.5.0.zip) = 1027129
SIZE (go_modules/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.mod) = 78
SIZE (go_modules/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.zip) = 13281
-SIZE (go_modules/github.com/package-url/packageurl-go/@v/v0.1.0.mod) = 53
-SIZE (go_modules/github.com/package-url/packageurl-go/@v/v0.1.0.zip) = 10604
+SIZE (go_modules/github.com/package-url/packageurl-go/@v/v0.1.1.mod) = 53
+SIZE (go_modules/github.com/package-url/packageurl-go/@v/v0.1.1.zip) = 15275
SIZE (go_modules/github.com/pjbgf/sha1cd/@v/v0.3.0.mod) = 213
SIZE (go_modules/github.com/pjbgf/sha1cd/@v/v0.3.0.zip) = 3528787
SIZE (go_modules/github.com/pkg/diff/@v/v0.0.0-20210226163009-20ebb0f2a09e.mod) = 36
@@ -336,8 +347,8 @@ SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.
SIZE (go_modules/github.com/spdx/gordf/@v/v0.0.0-20201111095634-7098f93598fb.mod) = 38
SIZE (go_modules/github.com/spdx/gordf/@v/v0.0.0-20221230105357-b735bd5aac89.mod) = 38
SIZE (go_modules/github.com/spdx/gordf/@v/v0.0.0-20221230105357-b735bd5aac89.zip) = 56398
-SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.1.mod) = 285
-SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.1.zip) = 582067
+SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.2.mod) = 285
+SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.2.zip) = 582429
SIZE (go_modules/github.com/stretchr/objx/@v/v0.1.0.mod) = 32
SIZE (go_modules/github.com/stretchr/objx/@v/v0.4.0.mod) = 137
SIZE (go_modules/github.com/stretchr/objx/@v/v0.5.0.mod) = 85
@@ -348,10 +359,10 @@ SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.3
SIZE (go_modules/github.com/stretchr/testify/@v/v1.7.4.mod) = 188
SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.0.mod) = 188
SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.2.mod) = 188
-SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.3.mod) = 188
-SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.3.zip) = 120084
-SIZE (go_modules/github.com/urfave/cli/v2/@v/v2.25.5.mod) = 280
-SIZE (go_modules/github.com/urfave/cli/v2/@v/v2.25.5.zip) = 3549490
+SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.4.mod) = 188
+SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.4.zip) = 120537
+SIZE (go_modules/github.com/urfave/cli/v2/@v/v2.25.7.mod) = 280
+SIZE (go_modules/github.com/urfave/cli/v2/@v/v2.25.7.zip) = 3549945
SIZE (go_modules/github.com/xanzy/ssh-agent/@v/v0.3.3.mod) = 203
SIZE (go_modules/github.com/xanzy/ssh-agent/@v/v0.3.3.zip) = 11274
SIZE (go_modules/github.com/xrash/smetrics/@v/v0.0.0-20201216005158-039620a65673.mod) = 33
@@ -361,16 +372,17 @@ SIZE (go_modules/golang.org/x/crypto/@v/v0.3.1-0.20221
SIZE (go_modules/golang.org/x/crypto/@v/v0.0.0-20190308221718-c2843e01d9a2.mod) = 88
SIZE (go_modules/golang.org/x/crypto/@v/v0.0.0-20210921155107-089bfa567519.mod) = 247
SIZE (go_modules/golang.org/x/crypto/@v/v0.0.0-20220622213112-05595931fe9d.mod) = 255
+SIZE (go_modules/golang.org/x/crypto/@v/v0.10.0.mod) = 188
+SIZE (go_modules/golang.org/x/crypto/@v/v0.10.0.zip) = 1780916
SIZE (go_modules/golang.org/x/crypto/@v/v0.3.1-0.20221117191849-2c476679df9a.mod) = 171
SIZE (go_modules/golang.org/x/crypto/@v/v0.7.0.mod) = 171
SIZE (go_modules/golang.org/x/crypto/@v/v0.8.0.mod) = 171
SIZE (go_modules/golang.org/x/crypto/@v/v0.9.0.mod) = 172
-SIZE (go_modules/golang.org/x/crypto/@v/v0.9.0.zip) = 1763182
SIZE (go_modules/golang.org/x/exp/@v/v0.0.0-20220722155223-a9213eeb770e.mod) = 325
SIZE (go_modules/golang.org/x/exp/@v/v0.0.0-20230522175609-2e198f4a06a1.mod) = 176
SIZE (go_modules/golang.org/x/exp/@v/v0.0.0-20230522175609-2e198f4a06a1.zip) = 449849
-SIZE (go_modules/golang.org/x/mod/@v/v0.10.0.mod) = 84
-SIZE (go_modules/golang.org/x/mod/@v/v0.10.0.zip) = 162521
+SIZE (go_modules/golang.org/x/mod/@v/v0.11.0.mod) = 84
+SIZE (go_modules/golang.org/x/mod/@v/v0.11.0.zip) = 165162
SIZE (go_modules/golang.org/x/mod/@v/v0.6.0-dev.0.20220419223038-86c51ed26bb4.mod) = 157
SIZE (go_modules/golang.org/x/mod/@v/v0.6.0.mod) = 117
SIZE (go_modules/golang.org/x/mod/@v/v0.8.0.mod) = 84
@@ -379,14 +391,15 @@ SIZE (go_modules/golang.org/x/net/@v/v0.10.0.zip) = 15
SIZE (go_modules/golang.org/x/net/@v/v0.0.0-20211112202133-69e39bad7dc2.mod) = 179
SIZE (go_modules/golang.org/x/net/@v/v0.0.0-20220722155237-a158d28d115b.mod) = 179
SIZE (go_modules/golang.org/x/net/@v/v0.10.0.mod) = 123
-SIZE (go_modules/golang.org/x/net/@v/v0.10.0.zip) = 1564890
+SIZE (go_modules/golang.org/x/net/@v/v0.11.0.mod) = 153
+SIZE (go_modules/golang.org/x/net/@v/v0.11.0.zip) = 1618900
SIZE (go_modules/golang.org/x/net/@v/v0.6.0.mod) = 123
SIZE (go_modules/golang.org/x/net/@v/v0.8.0.mod) = 123
SIZE (go_modules/golang.org/x/sync/@v/v0.0.0-20190423024810-112230192c58.mod) = 25
SIZE (go_modules/golang.org/x/sync/@v/v0.0.0-20220722155255-886fb9371eb4.mod) = 25
SIZE (go_modules/golang.org/x/sync/@v/v0.1.0.mod) = 25
-SIZE (go_modules/golang.org/x/sync/@v/v0.2.0.mod) = 25
-SIZE (go_modules/golang.org/x/sync/@v/v0.2.0.zip) = 27919
+SIZE (go_modules/golang.org/x/sync/@v/v0.3.0.mod) = 34
+SIZE (go_modules/golang.org/x/sync/@v/v0.3.0.zip) = 29766
SIZE (go_modules/golang.org/x/sys/@v/v0.0.0-20190215142949-d0b11bdaac8a.mod) = 24
SIZE (go_modules/golang.org/x/sys/@v/v0.0.0-20191026070338-33540a1f6037.mod) = 33
SIZE (go_modules/golang.org/x/sys/@v/v0.0.0-20201119102817-f84b799fce68.mod) = 33
@@ -403,29 +416,32 @@ SIZE (go_modules/golang.org/x/sys/@v/v0.8.0.zip) = 189
SIZE (go_modules/golang.org/x/sys/@v/v0.6.0.mod) = 33
SIZE (go_modules/golang.org/x/sys/@v/v0.7.0.mod) = 33
SIZE (go_modules/golang.org/x/sys/@v/v0.8.0.mod) = 33
-SIZE (go_modules/golang.org/x/sys/@v/v0.8.0.zip) = 1894928
+SIZE (go_modules/golang.org/x/sys/@v/v0.9.0.mod) = 33
+SIZE (go_modules/golang.org/x/sys/@v/v0.9.0.zip) = 1898437
SIZE (go_modules/golang.org/x/term/@v/v0.0.0-20201126162022-7de9c90e9dd1.mod) = 95
SIZE (go_modules/golang.org/x/term/@v/v0.0.0-20210927222741-03fcf44c2211.mod) = 95
SIZE (go_modules/golang.org/x/term/@v/v0.5.0.mod) = 67
SIZE (go_modules/golang.org/x/term/@v/v0.6.0.mod) = 67
-SIZE (go_modules/golang.org/x/term/@v/v0.8.0.mod) = 67
-SIZE (go_modules/golang.org/x/term/@v/v0.8.0.zip) = 19924
+SIZE (go_modules/golang.org/x/term/@v/v0.9.0.mod) = 67
+SIZE (go_modules/golang.org/x/term/@v/v0.9.0.zip) = 19924
+SIZE (go_modules/golang.org/x/text/@v/v0.10.0.mod) = 197
+SIZE (go_modules/golang.org/x/text/@v/v0.10.0.zip) = 8620307
SIZE (go_modules/golang.org/x/text/@v/v0.3.0.mod) = 25
SIZE (go_modules/golang.org/x/text/@v/v0.3.3.mod) = 97
SIZE (go_modules/golang.org/x/text/@v/v0.3.6.mod) = 97
SIZE (go_modules/golang.org/x/text/@v/v0.3.7.mod) = 97
+SIZE (go_modules/golang.org/x/text/@v/v0.6.0.mod) = 258
SIZE (go_modules/golang.org/x/text/@v/v0.7.0.mod) = 258
SIZE (go_modules/golang.org/x/text/@v/v0.8.0.mod) = 215
SIZE (go_modules/golang.org/x/text/@v/v0.9.0.mod) = 215
-SIZE (go_modules/golang.org/x/text/@v/v0.9.0.zip) = 8614767
SIZE (go_modules/golang.org/x/tools/@v/v0.0.0-20180917221912-90fa682c2a6e.mod) = 26
SIZE (go_modules/golang.org/x/tools/@v/v0.0.0-20191119224855-298f0cb1881e.mod) = 212
SIZE (go_modules/golang.org/x/tools/@v/v0.1.12.mod) = 327
+SIZE (go_modules/golang.org/x/tools/@v/v0.10.0.mod) = 213
+SIZE (go_modules/golang.org/x/tools/@v/v0.10.0.zip) = 2961243
SIZE (go_modules/golang.org/x/tools/@v/v0.2.0.mod) = 177
SIZE (go_modules/golang.org/x/tools/@v/v0.6.0.mod) = 211
SIZE (go_modules/golang.org/x/tools/@v/v0.6.1-0.20230217175706-3102dad5faf9.mod) = 211
-SIZE (go_modules/golang.org/x/tools/@v/v0.9.3.mod) = 213
-SIZE (go_modules/golang.org/x/tools/@v/v0.9.3.zip) = 2953479
SIZE (go_modules/golang.org/x/vuln/@v/v0.0.0-20230303230808-d3042fecc4e3.mod) = 568
SIZE (go_modules/golang.org/x/vuln/@v/v0.0.0-20230303230808-d3042fecc4e3.zip) = 305007
SIZE (go_modules/golang.org/x/xerrors/@v/v0.0.0-20190717185122-a985d3407aa7.mod) = 37
@@ -449,4 +465,4 @@ SIZE (osv-scanner-v1.3.4.zip) = 899201
SIZE (go_modules/mvdan.cc/unparam/@v/v0.0.0-20211214103731-d0ef000c54e5.zip) = 28548
SIZE (go_modules/sigs.k8s.io/yaml/@v/v1.3.0.mod) = 106
SIZE (go_modules/sigs.k8s.io/yaml/@v/v1.3.0.zip) = 21567
-SIZE (osv-scanner-v1.3.4.zip) = 899201
+SIZE (osv-scanner-v1.3.5.zip) = 903504
blob - b1dceb40df31543169043d40e9af4d47d0c85a06
blob + af3c3ed0c1c5589a44f21de35ec54c95968026b3
--- security/osv-scanner/modules.inc
+++ security/osv-scanner/modules.inc
@@ -1,5 +1,5 @@
MODGO_MODULES = \
- github.com/!burnt!sushi/toml v1.3.0 \
+ github.com/!burnt!sushi/toml v1.3.2 \
github.com/!cyclone!d!x/cyclonedx-go v0.7.1 \
github.com/!microsoft/go-winio v0.5.2 \
github.com/!proton!mail/go-crypto v0.0.0-20230518184743-7afd39499903 \
@@ -21,6 +21,8 @@ MODGO_MODULES = \
github.com/go-git/go-billy/v5 v5.4.1 \
github.com/go-git/go-git-fixtures/v4 v4.3.2-0.20230305113008-0c11038e723f \
github.com/go-git/go-git/v5 v5.7.0 \
+ github.com/goark/errs v1.1.0 \
+ github.com/goark/go-cvss v1.6.6 \
github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da \
github.com/google/go-cmdtest v0.4.1-0.20220921163831-55ab3332a786 \
github.com/google/go-cmp v0.5.9 \
@@ -37,7 +39,7 @@ MODGO_MODULES = \
github.com/mattn/go-runewidth v0.0.13 \
github.com/mmcloughlin/avo v0.5.0 \
github.com/niemeyer/pretty v0.0.0-20200227124842-a10e7caefd8e \
- github.com/package-url/packageurl-go v0.1.0 \
+ github.com/package-url/packageurl-go v0.1.1 \
github.com/pjbgf/sha1cd v0.3.0 \
github.com/pkg/diff v0.0.0-20210226163009-20ebb0f2a09e \
github.com/pkg/errors v0.9.1 \
@@ -50,22 +52,22 @@ MODGO_MODULES = \
github.com/sirupsen/logrus v1.7.0 \
github.com/skeema/knownhosts v1.1.1 \
github.com/spdx/gordf v0.0.0-20221230105357-b735bd5aac89 \
- github.com/spdx/tools-golang v0.5.1 \
+ github.com/spdx/tools-golang v0.5.2 \
github.com/stretchr/objx v0.5.0 \
- github.com/stretchr/testify v1.8.3 \
- github.com/urfave/cli/v2 v2.25.5 \
+ github.com/stretchr/testify v1.8.4 \
+ github.com/urfave/cli/v2 v2.25.7 \
github.com/xanzy/ssh-agent v0.3.3 \
github.com/xrash/smetrics v0.0.0-20201216005158-039620a65673 \
github.com/yuin/goldmark v1.4.13 \
- golang.org/x/crypto v0.9.0 \
+ golang.org/x/crypto v0.10.0 \
golang.org/x/exp v0.0.0-20230522175609-2e198f4a06a1 \
- golang.org/x/mod v0.10.0 \
- golang.org/x/net v0.10.0 \
- golang.org/x/sync v0.2.0 \
- golang.org/x/sys v0.8.0 \
- golang.org/x/term v0.8.0 \
- golang.org/x/text v0.9.0 \
- golang.org/x/tools v0.9.3 \
+ golang.org/x/mod v0.11.0 \
+ golang.org/x/net v0.11.0 \
+ golang.org/x/sync v0.3.0 \
+ golang.org/x/sys v0.9.0 \
+ golang.org/x/term v0.9.0 \
+ golang.org/x/text v0.10.0 \
+ golang.org/x/tools v0.10.0 \
golang.org/x/vuln v0.0.0-20230303230808-d3042fecc4e3 \
golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7 \
gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c \
@@ -78,7 +80,6 @@ MODGO_MODFILES = \
MODGO_MODFILES = \
github.com/!burnt!sushi/toml v0.3.1 \
- github.com/!burnt!sushi/toml v1.2.1 \
github.com/bwesterb/go-ristretto v1.2.0 \
github.com/cloudflare/circl v1.1.0 \
github.com/davecgh/go-spew v1.1.0 \
@@ -101,6 +102,7 @@ MODGO_MODFILES = \
golang.org/x/crypto v0.3.1-0.20221117191849-2c476679df9a \
golang.org/x/crypto v0.7.0 \
golang.org/x/crypto v0.8.0 \
+ golang.org/x/crypto v0.9.0 \
golang.org/x/exp v0.0.0-20220722155223-a9213eeb770e \
golang.org/x/mod v0.6.0 \
golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4 \
@@ -109,6 +111,7 @@ MODGO_MODFILES = \
golang.org/x/net v0.0.0-20210226172049-e18ecbb05110 \
golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2 \
golang.org/x/net v0.0.0-20220722155237-a158d28d115b \
+ golang.org/x/net v0.10.0 \
golang.org/x/net v0.6.0 \
golang.org/x/net v0.8.0 \
golang.org/x/sync v0.0.0-20190423024810-112230192c58 \
@@ -129,6 +132,7 @@ MODGO_MODFILES = \
golang.org/x/sys v0.5.0 \
golang.org/x/sys v0.6.0 \
golang.org/x/sys v0.7.0 \
+ golang.org/x/sys v0.8.0 \
golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1 \
golang.org/x/term v0.0.0-20210927222741-03fcf44c2211 \
golang.org/x/term v0.5.0 \
@@ -137,8 +141,10 @@ MODGO_MODFILES = \
golang.org/x/text v0.3.3 \
golang.org/x/text v0.3.6 \
golang.org/x/text v0.3.7 \
+ golang.org/x/text v0.6.0 \
golang.org/x/text v0.7.0 \
golang.org/x/text v0.8.0 \
+ golang.org/x/text v0.9.0 \
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e \
golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e \
golang.org/x/tools v0.1.12 \
Hello,
Here's an update for osv-scanner which has been working fine.
Other tests?
Thanks,
Lucas
commit - 20cf8735fbeddad90caa5253fa7cc06119f78a1e
commit + 19c94d7e61976ab21392163b018b5081557a7220
blob - afe7fd52e81fcf10048eac96797eedb68742f382
blob + 8d963684c86100d69c2a38e10b5952792241f864
--- security/osv-scanner/Makefile
+++ security/osv-scanner/Makefile
@@ -6,7 +6,7 @@ V = 1.3.4
COMMENT = scan your project's dependencies for vulnerabilities
-V = 1.3.4
+V = 1.3.5
MODGO_MODNAME = github.com/google/osv-scanner
MODGO_VERSION = v${V}
blob - 47d5658a20dd0904121303af1199b07dd7054dd0
blob + c6c5dfd352836e3e4985f7e1cc0c7db2e0b684f6
--- security/osv-scanner/distinfo
+++ security/osv-scanner/distinfo
@@ -1,7 +1,6 @@
SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.mod) = KAIbQYClnDmTYHqVsY4jDdC8a+pSQv/o6ou/tPT3tNc=
-SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.2.1.mod) = JnfIL+dPIDdyiJpagBr7Mp2VF1UId92ssXIZFpurPt0=
-SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.0.mod) = JnfIL+dPIDdyiJpagBr7Mp2VF1UId92ssXIZFpurPt0=
-SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.0.zip) = z0XD4hoU47CW1crqHllrzjH+QY0ZeSPzR5H+wnw0AGc=
+SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.2.mod) = JnfIL+dPIDdyiJpagBr7Mp2VF1UId92ssXIZFpurPt0=
+SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.2.zip) = XeJGoMtMJW8/1dDbigihFPWK8MLhk7vwrZASEErbtrI=
SHA256 (go_modules/github.com/!cyclone!d!x/cyclonedx-go/@v/v0.7.1.mod) = uqvhVbf1hOh1/U4bvuiQTjf0qn4QJl1WfdKYiAY/5oM=
SHA256 (go_modules/github.com/!cyclone!d!x/cyclonedx-go/@v/v0.7.1.zip) = +D2ExgswC7p36y6FOYnFDHq/mMWWIPtaC24x2gd3aAU=
SHA256 (go_modules/github.com/!microsoft/go-winio/@v/v0.5.2.mod) = Gbj76dRBkni7Hp0M8v1a7IeeQoKcU7o+/VZWuNGzWuc=
@@ -47,6 +46,10 @@ SHA256 (go_modules/github.com/golang/groupcache/@v/v0.
SHA256 (go_modules/github.com/go-git/go-git-fixtures/v4/@v/v4.3.2-0.20230305113008-0c11038e723f.zip) = VGUYT34LRmv9QlPdoE+76oPV2/QE59cfT/oUXXXXFGM=
SHA256 (go_modules/github.com/go-git/go-git/v5/@v/v5.7.0.mod) = hiQXhmzSVCgs8EoVW8rKHPV6gygpVO/hjETig3U7q90=
SHA256 (go_modules/github.com/go-git/go-git/v5/@v/v5.7.0.zip) = ffddu8q13gz+0DHENq4BeKF9l9cS998vbCSVOXPPBfw=
+SHA256 (go_modules/github.com/goark/errs/@v/v1.1.0.mod) = HdP0dfT4+GCMG+9lWyqNew4gr5jOusFXVZMrCapncEY=
+SHA256 (go_modules/github.com/goark/errs/@v/v1.1.0.zip) = i43JhykUlVOpgvOs4Xa3KJKpCCY6SiUpGux+Bz2ThBc=
+SHA256 (go_modules/github.com/goark/go-cvss/@v/v1.6.6.mod) = YOdemKeD2deEmjJAzwBtcCovyubv4HpxBv8bG+zMNn4=
+SHA256 (go_modules/github.com/goark/go-cvss/@v/v1.6.6.zip) = IkqCKDAhSMFmO5wZpleYQrJtjQD4xAqN24U7fvVpKOs=
SHA256 (go_modules/github.com/golang/groupcache/@v/v0.0.0-20210331224755-41bb18bfe9da.mod) = URfiu4bxzHzHSJ+fJYD6F7LvHjoKNGv2TtgGPKe4dmM=
SHA256 (go_modules/github.com/golang/groupcache/@v/v0.0.0-20210331224755-41bb18bfe9da.zip) = snA06PwBNidUPhrQmM/GUynyiW3z2lzzJmzJFm+T86U=
SHA256 (go_modules/github.com/google/go-cmdtest/@v/v0.4.1-0.20220921163831-55ab3332a786.mod) = YBCCwe/4ls1GJ8PCPRVrWD+85CRh5UhHNLZGe5ZOtk0=
@@ -83,8 +86,8 @@ SHA256 (go_modules/github.com/package-url/packageurl-g
SHA256 (go_modules/github.com/mmcloughlin/avo/@v/v0.5.0.zip) = Yr553IwOXt9NTTmAFiMbtK2jCxnkmd30q5OF9Lb5FCo=
SHA256 (go_modules/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.mod) = jxQBiQgBFlu9PaF1jGyWQ48SqjJIZmrBWBwYqGQkTUc=
SHA256 (go_modules/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.zip) = LctwU/rxHCjK19hPz6Pdf5Pj0jaznYPP8JNPaR+GDXo=
-SHA256 (go_modules/github.com/package-url/packageurl-go/@v/v0.1.0.mod) = dRewXBS0JZJtI9XFqlk5cMumXf0FYeZSFfUOetMSct8=
-SHA256 (go_modules/github.com/package-url/packageurl-go/@v/v0.1.0.zip) = jUeNIwh+x3V5lx5eKmWuYNZypreYIFw+CGSJPEzu0G4=
+SHA256 (go_modules/github.com/package-url/packageurl-go/@v/v0.1.1.mod) = WtMu4++y8MyV5RLpaxj2GWiBXwXLTpBVYacq5IyrWtE=
+SHA256 (go_modules/github.com/package-url/packageurl-go/@v/v0.1.1.zip) = E4RHGgDw4CbF5F2fzMDaNj6UIyZ875M5jbFvzyS9uGA=
SHA256 (go_modules/github.com/pjbgf/sha1cd/@v/v0.3.0.mod) = 8Qo2tGIntPuz5pD2zHJtlGR18xZp7rxSxK1bLombToA=
SHA256 (go_modules/github.com/pjbgf/sha1cd/@v/v0.3.0.zip) = rP7pbdL+jmrgiumGRQSDCknSNddMKrk996XfopqQpGE=
SHA256 (go_modules/github.com/pkg/diff/@v/v0.0.0-20210226163009-20ebb0f2a09e.mod) = XVuUVOLQIK8MdgNWjoaQS5m+/E1dZ8OoUF9hIVib0R8=
@@ -110,8 +113,8 @@ SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.
SHA256 (go_modules/github.com/spdx/gordf/@v/v0.0.0-20201111095634-7098f93598fb.mod) = eKUongYQUXmwBVYtvFiYMNLnHrFgrEUV5RiQ5fFMgYk=
SHA256 (go_modules/github.com/spdx/gordf/@v/v0.0.0-20221230105357-b735bd5aac89.mod) = eKUongYQUXmwBVYtvFiYMNLnHrFgrEUV5RiQ5fFMgYk=
SHA256 (go_modules/github.com/spdx/gordf/@v/v0.0.0-20221230105357-b735bd5aac89.zip) = XxsMQLKthYlrDa14n8WZRd/FR93bivyiABl27UQYdtw=
-SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.5.1.mod) = aSS5w8etG/mpXeTWSCwA/py3oIFpSkd2j0LCXlGv0xI=
-SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.5.1.zip) = XBe+mI+YJL60OtZP39qf/Ft4BwjUVlUXCbA5a+rjnnY=
+SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.5.2.mod) = 1AmtiCKBeI7KM6dD7wYyS8c15GYS3AQ+x23Ucj8SHfc=
+SHA256 (go_modules/github.com/spdx/tools-golang/@v/v0.5.2.zip) = a1+qOzY53gmg8Eu5YD8+o4DXca+RSN/zhDRbRYXhR3E=
SHA256 (go_modules/github.com/stretchr/objx/@v/v0.1.0.mod) = E1A1TVLSKHpiM27MDVYjLUxHaZr5u6ScZ8K0glTamPE=
SHA256 (go_modules/github.com/stretchr/objx/@v/v0.4.0.mod) = MbL9ze6HDw9hv/r6+5YiCWflvKCKdqkg1XQhb8H5E1U=
SHA256 (go_modules/github.com/stretchr/objx/@v/v0.5.0.mod) = yzJlQO/LEnSm5Olw1/yd4ugGLwigWPwpbYWQJeYugHo=
@@ -122,10 +125,10 @@ SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8
SHA256 (go_modules/github.com/stretchr/testify/@v/v1.7.4.mod) = 4HYHTBVgrR3amLiwD+pjCMS2zNBt3QiNIttGJu1o9zg=
SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.0.mod) = 4HYHTBVgrR3amLiwD+pjCMS2zNBt3QiNIttGJu1o9zg=
SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.2.mod) = rxpdyzMazno/n8G11+7pwLyCtKKhgv5M7CrdIX4oU9Y=
-SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.3.mod) = BeJs0GkoWjPPKvRv2s3vVp1a4YXnljp2wBeDKPaOl/k=
-SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.3.zip) = pL+MgUt9wD59Kkt2/A9objjwxrmPxhr+RCLwWYN3lSg=
-SHA256 (go_modules/github.com/urfave/cli/v2/@v/v2.25.5.mod) = vrUO54Wf55rTJgt1onaRXPZpTqf1UBuI9VD4q7RpqU0=
-SHA256 (go_modules/github.com/urfave/cli/v2/@v/v2.25.5.zip) = SgOQiR/xUzTfXM39qLIflUHKwQl03sxUMCo+igF+ahw=
+SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.4.mod) = BeJs0GkoWjPPKvRv2s3vVp1a4YXnljp2wBeDKPaOl/k=
+SHA256 (go_modules/github.com/stretchr/testify/@v/v1.8.4.zip) = 4gbart4L0D3gYL3765hKwsSbgwWHU//8k/4MIg6odTI=
+SHA256 (go_modules/github.com/urfave/cli/v2/@v/v2.25.7.mod) = XD3aJw3iuXT/2n/bvxItJJk7suwFeFtP+RROdhfqxBU=
+SHA256 (go_modules/github.com/urfave/cli/v2/@v/v2.25.7.zip) = EJQbJGidfJU6eLbRlqA+BCdOAS0n1PKX/oRM9YIhqGw=
SHA256 (go_modules/github.com/xanzy/ssh-agent/@v/v0.3.3.mod) = HOHMUJiJtzjB9j2/zFrVIs62MnLZ3v9u73SZ7TAaoSU=
SHA256 (go_modules/github.com/xanzy/ssh-agent/@v/v0.3.3.zip) = GahsJiOyDMmGh73diePwI9sMpRyLyeOLmtnFblt9EQ0=
SHA256 (go_modules/github.com/xrash/smetrics/@v/v0.0.0-20201216005158-039620a65673.mod) = Kz9hJyfgYrwlZDq5c5S7f0F6KXqf9lIqDxjs93h38EI=
@@ -135,16 +138,17 @@ SHA256 (go_modules/golang.org/x/crypto/@v/v0.3.1-0.202
SHA256 (go_modules/golang.org/x/crypto/@v/v0.0.0-20190308221718-c2843e01d9a2.mod) = M+0HClpm4JYGhaxThkQOG1mJnnTYo4oRgGhecqIZXe0=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.0.0-20210921155107-089bfa567519.mod) = zWMRYSoqpNDX4DxBs6ofvC1fiVqz9hCJ+rgL/p+PVIU=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.0.0-20220622213112-05595931fe9d.mod) = ryyI7r/wPjoq/ssbA2afxU6dEiyI97Ls/tBR7F28i7s=
+SHA256 (go_modules/golang.org/x/crypto/@v/v0.10.0.mod) = LAC5Gxo4OLTluAFtx+6AEL7pCK+ErVH30bgs956frN0=
+SHA256 (go_modules/golang.org/x/crypto/@v/v0.10.0.zip) = Lk+bct9vSAp0RIOxTWuMutmP8GY5mXmsdP8dxbdOm+w=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.3.1-0.20221117191849-2c476679df9a.mod) = t5UQb4uN637XdSOoHeAatGAfDwOBNTkYRX0teK2ePOk=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.7.0.mod) = yJ/iLnPawmoAplasEf9MbhprbNKrzFftzazew/va2C0=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.8.0.mod) = XUhSCyhK7tyyTEqDKJShagfQmOyRKjYjd1DFFIlNKOg=
SHA256 (go_modules/golang.org/x/crypto/@v/v0.9.0.mod) = nSAXdDfn8DoYKFjPQHQ6ImKD1dQRrVyFp5TiS6AiYLE=
-SHA256 (go_modules/golang.org/x/crypto/@v/v0.9.0.zip) = Zy68kWdAoEDV9UcrR34dGJjgawxsClqCC2VJW7sTPoI=
SHA256 (go_modules/golang.org/x/exp/@v/v0.0.0-20220722155223-a9213eeb770e.mod) = KqbbzGUyHHFTSmOE7NZqsrIERkRKV3BwZjFFGY3Rnas=
SHA256 (go_modules/golang.org/x/exp/@v/v0.0.0-20230522175609-2e198f4a06a1.mod) = EF8h/6AuHlv/paPw/lAoL4JDRLRXLLlG+MRWK0JUfWc=
SHA256 (go_modules/golang.org/x/exp/@v/v0.0.0-20230522175609-2e198f4a06a1.zip) = r5TnnT1zOBgxMKsXwSm3NTjTcs6rYCz7Z4eABdiSSsg=
-SHA256 (go_modules/golang.org/x/mod/@v/v0.10.0.mod) = YkVnRZxumUesSr3gtwNO5h3Ltqk3P1lwCUwLs+gSGWQ=
-SHA256 (go_modules/golang.org/x/mod/@v/v0.10.0.zip) = +HZHOsJ/HG47D/+XHIT7689nDbCz6PKB4DFJ/PY2/iU=
+SHA256 (go_modules/golang.org/x/mod/@v/v0.11.0.mod) = YkVnRZxumUesSr3gtwNO5h3Ltqk3P1lwCUwLs+gSGWQ=
+SHA256 (go_modules/golang.org/x/mod/@v/v0.11.0.zip) = NkGYkwzH9GuluxwJh9CJpVeqC0Bvjv7ASQdEpFTfAKU=
SHA256 (go_modules/golang.org/x/mod/@v/v0.6.0-dev.0.20220419223038-86c51ed26bb4.mod) = QtGQI/+PLq5wC8VJXzcezZmKItGbqYXQr19pkAslQIM=
SHA256 (go_modules/golang.org/x/mod/@v/v0.6.0.mod) = mfQKUOjWDCWZrEXGzix21VSoQorNE8LGikk/ymGbT6g=
SHA256 (go_modules/golang.org/x/mod/@v/v0.8.0.mod) = YkVnRZxumUesSr3gtwNO5h3Ltqk3P1lwCUwLs+gSGWQ=
@@ -153,14 +157,15 @@ SHA256 (go_modules/golang.org/x/net/@v/v0.10.0.zip) =
SHA256 (go_modules/golang.org/x/net/@v/v0.0.0-20211112202133-69e39bad7dc2.mod) = +pFfXQIs+wy4Zaou4306d0G0BvhOtKg3hi4pzGmrTvQ=
SHA256 (go_modules/golang.org/x/net/@v/v0.0.0-20220722155237-a158d28d115b.mod) = sxXFJkfS2i925c2502fh1nJ3hCNqm/+2EhkrGbEKEo0=
SHA256 (go_modules/golang.org/x/net/@v/v0.10.0.mod) = 07fiNv8J5jIr5IkXAhbgGNMiGGLxoFPctj5T6rhTPBc=
-SHA256 (go_modules/golang.org/x/net/@v/v0.10.0.zip) = +S+bJlUiam0BWvenYnmhH7VWeOQQuFGxWPyEZUb4BzM=
+SHA256 (go_modules/golang.org/x/net/@v/v0.11.0.mod) = DWuyXbLvxAvNvMtxZoT1ihVALyKzQpCY18uFDyIirWE=
+SHA256 (go_modules/golang.org/x/net/@v/v0.11.0.zip) = XZfbCzQ2dFKUmxsEGUtHpmPLsIUvQNEZul2RDMwSRlc=
SHA256 (go_modules/golang.org/x/net/@v/v0.6.0.mod) = Qex26iFy8+4wMeOPmlNZOaWE1rs170gIVP3LjCAmcBs=
SHA256 (go_modules/golang.org/x/net/@v/v0.8.0.mod) = 6275vWQFrOPZnkOB0CVs5B+Dxm0aILTigwpMd2JF9xo=
SHA256 (go_modules/golang.org/x/sync/@v/v0.0.0-20190423024810-112230192c58.mod) = Qh9hOWhtWJHz3FpWPQmVeA0yefZcrU0iXOpSaGeUFhw=
SHA256 (go_modules/golang.org/x/sync/@v/v0.0.0-20220722155255-886fb9371eb4.mod) = Qh9hOWhtWJHz3FpWPQmVeA0yefZcrU0iXOpSaGeUFhw=
SHA256 (go_modules/golang.org/x/sync/@v/v0.1.0.mod) = Qh9hOWhtWJHz3FpWPQmVeA0yefZcrU0iXOpSaGeUFhw=
-SHA256 (go_modules/golang.org/x/sync/@v/v0.2.0.mod) = Qh9hOWhtWJHz3FpWPQmVeA0yefZcrU0iXOpSaGeUFhw=
-SHA256 (go_modules/golang.org/x/sync/@v/v0.2.0.zip) = 7g30Vy3XNmV2eWT/gJsS8NQeOgdAIg1E1BihmYmgNjs=
+SHA256 (go_modules/golang.org/x/sync/@v/v0.3.0.mod) = 7Q/wxQgadUz8vnaMvPYMY5dbNddufXuZxayb+m2YKFE=
+SHA256 (go_modules/golang.org/x/sync/@v/v0.3.0.zip) = GHDnoZb3EZ1Mbtun3pzfxJ7hPIy3kh86lHVoFxxhUuA=
SHA256 (go_modules/golang.org/x/sys/@v/v0.0.0-20190215142949-d0b11bdaac8a.mod) = iWkRXko5EIhIMk55ob2KhEUjDm46rMvp+AV/tQ//yME=
SHA256 (go_modules/golang.org/x/sys/@v/v0.0.0-20191026070338-33540a1f6037.mod) = GBl56L1X0tngZBgtqGyaYRGqaXVeiI8IQx7OR0Kuw0M=
SHA256 (go_modules/golang.org/x/sys/@v/v0.0.0-20201119102817-f84b799fce68.mod) = GBl56L1X0tngZBgtqGyaYRGqaXVeiI8IQx7OR0Kuw0M=
@@ -177,29 +182,32 @@ SHA256 (go_modules/golang.org/x/sys/@v/v0.8.0.zip) = J
SHA256 (go_modules/golang.org/x/sys/@v/v0.6.0.mod) = 8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
SHA256 (go_modules/golang.org/x/sys/@v/v0.7.0.mod) = 8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
SHA256 (go_modules/golang.org/x/sys/@v/v0.8.0.mod) = 8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
-SHA256 (go_modules/golang.org/x/sys/@v/v0.8.0.zip) = JYizpkWDg5DjQfEAf4Z59eERe11ayUZ++DLRSLIhmjg=
+SHA256 (go_modules/golang.org/x/sys/@v/v0.9.0.mod) = 8DMzMJb+GY8xUd7tk/LeunTlC7/nc5E0BFvDt85KUCQ=
+SHA256 (go_modules/golang.org/x/sys/@v/v0.9.0.zip) = OzfIdTTrq/nRpg7wPaFoBfEpNAi8r4t8u6nWRu2gfX8=
SHA256 (go_modules/golang.org/x/term/@v/v0.0.0-20201126162022-7de9c90e9dd1.mod) = TLqxT3cGdxsnHZlaGzzBMf5aJGqtx+5tG6bwvYlHgfo=
SHA256 (go_modules/golang.org/x/term/@v/v0.0.0-20210927222741-03fcf44c2211.mod) = dAeU4pFPXMh+JWVsWEMiKyxlZlghIF9FYyoEd8jT95s=
SHA256 (go_modules/golang.org/x/term/@v/v0.5.0.mod) = DW9YIoqtwaZSjmdV2gGFFlZuOuXFIB963hdz9W+o2TQ=
SHA256 (go_modules/golang.org/x/term/@v/v0.6.0.mod) = ZDWbnGU3CEePAgcpiFBE/z2ABxhtnUQRJf6HSBfnEgE=
-SHA256 (go_modules/golang.org/x/term/@v/v0.8.0.mod) = XTYtaoNFP3Akcl6CTAXFlJYk749MsT9dfj1Lfxygsyc=
-SHA256 (go_modules/golang.org/x/term/@v/v0.8.0.zip) = GWHf6lnOUx4tbmoyKHgfWViyfG2dnAmTL1/8VMTZzfk=
+SHA256 (go_modules/golang.org/x/term/@v/v0.9.0.mod) = Wi2XadlxLw3n6DPKDO5iWibh8vvt+sp0huFBzs9+CUw=
+SHA256 (go_modules/golang.org/x/term/@v/v0.9.0.zip) = tObSrJdzJiXu5YH0f+SiEl3YZo/ihXlLrBqaGn/T8eM=
+SHA256 (go_modules/golang.org/x/text/@v/v0.10.0.mod) = FR5qGDlJHEtQ3+nDNFHwYyjVUYvY7koAYd4Ct60zL7I=
+SHA256 (go_modules/golang.org/x/text/@v/v0.10.0.zip) = U+Txr0Nx547HF/oaKRnrn7+xskx0NVTP0AXuQ2OIzuI=
SHA256 (go_modules/golang.org/x/text/@v/v0.3.0.mod) = NoedWG/YAB6E2oeHGQoR5PeHSeKoHf6Lm2kxiZ//Mc8=
SHA256 (go_modules/golang.org/x/text/@v/v0.3.3.mod) = +7eojtFAUV55Dsp6EP/TGcl4axHGpsfln4D3+ze7RUI=
SHA256 (go_modules/golang.org/x/text/@v/v0.3.6.mod) = +7eojtFAUV55Dsp6EP/TGcl4axHGpsfln4D3+ze7RUI=
SHA256 (go_modules/golang.org/x/text/@v/v0.3.7.mod) = xF1mkIlCe8RjXQexhfm5aAMy0cSMdbPEnLcVuBoEpbA=
+SHA256 (go_modules/golang.org/x/text/@v/v0.6.0.mod) = FZKedvzgSupMkqNUQmu0M3BoRkWk7gPy510MLrFGYwQ=
SHA256 (go_modules/golang.org/x/text/@v/v0.7.0.mod) = FZKedvzgSupMkqNUQmu0M3BoRkWk7gPy510MLrFGYwQ=
SHA256 (go_modules/golang.org/x/text/@v/v0.8.0.mod) = Q29ZLne1k7AvvqN04jrTNpyGI/8NKckd594eZnLbmkE=
SHA256 (go_modules/golang.org/x/text/@v/v0.9.0.mod) = Q29ZLne1k7AvvqN04jrTNpyGI/8NKckd594eZnLbmkE=
-SHA256 (go_modules/golang.org/x/text/@v/v0.9.0.zip) = wcvmhOrwHAU78SMnOGl9EEAyelyK1i2t/JULWF0bTKo=
SHA256 (go_modules/golang.org/x/tools/@v/v0.0.0-20180917221912-90fa682c2a6e.mod) = oOAvBnj+Ytw8S0vHf6kSybcN4Q+p988veq0DNzkrUq8=
SHA256 (go_modules/golang.org/x/tools/@v/v0.0.0-20191119224855-298f0cb1881e.mod) = iNR5Jl+Ib15ZjXbAA9DyV7QtvxuJXYIKErWrCzUBrKE=
SHA256 (go_modules/golang.org/x/tools/@v/v0.1.12.mod) = KouTZYmPCCL6zmW6CJoTU+aKZdNC8wDKMXzOzN5kIfM=
+SHA256 (go_modules/golang.org/x/tools/@v/v0.10.0.mod) = 83xvC/JvN9AkgWmxwNeUXs3cgkxG8BRg83gnzpWr62w=
+SHA256 (go_modules/golang.org/x/tools/@v/v0.10.0.zip) = Vi8l5nSqtJ8Aoj7B/LRqV7Cp0nKH6pqIWIbJlDBtnBQ=
SHA256 (go_modules/golang.org/x/tools/@v/v0.2.0.mod) = nJteYq9p8rEAKc4SlE3Ig08SJqg7skPpoNvzfguxhro=
SHA256 (go_modules/golang.org/x/tools/@v/v0.6.0.mod) = gw7Xjc0+mSfEEuJkEjAwhEd0nVE9MQJNJ24kQ7IBZgk=
SHA256 (go_modules/golang.org/x/tools/@v/v0.6.1-0.20230217175706-3102dad5faf9.mod) = gw7Xjc0+mSfEEuJkEjAwhEd0nVE9MQJNJ24kQ7IBZgk=
-SHA256 (go_modules/golang.org/x/tools/@v/v0.9.3.mod) = FBIGSEXOBF727VKe3jyzqLyO1KKnwrfU+WeAfXyVhVE=
-SHA256 (go_modules/golang.org/x/tools/@v/v0.9.3.zip) = R4itEpHgywRBiPnzGmMHBu3FL6BwtcEDZpd8l/Djyp0=
SHA256 (go_modules/golang.org/x/vuln/@v/v0.0.0-20230303230808-d3042fecc4e3.mod) = 7Myv1lmpCaM+E9+f7Z3rH0tCHyldsvRHWsUS/3jHXPA=
SHA256 (go_modules/golang.org/x/vuln/@v/v0.0.0-20230303230808-d3042fecc4e3.zip) = NaXn5o77jm6373+pQn8hnIDgLEBR121/xPCAu8zUnDQ=
SHA256 (go_modules/golang.org/x/xerrors/@v/v0.0.0-20190717185122-a985d3407aa7.mod) = ql4+ybt7n2gWCe+sAZ2d4ae6dxkkj/Hqon54iC2z1/U=
@@ -223,11 +231,10 @@ SHA256 (osv-scanner-v1.3.4.zip) = Gw6USdnJ/lZw1JbiyGC1
SHA256 (go_modules/mvdan.cc/unparam/@v/v0.0.0-20211214103731-d0ef000c54e5.zip) = qr8FBOW0Bnhdr9xPH2NT3FTWZzrMefnXAcnCEvD/yII=
SHA256 (go_modules/sigs.k8s.io/yaml/@v/v1.3.0.mod) = L8eybun2ctl7QvpvJfWxWlWYK7usaZYdduux0DbRUAE=
SHA256 (go_modules/sigs.k8s.io/yaml/@v/v1.3.0.zip) = qsiNpVHCpRK2Qss1ZYvz3IYllaNWa9hA6/GOSALx/Mk=
-SHA256 (osv-scanner-v1.3.4.zip) = Gw6USdnJ/lZw1JbiyGC1JU037NazzmwSzdvFGLUVu+4=
+SHA256 (osv-scanner-v1.3.5.zip) = Qe3X+OdYJk3BBTqXNEY0F9P/Q5ib+grl9XzoeYECpOM=
SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.mod) = 34
-SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.2.1.mod) = 43
-SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.0.mod) = 43
-SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.0.zip) = 292624
+SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.2.mod) = 43
+SIZE (go_modules/github.com/!burnt!sushi/toml/@v/v1.3.2.zip) = 303020
SIZE (go_modules/github.com/!cyclone!d!x/cyclonedx-go/@v/v0.7.1.mod) = 289
SIZE (go_modules/github.com/!cyclone!d!x/cyclonedx-go/@v/v0.7.1.zip) = 190030
SIZE (go_modules/github.com/!microsoft/go-winio/@v/v0.5.2.mod) = 147
@@ -273,6 +280,10 @@ SIZE (go_modules/github.com/golang/groupcache/@v/v0.0.
SIZE (go_modules/github.com/go-git/go-git-fixtures/v4/@v/v4.3.2-0.20230305113008-0c11038e723f.zip) = 98071761
SIZE (go_modules/github.com/go-git/go-git/v5/@v/v5.7.0.mod) = 1458
SIZE (go_modules/github.com/go-git/go-git/v5/@v/v5.7.0.zip) = 690957
+SIZE (go_modules/github.com/goark/errs/@v/v1.1.0.mod) = 38
+SIZE (go_modules/github.com/goark/errs/@v/v1.1.0.zip) = 17313
+SIZE (go_modules/github.com/goark/go-cvss/@v/v1.6.6.mod) = 110
+SIZE (go_modules/github.com/goark/go-cvss/@v/v1.6.6.zip) = 124320
SIZE (go_modules/github.com/golang/groupcache/@v/v0.0.0-20210331224755-41bb18bfe9da.mod) = 36
SIZE (go_modules/github.com/golang/groupcache/@v/v0.0.0-20210331224755-41bb18bfe9da.zip) = 39744
SIZE (go_modules/github.com/google/go-cmdtest/@v/v0.4.1-0.20220921163831-55ab3332a786.mod) = 126
@@ -309,8 +320,8 @@ SIZE (go_modules/github.com/package-url/packageurl-go/
SIZE (go_modules/github.com/mmcloughlin/avo/@v/v0.5.0.zip) = 1027129
SIZE (go_modules/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.mod) = 78
SIZE (go_modules/github.com/niemeyer/pretty/@v/v0.0.0-20200227124842-a10e7caefd8e.zip) = 13281
-SIZE (go_modules/github.com/package-url/packageurl-go/@v/v0.1.0.mod) = 53
-SIZE (go_modules/github.com/package-url/packageurl-go/@v/v0.1.0.zip) = 10604
+SIZE (go_modules/github.com/package-url/packageurl-go/@v/v0.1.1.mod) = 53
+SIZE (go_modules/github.com/package-url/packageurl-go/@v/v0.1.1.zip) = 15275
SIZE (go_modules/github.com/pjbgf/sha1cd/@v/v0.3.0.mod) = 213
SIZE (go_modules/github.com/pjbgf/sha1cd/@v/v0.3.0.zip) = 3528787
SIZE (go_modules/github.com/pkg/diff/@v/v0.0.0-20210226163009-20ebb0f2a09e.mod) = 36
@@ -336,8 +347,8 @@ SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.
SIZE (go_modules/github.com/spdx/gordf/@v/v0.0.0-20201111095634-7098f93598fb.mod) = 38
SIZE (go_modules/github.com/spdx/gordf/@v/v0.0.0-20221230105357-b735bd5aac89.mod) = 38
SIZE (go_modules/github.com/spdx/gordf/@v/v0.0.0-20221230105357-b735bd5aac89.zip) = 56398
-SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.1.mod) = 285
-SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.1.zip) = 582067
+SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.2.mod) = 285
+SIZE (go_modules/github.com/spdx/tools-golang/@v/v0.5.2.zip) = 582429
SIZE (go_modules/github.com/stretchr/objx/@v/v0.1.0.mod) = 32
SIZE (go_modules/github.com/stretchr/objx/@v/v0.4.0.mod) = 137
SIZE (go_modules/github.com/stretchr/objx/@v/v0.5.0.mod) = 85
@@ -348,10 +359,10 @@ SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.3
SIZE (go_modules/github.com/stretchr/testify/@v/v1.7.4.mod) = 188
SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.0.mod) = 188
SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.2.mod) = 188
-SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.3.mod) = 188
-SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.3.zip) = 120084
-SIZE (go_modules/github.com/urfave/cli/v2/@v/v2.25.5.mod) = 280
-SIZE (go_modules/github.com/urfave/cli/v2/@v/v2.25.5.zip) = 3549490
+SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.4.mod) = 188
+SIZE (go_modules/github.com/stretchr/testify/@v/v1.8.4.zip) = 120537
+SIZE (go_modules/github.com/urfave/cli/v2/@v/v2.25.7.mod) = 280
+SIZE (go_modules/github.com/urfave/cli/v2/@v/v2.25.7.zip) = 3549945
SIZE (go_modules/github.com/xanzy/ssh-agent/@v/v0.3.3.mod) = 203
SIZE (go_modules/github.com/xanzy/ssh-agent/@v/v0.3.3.zip) = 11274
SIZE (go_modules/github.com/xrash/smetrics/@v/v0.0.0-20201216005158-039620a65673.mod) = 33
@@ -361,16 +372,17 @@ SIZE (go_modules/golang.org/x/crypto/@v/v0.3.1-0.20221
SIZE (go_modules/golang.org/x/crypto/@v/v0.0.0-20190308221718-c2843e01d9a2.mod) = 88
SIZE (go_modules/golang.org/x/crypto/@v/v0.0.0-20210921155107-089bfa567519.mod) = 247
SIZE (go_modules/golang.org/x/crypto/@v/v0.0.0-20220622213112-05595931fe9d.mod) = 255
+SIZE (go_modules/golang.org/x/crypto/@v/v0.10.0.mod) = 188
+SIZE (go_modules/golang.org/x/crypto/@v/v0.10.0.zip) = 1780916
SIZE (go_modules/golang.org/x/crypto/@v/v0.3.1-0.20221117191849-2c476679df9a.mod) = 171
SIZE (go_modules/golang.org/x/crypto/@v/v0.7.0.mod) = 171
SIZE (go_modules/golang.org/x/crypto/@v/v0.8.0.mod) = 171
SIZE (go_modules/golang.org/x/crypto/@v/v0.9.0.mod) = 172
-SIZE (go_modules/golang.org/x/crypto/@v/v0.9.0.zip) = 1763182
SIZE (go_modules/golang.org/x/exp/@v/v0.0.0-20220722155223-a9213eeb770e.mod) = 325
SIZE (go_modules/golang.org/x/exp/@v/v0.0.0-20230522175609-2e198f4a06a1.mod) = 176
SIZE (go_modules/golang.org/x/exp/@v/v0.0.0-20230522175609-2e198f4a06a1.zip) = 449849
-SIZE (go_modules/golang.org/x/mod/@v/v0.10.0.mod) = 84
-SIZE (go_modules/golang.org/x/mod/@v/v0.10.0.zip) = 162521
+SIZE (go_modules/golang.org/x/mod/@v/v0.11.0.mod) = 84
+SIZE (go_modules/golang.org/x/mod/@v/v0.11.0.zip) = 165162
SIZE (go_modules/golang.org/x/mod/@v/v0.6.0-dev.0.20220419223038-86c51ed26bb4.mod) = 157
SIZE (go_modules/golang.org/x/mod/@v/v0.6.0.mod) = 117
SIZE (go_modules/golang.org/x/mod/@v/v0.8.0.mod) = 84
@@ -379,14 +391,15 @@ SIZE (go_modules/golang.org/x/net/@v/v0.10.0.zip) = 15
SIZE (go_modules/golang.org/x/net/@v/v0.0.0-20211112202133-69e39bad7dc2.mod) = 179
SIZE (go_modules/golang.org/x/net/@v/v0.0.0-20220722155237-a158d28d115b.mod) = 179
SIZE (go_modules/golang.org/x/net/@v/v0.10.0.mod) = 123
-SIZE (go_modules/golang.org/x/net/@v/v0.10.0.zip) = 1564890
+SIZE (go_modules/golang.org/x/net/@v/v0.11.0.mod) = 153
+SIZE (go_modules/golang.org/x/net/@v/v0.11.0.zip) = 1618900
SIZE (go_modules/golang.org/x/net/@v/v0.6.0.mod) = 123
SIZE (go_modules/golang.org/x/net/@v/v0.8.0.mod) = 123
SIZE (go_modules/golang.org/x/sync/@v/v0.0.0-20190423024810-112230192c58.mod) = 25
SIZE (go_modules/golang.org/x/sync/@v/v0.0.0-20220722155255-886fb9371eb4.mod) = 25
SIZE (go_modules/golang.org/x/sync/@v/v0.1.0.mod) = 25
-SIZE (go_modules/golang.org/x/sync/@v/v0.2.0.mod) = 25
-SIZE (go_modules/golang.org/x/sync/@v/v0.2.0.zip) = 27919
+SIZE (go_modules/golang.org/x/sync/@v/v0.3.0.mod) = 34
+SIZE (go_modules/golang.org/x/sync/@v/v0.3.0.zip) = 29766
SIZE (go_modules/golang.org/x/sys/@v/v0.0.0-20190215142949-d0b11bdaac8a.mod) = 24
SIZE (go_modules/golang.org/x/sys/@v/v0.0.0-20191026070338-33540a1f6037.mod) = 33
SIZE (go_modules/golang.org/x/sys/@v/v0.0.0-20201119102817-f84b799fce68.mod) = 33
@@ -403,29 +416,32 @@ SIZE (go_modules/golang.org/x/sys/@v/v0.8.0.zip) = 189
SIZE (go_modules/golang.org/x/sys/@v/v0.6.0.mod) = 33
SIZE (go_modules/golang.org/x/sys/@v/v0.7.0.mod) = 33
SIZE (go_modules/golang.org/x/sys/@v/v0.8.0.mod) = 33
-SIZE (go_modules/golang.org/x/sys/@v/v0.8.0.zip) = 1894928
+SIZE (go_modules/golang.org/x/sys/@v/v0.9.0.mod) = 33
+SIZE (go_modules/golang.org/x/sys/@v/v0.9.0.zip) = 1898437
SIZE (go_modules/golang.org/x/term/@v/v0.0.0-20201126162022-7de9c90e9dd1.mod) = 95
SIZE (go_modules/golang.org/x/term/@v/v0.0.0-20210927222741-03fcf44c2211.mod) = 95
SIZE (go_modules/golang.org/x/term/@v/v0.5.0.mod) = 67
SIZE (go_modules/golang.org/x/term/@v/v0.6.0.mod) = 67
-SIZE (go_modules/golang.org/x/term/@v/v0.8.0.mod) = 67
-SIZE (go_modules/golang.org/x/term/@v/v0.8.0.zip) = 19924
+SIZE (go_modules/golang.org/x/term/@v/v0.9.0.mod) = 67
+SIZE (go_modules/golang.org/x/term/@v/v0.9.0.zip) = 19924
+SIZE (go_modules/golang.org/x/text/@v/v0.10.0.mod) = 197
+SIZE (go_modules/golang.org/x/text/@v/v0.10.0.zip) = 8620307
SIZE (go_modules/golang.org/x/text/@v/v0.3.0.mod) = 25
SIZE (go_modules/golang.org/x/text/@v/v0.3.3.mod) = 97
SIZE (go_modules/golang.org/x/text/@v/v0.3.6.mod) = 97
SIZE (go_modules/golang.org/x/text/@v/v0.3.7.mod) = 97
+SIZE (go_modules/golang.org/x/text/@v/v0.6.0.mod) = 258
SIZE (go_modules/golang.org/x/text/@v/v0.7.0.mod) = 258
SIZE (go_modules/golang.org/x/text/@v/v0.8.0.mod) = 215
SIZE (go_modules/golang.org/x/text/@v/v0.9.0.mod) = 215
-SIZE (go_modules/golang.org/x/text/@v/v0.9.0.zip) = 8614767
SIZE (go_modules/golang.org/x/tools/@v/v0.0.0-20180917221912-90fa682c2a6e.mod) = 26
SIZE (go_modules/golang.org/x/tools/@v/v0.0.0-20191119224855-298f0cb1881e.mod) = 212
SIZE (go_modules/golang.org/x/tools/@v/v0.1.12.mod) = 327
+SIZE (go_modules/golang.org/x/tools/@v/v0.10.0.mod) = 213
+SIZE (go_modules/golang.org/x/tools/@v/v0.10.0.zip) = 2961243
SIZE (go_modules/golang.org/x/tools/@v/v0.2.0.mod) = 177
SIZE (go_modules/golang.org/x/tools/@v/v0.6.0.mod) = 211
SIZE (go_modules/golang.org/x/tools/@v/v0.6.1-0.20230217175706-3102dad5faf9.mod) = 211
-SIZE (go_modules/golang.org/x/tools/@v/v0.9.3.mod) = 213
-SIZE (go_modules/golang.org/x/tools/@v/v0.9.3.zip) = 2953479
SIZE (go_modules/golang.org/x/vuln/@v/v0.0.0-20230303230808-d3042fecc4e3.mod) = 568
SIZE (go_modules/golang.org/x/vuln/@v/v0.0.0-20230303230808-d3042fecc4e3.zip) = 305007
SIZE (go_modules/golang.org/x/xerrors/@v/v0.0.0-20190717185122-a985d3407aa7.mod) = 37
@@ -449,4 +465,4 @@ SIZE (osv-scanner-v1.3.4.zip) = 899201
SIZE (go_modules/mvdan.cc/unparam/@v/v0.0.0-20211214103731-d0ef000c54e5.zip) = 28548
SIZE (go_modules/sigs.k8s.io/yaml/@v/v1.3.0.mod) = 106
SIZE (go_modules/sigs.k8s.io/yaml/@v/v1.3.0.zip) = 21567
-SIZE (osv-scanner-v1.3.4.zip) = 899201
+SIZE (osv-scanner-v1.3.5.zip) = 903504
blob - b1dceb40df31543169043d40e9af4d47d0c85a06
blob + af3c3ed0c1c5589a44f21de35ec54c95968026b3
--- security/osv-scanner/modules.inc
+++ security/osv-scanner/modules.inc
@@ -1,5 +1,5 @@
MODGO_MODULES = \
- github.com/!burnt!sushi/toml v1.3.0 \
+ github.com/!burnt!sushi/toml v1.3.2 \
github.com/!cyclone!d!x/cyclonedx-go v0.7.1 \
github.com/!microsoft/go-winio v0.5.2 \
github.com/!proton!mail/go-crypto v0.0.0-20230518184743-7afd39499903 \
@@ -21,6 +21,8 @@ MODGO_MODULES = \
github.com/go-git/go-billy/v5 v5.4.1 \
github.com/go-git/go-git-fixtures/v4 v4.3.2-0.20230305113008-0c11038e723f \
github.com/go-git/go-git/v5 v5.7.0 \
+ github.com/goark/errs v1.1.0 \
+ github.com/goark/go-cvss v1.6.6 \
github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da \
github.com/google/go-cmdtest v0.4.1-0.20220921163831-55ab3332a786 \
github.com/google/go-cmp v0.5.9 \
@@ -37,7 +39,7 @@ MODGO_MODULES = \
github.com/mattn/go-runewidth v0.0.13 \
github.com/mmcloughlin/avo v0.5.0 \
github.com/niemeyer/pretty v0.0.0-20200227124842-a10e7caefd8e \
- github.com/package-url/packageurl-go v0.1.0 \
+ github.com/package-url/packageurl-go v0.1.1 \
github.com/pjbgf/sha1cd v0.3.0 \
github.com/pkg/diff v0.0.0-20210226163009-20ebb0f2a09e \
github.com/pkg/errors v0.9.1 \
@@ -50,22 +52,22 @@ MODGO_MODULES = \
github.com/sirupsen/logrus v1.7.0 \
github.com/skeema/knownhosts v1.1.1 \
github.com/spdx/gordf v0.0.0-20221230105357-b735bd5aac89 \
- github.com/spdx/tools-golang v0.5.1 \
+ github.com/spdx/tools-golang v0.5.2 \
github.com/stretchr/objx v0.5.0 \
- github.com/stretchr/testify v1.8.3 \
- github.com/urfave/cli/v2 v2.25.5 \
+ github.com/stretchr/testify v1.8.4 \
+ github.com/urfave/cli/v2 v2.25.7 \
github.com/xanzy/ssh-agent v0.3.3 \
github.com/xrash/smetrics v0.0.0-20201216005158-039620a65673 \
github.com/yuin/goldmark v1.4.13 \
- golang.org/x/crypto v0.9.0 \
+ golang.org/x/crypto v0.10.0 \
golang.org/x/exp v0.0.0-20230522175609-2e198f4a06a1 \
- golang.org/x/mod v0.10.0 \
- golang.org/x/net v0.10.0 \
- golang.org/x/sync v0.2.0 \
- golang.org/x/sys v0.8.0 \
- golang.org/x/term v0.8.0 \
- golang.org/x/text v0.9.0 \
- golang.org/x/tools v0.9.3 \
+ golang.org/x/mod v0.11.0 \
+ golang.org/x/net v0.11.0 \
+ golang.org/x/sync v0.3.0 \
+ golang.org/x/sys v0.9.0 \
+ golang.org/x/term v0.9.0 \
+ golang.org/x/text v0.10.0 \
+ golang.org/x/tools v0.10.0 \
golang.org/x/vuln v0.0.0-20230303230808-d3042fecc4e3 \
golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7 \
gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c \
@@ -78,7 +80,6 @@ MODGO_MODFILES = \
MODGO_MODFILES = \
github.com/!burnt!sushi/toml v0.3.1 \
- github.com/!burnt!sushi/toml v1.2.1 \
github.com/bwesterb/go-ristretto v1.2.0 \
github.com/cloudflare/circl v1.1.0 \
github.com/davecgh/go-spew v1.1.0 \
@@ -101,6 +102,7 @@ MODGO_MODFILES = \
golang.org/x/crypto v0.3.1-0.20221117191849-2c476679df9a \
golang.org/x/crypto v0.7.0 \
golang.org/x/crypto v0.8.0 \
+ golang.org/x/crypto v0.9.0 \
golang.org/x/exp v0.0.0-20220722155223-a9213eeb770e \
golang.org/x/mod v0.6.0 \
golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4 \
@@ -109,6 +111,7 @@ MODGO_MODFILES = \
golang.org/x/net v0.0.0-20210226172049-e18ecbb05110 \
golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2 \
golang.org/x/net v0.0.0-20220722155237-a158d28d115b \
+ golang.org/x/net v0.10.0 \
golang.org/x/net v0.6.0 \
golang.org/x/net v0.8.0 \
golang.org/x/sync v0.0.0-20190423024810-112230192c58 \
@@ -129,6 +132,7 @@ MODGO_MODFILES = \
golang.org/x/sys v0.5.0 \
golang.org/x/sys v0.6.0 \
golang.org/x/sys v0.7.0 \
+ golang.org/x/sys v0.8.0 \
golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1 \
golang.org/x/term v0.0.0-20210927222741-03fcf44c2211 \
golang.org/x/term v0.5.0 \
@@ -137,8 +141,10 @@ MODGO_MODFILES = \
golang.org/x/text v0.3.3 \
golang.org/x/text v0.3.6 \
golang.org/x/text v0.3.7 \
+ golang.org/x/text v0.6.0 \
golang.org/x/text v0.7.0 \
golang.org/x/text v0.8.0 \
+ golang.org/x/text v0.9.0 \
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e \
golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e \
golang.org/x/tools v0.1.12 \
Hello,
Here's an update for osv-scanner which has been working fine.
Other tests?
Thanks,
Lucas
Subscribe to:
Posts (Atom)