Re: Secondary monitor switches off when inteldrm switches on
Am 3. Juli 2019 02:54:28 MESZ schrieb Jonathan Gray : >I would not be surprised if the DVI output is SDVO. >Building a kernel with 'option DRMDEBUG' added to the config will >show some additional information in dmesg. >It can be made more verbose by setting additional variables. You are right, it is a SDVO ADD2 adapter. I'll se that I get this DRMDEBUG output.
Re: ssh-keygen specify max keysize for ed25519
Thus said Theo De Raadt on Tue, 02 Jul 2019 22:45:29 -0600 I think this is fine. At the point where the -b argument is matched, it is not clear what key-type is being handled. It is in your case, but not if -b and -t arguments are swapped. You can go read the source to see why. Cool! Thanks for the education!
Re: ssh-keygen specify max keysize for ed25519
I think this is fine. At the point where the -b argument is matched, it is not clear what key-type is being handled. It is in your case, but not if -b and -t arguments are swapped. You can go read the source to see why. jungle boogie wrote: > Hi All, > > $ ssh-keygen -t ed25519 -b 1000 > Bits has bad value 1000 (too large) > > > $ ssh-keygen -t ed25519 -b 2 > key bits exceeds maximum 16384 > > Should the first example report the max bits like in the second example? > > This happens to be: > kern.version=OpenBSD 6.5-current (GENERIC.MP) #86: Fri Jun 28 12:09:23 > MDT 2019 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > arm64 > > but I believe I've seen this on amd64 as well. > > $ ssh -V > OpenSSH_8.0, LibreSSL 3.0.0 > > thanks, > j.b. >
ssh-keygen specify max keysize for ed25519
Hi All, $ ssh-keygen -t ed25519 -b 1000 Bits has bad value 1000 (too large) $ ssh-keygen -t ed25519 -b 2 key bits exceeds maximum 16384 Should the first example report the max bits like in the second example? This happens to be: kern.version=OpenBSD 6.5-current (GENERIC.MP) #86: Fri Jun 28 12:09:23 MDT 2019 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP arm64 but I believe I've seen this on amd64 as well. $ ssh -V OpenSSH_8.0, LibreSSL 3.0.0 thanks, j.b.
ed(1) man page doesn't mention use of single / and ?
Hi! I am not good at explaining something shortly and clearly to fit into proper documentation, so I'll just describe my experience here. Terminating regular expressions with / or ? is necessary only if they are followed by commands, otherwise the following are legal in both OpenBSD ed, Plan 9 ed and GNU ed: /something / ? g/ing I hope I made life of many ed users easier :)
Re: Secondary monitor switches off when inteldrm switches on
On Tue, Jul 02, 2019 at 05:38:35PM -0700, Misc User wrote: > On 7/2/2019 2:45 PM, Henry Jensen wrote: > > Greetings, > > > > to keep it short: > > > > - older Fujitsu Esprimo PC, Core2Duo, Integrated Intel Graphics > > - 2 monitors, connected at VGA and DVI > > - during installation both monitors were on all the time. > > - Computer switched on, both displays on, boot begins > > - inteldrm kicks in, the monitor at the DVI port switches OFF (short > > message on the display says "power saving mode") > > - Xenodm starts, only at 1 display. xrandr reports only 1 monitor, Xorg log > > says DVI monitor is disconnected > > - similar behaviour on FreeBSD, but: > > - on Linux both monitors are working with drm and X. > > > > Where to begin to look? > > > > Kind regards, > > > > Henry > > > > > Can you post a dmesg, there were a -lot- of different video chips used > on the core2duo architecture and each has its quirks. Yours might be > actually supported, but a lot of them aren't. inteldrm attaches to this all all integrated Intel video of that era. > > From what I remember, there is some kind of proprietary bit of firmware > that needs to be installed to get both outputs working simultaneously, > but it requires a binary blob to be injected into the driver. IIRC its > some undocumented set of registers that need to get their bits flipped > for the second output to be recognized by the itneldrm code. This is complete nonsense. I would not be surprised if the DVI output is SDVO. Building a kernel with 'option DRMDEBUG' added to the config will show some additional information in dmesg. It can be made more verbose by setting additional variables.
Re: Secondary monitor switches off when inteldrm switches on
On 7/2/2019 2:45 PM, Henry Jensen wrote: Greetings, to keep it short: - older Fujitsu Esprimo PC, Core2Duo, Integrated Intel Graphics - 2 monitors, connected at VGA and DVI - during installation both monitors were on all the time. - Computer switched on, both displays on, boot begins - inteldrm kicks in, the monitor at the DVI port switches OFF (short message on the display says "power saving mode") - Xenodm starts, only at 1 display. xrandr reports only 1 monitor, Xorg log says DVI monitor is disconnected - similar behaviour on FreeBSD, but: - on Linux both monitors are working with drm and X. Where to begin to look? Kind regards, Henry Can you post a dmesg, there were a -lot- of different video chips used on the core2duo architecture and each has its quirks. Yours might be actually supported, but a lot of them aren't. From what I remember, there is some kind of proprietary bit of firmware that needs to be installed to get both outputs working simultaneously, but it requires a binary blob to be injected into the driver. IIRC its some undocumented set of registers that need to get their bits flipped for the second output to be recognized by the itneldrm code.
Secondary monitor switches off when inteldrm switches on
Greetings, to keep it short: - older Fujitsu Esprimo PC, Core2Duo, Integrated Intel Graphics - 2 monitors, connected at VGA and DVI - during installation both monitors were on all the time. - Computer switched on, both displays on, boot begins - inteldrm kicks in, the monitor at the DVI port switches OFF (short message on the display says "power saving mode") - Xenodm starts, only at 1 display. xrandr reports only 1 monitor, Xorg log says DVI monitor is disconnected - similar behaviour on FreeBSD, but: - on Linux both monitors are working with drm and X. Where to begin to look? Kind regards, Henry
Re: OT: hardware war with manufacturers (espionage claims)
I’m fine with hardware implants snooping on me. But if I was a CISO for a huge company, I might go the extra mile to care about said implants. I’ll continue living carefree. > On Jul 2, 2019, at 1:42 PM, Nathan Hartman wrote: > > On Tue, Jul 2, 2019 at 1:28 PM Brian Brombacher > wrote: > >> Oh and if the implant is smart, it’ll detect you’re trying to find it and >> go dormant. >> >> Even more good luck! > > > Well then the solution is obvious. > > Design your own hardware. > > Or learn to live off the land.
Re: Future of X.org?
Tue, 2 Jul 2019 10:31:21 -0700 John Brahy > Thanks for the Wikipedia link. I never researched sentence spacing before. Of course, and to reward the patience of reading to the end of the noise: Template: X Window System https://en.wikipedia.org/wiki/Template:XWinSys > On Tue, Jul 2, 2019 at 9:33 AM wrote: > > > Tue, 02 Jul 2019 12:09:01 +0300 cho...@jtan.com > > > > > > Also you've got two spaces again. > > > > Indeed.. https://en.wikipedia.org/wiki/Sentence_spacing#Computer_era > >
Re: OT: hardware war with manufacturers (espionage claims)
On Tue, Jul 2, 2019 at 1:28 PM Brian Brombacher wrote: > Oh and if the implant is smart, it’ll detect you’re trying to find it and > go dormant. > > Even more good luck! Well then the solution is obvious. Design your own hardware. Or learn to live off the land.
Re: OT: hardware war with manufacturers (espionage claims)
Oh and if the implant is smart, it’ll detect you’re trying to find it and go dormant. Even more good luck! > On Jul 2, 2019, at 1:24 PM, Brian Brombacher wrote: > > Hardware implants go beyond just sending packets out your network card. They > have transceivers that let agents control or snoop the device from a distance > using RF. > > You need to scan the hardware with RF equipment to be sure. > > Good luck! > >>> On Jul 2, 2019, at 12:27 PM, Misc User >>> wrote: >>> >>> On 7/2/2019 12:43 AM, John Long wrote: >>> On Tue, 2 Jul 2019 10:07:59 +0300 >>> Mihai Popescu wrote: Hello, I keep finding articles about some government bans against some hardware manufacturers related to some backdoor for espionage. I know this is an old talk. Most China manufacturers are under the search: Huawei, ZTE, Lenovo, etc. >>> It seems painfully obvious what's driving all the bans and vilification >>> of Chinese hardware and software is that the USA wants exclusive rights >>> to spy on you and won't tolerate any competition. >>> Does anybody think maybe the reason Google and Facebook don't pay taxes >>> anywhere might have something to do with what they do with all that >>> info they collect? Is the "new" talk about USA banning any meaningful >>> encryption proof of how seriously they take security and privacy? What do you think and do when using OpenBSD on this kind of hardware? >>> Lemote boxes are kinda neat but they're not the fastest in the world. >>> It beats the hell out of the alternatives if you can live with the >>> limitations. Do you prefer Dell, HP and Fujitsu? >>> Your only choice is probably to pick the least objectionable entity to >>> spy on you. If you buy Intel you know you're getting broken, insecure >>> crap no matter whose box it comes in. Sure it runs fast, but... in that >>> case everybody is going to spy on you. >>> /jl >> >> Assume everything is compromised. Don't trust something because someone >> else said it was good. Really, the only way to test if a machine is >> spying on you, do some kind of packet capture to watch its traffic until >> you are satisfied. But also put firewalls in front of your devices to >> ensure that if someone is trying to spy on you, their command and >> control packets don't make it to the compromised hardware. >> >> Besides, subverting a supply a hardware supply chain is a difficult and >> expensive process. And if there is one thing I've learned in my career >> as a security consultant, its that no matter how malevolent or >> benevolent a government is, they are still, above all, cheap and lazy. >> And in a world where everything is built with the first priority is >> making the ship date, there are going to be so many security flaws to be >> exploited. So much cheaper and easier to let Intel rush a design to >> market or Red Hat push an OS release without doing thorough testing and >> exploit the inevitable remote execution flaws. >> >> Or intelligence agencies can take advantage of the average person's tendency >> to laziness and cheapness by just asking organizations like Google, >> Facebook, Comcast, Amazon to just hand over the data they gathered in the >> name of building an advertising profile. >> >
Re: OT: hardware war with manufacturers (espionage claims)
Hardware implants go beyond just sending packets out your network card. They have transceivers that let agents control or snoop the device from a distance using RF. You need to scan the hardware with RF equipment to be sure. Good luck! > On Jul 2, 2019, at 12:27 PM, Misc User wrote: > >> On 7/2/2019 12:43 AM, John Long wrote: >> On Tue, 2 Jul 2019 10:07:59 +0300 >> Mihai Popescu wrote: >>> Hello, >>> >>> I keep finding articles about some government bans against some >>> hardware manufacturers related to some backdoor for espionage. I know >>> this is an old talk. Most China manufacturers are under the search: >>> Huawei, ZTE, Lenovo, etc. >> It seems painfully obvious what's driving all the bans and vilification >> of Chinese hardware and software is that the USA wants exclusive rights >> to spy on you and won't tolerate any competition. >> Does anybody think maybe the reason Google and Facebook don't pay taxes >> anywhere might have something to do with what they do with all that >> info they collect? Is the "new" talk about USA banning any meaningful >> encryption proof of how seriously they take security and privacy? >>> What do you think and do when using OpenBSD on this kind of hardware? >> Lemote boxes are kinda neat but they're not the fastest in the world. >> It beats the hell out of the alternatives if you can live with the >> limitations. >>> Do you prefer Dell, HP and Fujitsu? >> Your only choice is probably to pick the least objectionable entity to >> spy on you. If you buy Intel you know you're getting broken, insecure >> crap no matter whose box it comes in. Sure it runs fast, but... in that >> case everybody is going to spy on you. >> /jl > > Assume everything is compromised. Don't trust something because someone > else said it was good. Really, the only way to test if a machine is > spying on you, do some kind of packet capture to watch its traffic until > you are satisfied. But also put firewalls in front of your devices to > ensure that if someone is trying to spy on you, their command and > control packets don't make it to the compromised hardware. > > Besides, subverting a supply a hardware supply chain is a difficult and > expensive process. And if there is one thing I've learned in my career > as a security consultant, its that no matter how malevolent or > benevolent a government is, they are still, above all, cheap and lazy. > And in a world where everything is built with the first priority is > making the ship date, there are going to be so many security flaws to be > exploited. So much cheaper and easier to let Intel rush a design to > market or Red Hat push an OS release without doing thorough testing and > exploit the inevitable remote execution flaws. > > Or intelligence agencies can take advantage of the average person's tendency > to laziness and cheapness by just asking organizations like Google, Facebook, > Comcast, Amazon to just hand over the data they gathered in the name of > building an advertising profile. >
Re: How to debug hanging machines / proc: table is full
On 2019-07-02, Raimo Niskanen wrote: > Hi misc@! > > If anyone has got some tips about how to debug two hanging machines we have > in our test lab I am eager to learn. > > The machines runs 6.5, amd64 and are patched up to 005_libssl using M:Tier's > openup. Other than that they are rather different, one small Zotac > ZBox-AD02 with AMD E-350 at 1.6 GHz, and one rack mounted Dell PowerEdge > R230 with Intel Xeon E3-1220. > > The overall symptoms are that it is possible to switch screens using > Alt+Ctrl+F1..Fn, but when logging in as root the greeting prints but no > prompt. Alt+Ctrl+Del does not work. The power button does not work. I > have to long press the power button to force power off. > > This happens during our nightly tests, that are quite resource intesive. > > In /var/log/messages I find suspicious entries "/bsd: proc: table is full" > possibly before the machines become inresponsive, but these entries appear > many more times before that point. And after this "table is full" message > there are many syslog entries; on one machine smartd constatly complains about > an unreadable (pending) sector and atascsi_passthru_done timeout, and on > the other the kernel complains about a probed monitor but no|invalid EDID. > > So it seems the machine is out of some resource and fails to spawn a login > shell. Any clues to how I can find more details and a remedy? I suspect a > full process table, but wonder how to detect and|or avoid that. > > I have considered having systat running on a console screen but do not know > which systat display that might tell me anything. > > Best regards "/bsd: proc: table is full" means that the process table is full, but it doesn't tell you what caused this. The process table size is controlled by kern.maxproc, it is possible that the default is insufficient for your needs, but it's also possible that there was a build-up of processes that didn't exit due to another problem on the system. I would leave top(1) running on the system, and also save "ps ax" output regularly, then look at that output in the run-up to a failure, to see if that gives clues.
Re: Future of X.org?
Tue, 02 Jul 2019 12:09:01 +0300 cho...@jtan.com > li...@wrant.com writes: > > Worthless thread, worthless comments, annoying Matthew.. STOP spamming. > > Well you're not wrong so there's no need to keep the public involved. It's best discussed in public or not discussed at all, so list included. Your usual intention to tease, is more useful towards instant messaging. > Sorry I was just playing around. I've noticed your penchant for alignment and > felt the need to tease you a bit about it. > > Also you've got two spaces again. One novice. https://en.wikipedia.org/wiki/Sentence_spacing#Computer_era > > Matthew > > ps. No ulterior motive; it was all in good fun and I'm sorry if I've been a > nuisance. > I know, we've had enough fun already let's not waste more time and bits. With that, I consider the thread completely exhausted beyond all points.
Re: OT: hardware war with manufacturers (espionage claims)
On 7/2/2019 12:43 AM, John Long wrote: On Tue, 2 Jul 2019 10:07:59 +0300 Mihai Popescu wrote: Hello, I keep finding articles about some government bans against some hardware manufacturers related to some backdoor for espionage. I know this is an old talk. Most China manufacturers are under the search: Huawei, ZTE, Lenovo, etc. It seems painfully obvious what's driving all the bans and vilification of Chinese hardware and software is that the USA wants exclusive rights to spy on you and won't tolerate any competition. Does anybody think maybe the reason Google and Facebook don't pay taxes anywhere might have something to do with what they do with all that info they collect? Is the "new" talk about USA banning any meaningful encryption proof of how seriously they take security and privacy? What do you think and do when using OpenBSD on this kind of hardware? Lemote boxes are kinda neat but they're not the fastest in the world. It beats the hell out of the alternatives if you can live with the limitations. Do you prefer Dell, HP and Fujitsu? Your only choice is probably to pick the least objectionable entity to spy on you. If you buy Intel you know you're getting broken, insecure crap no matter whose box it comes in. Sure it runs fast, but... in that case everybody is going to spy on you. /jl Assume everything is compromised. Don't trust something because someone else said it was good. Really, the only way to test if a machine is spying on you, do some kind of packet capture to watch its traffic until you are satisfied. But also put firewalls in front of your devices to ensure that if someone is trying to spy on you, their command and control packets don't make it to the compromised hardware. Besides, subverting a supply a hardware supply chain is a difficult and expensive process. And if there is one thing I've learned in my career as a security consultant, its that no matter how malevolent or benevolent a government is, they are still, above all, cheap and lazy. And in a world where everything is built with the first priority is making the ship date, there are going to be so many security flaws to be exploited. So much cheaper and easier to let Intel rush a design to market or Red Hat push an OS release without doing thorough testing and exploit the inevitable remote execution flaws. Or intelligence agencies can take advantage of the average person's tendency to laziness and cheapness by just asking organizations like Google, Facebook, Comcast, Amazon to just hand over the data they gathered in the name of building an advertising profile.
Re: Bypass doas password check with chroot
Use doas.conf to permit root with nopass option. See doas.conf(5). > On Jul 2, 2019, at 4:43 AM, cho...@jtan.com wrote: > > This isn't a bug per se, more of an incongruity in how security-centric tools > work wrt root, specifically doas and chroot/su/other: > > joe@drogo$ doas -s > drogo# doas -u chohag -s > doas (root@drogo) password: > doas: Authorization failed > drogo# chroot -u chohag / > drogo$ ^D > drogo# su -l chohag > drogo$ ^D > > Obviously a little one-liner or tiny C app could achieve the same result too. > > I assume this is more or less known, since each tool is working to its > designed spec, so is the above ultimately the desired behaviour? Should doas > ask even for root's password while myriad other ways of obtaining any user ID > do and probably always will exist? > > On some servers root doesn't have a password. > > Matthew >
How to debug hanging machines / proc: table is full
Hi misc@! If anyone has got some tips about how to debug two hanging machines we have in our test lab I am eager to learn. The machines runs 6.5, amd64 and are patched up to 005_libssl using M:Tier's openup. Other than that they are rather different, one small Zotac ZBox-AD02 with AMD E-350 at 1.6 GHz, and one rack mounted Dell PowerEdge R230 with Intel Xeon E3-1220. The overall symptoms are that it is possible to switch screens using Alt+Ctrl+F1..Fn, but when logging in as root the greeting prints but no prompt. Alt+Ctrl+Del does not work. The power button does not work. I have to long press the power button to force power off. This happens during our nightly tests, that are quite resource intesive. In /var/log/messages I find suspicious entries "/bsd: proc: table is full" possibly before the machines become inresponsive, but these entries appear many more times before that point. And after this "table is full" message there are many syslog entries; on one machine smartd constatly complains about an unreadable (pending) sector and atascsi_passthru_done timeout, and on the other the kernel complains about a probed monitor but no|invalid EDID. So it seems the machine is out of some resource and fails to spawn a login shell. Any clues to how I can find more details and a remedy? I suspect a full process table, but wonder how to detect and|or avoid that. I have considered having systat running on a console screen but do not know which systat display that might tell me anything. Best regards -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: L2TP/IPSec PSK with Android -- INVALID_ID_INFORMATION
Oh, and one other issue, if anyone gets bitten by this: Don't use the 'any' keyword after the 'from'/'to' attributes. Even though iked.conf(5) says you can, I got an "unsupported address family 0" error from iked. 0.0.0.0/0 works instead. -- Lévai, Dániel ‐‐‐ Original Message ‐‐‐ On Monday, 1 July 2019 21:19, Lévai, Dániel wrote: > Wow, thanks for this... For some reason I always thought that anything VPN > related would require a rooted Android phone to mess with interfaces and > routing, but clearly it doesn't. > It took about 10 minutes to read https://www.openbsd.org/faq/faq17.html and > configure a successful IKEv2 connection from strongSwan on the phone to the > router. > > One more thing, how do I know what IP address my client has gotten? > `ipsecctl(8) -vsa` doesn't show that, and iked(8) output in /var/log/daemon > doesn't either. Right now I'm pinging my router from my phone and tcpdump-ing > the enc0 interface for icmp packets :) > > Dani > > ‐‐‐ Original Message ‐‐‐ > On Monday, 1 July 2019 19:34, Stuart Henderson s...@spacehopper.org wrote: > > > On 2019-06-30, Lévai Dániel l...@ecentrum.hu wrote: > > > > > I know (saw) this has come up numerous times, and someone has been > > > successful, others weren't. I thought I'd try this out myself, and not > > > surprisingly it wasn't successful :) > > > I've been using these howtos [1] -- I know these can be outdated and/or > > > simply wrong, I just wanted to get the general idea on how to tackle this. > > > I've made it through a couple of hurdles but now I'm stuck and thought > > > I'd ask some questions here. > > > > L2TP+IPsec can be made to work, but to be perfectly honest, unless you > > have a special reason (e.g. need to run this on a box which is also > > doing other tunnels which have to be IKEv1), then I would switch to > > IKEv2/iked and strongswan on Android (or the built-in client on Windows > > or iOS), it is fast to connect and generally much more pleasant to use... > > (I still use IKEv1/isakmpd for lan-to-lan tunnels but now try to avoid > > it for standard "roaming client" type connections). publickey - leva@ecentrum.hu - 0x66E1F716.asc Description: application/pgp-keys
Re: umsm: sparc64
On 2019-06-29, Kihaguru Gathura wrote: > Hello, > > umsm is not being detected on this machine for Huawei E303 modem. Only > interface 0 and 1 which are both umass are detected. interface 2 is > umsm but not active please see boot message. Try adding umsm to /sys/arch/sparc64/conf/GENERIC and build a new kernel. If it works ok, report back, maybe we can add it to the standard kernel. Index: GENERIC === RCS file: /cvs/src/sys/arch/sparc64/conf/GENERIC,v retrieving revision 1.312 diff -u -p -r1.312 GENERIC --- GENERIC 11 Jun 2019 01:35:55 - 1.312 +++ GENERIC 2 Jul 2019 09:03:35 - @@ -205,6 +205,8 @@ uipaq* at uhub?# iPAQ serial adapter ucom* at uipaq? uchcom*at uhub?# WinChipHead CH341/340 serial ucom* at uchcom? +umsm* at uhub?# Qualcomm MSM EVDO +ucom* at umsm? uaudio* at uhub? # USB Audio audio* at uaudio? umidi* at uhub?# USB MIDI
Re: 6.5 pkg_add "Fatal error: Can't write session into tmp directory"
On 2019-06-30, Jonathan Thornburg wrote: > I have 6.5/i386 installed on a PC Engines alix board (hostname 'sodium'), > acting as a home firewall and router. I'd like to install some packages > the firewall it to make system adminstration easier. So... I downloaded > the appropriate 6./i386 packages from a nearby OpenBSD mirror, ssh-ed them > to /tmp on the firewall, and then (logged into the firewall as root) tried > to pkg_add them. Alas, pkg_add failed with an error message about being > unable to write into a temp directory: > > sodium# pkg_add -vv tcsh-6.20.00p1-static.tgz > Fatal error: Can't write session into tmp directory >at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 1025. > sodium# > > I've checked that the firewall has adequate free memory & swap space, > that all the obviously-relevant filesystems are mounted read-write and > have free inodes and disk space, and that 'touch foo' can create a new > file in each of /tmp, /var/tmp, and /usr/tmp. > > Is there something obvious I'm overlooked here? A Fine Man Page I should > be rereading before I start hacking debug prints into the pkg_add (perl) > source code? Chances are you're temporarily out of space in /tmp during the run, but don't see it because the files are cleaned up on exit. I think you would be better off merging /tmp and /usr/tmp into a single slightly larger fs (or just use a partition on wd0 for tmp - alixes don't really have enough RAM to throw ~half of it into a ramdisk). Running under ktrace may give some clues. Try "ktrace -Bi pkg_add (...)". The file is likely to be large so maybe cd /usr/obj first, or use ktrace -f. Use kdump to see the plaintext version, which will be even larger, you might want to "kdump | gzip -1 > kdump.txt.gz" and copy it to another system to read it in an editor. Search backwards from the end of the file for part of the text in the error message, then work backwards. > Further information (cut-and-pasted from ssh session on the firewall): > > sodium# uname -a > OpenBSD sodium.bkis-orchard.net 6.5 GENERIC#1 i386 > sodium# df -hi > Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted > on > /dev/wd0a 378M 47.7M311M13%1771 47379 4% / > mfs:54350 62.9M2.0M 57.7M 3% 88182 0% /tmp > /dev/wd0e 677M 15.1M628M 2% 352 87710 0% /var > /dev/wd0f 1.5G698M734M49% 16248 191622 8% /usr > mfs:42325 62.9M2.0K 59.7M 0% 18189 0% /usr/tmp > /dev/wd0g 516M138M352M28%8980 5860213% > /usr/X11R6 > /dev/wd0h 1.7G218K1.6G 0% 110 233744 0% > /usr/local > /dev/wd0j 5.1G2.0K4.8G 0% 1 701565 0% /usr/obj > /dev/wd0i 1.3G2.0K1.3G 0% 1 181885 0% /usr/src > sodium# cat /etc/fstab > 5fd63b50b0c6cb1d.a /ffs rw,softdep,noatime 1 1 > 5fd63b50b0c6cb1d.d /tmp mfs rw,async,nodev,nosuid,-s=64m0 0 > 5fd63b50b0c6cb1d.e /var ffs rw,softdep,noatime,nodev,nosuid 1 2 > 5fd63b50b0c6cb1d.f /usr ffs rw,softdep,noatime,nodev1 2 > 5fd63b50b0c6cb1d.d /usr/tmp mfs rw,async,nodev,nosuid,-s=64m0 0 > 5fd63b50b0c6cb1d.g /usr/X11R6 ffs rw,softdep,noatime,nodev1 2 > 5fd63b50b0c6cb1d.h /usr/local ffs rw,softdep,noatime,wxallowed,nodev 1 2 > 5fd63b50b0c6cb1d.j /usr/obj ffs rw,softdep,noatime,nodev,nosuid 1 2 > 5fd63b50b0c6cb1d.i /usr/src ffs rw,softdep,noatime,nodev,nosuid 1 2 > sodium# top|head > load averages: 0.08, 0.02, 0.01sodium.bkis-orchard.net 13:12:00 > 52 processes: 1 running, 50 idle, 1 on processor up 14 days, 5:21 > CPU: 0.1% user, 0.0% nice, 0.3% sys, 0.0% spin, 0.3% intr, 99.3% idle > Memory: Real: 35M/110M act/tot Free: 127M Cache: 46M Swap: 0K/548M > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND > 59735 root 1000K 19M sleep bored44:53 0.44% softnet > 65312 root -2200K 19M sleep - 339.9H 0.00% idle0 > 57981 root 1000K 19M sleep bored 7:56 0.00% sensors > 39371 _unbound 20 12M 10M sleep kqread1:33 0.00% unbound > sodium# cd /tmp > sodium# ls -l > total 4144 > drwxrwxrwt 2 root wheel 512 Jun 16 07:51 .ICE-unix > drwxrwxrwt 2 root wheel 512 Jun 16 07:51 .X11-unix > -rw-r--r-- 1 root wheel 1499861 Jun 30 12:31 lynx-2.8.9rel1.tgz > drwxr-xr-x 2 root wheel 512 Jun 16 07:51 sndio > -rw-r--r-- 1 root wheel 564428 Jun 30 12:31 tcsh-6.20.00p1-static.tgz > drwxrwxrwt 2 root wheel 512 Jun 30 12:33 vi.recover > sodium# > sodium# pkg_info > sodium# > sodium# which pkg_add > /usr/sbin/pkg_add > sodium# pkg_add -vv tcsh-6.20.00p1-static.tgz > Fatal error: Can't write
Re: Future of X.org?
Tue, 02 Jul 2019 11:19:17 +0300 cho...@jtan.com > > Matthew Worthless thread, worthless comments, worthless Matthew. STOP spamming.
Bypass doas password check with chroot
This isn't a bug per se, more of an incongruity in how security-centric tools work wrt root, specifically doas and chroot/su/other: joe@drogo$ doas -s drogo# doas -u chohag -s doas (root@drogo) password: doas: Authorization failed drogo# chroot -u chohag / drogo$ ^D drogo# su -l chohag drogo$ ^D Obviously a little one-liner or tiny C app could achieve the same result too. I assume this is more or less known, since each tool is working to its designed spec, so is the above ultimately the desired behaviour? Should doas ask even for root's password while myriad other ways of obtaining any user ID do and probably always will exist? On some servers root doesn't have a password. Matthew
Re: OT: hardware war with manufacturers (espionage claims)
On Tue, 2 Jul 2019 10:07:59 +0300 Mihai Popescu wrote: > Hello, > > I keep finding articles about some government bans against some > hardware manufacturers related to some backdoor for espionage. I know > this is an old talk. Most China manufacturers are under the search: > Huawei, ZTE, Lenovo, etc. It seems painfully obvious what's driving all the bans and vilification of Chinese hardware and software is that the USA wants exclusive rights to spy on you and won't tolerate any competition. Does anybody think maybe the reason Google and Facebook don't pay taxes anywhere might have something to do with what they do with all that info they collect? Is the "new" talk about USA banning any meaningful encryption proof of how seriously they take security and privacy? > What do you think and do when using OpenBSD on this kind of hardware? Lemote boxes are kinda neat but they're not the fastest in the world. It beats the hell out of the alternatives if you can live with the limitations. > Do you prefer Dell, HP and Fujitsu? Your only choice is probably to pick the least objectionable entity to spy on you. If you buy Intel you know you're getting broken, insecure crap no matter whose box it comes in. Sure it runs fast, but... in that case everybody is going to spy on you. /jl
Re: Future of X.org?
li...@wrant.com writes: > Tue, 02 Jul 2019 08:40:35 +0300 cho...@jtan.com > > > > Also I don't need to fix your email system's inability to classify spam. > > YOUR mail server reputation is negative, fix your setup.. STOP spamming. IWFM Matthew ps. Two dots *and* two spaces? Try harder.
Re: Future of X.org?
Tue, 02 Jul 2019 08:40:35 +0300 cho...@jtan.com > > Also I don't need to fix your email system's inability to classify spam. YOUR mail server reputation is negative, fix your setup.. STOP spamming. > Matthew >
OT: hardware war with manufacturers (espionage claims)
Hello, I keep finding articles about some government bans against some hardware manufacturers related to some backdoor for espionage. I know this is an old talk. Most China manufacturers are under the search: Huawei, ZTE, Lenovo, etc. What do you think and do when using OpenBSD on this kind of hardware? Do you prefer Dell, HP and Fujitsu? Is it just a marketing hype? Thank you.
Re: Future of X.org?
li...@wrant.com writes: > You're misreading something, or talking to yourself, making corrections. > Your emails ended up in the spam twice so far, do something about that.. Two dots again? We've been over this. > Your emails came in as spam twice so far, maybe do something about that? Get it together. It's just counting. Also I don't need to fix your email system's inability to classify spam. Matthew
