Slashdot Mirror

"BSD", as some idiot quoted it, is NOT a "License", it's a *Copyright*. There is a huge difference there. Get it right.

The BSD style Copyright is now best represented by, and deployed as, the following...

https://www.openbsd.org/policy.html https://cvsweb.openbsd.org/src... https://www.freebsd.org/copyri...

With additional discussion here... http://landley.net/toybox/lice... https://urchin.earth.li/~twic/...

You should also know that the next major release of FreeBSD 12.0 will be out in 1.5 weeks :-) You can liveboot the RC3 sampler from USB today.

Copyright is a legal concept emblazoned in the United States Constitution and in many other countries around the world. To make a lot of legal stuff as simple as possible, it means "if you write the code, you own it and have the right to say what happens to it". Since you are the owner, you now have to do something to allow usage by someone else. That "something" is the license. BSD is a license, not a copyright. BSD always was more permissive than most other licenses, and over the years it removed the few requirements that it had, until now the "0BSD" license is almost indistinguishable from "Public Domain" software. However, it is best to put a license somewhere in your code stream, just to let the people who want to use your code that they can and under what circumstances.

So the same as any Linux distro, but with OpenBSD I just boot bsd.rd, I choose upgrade, and then pkg_add -Ui. Done.

Well, going by the 6.3->6.4 upgrade, which I just did a trial run of, you may have to fiddle with a few config files, and do some minor tweaking like deleting an obsolete daemon and its user and group, but it's quite straightforward if you have basic command line system administration skills.

I misunderstood your comment to mean you need to do a full reinstall from scratch, meaning configuration and setup. That is not the case.

I'm just now seriously starting my move from Linux to OpenBSD, and just did a trial 6.3->6.4 upgrade of a vanilla only one package installed scratch 6.3 installation. It does look like the process reinstalls all? the standard binary etc. system files, but as you say, the configuration, disk setup, etc. remains the same.

Here's the upgrade guide BTW. It's all manual, but easy for people with sysadmin experience. Replace the bsd.rd ramdisk kernel (for AMD64 it's tiny at 9.6MiB, although I suppose that means it's missing a lot of device drivers Linux and Windows have), tweak config files where syntax or semantics have changed, remove obsolete stuff, boot from that new ramdisk kernel, follow the easy prompts, fix up any mistakes you made in updating the config files (there's a tool to help with that), update your non-base system packages, and you're essentially done.

Not quite for this release, e.g. it turns off Intel Hyperthreading by default, and my OpenBSD scratch system is using a cheap 1 core 2 Hyperthreads Celeron CPU, so I need to turn that back on to test its SMP, and if I was using a sound input, I'd have to carefully turn that back on, it's now disabled by default for the obvious reasons.

So far I'm quite pleased, it's sane like the V7, BSD2.x and 4.x systems I used in the 1980s, but I haven't put it to serious use yet.

"with OpenBSD, you must reinstall the whole system at least once a year, if you want to keep it secure"

Nonsense. There is an upgrade option when you boot from the ISO or ISO image. Here how you upgrade from 6.3 -> 6.4. I have gone this route for years and it has never failed me. Just be sure to check what it is suggesting and watch the diffs.

But they DO have release songs (although only up to 6.1):

https://www.openbsd.org/lyrics...

The current release of OpenBSD, version 6.3, has issued a total of 10 patches against base since release on April 15th. Four of these are security-related, and six are reliability bug fixes.

Oracle / Red Hat Linux in that time has issued 50 security-related patches, and hundreds more that are classed as bug fixes or enhancements.

Linux is strong because it scales up and down very well, it exploits CPU features for speed to make applications run very fast, it is friendly to new features, and it has the most market share in the POSIX realm. Linux is weak because it has sacrificed security for speed in many cases, and we have Dirty Cow, Towelroot, and many similar problems in userspace - this makes Linux a bad choice for systems that will not receive patches (i.e. phones, IoT devices, embedded systems, etc.).

OpenBSD prioritizes security over speed and flexibility. It does not implement fine-grained SMP due to security concerns, and has a "big kernel lock" that Linux left behind in 2.2. It ignores many well-known standards (i.e. NFSv4). There are many things that you cannot do on OpenBSD, but what you can do is magnitudes safer than Linux.

Android politely stole OpenBSD's entire libc implementation (and then ignored it for several years), and IIRC the OpenBSD code is the largest contribution outside of the kernel itself.

OpenBSD is also the home of OpenSSH, which itself is quite secure.

I trust the opinions of the OpenBSD kernel architects, and I will look forward to their patch.

By using OpenBSD you have already opted in to using the most secure code possible, even at a performance cost. They say:

OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make. Also, since OpenBSD is exported with cryptography, we are able to take cryptographic approaches towards fixing security problems.

where does it say what you said it says?

OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make. Also, since OpenBSD is exported with cryptography, we are able to take cryptographic approaches towards fixing security problems.

Given the class of Spectre and Meltdown attacks rely on someone else having the freedom to execute code on your hardware, shouldn't something like this be opt-in? There's a whole world of servers out that where Spectre is ultimately completely irrelevant in terms of a security threat, but hyperthreading is definitely not irrelevant in terms of performance.

I can't do any better than quote OpenBSD on this:

OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make.

https://www.openbsd.org/security.html

Nothing stops Root from resetting append access only (I do it in the program I noted to Mr. Stoll himself during the File Open (as append, reset etc.)/Read-Write/Flush-Close cycle either really IF you think about it...

Same goes for diverting where the print goes. Difference is though, if both are attacked, you have some chance of grepping the logs, grepping print output takes a much longer as eyeballs don't work as fast. This assumes you can do something with it afterwards. On a laser, I'm not sure, but if you close the print fd file, I think it ejects the page. On line printers, this isn't as much an issue. If there is a large (page) buffer, then I think there's some chance that the lpd could be -9'd thus nothing gets written. Obvious when the admin gets in, but was damage done in the meanwhile? To be honest, I'm more bothered about dormant intrusions, those that are immediately obvious are less of a problem as you can deal with those.

My hints were towards https://man.openbsd.org/OpenBS...

I'd have more confidence in that than other methods. Granted you have to reboot to rotate, but it seems a fairly good compromise and has a lower carbon foot print than the paper method. There may also be times when the log buffer fills waiting for the printer to warm up and some connections may time out, though I've never checked this, would be mighty annoying if you cannot ssh to quiet machine because the log write hasn't returned.

Why does the submission link to someone’s “congratulations” email response instead of the original email announcement... or the web posting about the release itself?

https://www.openbsd.org/63.htm...

Google ought to pour a LOT of love into a SPARC port. The best-situated would be OpenBSD.

Why, you ask? For the same reason that Microsoft's original target for the NT kernel was MIPS, and x86 was specifically secondary - oddball architectures will force you to clean up your code.

OpenBSD is also vicious in showing you your use-after-free mistakes since malloc() uses mmap() instead of sbrk() on their platform.

The other architectures that OpenBSD supports have benefited because some kinds of bugs are exposed more often by the 64-bit big endian nature of UltraSPARC.

OpenBSD has promoted this belief for years. The description of their audit process states...

"Another facet of our security auditing process is its proactiveness. In most cases we have found that the determination of exploitability is not an issue. During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable. (Or, more likely someone on BUGTRAQ would report that other operating systems were vulnerable to a `newly discovered problem', and then it would be discovered that OpenBSD had been fixed in a previous release). In other cases we have been saved from full exploitability of complex step-by-step attacks because we had fixed one of the intermediate steps."

You might want to look at Open BSD. Much of what they have done has been adopted by lesser OSS projects.

Have you looked at the OpenBSD license?

From the URL "OpenBSD strives to provide code that can be freely used, copied, modified, and distributed by anyone and for any purpose. This maintains the spirit of the original Berkeley Software Distribution."

Very altruistic but does not have much control over what can be done with said software and do you honestly think some users are going to play fair?

Over any period, the number of Linux kernel flaws will absolutely dwarf the number of flaws patched in the OpenBSD kernel.

There are consequences when choosing popularity over correctness.

You missed my point or else I wrote poorly. Theo and crew don't like using GPL'd software for a number of reasons, least of all the license. The OpenBSD devs likely write the best wifi drivers out there and they do this with very little cooperation from the vendors. OpenBSD has consistently said they will not use GPL'd bits.

The following snippet is taken from the "Getting Started with OpenBSD Device Driver Development"
Getting Started with OpenBSD Device Driver Development

Licensing

Follow the project’s copyright policy:

http://www.openbsd.org/policy.html

New code should be ISC-licensed /usr/share/misc/license.template

Honour the rights of authors
Many authors do not want their code copied into OpenBSD
This includes GPL and other incompatible open source licences

I use OpenBSD for more than a decade now, mostly as router/firewall solution, because it has all I need directly in base system.

PF Firewall
OSPF Routing
BGP Routing
CARP - Common Address Redundancy
IPsec
Sync IPsec states on CARPed boxes
PPTP/L2TP VPN

I could go on...

I use OpenBSD for more than a decade now, mostly as router/firewall solution, because it has all I need directly in base system.

PF Firewall
OSPF Routing
BGP Routing
CARP - Common Address Redundancy
IPsec
Sync IPsec states on CARPed boxes
PPTP/L2TP VPN

I could go on...

I use OpenBSD for more than a decade now, mostly as router/firewall solution, because it has all I need directly in base system.

PF Firewall
OSPF Routing
BGP Routing
CARP - Common Address Redundancy
IPsec
Sync IPsec states on CARPed boxes
PPTP/L2TP VPN

I could go on...

I use OpenBSD for more than a decade now, mostly as router/firewall solution, because it has all I need directly in base system.

PF Firewall
OSPF Routing
BGP Routing
CARP - Common Address Redundancy
IPsec
Sync IPsec states on CARPed boxes
PPTP/L2TP VPN

I could go on...

I use OpenBSD for more than a decade now, mostly as router/firewall solution, because it has all I need directly in base system.

PF Firewall
OSPF Routing
BGP Routing
CARP - Common Address Redundancy
IPsec
Sync IPsec states on CARPed boxes
PPTP/L2TP VPN

I could go on...

I use OpenBSD for more than a decade now, mostly as router/firewall solution, because it has all I need directly in base system.

PF Firewall
OSPF Routing
BGP Routing
CARP - Common Address Redundancy
IPsec
Sync IPsec states on CARPed boxes
PPTP/L2TP VPN

I could go on...

I use OpenBSD for more than a decade now, mostly as router/firewall solution, because it has all I need directly in base system.

PF Firewall
OSPF Routing
BGP Routing
CARP - Common Address Redundancy
IPsec
Sync IPsec states on CARPed boxes
PPTP/L2TP VPN

I could go on...

And for that whirlwind tour of what's good in that system, take a peek at my OpenBSD and you slides.

here's a clue
https://www.openbsd.org/lyrics...

If OpenBSD wasn't vulnerable, why did they issue a patch:
https://ftp.openbsd.org/pub/Op...
?

It is relevant for at least the following reasons:

The OpenBSD project has a proactive approach to security https://www.openbsd.org/securi... with people who do what they do because they want to do it.

The Windows model is perpetuate the need for patches so you can make the customer dependent on continuous releases. They never had any intent to procure a secure system and likely never will.

And your bug-free 100% secure multi-user OS w/ flawless network stack is where, exactly?

Here you go. They have exploits occasionally, but they're rare. Not bad for a scrappy team of programmers, showing the world what is possible.

If they had Microsoft's resources, they would be perfect.

Theo has voiced concerns specifically against the Apache 2.0 licence -- a decade ago.

What is up with some free software providers?! They say "Here's something free! Oh wait, I changed my mind."

While not exactly bait-and-switch, this is something which has been causing the community continual grief, and therefore we decided to honour a few of the projects that have decided to go non-free. After all.. having gone non-free, no one is going to remember them in the end.
[...]
The Apache group started from the humble beginnings of just being 'a patchy' set of changes to a completely free web server of dubious quality. But the years have changed them, and what they supply is now quite non-free... released under a license so entangled in legalese that we have absolutely no doubt that there are encumbrances hidden within. Legal terms protect. Who are they protecting? Not your freedom.

(From https://www.openbsd.org/lyrics... ; I'm sure there's a relevant mailing list post somewhere.)

Basically, they refused to update their in-tree Apache from 1.3.30 to anything newer, since 1.3.31 and so forth were Apache 2.0 licensed. Many years later, I believe they removed it and replaced it with something whose licence they could agree with (nginx IIRC).

In general, the BSDs are really wary of incorporating anything that is 'less free' than the MIT/ISC/BSD license into their base system.

If you had mentioned cvs, or rcs, then i'd agree ;-)

OpenBSD, arguably the most secure operating system in existence, uses CVS.

http://cvsweb.openbsd.org

There are plenty of security-focused Linux OSes, e.g. Tails, Qubes, Whonix, Ubuntu Privacy Remix, Kali Linux - just to mention a few. And then there is also the whole BSD family of free Unix OSes who are very security vetted, e.g. NetBSD, OpenBSD and FreeBSD. So I'm not sure what you mean by "the linux community is not capitalizing on the situation" ..?

You seem to be advocating the user is responsible for their actions, a la the car model.

Oddly, you seem to an OS recommendation. Surely you recommend OpenBSD, correct?

You also realize anti-virus software is garbage, right?

Whoa, calm down.

> Every fucking release has mountains of errors flaws holes and bugs.
So does every OS. There is no "magic code" where there are zero bugs.

> https://www.openbsd.org/errata...
I count 25 issues. Doesn't look like a "mountain" to me.

> If your software was in control of nuclear missles you would have killed everyone twice.
And what's the bug count for the Linux kernel or GNU/Linux system?? Compared to OpenBSD, Linux is insecure out-of-the-box.

> if your compiler has a bug and there is no way to get a patched compiler you have to go through an entire compiler bootstrap to be sure the patch for the compiler works.
What this a rhetorical rant or do you have a link for more information? Thanks.

No, by far the best feature is that there is NO way to patch the system unless you build and distribute those patches yourself.

What a great, great fucking way to keep an OS secure. Dont have an inbox way of updating the fucking thing when there is errata.

AND BOY, there is errata. Every fucking release has mountains of errors flaws holes and bugs.

https://www.openbsd.org/errata...

All of this shit is fixed with source patches. Imagine this, Theo de Fucking Ass Rat, if your compiler has a bug and there is no way to get a patched compiler you have to go through an entire compiler bootstrap to be sure the patch for the compiler works.

Fuck you Theo The Rat. Secure by default? My ass! You had two remote holes so far. Good job. If your software was in control of nuclear missles you would have killed everyone twice.

Yes, shitstemD is a fucking stain. Yes Lennart Poettering is a god damned faggot father fucking piece of low life scum dog shit puke. Anyone who thinks ShitStemD isnt shit is a fucking asshole.

But OpenBSD, fuck you for no binary patches, fuck you, LIAR, LIAR, LIAR. You fucking dicklicking puke fucks should have offered a for-pay service to get binary patches but instead you just offer to give your users a prostate milking by putting your spiky puffer fish in our assholes and smashing it around.

Two things caught my eye in the release notes:

Security improvements:
* Remove systrace.
* Remove Linux emulation support.

Theo has some cool slides about "Pledge" that replaced systrace. Slide 3 has this "gem":

"Loudmouth Linus"
http://www.openbsd.org/papers/...

Note: NSFW

That was a response to Linus saying "the OpenBSD crowd is a bunch of masturbating monkeys."
http://www.zdnet.com/article/l...

Ouch.

Wow, not even the alternative OS's are free from drama -- sad to see Linus (Linux) and Theo (OpenBSD) having to resort to name calling over "best practices" about security.

Theo might be getting the last laugh though:

http://www.openbsd.org/papers/...
http://www.openbsd.org/papers/...

Adopted some designs from others. We are know for PUSHING mitigations into mainstream use:

- stack protector
- W^X
- ASLR
- malloc with seatbelts
- priv- separation & priv-drop

I guess if name calling helps make the OS's better so be it. :-)

Two things caught my eye in the release notes:

Security improvements:
* Remove systrace.
* Remove Linux emulation support.

Theo has some cool slides about "Pledge" that replaced systrace. Slide 3 has this "gem":

"Loudmouth Linus"
http://www.openbsd.org/papers/...

Note: NSFW

That was a response to Linus saying "the OpenBSD crowd is a bunch of masturbating monkeys."
http://www.zdnet.com/article/l...

Ouch.

Wow, not even the alternative OS's are free from drama -- sad to see Linus (Linux) and Theo (OpenBSD) having to resort to name calling over "best practices" about security.

Theo might be getting the last laugh though:

http://www.openbsd.org/papers/...
http://www.openbsd.org/papers/...

Adopted some designs from others. We are know for PUSHING mitigations into mainstream use:

- stack protector
- W^X
- ASLR
- malloc with seatbelts
- priv- separation & priv-drop

I guess if name calling helps make the OS's better so be it. :-)

Two things caught my eye in the release notes:

Security improvements:
* Remove systrace.
* Remove Linux emulation support.

Theo has some cool slides about "Pledge" that replaced systrace. Slide 3 has this "gem":

"Loudmouth Linus"
http://www.openbsd.org/papers/...

Note: NSFW

That was a response to Linus saying "the OpenBSD crowd is a bunch of masturbating monkeys."
http://www.zdnet.com/article/l...

Ouch.

Wow, not even the alternative OS's are free from drama -- sad to see Linus (Linux) and Theo (OpenBSD) having to resort to name calling over "best practices" about security.

Theo might be getting the last laugh though:

http://www.openbsd.org/papers/...
http://www.openbsd.org/papers/...

Adopted some designs from others. We are know for PUSHING mitigations into mainstream use:

- stack protector
- W^X
- ASLR
- malloc with seatbelts
- priv- separation & priv-drop

I guess if name calling helps make the OS's better so be it. :-)

the dipshit here is you. Linux system logins are secured over network by code written by OpenBSD team. OpenBSD runs on mobile devices to multi-CPU servers. Armv7, Sparc64, Base install of OpenBSD includes hardened web, proxy, mail, name, packet filter and private netwoking. And with pledge(2) OpenBSD is about ten years ahead of Linux in internal process security.

Educate your ignorant self you fucking twat: https://www.openbsd.org/60.htm...

nope, the BSDs just shallow copy all of the Linux kernel code at this point. BSDs are actually attempting to copy the new Linux network code, since it's years ahead of the BSDs. That's why embedded systems designers, network appliance manufactures, etc. are dropping the BSDs for Linux every day.

You're wrong.

the dipshit here is you. Linux system logins are secured over network by code written by OpenBSD team. OpenBSD runs on mobile devices to multi-CPU servers. Armv7, Sparc64, Base install of OpenBSD includes hardened web, proxy, mail, name, packet filter and private netwoking. And with pledge(2) OpenBSD is about ten years ahead of Linux in internal process security.

Educate your ignorant self you fucking twat: https://www.openbsd.org/60.htm...

Remove Linux emulation support.

Don't forget about the redundancy detector van from the Monopoly of Cizzz-coeee.

Seriously, that Ogg is worth listening to, doubly so if you like Monty Python.

Here is their list. Looks like they've finally given up on vax.

their support just happens to take the form of a proprietary driver for their already proprietary card, to which i can only say "who gives a shit?"

When Snowden finally gets his fair trial (ha ha ha ha ha ha), the first witness called by the defense will be one Doctor Puffystein.

Yes, but why do you recommend a crap choice?

Some better ones:

https://linuxmint.com
https://kororaproject.org
https://getfedora.org
http://alpinelinux.org
http://www.ghostbsd.org
http://www.openbsd.org
https://www.freebsd.org

He's... not even wrong. It's rather impressive, the number of misconceptions and sheer volume of ignorance he manages to cram into just six short paragraphs.

It was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.

Except that it wasn't by default. You logout, your shell gets the HUP signal. That signal gets propagated down to all of the shell's children, and all of their children, and their children - all the way down to the end of the chain. By default, HUP terminates a given process. If it doesn't terminate a process as described, it's because one of three things has happened. First possibility: the process has deliberately severed its child-parent relationship with the shell, as any program designed to run as a daemon will do. Second possibility: the process has explicitly set a signal handler to trap (or ignore) the HUP signal. Third possibility: the process has been launched with the nohup command (which effectively is the same as the second possibility).

If a program hangs around after logout that isn't supposed to, that's a bug in the program, not in the operating system. The defaults are all set up properly; if a program deliberately sets out to ignore them, presumably that's for a good reason.

It has never been the default that a program will just hang around forever for no good reason.

we should consider it our duty as Fedora developers to improve the Linux platform

Right. That's it. I'm done. I'm out. I've been involved with Linux in some form or another since the days of the a.out to ELF transition - over ten years. I've been grumbling about systemd breaking a whole bunch of conventions for no good reason since I first laid eyes on it. This? This is the straw that broke the camel's back. Any operating system that quietly introduces a breaking change like this - something that is a fundamental part of the design of the Unix operating system, that is a basic assumption that every long-term Unix user is aware of - is not an operating system I want to have to deal with. Sure, it's easy to change the configuration setting for this thing. What about the next change that breaks something fundamental? Or the one after that? Or the one after that?

This isn't good enough. Sure, sometimes change is necessary - the a.out to ELF transition was done for good reasons; swapping out telnet to ssh was done for good reasons - but this kind of subtle breakage is a huge time sink to any halfway serious systems administrator.

Well, at least there are alternatives out there.

Which require more than one floppy I assume! BLOAT!

For those who don't get it;
this is the one floppy you need to net-install OpenBSD 5.9/AMD64: http://ftp.eu.openbsd.org/pub/...

It's _NET_-install, not fucking floppy-install =P

IIRC the kernel dropped boot floppies around version 2.6

Last time I installed OpenBSD and NetBSD they installed from one and two floppies each if I remember correctly.

Back before then I think Debian maybe had like five or something..

See, this is how it's done:
http://ftp.eu.openbsd.org/pub/... - The _ONE_ floppy required to net-install OpenBSD 5.9 i386.
http://ftp.eu.openbsd.org/pub/... The _ONE_ floppy required to net-install OpenBSD 5.9 AMD64.

Wow, NetBSD uses _FIVE_ floppies now?!
http://ftp.fi.netbsd.org/pub/N...

FreeBSD doesn't even offer floppy-installation any more?
ftp://ftp.se.freebsd.org/pub/F...

IIRC the kernel dropped boot floppies around version 2.6

Last time I installed OpenBSD and NetBSD they installed from one and two floppies each if I remember correctly.

Back before then I think Debian maybe had like five or something..

See, this is how it's done:
http://ftp.eu.openbsd.org/pub/... - The _ONE_ floppy required to net-install OpenBSD 5.9 i386.
http://ftp.eu.openbsd.org/pub/... The _ONE_ floppy required to net-install OpenBSD 5.9 AMD64.

Wow, NetBSD uses _FIVE_ floppies now?!
http://ftp.fi.netbsd.org/pub/N...

FreeBSD doesn't even offer floppy-installation any more?
ftp://ftp.se.freebsd.org/pub/F...

The manual doesn't say anything about that ridiculous switch, you GNU-centered moron.

Makes me wonder, is GNU already at the point where clippy pops up and asks whether you need assistance with rm(1)?

If you're going to leave Windows on the box, use ITS boot menu to dual boot.

I have a test laptop with 4 boot targets for the Windows boot process: Recovery, Windows 7, OpenBSD, and GRUB (which can, of course, also boot Windows). OpenBSD put its boot loader at the start of its partition, as did GRUB. With Cygwin installed on Windows (or booting from a "Live" of some sort, copy those boot blocks to files in Windows' C:\, and reference them in the Boot Configuration Data. OpenBSD's FAQ has a very nice tutorial section 4.15. GRUB is used to boot between several flavors of Linux for testing (yes, I could use VMs, but OpenBSD, at least, likes bare metal best, and it's no harder to copy back a specific partition than VM image).

http://www.openbsd.org/faq/faq4.html#Multibooting