Re: lynx: disable old protocols
On Sat, 2014-07-12 at 23:58 -0700, William Orr wrote: wrt. auditing it, should we send patches here? Or upstream? I'd send them both places, if they apply cleanly to both sets of code. Otherwise, send them here. I'd love to be proven wrong about the maintainers not really giving a shit about the users, and accepting packages which make gopher browsing more secure or improve the code quality would help. BTW, I forgot to ask, where are the exploits for this poor quality code? i.e. if I'm browsing a gopher site with the current Lynx as root, what exactly do I have to stumble upon to get owned? Or is it just a this is ugly in a few places kind of vague feeling by some devs? I have a feeling there aren't any (exploits), but I thought I'd ask anyway. -- Shawn K. Quinn skqu...@rushpost.com
Re: lynx: disable old protocols
On Sun, 2014-07-13 at 01:38 -0600, Theo de Raadt wrote: With your attitude, I beg you to please go run some other operating system. The plan is when the first Bitrig release comes out, I'm done and switch to that. The donations I was going to make to your project later this year? Not anymore. They are either going to Bitrig, or maybe some even to the FSF. Oh, the latter I would love to do especially since you keep trashing Richard Stallman every chance you get, even after the FSF gave you an award. (Did they ever ask for that award back? The FSF is run by a lot of nice people. Maybe they are too nice to have asked for you to return the award, but they should have. The lack of gratitude shown by your ridicule of RMS after getting it is just plain atrocious and casts a black eye on the open source movement you claim to be part of.) By the way, you would not have had BSD source code to hack on without the efforts of RMS. Think about that next time before you insult him. Show a little fucking gratitude for a change. Until then, I'm going to keep a close eye on changes under /usr/src/gnu/usr.bin/lynx and undo them on my own system if it disables useful functionality. It's just outrageous I have to do this to keep things like gopher support. BTW, I still want to see an actual exploit. None of this the code looks shitty vagueness. Look hard enough, you'll find code that looks shitty everywhere. -- Shawn K. Quinn skqu...@rushpost.com OpenBSD: Where do you want to go today?
Re: lynx: disable old protocols
On Sun, 2014-07-13 at 02:01 -0600, Theo de Raadt wrote: Why haven't you left yet Shawn? Because for the moment, I still am an OpenBSD user. And you haven't answered my question why there's been no exploit of this poor quality code (in the entire history of Lynx going back to 1992, no less). It's so easy to look at code and say it's shitty. It's another to prove it. -- Shawn K. Quinn skqu...@rushpost.com
Re: lynx: disable old protocols
On Sun, 2014-07-13 at 02:23 -0600, Theo de Raadt wrote: You demand us to do work? Please leave immediately. No, I'm asking why there's been no exploit, not necessarily for you to write one. In fact, Theo, I'd really rather you not try to write one, since apparently you're averse to the idea of doing so. -- Shawn K. Quinn skqu...@rushpost.com
Re: lynx: disable old protocols
On Fri, 2014-07-11 at 03:03 -0600, Theo de Raadt wrote: If lynx was removed from base, and only available in ports... how many of you would even know of it's existance and use it? Not only would I know of its existence and go install it to use, I would wonder out loud why the hell it's not in base. Furthermore, if it had been intentionally crippled to exclude rare but definitely used protocols like gopher that are part of stock Lynx as released by the current maintainers, I would wonder what kind of whacked out hallucinogenics someone had to have been on to do such a thing. (It's something I'd expect from Firefox developers, but definitely not from OpenBSD maintaners.) If there's a security hole related to gopher or bibp, let's fix it, let's not up and drop support for those protocols because of it. People do use these protocols even in 2014. If it's code bloat, I'd like to know just how much code we're talking about. Unless we're going to try to put Lynx on install media (and I am definitely not suggesting that we do), 1.7 megabytes really isn't all that big (it's actually smaller than ftp). If you have gamesXX.tgz installed and never play them you have no business complaining about bloat on a binary of that size. Looking back over this patch, I see no reason to break telnet support since we still ship a telnet client. (In case anyone brings this up, I see no reason to remove telnet from base either.) Also, there's no good reason I can think of to break rlogin and tn3270 support for the people who have those installed and need to use it. I retract any support I may have indicated. Now, should the upstream remove this support for whatever reason, that's an entirely different can of worms. But if it ain't broke, don't fix it. And from here it looks like it ain't broke. -- Shawn K. Quinn skqu...@rushpost.com
Re: lynx: disable old protocols
On Sat, 2014-07-12 at 06:11 -0500, Shawn K. Quinn wrote: If it's code bloat, I'd like to know just how much code we're talking about. Unless we're going to try to put Lynx on install media (and I am definitely not suggesting that we do), 1.7 megabytes really isn't all that big (it's actually smaller than ftp). If you have gamesXX.tgz installed and never play them you have no business complaining about bloat on a binary of that size. The recent patch which removes bibp support and breaks telnet URLs removes a whopping 8k or so (at least on amd64 here, versus -current from a couple days before). If hard drives still topped out at a gigabyte or less that might be an impressive reduction, but those days are long gone. Taking out dired, gopher, news, and finger only makes a total reduction of some 121k. Again, it might make a difference if your whole hard disk is under a gigabyte. Today, a terabyte or significant fraction thereof is more likely. So, not impressive given what we're losing by saving that small amount of disk space. And this comment: leave gopher, news, and dired in place for now. but we will soon catch up to the security level of internet explorer 7 by removing these too. This is complete bullshit, to the point where I would think it came straight from Microsoft's PR department. There is no way in hell that Lynx was ever as insecure as Internet Explorer 7, much less is today. Lynx, by its very nature, is one of the most secure browsers out there, as it lacks almost all of the attack vectors (Javascript, CSS, etc) that, say, Firefox or Chrome has. The most recent advisory for Lynx I found was from 2005, then one from 2003, then one from 2000. That's three over a six-year span, then bupkis for the next nine. I think a more appropriate way of wording this comment in full is: despite several messages on tech@, start gutting lynx under the guise of security. specifically, ignore the people who said bibp is in use and get rid of it. break telnet, rlogin, and tn3270 for the hell of it. leave gopher, news, and dired in place for now. but we will soon catch up to Microsoft's level of saying 'fuck the users' by removing these too, because we feel like it. ok's for the version of this diff that removes even more protocols from deraadt@, tedu@. general support from other devs. again, fuck the people actually using our software, fuck gopher, fuck bibp, fuck nntp and Usenet. OpenBSD: where do you want to go today? Seriously, if you are worried about getting hacked from using Lynx (and I mean real Lynx as distributed, with support for gopher, finger, bibp, telnet, and the kitchen sink included), maybe the Internet is just not for you. As for me, I feel safe running Lynx as root. I'd be surprised to find that many people who were not. Finally, I'm horrified that bibp support was removed, and telnet support was broken, *after* others said they were still using it. I expect this kind of ham-fisted fuck the users move from companies like Microsoft and Apple. I honestly never thought I'd see the day that it would happen in OpenBSD. For now, I'm going to make sure my Lynx still has full functionality if I have to manually unfuck the Makefile myself everytime after I update my sources. In the future? Maybe I (and the other users who actually give a shit about having non-crippled software) should have switched to BitRig (or NetBSD, or maybe even something else) already. It's a shame because I was looking to buy a CD set for 5.6, too. But I won't if Lynx isn't all there in 5.6-release, and I'll be donating the money to another project (most likely BitRig) instead. Feel free to follow my lead should you desire. -- Shawn K. Quinn skqu...@rushpost.com
Re: lynx: disable old protocols
On Thu, 2014-07-10 at 23:05 -0400, Daniel Dickman wrote: Patch below turns off the following ancient protocols built into lynx: bibp, finger, gopher, and news. For some urls, lynx will invoke an external command. Turn off telnet, rlogin and tn3270 urls by defining them to false(1) as documented in the lynx manual. Gopher and NNTP are actually still being used (the former a bit sparsely, but there are a few servers here and there). The rest I don't mind seeing disappear (we don't ship the telnet and rlogin programs anymore AFAIK, I've never heard of bibp, and we have a finger program as an alternative to the functionality in lynx). Finally, turn off the file editor which can be accessed with g.enter using the --disable-dired switch. I don't see a good reason to get rid of this. What is the rationale? -- Shawn K. Quinn skqu...@rushpost.com
Re: ffs2 boot
On Wed, Apr 16, 2014, at 03:05 PM, Miod Vallat wrote: [responding to Brandon Mercer who wrote:] The other day I was doing an install in qemu-kvm and newfs was taking forever, to the tune of hours. This is similar to formatting on arm boards. In my quest to track down why, I discovered that ffs2 takes far less time to format than ffs1 (about 30 seconds for the entire disk). I've put together a diff that updates the boot blocks on amd64 to be able to boot ffs2. From there it's a one line change to make newfs format ffs2 by default. Obviously this would need to happen for other architectures as well and I'd be glad to tackle that if others see this as worthwhile. Please let me know your thoughts. Awesome. You've just trimmed my todolist by a few lines (-: And you've done it so that you do not force UFS2 support on tight-space-challenged boot blocks on other arches. I'm not against adding cool features, but are there people who really need a root filesystem of one whole terabyte or larger? I've never needed my root filesystem to be larger than, say, a gigabyte or two. The only case for which this might make some sense is an external hard drive, formatted FFS2, on a 1T+ drive nearly full of personal files that just happens to have a bsd.rd in the root to reinstall/upgrade a hosed system. For most others, there should be a note that making your root filesystem That Big is usually a Really Bad Idea. -- Shawn K. Quinn skqu...@rushpost.com
Re: missing ports.tar.gz in snapshot
On Thu, Mar 6, 2014, at 08:56 AM, Theo de Raadt wrote: is there a reason, why there is no ports.tar.gz in the latest snapshot folder? At present, it is not being built in the ftp area any more. I'd like to ask. Does anyone find it useful? It is not in sync with the packages beside it. I don't use the ports tree at all anymore. That said, I would trust the empirical evidence (FTP logs) more than any on-list answers you might get. -- Shawn K. Quinn skqu...@rushpost.com
Re: your mail
On Sat, Jan 25, 2014, at 08:53 AM, Marc Espie wrote: I agree with so-called having negative connotations. I think both those instances are using it intentionally, namely there are nasty surprises in some MBR blocks that are not covered by the so-called MBR standard. There's an actual MBR standard? If so, maintained by whom? -- Shawn K. Quinn skqu...@rushpost.com
Re: pkg_add tests
On Fri, Jan 24, 2014, at 06:50 AM, Marc Espie wrote: You should realize that the pkg tools have gone thru *major internal changes* over the last month or so. If you see weird things happening, now is a really good time to report them, before it's too late... Also, the 5.4 - 5.5 update is going to be fun: there was a kernel flag day. The proper way to update packages will be along the lines of: in 5.4: pkg_info -mq list pkg_delete * (update to 5.5) in 5.5, install new packages: pkg_add -z -l list Again, there might be issues. Now is a very good time to start looking... Do we have to do any of this if we have been following snapshots or -current? Are there any other gotchas related to these for those of us who are running snapshots or -current? I haven't had any obvious Bad Things jump up and bite me yet, want to keep it that way. (Software-related, at least; having my onboard SATA controller fall down and go boom kind of falls outside the realm of that.) -- Shawn K. Quinn skqu...@rushpost.com
Re: linebuffering diff for tr(1)
On Tue, Nov 19, 2013, at 03:10 PM, Theo de Raadt wrote: In general, new non-standard options are bad. Basically, if we add this someone will use it in a script. Then it will become non-portable. You cannot just invent something on your own like this, without doing research to find out if someone else added a different option. I don't see evidence of that, so the gut answer is no. FreeBSD and Dragonfly BSD have this option in tr. So, this actually improves portability. -- Shawn K. Quinn skqu...@rushpost.com
Re: linebuffering diff for tr(1)
On Wed, Nov 20, 2013, at 12:49 PM, Ted Unangst wrote: On 2013/11/20 07:40, Shawn K. Quinn wrote: FreeBSD and Dragonfly BSD have this option in tr. So, this actually improves portability. It's just spreading the disease. portable means it works everywhere. Increasing the number of people who can write nonportable code is not the same as increasing portability. How many others have to adopt it before it's considered portable, then? Would you feel the same way if this were the -l option on ls, GNU had it, and none of the BSD descendants did? It's possible, as mentioned elsewhere, that simply making tr be unbuffered by default is the better move, and ignore -u for compatibility with FreeBSD and Dragonfly BSD. -- Shawn K. Quinn skqu...@rushpost.com
Re: Adds product ATI RADEON_HD5570
On Sun, 2013-03-24 at 16:38 -0600, Abel Abraham Camarillo Ojeda wrote: I'm using gmail :( You can't inline them using it... It is possible to set up a regular IMAP email client (Evolution, for example) to access Gmail, and you can use that for sending patches. -- Shawn K. Quinn skqu...@rushpost.com
Re: bind mountd to a specified port
On Thu, Oct 18, 2012, at 12:17 PM, Theo de Raadt wrote: As you note, this has come up before, and the same reasons exist then as now. The security model makes no sense: firewall, but allow NFS. It may make no sense to you, but that doesn't mean it makes no sense to everyone, especially those with setups where this is the only way to accomplish the desired goal. Put another way, it makes as much sense as firewall, but allow SMB, or even allow SSH, FTP, or HTTP. -- Shawn K. Quinn skqu...@rushpost.com
