Re: Nobody said it yet...
Better late than never, Happy birthday and all the appreciation to the developers and community of this amazing OpenBSD’s culture and philosophy around it! > El 18 oct 2019, a la(s) 21:03, Theo de Raadt escribió: > > STeve Andre' wrote: > >> Happy birthday to OpenBSD! > > It forgot. > > In my mind, I've been at this a lot longer since I was also initial > NetBSD. > > > >
Thank you OpenBSD!
Because of your high security standards, my distro has adopted LibreSSL and Xenocara. In the future it plans to also adopt sndio instead of that pulse garbage. I hope OpenBSD lasts a very, long, long time, not just for this, but because you guys take security very seriously.
Re: Nobody said it yet...
STeve Andre' wrote: > Happy birthday to OpenBSD! It forgot. In my mind, I've been at this a lot longer since I was also initial NetBSD.
Re: Nobody said it yet...
On Fri, Oct 18, 2019, 6:22 PM STeve Andre' wrote: > Happy birthday to OpenBSD! > Here, here. Have a great weekend to all the developers, contributors, and users of the project.
Nobody said it yet...
Happy birthday to OpenBSD!
Re: Requesting vi tips
On 2019-10-18, Nam Nguyen wrote: >> Since 'q' is unused in nvi, I have this in my .nexrc: >> map q !}fmt > > I just wanted to add that you can Ctrl-v Enter to produce the ^M at the end. > This way it inputs and executes the command for you. > > It could be like this if you want it to press Enter for you: > map q !}fmt^M And upon closer inspection I see that's what I actually have in my .nexrc; less(1) didn't show the ^M and I had forgotten about it. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: mpd: failed to open default sndio device
On Fri, Oct 18, 2019 at 02:34:48PM +0300, Кирилл wrote: > Hello. > After install mpd: > $ mpc play > Antimatter - Over Your Shoulder > [paused] #1/7 0:00/4:41 (0%) > volume:100% repeat: off random: off single: off consume: off > ERROR: Failed to open "sndio output" (sndio); Failed to open default sndio > device > This is most probably caused by mpd running as a different user as you, in turn not having access to your ~/.sndio/cookie, needed to connect to sndiod while you're using it. You could either run mpd as your user-id or give the _mpd user access to your audio session by copying your ~/.sndio/cookie into _mpd's home directory.
Re: Requesting vi tips
On 2019-10-18, Christian Weisgerber wrote: > On 2019-10-18, cho...@jtan.com wrote: > >> I didn't know [how] ! took movement commands. Thanks. I'll have a play >> with that one. >> >> It's not quite M-q (it's M not C) but I'm using vi after all. > > Since 'q' is unused in nvi, I have this in my .nexrc: > > map q !}fmt > > Close enough to emacs's M-q. > I just wanted to add that you can Ctrl-v Enter to produce the ^M at the end. This way it inputs and executes the command for you. It could be like this if you want it to press Enter for you: map q !}fmt^M I like joining lines before using fmt on a single line, hence the '.'. I had forgotten about the '}' motion and may need to incorporate that. I also did not know that the ':' can be omitted. I currently use: map gq :.!fmt -w 72^M map q0 :.!fmt -w 77^M map q1 :.!fmt -w 69^M map q2 :.!fmt -w 61^M map q3 :.!fmt -w 53^M map qq :.!fmt -w 80^M
Re: vi(1) and ranges
I for one am currently not interested in looking at your work (assuming there's going to be any) No, there is not going to be any. I don't like what you are encouraging. Bye.
Re: vi(1) and ranges
On 10/18/19 7:23 PM, adr wrote: > Going through the vi man page (and the one of editors/nvi) looking > for some hint about '|' in maps some days before, I noticed that > the ranges aren't described. > > If the developers are interested I can add the description from > the nvi reference manual, next to the description of count, motion, > etc. > > regards, > adr > First you insult someone who says he's happy with a developers answer and then you send this email without any contribution to basically the wrong list. You might want to learn from the saying "You catch more flies with honey than vinegar". I for one am currently not interested in looking at your work (assuming there's going to be any) if that's how you present yourself to the community. martijn@
vi(1) and ranges
Going through the vi man page (and the one of editors/nvi) looking for some hint about '|' in maps some days before, I noticed that the ranges aren't described. If the developers are interested I can add the description from the nvi reference manual, next to the description of count, motion, etc. regards, adr
Re: Requesting vi tips
On Fri, 18 Oct 2019, cho...@jtan.com wrote: For the record, I have a finite amount of neurons with a correspondingly finite amount of synapses. There is only so much even I can hold in my head. Asking actual humans for access to the particular minutiae they happen to have itemised to the nth unnecessary degree for obscure factoids that might be found helpful is a valid strategy. That is the dumbest thing I've ever heard. Turn your computer in. You are incapable of handling one. I told you, is so easy.
Re: Requesting vi tips
adr writes: > You see, is so easy to be an asshole. You're telling me? I know I'm not particularly active on OpenBSD's mailing lists but I've certainly been around. For the record, I have a finite amount of neurons with a correspondingly finite amount of synapses. There is only so much even I can hold in my head. Asking actual humans for access to the particular minutiae they happen to have itemised to the nth unnecessary degree for obscure factoids that might be found helpful is a valid strategy. Matthew
Re: On blindly running code
On Fri, Oct 18, 2019 at 01:20:33PM +0100, cho...@jtan.com wrote: Frank Beuth writes: On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote: >Virtualisation is not a panacea. I have managed to achieve data loss through destructi ve actions taken within a "safe" virtualised sandbox. How did you manage that feat? Basically assuming "safe" then taking actions to subvert that, namely mounting an SMB share within the VM. rm(1) does not discriminate. My own fault obviously but it's notable that the "virtual environment == safe" assumption was shattered so effectively, so easily, and by actions which in most circumstances would be benign. Poking holes in parachutes has been known to impair their function, yes...
Re: On blindly running code
Raul Miller writes: > My mental model of computer security often approximates putting a bank > vault door on a picket fence (and maybe setting up a sniper to stop > people from climbing over the door). But in layers. One of them will work right? It's defense^Wobscurity in depth. > Doesn't mean that the exercises weren't worthwhile, but in my opinion > we put far too little effort into making people comprehend what's > going on. > (Not entirely true, and raspberry pi/arduino I think it's very true. Case in point is ssl/pkc. For a while I refused to believe that I understood public key cryptography because it was so incredibly simple and yet all the documentation I'd seen up to that point had been impenetrable, contradictory, incomplete or some mixture of the three. I can count on one hand the number of people I've worked with who understood it rather than relying on copy pasta. Hence LetsEncrypt now exists. The lack of understanding is tangible and worrying. > but I sometimes worry about the lack of > focus on physical and electronic abstraction layers.) Already lost. There's nothing real about an abstraction layer. We can't reconcile with them in the real world. Instead we ascribe human-like attributes to automota which can only mock the appearance without any of the substance. "Smart" devices are smart like a parrot that's learned how the crackers come and just as vindictive yet they have in less than half a generation become embedded into our lives and societies as though they are godlike in their prescience. They now drive our death machines around. We have machines with the intelligence of a parrot and the attention span of a toddler driving multi-tonne killing machines at upwards of 70mph. That's insane. Abstraction layers are all very well when developing algorithms but when the rubber hits the road the CPU's gonna do what the CPU's gonna do and if you don't know what it can, will and does do then no abstraction layer is going to help you. We need to trust the machines like the badly-treated rottweiler who's muzzle we can't remove and who's looking at our children hungrily, not like the adorable harmless puppies the devices try to act as and who's place they currently occupy. That is the fundamental flaw in our collective security model. I handle it by understanding the technology so I can work around the holes. Those who can't or won't need a better model than "aww! cute!" Anyway I didn't mean for this to turn into a rant so I'm done. Well I did because I started it as one but it was meant to be a rant about administrators and developers who don't understand what they're doing but do it anyway and not the sorry state of IT security around the world and how it's turning society into the worst possible bastard child of George Orwell and Aldous Huxley. That would require far more space than this mailing list allows to do it justice. > recovering backups (I've seen backup systems which never worked where A pile of data may look like a backup but without a proven recovery strategy it's just a pile of data. Matthew
Re: Requesting vi tips
On Fri, Oct 18, 2019 at 03:39:41PM BST, cho...@jtan.com wrote: > Raf Czlonka writes: > > On Fri, Oct 18, 2019 at 03:12:37PM BST, cho...@jtan.com wrote: > > Is this what you had in mind? > > > > set editor="EXINIT='set wraplen=72' /usr/bin/vi" I forgot to mention - this is the line in my muttrc(5). > I'm not sure that I'm happy with it doing it mid-insert. I'd prefer an > explicit action or insert mode itself being adapted so that it includes > a final reformat (ie. when I press escape (if the appropriate flag is > enabled)). Then I clearly misunderstood what you meant. > Also it has the fault that if, say, the 4th character of a word causes a > line break, then reducing that word to less than 4 characters doesn't > remove it (although the newline can be deleted as though it were > inserted as usual, which is good). > > Matthew > As others have already mentioned - fmt(1) from base... or par(1) from ports. Regards, Raf
Re: Requesting vi tips
I didn't know [how] ! took movement commands. Thanks. I'll have a play with that one. It's not quite M-q (it's M not C) but I'm using vi after all. Matthew The entire man page is 1332 widely-spaced-out lines of clear, simple formated text. Including comments. Read the damn thing. You see, is so easy to be an asshole. adr.
Re: Requesting vi tips
On 2019-10-18, cho...@jtan.com wrote: > I didn't know [how] ! took movement commands. Thanks. I'll have a play > with that one. > > It's not quite M-q (it's M not C) but I'm using vi after all. Since 'q' is unused in nvi, I have this in my .nexrc: map q !}fmt Close enough to emacs's M-q. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Requesting vi tips
On Fri, Oct 18, 2019 at 03:12:37PM +0100, cho...@jtan.com wrote: Alternatively is there something that would make vi do it on the fly, or something akin to emacs' C-q or vim's gq. Although I appreciate the fact that vi doesn't try to be clever. 1) select all text in visual mode (e.g with V, then gg) 2) :!fmt -w 72 disclaimer: vi is aliased to vim on my system so apologies if this doesn't work
Mugs
Hi, In the past I've bought mugs from OpenBSDStore.com. The site now points to the main OpenBSD.org website and the DNS SOA indicates it may have been doing so for 7 days. Is there a story to this? Where should we get fan items in the future? Regards, -peter
Re: On blindly running code
On Fri, Oct 18, 2019 at 8:23 AM wrote: > That's not to even start on the fact that it's little more than process > switching and virtual memory on steroids, so the extra seperation on top of > what the OS already provides is little more than smoke and mirrors. My mental model of computer security often approximates putting a bank vault door on a picket fence (and maybe setting up a sniper to stop people from climbing over the door). Doesn't mean that the exercises weren't worthwhile, but in my opinion we put far too little effort into making people comprehend what's going on. (Not entirely true, and raspberry pi/arduino communities for example have been putting in some useful efforts. OpenBSD is no slouch, either, but I sometimes worry about the lack of focus on physical and electronic abstraction layers.) In my opinion, good computer security typically involves multiple pieces of independent hardware (and good practices such as making and recovering backups (I've seen backup systems which never worked where that wasn't detected until they were needed because no one thought to test the backups (... then again, I've also seen multiple redundant systems taken out by a single stroke of lightning because they were in the same room... ))). Anyways, we do what we can, and no security can be perfect, but also the existence of flaws is not, in and of itself, a reason to give up. Better to classify that as "room for improvement". (Also, sad to say, but: smoke and mirrors can sometimes be useful -- if you have enough other measures in place.) Thanks, -- Raul
about vim objects (Re: Requesting vi tips)
hello,
> I didn't know [how] ! took movement commands. Thanks. I'll have a play
> with that one.
almost related: in addition to the motions, vim has a notion of objects
:h objects
so you can easily filter a complete paragraph with
!ap
fmt -w72
in visual mode, you can select nested objects by adding a selection
{ // the whole code
{ // the object i want to select
{
you are here
}
}
}
you can select the expected object using va{a{
HTH
marc
Re: Requesting vi tips
On Fri, Oct 18, 2019 at 03:12:37PM +0100, cho...@jtan.com wrote: > but I wonder if there's something that can correctly parse the > whole email and format the entire thing en masse :%!fmt -s
Re: Softraid data recovery
> -Original Message- > From: Aaron Mason > Sent: Monday, October 14, 2019 7:13 PM > To: Steven Surdock > Cc: misc@openbsd.org > Subject: Re: Softraid data recovery > > On Tue, Oct 15, 2019 at 7:34 AM Steven Surdock net.com> wrote: > > ... > > > > How can I recover as much data as possible off the failed RAID array. > > If I recreate the array, "bioctl -c 1 -l /dev/wd0d,/dev/wd1d > softraid0", will the existing data be preserved? > > ... Based on the information found here: https://marc.info/?l=openbsd-misc=136553269631163=2 I was successfully able to create a disk image off the failing drive. $ dd if=/dev/wd0d of=raid.img conv=noerror,sync skip=528 $ vnconfig vnd0 raid.img $ fsck /dev/vnd0a $ fsck /dev/vnd0d $ mount /dev/vnd0a /home/public
Re: Requesting vi tips
Claudio Jeker writes:
> set wl=72 will limit the line lenght to around 72. Additionally you
> can use !fmt with movement chars to reformat sections. I use !{fmt
> or {!}fmt frequently to reformat the paragraph I'm in.
I didn't know [how] ! took movement commands. Thanks. I'll have a play
with that one.
It's not quite M-q (it's M not C) but I'm using vi after all.
Matthew
Re: Requesting vi tips
Raf Czlonka writes: > On Fri, Oct 18, 2019 at 03:12:37PM BST, cho...@jtan.com wrote: > Is this what you had in mind? > > set editor="EXINIT='set wraplen=72' /usr/bin/vi" I'm not sure that I'm happy with it doing it mid-insert. I'd prefer an explicit action or insert mode itself being adapted so that it includes a final reformat (ie. when I press escape (if the appropriate flag is enabled)). Also it has the fault that if, say, the 4th character of a word causes a line break, then reducing that word to less than 4 characters doesn't remove it (although the newline can be deleted as though it were inserted as usual, which is good). Matthew
Re: Requesting vi tips
On Fri, Oct 18, 2019 at 03:12:37PM +0100, cho...@jtan.com wrote:
> OK this has started to get on my nerves now.
>
> I use vi to enter emails despite using evil emacs for development and
> other general editing. Rather than linking them together (they're on
> seperate machines) to enter emails in emacs I'd rather figure out
> something interesting about vi.
>
> At the moment I limit lines to 72 characters through a laborious process
> of finding the appropriate space character myself and replacing it with
> a ^M. Obviously nonsense which is why I sometimes don't bother. (Sorry).
>
> I know about fmt and could easily concoct the pipeline to format each
> paragraph but I wonder if there's something that can correctly parse the
> whole email and format the entire thing en masse without me writing what
> would undoubtedly be Yet Another Poor Implementation.
>
> Alternatively is there something that would make vi do it on the fly, or
> something akin to emacs' C-q or vim's gq. Although I appreciate the fact
> that vi doesn't try to be clever.
>
set wl=72 will limit the line lenght to around 72. Additionally you
can use !fmt with movement chars to reformat sections. I use !{fmt
or {!}fmt frequently to reformat the paragraph I'm in.
--
:wq Claudio
Re: Requesting vi tips
On Fri, Oct 18, 2019 at 03:12:37PM BST, cho...@jtan.com wrote: > OK this has started to get on my nerves now. > > I use vi to enter emails despite using evil emacs for development and > other general editing. Rather than linking them together (they're on > seperate machines) to enter emails in emacs I'd rather figure out > something interesting about vi. > > At the moment I limit lines to 72 characters through a laborious process > of finding the appropriate space character myself and replacing it with > a ^M. Obviously nonsense which is why I sometimes don't bother. (Sorry). > > I know about fmt and could easily concoct the pipeline to format each > paragraph but I wonder if there's something that can correctly parse the > whole email and format the entire thing en masse without me writing what > would undoubtedly be Yet Another Poor Implementation. > > Alternatively is there something that would make vi do it on the fly, or > something akin to emacs' C-q or vim's gq. Although I appreciate the fact > that vi doesn't try to be clever. > > Thanks, > > Matthew > Is this what you had in mind? set editor="EXINIT='set wraplen=72' /usr/bin/vi" Regards, Raf
Re: remaining references to xman (RIP)
Hi Alfred, Alfred Morgan wrote on Thu, Oct 17, 2019 at 11:49:35PM -0700: > Here are some leftover references to xman > I found after the upgrade to 6.6. [...] > /usr/X11R6/man/man1/appres.1: > /usr/X11R6/man/man1/editres.1: > /usr/X11R6/man/man1/fvwm.1: > /usr/X11R6/man/man1/xmore.1: We'll do nothing about that. Those are all third-party manual pages and making minor changes to them has no effect but to make Matthieu's life harder when updating these tools. In third-party manuals, references to other third-party tools that aren't included in OpenBSD do not cause any real poblem. You can't expect third-party manuals to be of the same quality as OpenBSD base system manuals in the first place. Yours, Ingo
Requesting vi tips
OK this has started to get on my nerves now. I use vi to enter emails despite using evil emacs for development and other general editing. Rather than linking them together (they're on seperate machines) to enter emails in emacs I'd rather figure out something interesting about vi. At the moment I limit lines to 72 characters through a laborious process of finding the appropriate space character myself and replacing it with a ^M. Obviously nonsense which is why I sometimes don't bother. (Sorry). I know about fmt and could easily concoct the pipeline to format each paragraph but I wonder if there's something that can correctly parse the whole email and format the entire thing en masse without me writing what would undoubtedly be Yet Another Poor Implementation. Alternatively is there something that would make vi do it on the fly, or something akin to emacs' C-q or vim's gq. Although I appreciate the fact that vi doesn't try to be clever. Thanks, Matthew
Re: On blindly running code
On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote: Virtualisation is not a panacea. I have managed to achieve data loss through destructive actions taken within a "safe" virtualised sandbox. How did you manage that feat? If the only thing that can demonstrate what a piece of code does is to run it blindly, rather than to work it out by reading and study, then the code is faulty and should be replaced. I expect the code I use to be in this state before I will even begin to trust its documentation because if the developer doesn't understand what it does how can his explanation be at all enlightening? Executing code in a test environment should only be to *verify* the assumptions and calculations you have *already made*. In the world of malware analysis, running code blindly (in a virtual machine) in order to figure out what it does (by comparing "before" and "after" snapshots) is standard operating procedure. (standard operating procedure doesn't necessarily make it a good idea, but it is what it is)
Re: On blindly running code
Frank Beuth writes: > On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote: > >Virtualisation is not a panacea. I have managed to achieve data loss through > >destructi > ve actions taken within a "safe" virtualised sandbox. > > How did you manage that feat? Basically assuming "safe" then taking actions to subvert that, namely mounting an SMB share within the VM. rm(1) does not discriminate. My own fault obviously but it's notable that the "virtual environment == safe" assumption was shattered so effectively, so easily, and by actions which in most circumstances would be benign. That's not to even start on the fact that it's little more than process switching and virtual memory on steroids, so the extra seperation on top of what the OS already provides is little more than smoke and mirrors. > In the world of malware analysis, running code blindly (in a virtual > machine) in order to figure out what it does (by comparing "before" and > "after" snapshots) is standard operating procedure. > > (standard operating procedure doesn't necessarily make it a good idea, > but it is what it is) There's something to be said for it if your constraints are sound. I doubt a half-decent malware analyst isn't both extremely paranoid about their testing gig and still won't run code without at least a cursory glance at the disassembly. Consider that without access to the source code the game changes considerably. Matthew
Re: xauth segfault
Well it seems I was wrong and this is a common-or-garden bug. Specifically,
from xauth/gethost.c, starting at line 199:
#ifdef HAVE_STRLCPY
strlcpy(path, fulldpyname, sizeof(path));
#else
strncpy(path, fulldpyname, sizeof(path));
path[sizeof(path) - 1] = '\0';
#endif
if (0 == stat(path, )) {
is_path_to_socket = 1;
} else {
char *dot = strrchr(path, '.');
if (dot) {
*dot = '\0';
/* screen = atoi(dot + 1); */
if (0 == stat(path, )) {
is_path_to_socket = 1;
}
}
}
fulldpyname is "drogo.datum:0" and there is a directory in $HOME named "drogo".
is_path_to_socket then gets set to 1 and the strlcpy(buf, strrchr(fulldpyname,
'/') + 1, sizeof(buf)) a few lines down passes 0x01 as the source pointer to
strlcpy.
I don't know if it is or should be required that $DISPLAY pointing to a unix
socket can be a relative path, but if they must be absolute then this patch
enforces that (and fixes my segfault, though by making the same assumption that
$DISPLAY will include a '/' in two places).
Matthew
Index: parsedpy.c
===
RCS file: /home/flask/src/openbsd/cvsync/xenocara/app/xauth/parsedpy.c,v
retrieving revision 1.5
diff -u -p -r1.5 parsedpy.c
--- parsedpy.c 19 Feb 2017 17:30:58 - 1.5
+++ parsedpy.c 18 Oct 2019 12:02:34 -
@@ -177,7 +177,7 @@ parse_displayname (const char *displayna
#endif
if (0 == stat(path, )) {
family = FamilyLocal;
-} else {
+} else if (strrchr(path, '/') == path) { /* I'm not sure this is the
best way to test for this */
char *dot = strrchr(path, '.');
if (dot) {
*dot = '\0';
mpd: failed to open default sndio device
Hello. After install mpd: $ mpc play Antimatter - Over Your Shoulder [paused] #1/7 0:00/4:41 (0%) volume:100% repeat: off random: off single: off consume: off ERROR: Failed to open "sndio output" (sndio); Failed to open default sndio device dmesg: https://pastebin.com/y5A81Cqh
Re: Encrypting my keydisk
> > On Wednesday, October 16, 2019 11:06 PM, List wrote: > >> I was wondering if there is a reason for the lack of keydisk encryption. $ man bioctl # bioctl -h -v -c C ...
Re: On blindly running code
Shane Lazarus writes: > Heya > > My own experience agrees with you with regards to any system in production. > > However, it is also my experience that nothing demonstrates the > difference between what should happen and what actually occurs better > than running the code and seeing the aftermath. > > Thankfully, virtualisation makes things much simpler these days, and > running through everything on a clone prior to even considering steps > on the production system is consequently highly recommended. Virtualisation is not a panacea. I have managed to achieve data loss through destructive actions taken within a "safe" virtualised sandbox. If the only thing that can demonstrate what a piece of code does is to run it blindly, rather than to work it out by reading and study, then the code is faulty and should be replaced. I expect the code I use to be in this state before I will even begin to trust its documentation because if the developer doesn't understand what it does how can his explanation be at all enlightening? Executing code in a test environment should only be to *verify* the assumptions and calculations you have *already made*. A development, test or other environment is as much "in production" as any other, because if they somehow become unavailable then someone, somewhere is losing money. And if you took it down because you didn't know what code you were executing was going to do then it's your fault. Matthew
Re: On blindly running code
Heya My own experience agrees with you with regards to any system in production. However, it is also my experience that nothing demonstrates the difference between what should happen and what actually occurs better than running the code and seeing the aftermath. Thankfully, virtualisation makes things much simpler these days, and running through everything on a clone prior to even considering steps on the production system is consequently highly recommended. Shane On Fri, Oct 18, 2019 at 11:19 PM wrote: > > With regards to recent discussion, here is a little anecdote that came out of > the 6.5 to 6.6 upgrade. > > On one machine I run bitlbee, an IRC:IM gateway. After upgrading all the > ports it left suggestions in the form of copy pasta commands to run to > complete the upgrade process, as it does. One of these was rm -rf > /var/bitlbee/*. > > Had I been so stupid as to just run the command, or if the hyper-complicated > upgrade script required to support every possibility included a single > mistake, all of the settings to connect to my IM accounts (currently > constituting the only place some ancient passwords are guaranteed to be > saved) would have been lost, where in fact what I had to do about those files > was absolutely nothing. > > There is no fault here. The wording is something like 'you should also run', > clearly not 'this is absolutely essential' (because if it was, why wasn't it > done already or documented better?), which couldn't make it any clearer that > you need to think first why you might want to run that command. > > There are good reasons not to delete user accounts when removing the software > that uses them, for example, which is why pkg_delete doesn't but suggests > that you might want to (with copy pasta for your convenience). > > It's my responsibility to understand the software I'm running, how it works > and what effect the things I do will have on it. Nobody would have cried for > me if I'd pasted first and only then realised that I'd lost everything. > > Take responsibility for your own computers or stop using them and buy one of > those Fisher Price remote controlled radio-tracker remote execution vector > iToys that all the kids are playing with these days. > > Matthew > > ps. I do have backups of course. >
On blindly running code
With regards to recent discussion, here is a little anecdote that came out of the 6.5 to 6.6 upgrade. On one machine I run bitlbee, an IRC:IM gateway. After upgrading all the ports it left suggestions in the form of copy pasta commands to run to complete the upgrade process, as it does. One of these was rm -rf /var/bitlbee/*. Had I been so stupid as to just run the command, or if the hyper-complicated upgrade script required to support every possibility included a single mistake, all of the settings to connect to my IM accounts (currently constituting the only place some ancient passwords are guaranteed to be saved) would have been lost, where in fact what I had to do about those files was absolutely nothing. There is no fault here. The wording is something like 'you should also run', clearly not 'this is absolutely essential' (because if it was, why wasn't it done already or documented better?), which couldn't make it any clearer that you need to think first why you might want to run that command. There are good reasons not to delete user accounts when removing the software that uses them, for example, which is why pkg_delete doesn't but suggests that you might want to (with copy pasta for your convenience). It's my responsibility to understand the software I'm running, how it works and what effect the things I do will have on it. Nobody would have cried for me if I'd pasted first and only then realised that I'd lost everything. Take responsibility for your own computers or stop using them and buy one of those Fisher Price remote controlled radio-tracker remote execution vector iToys that all the kids are playing with these days. Matthew ps. I do have backups of course.
Re: NPPPD Server behind a firewall
On Wed, 16 Oct 2019, Stuart Henderson wrote: I would srongly recommend switching to IKEv2 if you can, it is far easier to come up with a config that still gives decent crypto with mixed client platforms. (Internal client on Apple OS and non-ancient Windows - strongswan on Android/Linux). I do not disagree. I just need to move an existing NPPPD to behind a firewall in the short term that serves several iPads and Windows PCs. Once I have the move done, I want to move expand to IKEv2. I was also under the impression that IKEv2 was faster. The IPsec side should be ok as long as everything supports nat-t (not unusual). I am still stuck and will try some new things on Monday. Regards - Damian
Re: Strong Host Model in OpenBSD network stack
On Thu, Oct 17, 2019 at 09:50:28PM +0200, Bastian Kanbach wrote:
> Hello,
>
> recently I was performing some checks that relate to the "Strong Host
> Model" and "Weak Host Model", and I noticed that OpenBSD was behaving
> different than I expected. I always assumed that the network stack of
> OpenBSD was following the "Strong Host Model", but I might be wrong with
> that:
OpenBSD does follow the "Weak Host Model". Has always been like that.
> Basically the Strong Host Model means that the network stack "accepts
> locally destined packets if the destination IP address in the packet
> matches an IP address assigned to the network interface on which the
> packet was received."
>
> FreeBSD and NetBSD have a sysctl property for this, called
> "net.inet.ip.check_interface", which defaults to 0 (Weak Host Model).
> However for OpenBSD I haven't seen such a property at all.
>
>
> Basically my setup consisted of the following virtual machines and
> network interfaces (IP-Forwarding disabled):
>
>
> VM 1 (OpenBSD 6.5):
>
> em0: 192.168.100.1/24 ("Internal Network")
>
> em1: 10.0.0.97/24 ("NAT")
>
>
> VM 2 (Ubuntu Server 18.10):
>
> ens33: 192.168.100.2/24 ("Internal Network")
>
>
>
>
>
> As expected, ens33 of VM2 can communicate with em0 of VM1, since both
> interfaces are associated with the same Virtualbox network, and both IP
> addresses are part of the same /24 subnet.
>
> ens33 of VM2 can't directly communicate with em1 of VM1, since the IP
> addresses are part of different subnets and no routes were configured.
>
>
> Then I performed 2 tests:
>
>
> Test 1:
>
> Perform an arping from ens33/VM2 (192.168.100.2) to 10.0.0.97 (VM1). The
> packet was NOT answered by VM1.
>
This is a Layer 2 ARP test. Since 10.0.0.97 is not on that interface arp
will not answer. The host model only matters for Layer 3.
>
> Test 2:
>
> Set the following route on VM2: ip r add 10.0.0.0/24 via 192.168.100.1.
> Then send an ICMP echo request to 10.0.0.97 (VM1), originating from
> 192.168.100.2 (VM2). VM1 replied with an ICMP echo reply (with a source
> MAC address of interface em0).
>
>
> While the behaviour of Test 1 indicates that the Strong Host Model is
> followed, Test 2 shows the behaviour of a "Weak Host Model".
No, Test 1 is not the right test for the host model.
> What of both is actually supposed to be the default for OpenBSD? Is
> there any kernel parameter to control these behaviours, like
> net.inet.ip.check_interface for FreeBSD or NetBSD?
We don't have a button and just follow the "Weak Host Model".
You can enforce a strong model per interface with pf(4):
block in on !em0 inet to (em0)
or
block in
pass in on em0 to (em0)
pass in on em1 to (em1)
--
:wq Claudio
remaining references to xman (RIP)
Here are some leftover references to xman I found after the upgrade to 6.6. Mostly examples, mentions, and configs. I think the most significant one is the missing man page that xmore references. /usr/X11R6/man/man1/appres.1: % appres Xman.TopLevelShell.Form xman.topBox.form will list the resources of widgets of xman topBox hierarchy. /usr/X11R6/man/man1/editres.1: For example, xman only creates the widgets for its topbox when it starts up. None of the widgets for the manual page window are created until the user actually clicks on the Manual Page button. If you retrieved xman's widget tree before the the manual page is active, you may wish to refresh the widget tree after the manual page has been displayed. This will allow you to also edit the manual page's resources. /usr/X11R6/man/man1/fvwm.1: When sloppy focus is used as the default focus style, it is nice to make windows in which you do not typically type into (xmag, xman, xgraph, xclock, xbiff, etc) click-to-focus, so that your terminal window doesn't lose focus unnecessarily. ... + "Xman" Exec exec xman ... Style "xman"Icon xman.xpm /usr/X11R6/man/man1/xmore.1: SEE ALSO X11(7), xman(1) -alfred
Re: Strong Host Model in OpenBSD network stack
On Fri, Oct 18, 2019 at 07:21:42AM +0200, Remi Locherer wrote: > On Thu, Oct 17, 2019 at 10:33:41PM -0600, Theo de Raadt wrote: > > > Setting net.inet.ip.check_interface=1 on FreeBSD stopped any ICMP Echo > > > replies immediately. > > > > > > On NetBSD I set net.inet.ip.checkinterface=1 and it showed the same > > > behaviour like FreeBSD. No replies anymore, whenever the "wrong" > > > interface was contacted. > > > > How many users set those variables? > > > > A global seems this is a misguided place to establish such a policy. > > > > If it was good and neccessary for everyone on all interfaces and had no > > downsides, they would have turned it on. But they didn't. > > > > A similar feature "urpf-failed" which is more nuanced is available in > > pf.conf, and you can properly use it on a per-interface basis, also > > selecting to do so based un other per-rule options, rather than having > > a 'global rule'. > > > > Something blocked FreeBSD or NetBSD from turning this into the default. > > What was that reason -- was it too damaging? > > > > (I'm going to assume the people with so-called 'strong' views didn't win > > the battle, and the so-called 'weak' view pervailed, probably because > > the 'strong' option created breakage and prevents the dominant > > operational model of Getting-Shit-Done. That's why I ask how many > > people in real life subscribe the 'strong' view by turning on this > > option in FreeBSD/NetBSD. 3 people or is it 2? In my experience, > > everyone is so busy getting on about their lives they don't flip any > > knobs which don't provide an immediately confirmable and neccessary > > value). > > > > from source port source os source to dest port dest > > This rule applies only to packets with the specified source and > > destination addresses and ports. > > > > Addresses can be specified in CIDR notation (matching > > netblocks), > > as symbolic host names, interface names or interface group > > names, > > or as any of the following keywords: > > > > any Any address. > > no-route Any address which is not currently routable. > > route label Any address matching the given route(8) label. > > self Expands to all addresses assigned to all > > interfaces. > >Any address matching the given table. > > urpf-failed Any source address that fails a unicast reverse > > path > > forwarding (URPF) check, i.e. packets coming in on > > an interface other than that which holds the route > > back to the packet's source address. > > > > Convince us we should change to the strong model, and I'll embrace it. > > > > You won't convince us to make a global which people don't understand... > > > > This "strong" model is a bad fit for routers. > > When this model is needed we have pf (antispoof or urpf-failed). > Alternatively rdomains can be used (put a network interface with management > services on it in a separate rdomain). > The BSD systems and IIRC most unix systems have been following the weak host model. As mentioned the weak model has a lot of benefits. I see no point in changing this. -- :wq Claudio
tar keeps writing after pipe has been closed
Why does tar not stop? It immediately shows the first line and then sits there for over 3 seconds. $ time tar tzf ports.tar.gz | head -1 ports 0m03.29s real 0m04.03s user 0m01.00s system -alfred
