Re: openbsd.org - certain https URLs downgraded to http in redirection
On 2020-02-25, Nick Holland wrote: > Sorry, took a look at this a while back when I didn't have time to > fully work through it...and then forgot about it. ;-/ > > On 2020-02-12 04:34, Aham Brahmasmi wrote: >> Namaste misc, >> >> Overview: >> Certain https URLs on openbsd.org get downgraded to http in redirection. >> >> Steps: >> When navigating to https://www.openbsd.org/cgi-bin/man.cgi [1] from a >> browser, one ends up on http://man.openbsd.org/cgi-bin/man.cgi. >> >> Same with https://www.openbsd.org/cgi-bin/cvsweb [1], which ends up on >> http://cvsweb.openbsd.org/cgi-bin/cvsweb/. > > I Google for "openbsd man", I end up with a link to > httpS://man.openbsd.org. > and it takes me to man.openbsd.org via httpS. > > I duckduckgo.com for "openbsd man", same thing. > (yay. I just used a website as a verb.) > > Google does seem to show a link for httpS://cvsweb.openbsd.org, but > tosses the browser at http://cvsweb.openbsd.org. DuckDuckGo does not > and does what you would expect and hope. Google has https://www.openbsd.org/cgi-bin/cvsweb/, not https://cvsweb.openbsd.org. > Looking at the page source for the google return, it DOES appear to > be sending the browser to http://, so everything is working as > designed. Is there a problem? Yes -- google is aware https:// > those sites exists, but doesn't actually send users to them. > > Apparently your favorite search engine does as well. Perhaps it > isn't as privacy friendly as you are thinking it is. The problem > isn't with the websites, it's with where the search engine is > sending the user. The problem *is* with the website (specifically www.openbsd.org, not man/cvsweb). It redirects the old cgi-bin URLs to http versions whatever protocol the request came in on. $ ftp -o/dev/null https://www.openbsd.org/cgi-bin/cvsweb/ Trying 129.128.5.194... Requesting https://www.openbsd.org/cgi-bin/cvsweb/ Redirected to http://cvsweb.openbsd.org/cgi-bin/cvsweb/ Trying 128.100.17.243... Requesting http://cvsweb.openbsd.org/cgi-bin/cvsweb/ 2607 bytes received in 0.01 seconds (265.55 KB/s) $ ftp -o/dev/null https://www.openbsd.org/cgi-bin/man.cgi Trying 129.128.5.194... Requesting https://www.openbsd.org/cgi-bin/man.cgi Redirected to http://man.openbsd.org/cgi-bin/man.cgi Trying 128.100.17.244... Requesting http://man.openbsd.org/cgi-bin/man.cgi 5590 bytes received in 0.00 seconds (1.55 MB/s) > You want it changed so that when someone clicks on a link, they go > somewhere OTHER than where that link sends them? I understand your > goal (everything should be HTTPS!!), but I don't really like the > idea of "click here, go elsewhere". > > Want https? great. use it. There are times when it's handy to NOT > be obsessed with https (i.e., clock is hosed on your computer). > > So ... unless some developer I really respect (which is just about > all of them1) tells me to change this, I'm not planning on > changing the behavior of the machines. I did object to http->https redirects in the past, but now the web is unusable without working https anyway and the "INSECURE openbsd.org" shown on some browsers *is* a bit of an eyesore ...
Re: What TERM fixes Emacs?
On 2020-02-25, Emilia wrote: > It is impossible to use Emacs on OpenBSD Terminal (no X). > > Look at this screenshots: > > On Linux / macOs -- this same version of Emacs and org-mode would > display this file with colors etc. > > OpenBSD can't even show the mode line. > > How do I fix this? Try pccon. > --=_f69ee5e0e3f3ba5b74bb1250e9e8a612 > Content-ID: <15826084275e54b02bbe0d7530097...@sonic.net> > Content-Disposition: inline; > filename=c-3.gif; > size=67545 > Content-Transfer-Encoding: base64 > Content-Type: image/gif; > name=c-3.gif > > R0lGODlhkwEuAfcAAAQBAA0DAQkEDBMEARoGARwJAhYJCQoGHAkGGBcLGhsS > GSQLASkOASQIAywSAigUCDcZAygSHSYOGj0hBgYFIwkGIgsJJAwLLAgGKxMN .. Please don't send image attachments to the OpenBSD lists (and in general most techmical mailing lists)
Re: What TERM fixes Emacs?
On 25/02/2020, Emilia wrote: > It is impossible to use Emacs on OpenBSD Terminal (no X). > OpenBSD does not do non-X versions of ported software so even if you dont use X as such it still needs to be in the base install. HTH (I've had my backside reamed over this more than once!)
What TERM fixes Emacs?
It is impossible to use Emacs on OpenBSD Terminal (no X). Look at this screenshots: On Linux / macOs -- this same version of Emacs and org-mode would display this file with colors etc. OpenBSD can't even show the mode line. How do I fix this? Em
Re: inteldrm changes cause high temperature / fan speeds
Hi Tero, Apologies if this breaks the threading -- I wasn't subscribed to misc@ at the time the original was sent. Have you (or any others) dug any deeper into this? I've spent a good few hours reading different related threads, but haven't found any solutions, and you seem to have come closest to narrowing down the search space for the root cause. I am also experiencing a similar heat problem on my X220. When idling, I am consistently seeing ~50deg Celcius for the CPU. I've seen this with a fresh install of 6.6 and more recently on -current. I downgraded to 6.5 and the issue disappeared (with idle CPU's at mid thirties or so). I should note that these temperatures hold for just idling in the console (no X11). Based on my symptoms, and your description, I have a hunch I might be seeing the same issue you described. In particular, the other reports of heat seem to have been solved by tweaking the BIOS settings [1], but I tried all the mentioned settings and more without any luck. If anyone has any pointers on where to look as next steps (what part of the 250k line diff might be problematic, troubleshooting steps, etc), that would be very welcome too! Thanks all for your time and help, Alex [1]: https://marc.info/?t=15738333783 dmesg: OpenBSD 6.6-current (GENERIC.MP) #653: Thu Feb 20 21:40:37 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4156157952 (3963MB) avail mem = 4017606656 (3831MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries) bios0: vendor LENOVO version "8DET76WW (1.46 )" date 06/21/2018 bios0: LENOVO 4286CTO acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 797.55 MHz, 06-2a-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 797.42 MHz, 06-2a-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus 14 (EXP7) acpicpu0 at acpi0: C3(200@109 io@0x416), C2(500@80 io@0x414), C1(1000@1 halt), PSS acpicpu1 at acpi0: C3(200@109 io@0x416), C2(500@80 io@0x414), C1(1000@1 halt), PSS acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2 acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0: TPM_ addr 0xfed4/0x5000, device 0x104a rev 0x4e acpibat0 at acpi0: BAT0 model "42T4940" serial 5067 type LION oem "SANYO" acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivout0 at acpivideo0: LCD0 acpivideo1 at acpi0: VID_ cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 797 MHz: speeds: 2701, 2700, 2400, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address f0:de:f1:66:e4:d2 ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev
High CPU usage with docker on alpine linux vmm
Hi all, I am running obsd -current and was trying to get alpine vmm to work, more specifically to learn docker. I'm noticing a very high CPU usage when I get docker running, which is without any containers Steps to reproduce: 1) Install alpine in a vmm 2) Install docker and start (first need to enable community repo) apk add docker rc-service docker start Expected: Docker starts, life goes on Reality: Docker starts, CPU usage in vmm goes to ~75-90%, containerd is using all the memory. Also, tsc is marked as unstable in dmesg for alpine [ 0.00] tsc: Fast TSC calibration failed [ 0.03] tsc: Using PIT calibration value [ 0.03] tsc: Detected 18090.273 MHz processor [ 0.02] clocksource: tsc-early: mask: 0x max_cycles: 0x104c2d0d539a, max_idle_ns: 440795933422 ns [ 0.311645] clocksource: Switched to clocksource tsc-early [ 0.510259] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc-early' as unstable because the skew is too large: [ 0.510259] clocksource: 'tsc-early' cs_now: 5174087c0cc cs_last: 516d7de6c74 mask: [ 0.510259] tsc: Marking TSC unstable due to clocksource watchdog [ 0.510654] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. This is a pretty crippling bug, as I am unable to do a lot more things on my VM or on my actual machine, given that my plan was to run multiple VMs, which has now been lost in the midst of clock errors and syncings. Would love to know how anyone has managed to get this to work. Cheers, Aisha OpenBSD 6.6-current (GENERIC.MP) #653: Thu Feb 20 21:40:37 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34059407360 (32481MB) avail mem = 33014579200 (31485MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb500 (59 entries) bios0: vendor Intel Corp. version "S1200RP.86B.03.03.0003.121820151104" date 12/18/2015 bios0: Intel Corporation S1200RP acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S1 S3 S5 acpi0: tables DSDT FACP APIC SPMI FPDT MCFG WDDT HPET SSDT BOOT SSDT SSDT SSDT SSDT SSDT SSDT DMAR HEST BERT ERST EINJ acpi0: wakeup devices PEG0(S3) PEGP(S3) PEG1(S3) PEGP(S3) PEG2(S3) PEGP(S3) RP01(S3) PXSX(S3) RP02(S3) PXSX(S3) RP03(S3) PXSX(S3) RP04(S3) PXSX(S3) RP05(S3) PXSX(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3193.05 MHz, 06-3c-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.62 MHz, 06-3c-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.62 MHz, 06-3c-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.62 MHz, 06-3c-03 cpu3:
Kernel panic during install 6.6
Been a long time since I've written, but I've been reading (almost) all along, and it was that troll thread two months ago that keyed me into the fact that my email preferences were NOT being obeyed, and started the wheels grinding. In trying to set up a new system to begin knocking off 15 years of rust and starting to learn something new, I'm pulling a PowerEdge SC1435 out of the closet, then promptly getting a kernel panic from both install66.fs and install66.iso. Memory seems to check out, suspected cause is the Areca ARC-1200 RAID controller since that's where the boot process fails, but that's about all I can give apart from the drives behind the controller being a pair of Seagate 3TB ST3000DM001 drives configured as RAID-1 with 64bit LBA addressing, and that the keyboard is unresponsive (so no ps/trace) except for CTRL-A rebooting the system. I haven't tried 4k blocks yet, figured I'd ask first before beginning the array re-initialization process. Bootloader and dmesg follows: CD-ROM: 82 Loading /6.6/AMD64/CDBOOT probing: pc0 com0 mem[640K 3581M 12800M a20=on] disk: hd0+* cd0 >> OpenBSD/amd64 CDBOOT 3.44 boot> set tty com0 switching console to com0 cannot open cd0a:/etc/random.seed: No such file or directory booting cd0a:/6.6/amd64/bsd.rd: 3732171+1537024+3885432+0+598016 [376562+128+455544+303577]=0xa648d0 entry point at 0x81001000 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.6 (RAMDISK_CD) #349: Sat Oct 12 11:03:52 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 17161854976 (16366MB) avail mem = 16637759488 (15867MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xdffbc000 (50 entries) bios0: vendor Dell Inc. version "2.2.5" date 03/21/2008 bios0: Dell Inc. PowerEdge SC1435 acpi0 at bios0: ACPI 3.0 acpi0: tables DSDT FACP APIC SPCR HPET MCFG SLIC ERST HEST BERT EINJ SRAT SSDT acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual-Core AMD Opteron(tm) Processor 2212, 1995.35 MHz, 0f-41-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAP8 cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: apic clock running at 199MHz cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 16 pins, remapped ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 11, 16 pins, remapped ioapic2 at mainbus0: apid 6 pa 0xfec02000, version 11, 16 pins, remapped acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (PXB_) acpiprt2 at acpi0: bus 4 (PPBX) acpiprt3 at acpi0: bus 5 (EXB0) acpiprt4 at acpi0: bus 1 (EXB1) acpiprt5 at acpi0: bus 2 (EXB2) acpiprt6 at acpi0: bus 6 (EXB3) acpiprt7 at acpi0: bus 7 (EXB4) acpicpu at acpi0 not configured "PNP0A08" at acpi0 not configured acpicmos0 at acpi0 pci0 at mainbus0 bus 0 ppb0 at pci0 dev 1 function 0 "ServerWorks HT-1000 PCI" rev 0x00 pci1 at ppb0 bus 3 ppb1 at pci1 dev 13 function 0 "ServerWorks HT-1000 PCIX" rev 0xc0 pci2 at ppb1 bus 4 pchb0 at pci0 dev 2 function 0 "ServerWorks HT-1000" rev 0x00 "ServerWorks HT-1000 LPC" rev 0x00 at pci0 dev 2 function 2 not configured ohci0 at pci0 dev 3 function 0 "ServerWorks HT-1000 USB" rev 0x01: apic 4 int 15, version 1.0, legacy support ohci1 at pci0 dev 3 function 1 "ServerWorks HT-1000 USB" rev 0x01: apic 4 int 15, version 1.0, legacy support ehci0 at pci0 dev 3 function 2 "ServerWorks HT-1000 USB" rev 0x01: apic 4 int 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "ServerWorks EHCI root hub" rev 2.00/1.00 addr 1 vga1 at pci0 dev 4 function 0 "ATI ES1000" rev 0x02 wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) ppb2 at pci0 dev 7 function 0 "ServerWorks HT-2100 PCIE" rev 0xa2 pci3 at ppb2 bus 5 ppb3 at pci0 dev 8 function 0 "ServerWorks HT-2100 PCIE" rev 0xa2 pci4 at ppb3 bus 1 bge0 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x21, BCM5750 C1 (0x4201): msi, address 00:18:8b:75:37:ad brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 ppb4 at pci0 dev 9 function 0 "ServerWorks HT-2100 PCIE" rev 0xa2 pci5 at ppb4 bus 2 ppb5 at pci0 dev 10 function 0 "ServerWorks HT-2100 PCIE" rev 0xa2: msi pci6 at ppb5 bus 6 arc0 at pci6 dev 0 function 0 "Areca ARC-1200B" rev 0x00: apic 5 int 3 uvm_fault(0x81910b70, 0x10, 0, 1) -> e fatal page fault in supervisor mode trap type 6 code 0 rip 8123f3ae cs 8 rflags 10293 cr2 10 cpl e rsp 81a068f0 gsbase 0x818afff0 kgsbase 0x0 panic:
Re: openbsd.org - certain https URLs downgraded to http in redirection
Sorry, took a look at this a while back when I didn't have time to fully work through it...and then forgot about it. ;-/ On 2020-02-12 04:34, Aham Brahmasmi wrote: > Namaste misc, > > Overview: > Certain https URLs on openbsd.org get downgraded to http in redirection. > > Steps: > When navigating to https://www.openbsd.org/cgi-bin/man.cgi [1] from a > browser, one ends up on http://man.openbsd.org/cgi-bin/man.cgi. > > Same with https://www.openbsd.org/cgi-bin/cvsweb [1], which ends up on > http://cvsweb.openbsd.org/cgi-bin/cvsweb/. I Google for "openbsd man", I end up with a link to httpS://man.openbsd.org. and it takes me to man.openbsd.org via httpS. I duckduckgo.com for "openbsd man", same thing. (yay. I just used a website as a verb.) Google does seem to show a link for httpS://cvsweb.openbsd.org, but tosses the browser at http://cvsweb.openbsd.org. DuckDuckGo does not and does what you would expect and hope. Looking at the page source for the google return, it DOES appear to be sending the browser to http://, so everything is working as designed. Is there a problem? Yes -- google is aware https:// those sites exists, but doesn't actually send users to them. Apparently your favorite search engine does as well. Perhaps it isn't as privacy friendly as you are thinking it is. The problem isn't with the websites, it's with where the search engine is sending the user. You want it changed so that when someone clicks on a link, they go somewhere OTHER than where that link sends them? I understand your goal (everything should be HTTPS!!), but I don't really like the idea of "click here, go elsewhere". Want https? great. use it. There are times when it's handy to NOT be obsessed with https (i.e., clock is hosed on your computer). So ... unless some developer I really respect (which is just about all of them1) tells me to change this, I'm not planning on changing the behavior of the machines. Nick.
Re: pass 'password manager' problem
As far as I have seen in the pass script, --batch mode is oly invoked if you are running a gpg agent or are running gpg2. Do you have gpg2 installed? Do you have a gpg agent configured? You may need to include the following line in your ~.profile : export GPG_TTY=$(tty) Shadrock Uhuru wrote: > [-- text/plain, encoding 8bit, charset: utf-8, 61 lines --] > > Hi > >>From: Rubén Llorente >>To: misc@openbsd.org >>Subject: Re: pass 'password manager' problem >>Date: Fri, 21 Feb 2020 16:22:37 - (UTC) >> >>Do you have a ~.gnupg/gpg.conf ? Pass works fine for me. >> >>Shadrock Uhuru wrote: >>> [-- text/plain, encoding 7bit, charset: utf-8, 6 lines --] >>> >>> running 'pass username' returns >>> "gpg: Sorry, we are in batchmode - can't get input", >>> am i missing a piece of software or setting ? >>> >>> shadrock >>> > > yes i have the following > cat ~/.gnupg/gpg.conf > > use-agent > pinentry-mode loopback > personal-cipher-preferences CAMELLIA256 AES256 AES192 AES CAST5 > # personal-cipher-preferences AES256 AES192 AES CAST5 CAMELLIA192 > # BLOWFISH TWOFISH CAMELLIA128 3DES > personal-digest-preferences SHA512 SHA384 SHA256 SHA224 > personal-compress-preferences BZIP2 ZIP ZLIB > default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES > CAST5 ZLIB BZIP2 ZIP Uncompressed > cert-digest-algo SHA512 > digest-algo SHA256 > s2k-mode 3 > s2k-digest-algo SHA512 > s2k-cipher-algo AES256 > s2k-count 1015808 > charset utf-8 > fixed-list-mode > no-greeting > no-secmem-warning > no-comments > no-emit-version > keyid-format 0xlong > list-options show-uid-validity > verify-options show-uid-validity > keyserver-options import-clean-sigs import-clean-uids export-clean-sigs > export-clean-uids > keyserver hkp://hkps.pool.sks-keyservers.net > keyserver-options auto-key-retrieve > keyserver-options no-honor-keyserver-url > escape-from-lines > bzip2-compress-level 9 > compress-level 9 > with-fingerprint > > > --- > > shadrock > > [-- application/x-pkcs7-signature, encoding base64, 67 lines, name: smime.p7s > --] -- OpenPGP Key Fingerprint: BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA
Trusted Boot with OpenBSD
As part of my master thesis i wrote code to enable a trusted boot with OpenBSD. This short manual is for everyone who wants to try it. Feedback on the code and the feature itself is also appreciated. Requirements: 1: OpenBSD 6.5 (might also work with 6.6 but only tested with 6.5) 2: Default installation with Full Disk Encryption (FDE) 3: Clean sys source code in /usr/src/sys/** 4: Firmware with Logical Block Adressing (LBA) support 5: 64-Bit Processor 6: System with a dedicated TPM 1.2 Chip 7: Downloaded all attachments to this email in /tmp 8: Adventurous mindset (this might brick your installation) 1: Updating the MBR startprogram to measure biosboot(8) The following commands are meant to be inserted one by one by the user and need adjustments depending on the system. cd /usr/src/sys/arch/amd64/stand/mbr/ # patch the source code and compile the new MBR patch mbr.S /tmp/mbr.patch make CPPFLAGS+=-DTPM_MEASURE CPPFLAGS+=-DNO_CHS # updating MBR on disk (replace X with drive). To preserve partition # table copy existing, overwrite startprogram and write back dd if=/dev/rsdXc of=mbr.img bs=512 count=1 dd if=mbr of=mbr.img bs=440 count=1 conv=notrunc dd if=mbr.img of=/dev/rsdXc bs=512 count=1 rm mbr.img 2: Updating biosboot(8) and boot(8) Same as in the first step. These commands contain absolute paths and drive numbers that need to be changed by the user. cd /usr/src/sys/arch/amd64/stand/biosboot/ # patch the biosboot(8) source code and compile patch biosboot.S /tmp/biosboot.patch make DEBUGFLAGS+=-DNO_CHS DEBUGFLAGS+=-DTPM_MEASURE # patch the boot(8) source code and compile cd /usr/src/sys/arch/amd64/stand patch ./boot/Makefile /tmp/makefile.patch # this fix got already included in the OpenBSD source but did not make # it in 6.6 patch ./libsa/gidt.S /tmp/boot/gidt.patch patch ./libsa/cmd_i386.c /tmp/cmd_i386.patch cp /tmp/tpm.c ./libsa/ cp /tmp/tpm.h ./libsa/ cd ./boot make # install biosboot(8) and boot(8) # replace X with the drive number of the virtual softraid device cd /usr/src/sys/arch/amd64/stand installboot sdX ./biosboot/biosboot ./boot/boot If every step finished successfully, your system extends the measurement chain from a small immutable piece of firmware up to boot(8). The updated mbr(8) measures biosboot(8) and biosboot(8) measures boot(8). The TPM has to be initialized bevor any of the tpm commands will work. To perform the initialization: 1: reset the TPM in the firmware 2: create a bootable Fedora USB-Stick 3: start the system with it 4: and execute the following commands: sudo dnf install tpm-tools tpm_takeownership -z -y boot(8) supports the machine specific command "tpm". This allows a user to: 1: read the current contents of the Platform Control Registers (PCR) with the "pcr" parameter machine tpm p[cr] 2: seal a user supplied secret to the current PCR values and store it in the second block on a disk, that can be altered via a parameter. WARNING: If there is any other data in this block, it will be overwritten without asking again. machine tpm s[eal] secret [DiskNumber] 3: unseal a previously sealed secrent and display it to the user. This command just reads the second block of the disk that can be specified by the user and unseals it via the TPM machine tpm u[nseal] [DiskNumber] Lets hope everything works as it does on my machine :). I will now be away from my computer for a month. So if this feature is something the OpenBSD would welcome, i would put in the other 90% it takes to bring this feature from a prototype to something that could actually be merged. Kind Regards Julius tpm.h Description: Binary data tpm.c Description: Binary data biosboot.patch Description: Binary data cmd_i386.patch Description: Binary data gidt.patch Description: Binary data makefile.patch Description: Binary data mbr.patch Description: Binary data
