Actually you'd have to fork off 4.4BSD-Lite2 because all of the later contributions to Free/Net/OpenBSD were made under the then-existing license (not GPL-compatible), and some of the contributors may not want their work relicensed without permission. The code owned by UCB can be (and was) relicensed by them, but code contributed by third parties can't be without the permission of all involved.
> Straight off, I get the message that this user is not in the appropriate group to su to root.
This has been the default behaviour in BSD-derived UNIXes since the 80s. For example, under FreeBSD:
bash-2.03$ su
su: you are not in the correct group to su root.
You have to be in the 'wheel' group to su to root. I think some versions of Linux don't do it this way (i.e. joe random luser can su to root if he knows the password), but thats hardly a reason to blame OpenBSD for it.
I'm sure OpenBSD's installation lets you specify the groups you want your user account to be in, so this could have easily been overcome if you knew the basics of administering a BSD-derived UNIX.
Minor nit: ftp.cdrom.com and ftp.freesoftware.com are not the same machine. ftp.cdrom.com was sold off by Walnut Creek CDROM (it still runs FreeBSD - they're not stupid and need to keep up with the load), but ftp.freebsd.org is now hosted on ftp.freesoftware.com, also running FreeBSD on a similar platform.
Re:Is the Linux emulation good enough to...
on
FreeBSD 4.0 Released
·
· Score: 1
It's not an emulator - it's linux ABI compatability. Basically, the kernel loads in a different system call interface when running a linux binary, and so the binary can make all of the native linux system calls it expects while running on the bare hardware (i.e. not from a virtual machine).
Basically, the FreeBSD kernel reconfigures itself to look like a Linux 2.2.x kernel from the point of view of a linux binary ("I can't believe it's not Linux!") - quite cool, really.
See http://www.freebsd.org/handbook/x20065.html ("How does the Linux mode work?") for a more detailed explanation.
Re:What's improved in the thread libraries?
on
FreeBSD 4.0 Released
·
· Score: 1
The user-threads library (libc_r) uses call-conversion to map blocking syscalls to nonblocking ones, so when a thread makes a blocking syscall the thread scheduler can just switch to another thread and carry on as if nothing happened.
Blocking on syscalls should not be an issue with libc_r (and this is also the case in 3.x - the changes to the 4.0 libc_r weren't in this area).
Not that I'm knocking OpenBSD - I like and respect it - but the audit they did was hardly "line by line". What they did was go through the source looking for likely problems (use of potentially unsafe functions, etc) - some parts more thoroughly than others, to be sure. They fixed a lot of potential and actual problems (security and otherwise), but not all of them.
Most of the bugs they fixed fall into the "paranoia" category, i.e. they could conceivably lead to a security problem if the admin does something really weird with the program, but under 99% of normal use they're just a regular bug which causes the program to fail.
The FreeBSD auditing project is certainly alive and getting results. Yes, OpenBSD fixed most of the problems a while ago, but the FreeBSD auditing guys already found a number of bugs which OpenBSD missed the first time around, and as a result both OSes are better for it.
Most of the OpenBSD user-land security fixes, and a good proportion of the kernel ones, are being merged back into FreeBSD (I'm should know, I'm doing the work myself). Expect to see a lot more focus on security in FreeBSD in the future.
Does this mean that OpenBSD will lose its market niche? I don't think so - they'll always be more security-paranoid than the rest of us are willing to be, I think (some of the changes they've made involve breaking backwards-compatability or introducing changes which have other slight negative side-effects, in the name of security)
They wouldn't even have to start a new BSD project. BSDI can't steal the FreeBSD name, because (while Walnut Creek owns it right now until the FreeBSD Foundation can be set up to transfer it to) the administration rights to the trademark belong to FreeBSD-core, who you can bet would not give them up to a commercial distribution.
The best BSDI could do is to take the FreeBSD code, merge it with BSD/OS and create PlusBSD 5.0 - which is what *anyone is allowed to do and do all the time*, and FreeBSD will continue unchanged as before.
BSDI can't "assimilate" FreeBSD because neither Walnut Creek, nor the new merged company will have control of it. Control rests firmly where it always has, in the hands of FreeBSD Core.
Sure, BSDI could take the free version of FreeBSD and make their own proprietary version - but wait, they always could, and did exactly this with BSD/OS (which incorporated some amount of FreeBSD code). This hypothetical version could not be called FreeBSD, because that name is administered by FreeBSD core.
You can bet that if they tried to somehow make FreeBSD non-Free, the vast majority of the developer and user base would not follow them, and would carry on developing the real FreeBSD as ever before.
There will always be a free FreeBSD out there - no-one can take away my CVS repository from me.
My take as a FreeBSD committer is that -core isn't anti-desktop, they're just not PRO-desktop. In other words, the desktop isn't the main focus of the people in -core.
More to the point, -core doesn't have anything to do with the day-to-day running of FreeBSD or what gets committed to the tree or not: that's up to the developers. So far, we've seen not much in the way of contributions from the user/developer population directed to "improving the desktop" (whatever that means). Jordan once tried to run a desktop contest for a "default desktop" and didn't get any submissions.
In a free software project, things don't happen until someone does the work - so it seems that not many people who use FreeBSD are motivated enough to work on "improving the desktop". Whenever it comes that FreeBSD should "support the desktop better" the answer is invariably "yes, better desktop support would be great! I can't wait to see your patches!" and then it goes no further.
From what I've heard so far from people close to the source, FreeBSD will NOT be changing significantly in the way we do things. The new merged company won't have direct control over anything, but will just contribute code via the "usual mechanisms" open to everyone (submitting patches, etc).
Specifically, I'd expect to see various BSDI developers who are doing useful merge work being granted commit privileges to apply their changes to FreeBSD directly, subject to the usual architectural and review policies, overseen by FreeBSD core.
"The FreeBSD Project" is being set up as an independent, nonprofit organisation of some description to ensure it stays independent of control by BSDI/WC.
Basically, what I expect to see is pretty much what we've seen from FreeBSD's main corporate sponsor in the past (Walnut Creek), namely that they pay a number of developers to work full-time on FreeBSD as members of the wider developer community, and they profit from selling the resulting product on CDROM. Since it's open source, any other company can also sell it as well (CheapBytes does).
FreeBSD-derived distributions are another issue - if someone wants to change bits of the "official FreeBSD" and repackage it, it's arguable they should have to obtain permission to use the FreeBSD trademark, which is intended to be transferred to the Foundation.
The main difference I expect to see from the status quo that we'll get a LOT more developers contributing code, and a lot of this code will hopefully be juicy BSD/OS code (e.g. I'm told their SMP implementation is quite good). The new combined company will have a lot more resources to contribute to FreeBSD-related services, like support contracts, training, book publication, advertisement, paid development sponsoring, etc.
After the CSRG at Berkeley dissolved (lost funding) a bunch of the 4.4BSD guys got together and formed BSDI (Mike Karels in particular). So in a sense this merger between BSDI and the principal sponsors of FreeBSD reunites FreeBSD with its' history.
The www.bsdi.com website has a fairly good section on the company and its history..
Common Themes in Banks' work
on
Inversions
·
· Score: 1
I wonder if anyone else has noticed the common theme running through Banks' work, SF and non-SF. The Culture is fairly obviously his idea of a utopian society, but the same ideals also manifest themselves in all of his non-fiction books I have read.
His protagonists usually live a life happily involving copious amounts of drugs, booze, and casual sex and are usually living a pretty all-round contented life (or were, until something comes along to screw it up). This is fairly obviously the case in The Bridge and Complicity, and less obviously so in Whit (but if you think about it, it's almost exactly the same concept viewed from a different angle, i.e. a benevolent religious cult). In "A Song of Stone" the two main characters seemed to be living a life of happy debauchery before the war came along. I'm still working my way through his other non-SF books, but I wouldn't be surprised to see the same thread evident there.
This is by no means a complaint - Banks is one of my favourite authors: his ability to lay out and develop a story is almost unparalleled in my experience.
All I can say is that if Banks' real life is anywhere near this carefree and content, he is one lucky guy. If my life turns out anything like that I'll die a happy man:-)
[ Side note: I'm surprised the reviewer didn't notice the (I thought fairly obvious) hints that Inversions was another Culture novel, inverted. Consider: the fact that the Doctor was from 'another place' and so far in advance of her peers, the bodyguard telling stories about how he disagreed with the philosophy of 'his people' with regard to intervention in societies, the Doctor's blunt knife with the missing stones which she had to 'exchange' to get her way out of trouble during her voyages, the fact that one of the stones temporarily disappears when she is rescued and later returns, the fact that she is rescued BY THE KNIFE [missile], and the fact that she disappears en route from her sea voyage. Perhaps I noticed it sooner because I was really hoping it would connect to his other body of work, but it was really obvious to me early on. Oh well:=]
Re:Value added for SRP?
on
SSH v. SRP
·
· Score: 1
Yes, they are DETECTED, but not PREVENTED (the "official" SSH does this too). If I know someone has inserted data into my session, how much use it after they've already done the damage?
The comment about RSA was in response to someone else who claimed OpenSSH removed the limitation on RSA, which it doesn't. I was careful to point out that *NO* conforming SSH v1 implementation can work without RSA because it's a fundamental part of the protocol.
Can you point me to an exact URL? I could not see where they refer to fixing the insertion attack. Because this weakness is fundamental to the SSH protocol (use of CRC checksums) I don't see how they could fix it without breaking interoperability with other SSH implementations. This has come up a few times on the mailing lists..
I agree with your comments about encrypted RSA keys.
The main advantage to SRP is that it uses a simple password to authenticate, instead of requiring the user to carry around a public/private keypair with them as they move around (in other words, there's no client-side setup required beyond the installation of an SRP-capable client app). This can be the same password as the regular UNIX account password, although it's hashed in a different format and so SRP can't be used with existing password files. I've written a plugin crypt module for a replacement to FreeBSD's libcrypt which teaches crypt() how to speak SRP hashed passwords, so if you do something like this then everything else (non-SRP apps like login) will authenticate just fine. There's also an SRP PAM module floating around.
Security-wise, the authentication protocol has been well investigated, and as far as I know it's stood up fine so far - no serious weaknesses have been discovered.
On the other hand, the SSH v1 protocol as implemented by OpenSSH and all other SSH v1 implementations has an insertion attack which allows the insertion of data into the stream because of insecure integrity protection (it uses a weak checksum). The SSH2 protocol fixes the design flaws in SSH1 (as well as allowing other key exchange schemes than RSA) but OpenSSH doesn't speak it (since it's based on an old SSH 1.x distribution). Hopefully this will change in the near future.
As part of the SRP authentication handshake, a session key can be shared which allows the rest of the session to be encrypted. So SRP provides for authentication as well as secrecy, like SSH does.
SRP is just an algorithm - there's nothing preventing someone from creating a SSH-like app which authenticates using SRP, and then provides all of the port-forwarding features which SSH does. This would be quite useful, actually, and is something I'm hoping to do when I get around to bringing native SRP capability into FreeBSD.
The major downside to SRP is that the authentication is only as strong as your passphrase. But on the other hand, this is true as well in SSH if you can get a hold of someone's encrypted private key (if they carry it around with them on a floppy so they can log in from random hosts, for example). This can be mitigated by enforcing strong passphrase selection on the SRP server. An attacker sniffing the authentication exchange cannot obtain any data which is useful for determining the passphrase, even by a brute-force dictionary attack - you have to obtain access to the/etc/tpasswd file and brute-force attack that.
The Stanford SRP distribution is distributed under a BSD-style license. This is good for most people (e.g. commercial users who want to add SRP support to their products, etc), but it may prohibit the code from being incorporated into a larger GPLed program (because of the GPL's "no other restrictions" clause and the BSDL's "must give acknowledgement" clause). Consult your lawyer..
On the whole, SRP is more practical to implement because it doesn't require per-user client-side configuration. In most ways it seems to be a superior solution which is just awaiting wider adoption.
Re:Value added for SRP?
on
SSH v. SRP
·
· Score: 1
OpenSSH, last time I checked, only implements the SSH version 1 protocol, which only supports RSA. There's no way to make it use an unencumbered PK algorithm without breaking compatability with all of the other SSH 1.x implementations out there.
The SSH 1.x protocol also has a design flaw which allows insertion of arbitrary data into the data stream, because (I believe) it uses a weak CRC checksum instead of a strong cryptographic hash to verify the data integrity. Again, fixing this would break interoperability with other SSH implementations.
The SSH v2 protocol _does_ support other forms of authentication (and strong integrity protection), I believe, but it probably would require a major rewrite to implement, and that hasnt happened yet.
If you're in the U.S. then unless you can legally use RSAREF you're SOL for OpenSSH:-(
Ah, okay - I just checked the homepage, and I'm pretty sure this is just some guy operating out of his garage who puts computers together. In other words, he's offering HURD because he thinks it's cool and people should play with it, not because of a perceived market demand:-) That makes more sense now..
As I'm often fond of pointing out here, more OS choice and variation is a good thing (provided it's not gratuitously incompatible).
But why would anyone buy a computer with HURD preinstalled on it? I mean, it's only at version 0.2, which hasn't been updated in 3 years - how complete/useful can it really be? I can certainly see how it would be interesting to play with and/or hack on, but is it even up to the task of running a computer 24/7?
I'd be really interested to know how many of these things they actually sell.
OpenBSD fixed _a_ problem some time ago, namely the use of mktemp instead of mkstemp, which is really a fairly perfectionist thing and not a major problem. However they (Theo and Todd) only thought they'd fixed the problem I reported to them - in their earlier change they didn't actually look at HOW the tempfile was being used - turns out the same randomly-generated filename was being repeatedly created and removed, thus making a trivial race to exploit with or without mkstemp().
No real harm done - the make -j option has maximum performance on an SMP machine (which OpenBSD unfortunately do not support), although many people do report performance boosts even on uniprocessors since it makes better concurrent use of resources, e.g. CPU time for one job while the next is being read from disk.
I should also state for the record that FreeBSD is in the process of being audited in much the same way as OpenBSD was - we've already turned up a number of bugs which they missed, so I hope the combined efforts of the problems fixed by the two teams (FreeBSD is merging over all of OpenBSD's fixes as well) should leave both OSes pretty darn secure!
Oh dear. Tell me, which POSTIX standards does Linux comply with? What are the manyfold advantages of the "ELF file format" over..what are the alternatives again? I'm sorry to say that you come across like someone who is just repeating what they think they heard someone else say. However, I'll give you the benefit of the doubt.
The various BSDs have lots of features, large and small, which Linux doesn't have - if you were really interested you can find out more yourself by doing a bit of research. And similarly, Linux has lots of features, large and small, which the BSDs do not have.
Even supposing there were no feature differences, they're just different. Some prefer Linux, some prefer the different structure and environment of BSD. Why should we consolidate and join the collective just because Linux also works similarly?
And then there's the fact that the BSD license is commercial-friendly (i.e. companies can do what they want with the code, not what Richard Stallman wants, namely forced disclosure of code. This is NOT friendly to the business models of most software companies). Some of us (probably most BSD developers) are coding under the BSD license because they want to raise the bar of software quality, so all companies everywhere (yes, even the evil ones like microsoft) can use the same high-quality code as a starting point even if they want to keep it closed-source. It's about providing tools to everyone, regardless of their ideology towards keeping software open.
As someone else said recently, without this "copycenter" (thanks to Kirk McKusick for this wonderful expression) approach to software, there would not BE an internet today and we'd all be using OSI for our networking.
Why must we all be forced into a one world, one OS, one true Linux (or Microsoft) way? Isn't the ability to choose one of the things the "Linux movement" is supposed to be about? Or does "freedom to choose" only mean "freedom to choose Linux".
Slashdot Mirror
The previous posting was written by me. (Damn slashdot, now I'm not going to whore any K4rM4)
Actually you'd have to fork off 4.4BSD-Lite2 because all of the later contributions to Free/Net/OpenBSD were made under the then-existing license (not GPL-compatible), and some of the contributors may not want their work relicensed without permission. The code owned by UCB can be (and was) relicensed by them, but code contributed by third parties can't be without the permission of all involved.
> Straight off, I get the message that this user is not in the appropriate group to su to root.
This has been the default behaviour in BSD-derived UNIXes since the 80s. For example, under FreeBSD:
bash-2.03$ su
su: you are not in the correct group to su root.
You have to be in the 'wheel' group to su to root. I think some versions of Linux don't do it this way (i.e. joe random luser can su to root if he knows the password), but thats hardly a reason to blame OpenBSD for it.
I'm sure OpenBSD's installation lets you specify the groups you want your user account to be in, so this could have easily been overcome if you knew the basics of administering a BSD-derived UNIX.
Minor nit: ftp.cdrom.com and ftp.freesoftware.com are not the same machine. ftp.cdrom.com was sold off by Walnut Creek CDROM (it still runs FreeBSD - they're not stupid and need to keep up with the load), but ftp.freebsd.org is now hosted on ftp.freesoftware.com, also running FreeBSD on a similar platform.
It's not an emulator - it's linux ABI compatability. Basically, the kernel loads in a different system call interface when running a linux binary, and so the binary can make all of the native linux system calls it expects while running on the bare hardware (i.e. not from a virtual machine).
Basically, the FreeBSD kernel reconfigures itself to look like a Linux 2.2.x kernel from the point of view of a linux binary ("I can't believe it's not Linux!") - quite cool, really.
See http://www.freebsd.org/handbook/x20065.html ("How does the Linux mode work?") for a more detailed explanation.
The user-threads library (libc_r) uses call-conversion to map blocking syscalls to nonblocking ones, so when a thread makes a blocking syscall the thread scheduler can just switch to another thread and carry on as if nothing happened.
Blocking on syscalls should not be an issue with libc_r (and this is also the case in 3.x - the changes to the 4.0 libc_r weren't in this area).
Not that I'm knocking OpenBSD - I like and respect it - but the audit they did was hardly "line by line". What they did was go through the source looking for likely problems (use of potentially unsafe functions, etc) - some parts more thoroughly than others, to be sure. They fixed a lot of potential and actual problems (security and otherwise), but not all of them.
Most of the bugs they fixed fall into the "paranoia" category, i.e. they could conceivably lead to a security problem if the admin does something really weird with the program, but under 99% of normal use they're just a regular bug which causes the program to fail.
The FreeBSD auditing project is certainly alive and getting results. Yes, OpenBSD fixed most of the problems a while ago, but the FreeBSD auditing guys already found a number of bugs which OpenBSD missed the first time around, and as a result both OSes are better for it.
Most of the OpenBSD user-land security fixes, and a good proportion of the kernel ones, are being merged back into FreeBSD (I'm should know, I'm doing the work myself). Expect to see a lot more focus on security in FreeBSD in the future.
Does this mean that OpenBSD will lose its market niche? I don't think so - they'll always be more security-paranoid than the rest of us are willing to be, I think (some of the changes they've made involve breaking backwards-compatability or introducing changes which have other slight negative side-effects, in the name of security)
They wouldn't even have to start a new BSD project. BSDI can't steal the FreeBSD name, because (while Walnut Creek owns it right now until the FreeBSD Foundation can be set up to transfer it to) the administration rights to the trademark belong to FreeBSD-core, who you can bet would not give them up to a commercial distribution.
The best BSDI could do is to take the FreeBSD code, merge it with BSD/OS and create PlusBSD 5.0 - which is what *anyone is allowed to do and do all the time*, and FreeBSD will continue unchanged as before.
BSDI can't "assimilate" FreeBSD because neither Walnut Creek, nor the new merged company will have control of it. Control rests firmly where it always has, in the hands of FreeBSD Core.
Sure, BSDI could take the free version of FreeBSD and make their own proprietary version - but wait, they always could, and did exactly this with BSD/OS (which incorporated some amount of FreeBSD code). This hypothetical version could not be called FreeBSD, because that name is administered by FreeBSD core.
You can bet that if they tried to somehow make FreeBSD non-Free, the vast majority of the developer and user base would not follow them, and would carry on developing the real FreeBSD as ever before.
There will always be a free FreeBSD out there - no-one can take away my CVS repository from me.
My take as a FreeBSD committer is that -core isn't anti-desktop, they're just not PRO-desktop. In other words, the desktop isn't the main focus of the people in -core.
More to the point, -core doesn't have anything to do with the day-to-day running of FreeBSD or what gets committed to the tree or not: that's up to the developers. So far, we've seen not much in the way of contributions from the user/developer population directed to "improving the desktop" (whatever that means). Jordan once tried to run a desktop contest for a "default desktop" and didn't get any submissions.
In a free software project, things don't happen until someone does the work - so it seems that not many people who use FreeBSD are motivated enough to work on "improving the desktop". Whenever it comes that FreeBSD should "support the desktop better" the answer is invariably "yes, better desktop support would be great! I can't wait to see your patches!" and then it goes no further.
From what I've heard so far from people close to the source, FreeBSD will NOT be changing significantly in the way we do things. The new merged company won't have direct control over anything, but will just contribute code via the "usual mechanisms" open to everyone (submitting patches, etc).
Specifically, I'd expect to see various BSDI developers who are doing useful merge work being granted commit privileges to apply their changes to FreeBSD directly, subject to the usual architectural and review policies, overseen by FreeBSD core.
"The FreeBSD Project" is being set up as an independent, nonprofit organisation of some description to ensure it stays independent of control by BSDI/WC.
Basically, what I expect to see is pretty much what we've seen from FreeBSD's main corporate sponsor in the past (Walnut Creek), namely that they pay a number of developers to work full-time on FreeBSD as members of the wider developer community, and they profit from selling the resulting product on CDROM. Since it's open source, any other company can also sell it as well (CheapBytes does).
FreeBSD-derived distributions are another issue - if someone wants to change bits of the "official FreeBSD" and repackage it, it's arguable they should have to obtain permission to use the FreeBSD trademark, which is intended to be transferred to the Foundation.
The main difference I expect to see from the status quo that we'll get a LOT more developers contributing code, and a lot of this code will hopefully be juicy BSD/OS code (e.g. I'm told their SMP implementation is quite good). The new combined company will have a lot more resources to contribute to FreeBSD-related services, like support contracts, training, book publication, advertisement, paid development sponsoring, etc.
I think this is great!
After the CSRG at Berkeley dissolved (lost funding) a bunch of the 4.4BSD guys got together and formed BSDI (Mike Karels in particular). So in a sense this merger between BSDI and the principal sponsors of FreeBSD reunites FreeBSD with its' history.
The www.bsdi.com website has a fairly good section on the company and its history..
I wonder if anyone else has noticed the common theme running through Banks' work, SF and non-SF. The Culture is fairly obviously his idea of a utopian society, but the same ideals also manifest themselves in all of his non-fiction books I have read.
:-)
:=]
His protagonists usually live a life happily involving copious amounts of drugs, booze, and casual sex and are usually living a pretty all-round contented life (or were, until something comes along to screw it up). This is fairly obviously the case in The Bridge and Complicity, and less obviously so in Whit (but if you think about it, it's almost exactly the same concept viewed from a different angle, i.e. a benevolent religious cult). In "A Song of Stone" the two main characters seemed to be living a life of happy debauchery before the war came along. I'm still working my way through his other non-SF books, but I wouldn't be surprised to see the same thread evident there.
This is by no means a complaint - Banks is one of my favourite authors: his ability to lay out and develop a story is almost unparalleled in my experience.
All I can say is that if Banks' real life is anywhere near this carefree and content, he is one lucky guy. If my life turns out anything like that I'll die a happy man
[ Side note: I'm surprised the reviewer didn't notice the (I thought fairly obvious) hints that Inversions was another Culture novel, inverted. Consider: the fact that the Doctor was from 'another place' and so far in advance of her peers, the bodyguard telling stories about how he disagreed with the philosophy of 'his people' with regard to intervention in societies, the Doctor's blunt knife with the missing stones which she had to 'exchange' to get her way out of trouble during her voyages, the fact that one of the stones temporarily disappears when she is rescued and later returns, the fact that she is rescued BY THE KNIFE [missile], and the fact that she disappears en route from her sea voyage. Perhaps I noticed it sooner because I was really hoping it would connect to his other body of work, but it was really obvious to me early on. Oh well
Yes, they are DETECTED, but not PREVENTED (the "official" SSH does this too). If I know someone has inserted data into my session, how much use it after they've already done the damage?
The comment about RSA was in response to someone else who claimed OpenSSH removed the limitation on RSA, which it doesn't. I was careful to point out that *NO* conforming SSH v1 implementation can work without RSA because it's a fundamental part of the protocol.
Can you point me to an exact URL? I could not see where they refer to fixing the insertion attack. Because this weakness is fundamental to the SSH protocol (use of CRC checksums) I don't see how they could fix it without breaking interoperability with other SSH implementations. This has come up a few times on the mailing lists..
I agree with your comments about encrypted RSA keys.
The main advantage to SRP is that it uses a simple password to authenticate, instead of requiring the user to carry around a public/private keypair with them as they move around (in other words, there's no client-side setup required beyond the installation of an SRP-capable client app). This can be the same password as the regular UNIX account password, although it's hashed in a different format and so SRP can't be used with existing password files. I've written a plugin crypt module for a replacement to FreeBSD's libcrypt which teaches crypt() how to speak SRP hashed passwords, so if you do something like this then everything else (non-SRP apps like login) will authenticate just fine. There's also an SRP PAM module floating around.
/etc/tpasswd file and brute-force attack that.
Security-wise, the authentication protocol has been well investigated, and as far as I know it's stood up fine so far - no serious weaknesses have been discovered.
On the other hand, the SSH v1 protocol as implemented by OpenSSH and all other SSH v1 implementations has an insertion attack which allows the insertion of data into the stream because of insecure integrity protection (it uses a weak checksum). The SSH2 protocol fixes the design flaws in SSH1 (as well as allowing other key exchange schemes than RSA) but OpenSSH doesn't speak it (since it's based on an old SSH 1.x distribution). Hopefully this will change in the near future.
As part of the SRP authentication handshake, a session key can be shared which allows the rest of the session to be encrypted. So SRP provides for authentication as well as secrecy, like SSH does.
SRP is just an algorithm - there's nothing preventing someone from creating a SSH-like app which authenticates using SRP, and then provides all of the port-forwarding features which SSH does. This would be quite useful, actually, and is something I'm hoping to do when I get around to bringing native SRP capability into FreeBSD.
The major downside to SRP is that the authentication is only as strong as your passphrase. But on the other hand, this is true as well in SSH if you can get a hold of someone's encrypted private key (if they carry it around with them on a floppy so they can log in from random hosts, for example). This can be mitigated by enforcing strong passphrase selection on the SRP server. An attacker sniffing the authentication exchange cannot obtain any data which is useful for determining the passphrase, even by a brute-force dictionary attack - you have to obtain access to the
The Stanford SRP distribution is distributed under a BSD-style license. This is good for most people (e.g. commercial users who want to add SRP support to their products, etc), but it may prohibit the code from being incorporated into a larger GPLed program (because of the GPL's "no other restrictions" clause and the BSDL's "must give acknowledgement" clause). Consult your lawyer..
On the whole, SRP is more practical to implement because it doesn't require per-user client-side configuration. In most ways it seems to be a superior solution which is just awaiting wider adoption.
OpenSSH, last time I checked, only implements the SSH version 1 protocol, which only supports RSA. There's no way to make it use an unencumbered PK algorithm without breaking compatability with all of the other SSH 1.x implementations out there.
:-(
The SSH 1.x protocol also has a design flaw which allows insertion of arbitrary data into the data stream, because (I believe) it uses a weak CRC checksum instead of a strong cryptographic hash to verify the data integrity. Again, fixing this would break interoperability with other SSH implementations.
The SSH v2 protocol _does_ support other forms of authentication (and strong integrity protection), I believe, but it probably would require a major rewrite to implement, and that hasnt happened yet.
If you're in the U.S. then unless you can legally use RSAREF you're SOL for OpenSSH
I dunno about you, but I always thought stroustrup() would make a really cool name for a string parsing function.
/* Oustrup the source string */
int stroustrup(const char *src, char *dst);
Ah, okay - I just checked the homepage, and I'm pretty sure this is just some guy operating out of his garage who puts computers together. In other words, he's offering HURD because he thinks it's cool and people should play with it, not because of a perceived market demand :-) That makes more sense now..
As I'm often fond of pointing out here, more OS choice and variation is a good thing (provided it's not gratuitously incompatible).
But why would anyone buy a computer with HURD preinstalled on it? I mean, it's only at version 0.2, which hasn't been updated in 3 years - how complete/useful can it really be? I can certainly see how it would be interesting to play with and/or hack on, but is it even up to the task of running a computer 24/7?
I'd be really interested to know how many of these things they actually sell.
OpenBSD fixed _a_ problem some time ago, namely the use of mktemp instead of mkstemp, which is really a fairly perfectionist thing and not a major problem. However they (Theo and Todd) only thought they'd fixed the problem I reported to them - in their earlier change they didn't actually look at HOW the tempfile was being used - turns out the same randomly-generated filename was being repeatedly created and removed, thus making a trivial race to exploit with or without mkstemp().
No real harm done - the make -j option has maximum performance on an SMP machine (which OpenBSD unfortunately do not support), although many people do report performance boosts even on uniprocessors since it makes better concurrent use of resources, e.g. CPU time for one job while the next is being read from disk.
I should also state for the record that FreeBSD is in the process of being audited in much the same way as OpenBSD was - we've already turned up a number of bugs which they missed, so I hope the combined efforts of the problems fixed by the two teams (FreeBSD is merging over all of OpenBSD's fixes as well) should leave both OSes pretty darn secure!
How can FreeBSD, a non-commercial entity, go bankrupt? This is like saying the Linux kernel is on the verge of going broke.
I didn't hear of any Linux booths at the FreeBSD Con last october - even RedHat didn't show. I thus conclude that Linux is on the verge of death.
You are a twit.
> Linux is fully POSTIX compliant.
Oh dear. Tell me, which POSTIX standards does Linux comply with? What are the manyfold advantages of the "ELF file format" over..what are the alternatives again? I'm sorry to say that you come across like someone who is just repeating what they think they heard someone else say. However, I'll give you the benefit of the doubt.
The various BSDs have lots of features, large and small, which Linux doesn't have - if you were really interested you can find out more yourself by doing a bit of research. And similarly, Linux has lots of features, large and small, which the BSDs do not have.
Even supposing there were no feature differences, they're just different. Some prefer Linux, some prefer the different structure and environment of BSD. Why should we consolidate and join the collective just because Linux also works similarly?
And then there's the fact that the BSD license is commercial-friendly (i.e. companies can do what they want with the code, not what Richard Stallman wants, namely forced disclosure of code. This is NOT friendly to the business models of most software companies). Some of us (probably most BSD developers) are coding under the BSD license because they want to raise the bar of software quality, so all companies everywhere (yes, even the evil ones like microsoft) can use the same high-quality code as a starting point even if they want to keep it closed-source. It's about providing tools to everyone, regardless of their ideology towards keeping software open.
As someone else said recently, without this "copycenter" (thanks to Kirk McKusick for this wonderful expression) approach to software, there would not BE an internet today and we'd all be using OSI for our networking.
Why must we all be forced into a one world, one OS, one true Linux (or Microsoft) way? Isn't the ability to choose one of the things the "Linux movement" is supposed to be about? Or does "freedom to choose" only mean "freedom to choose Linux".
Well, they do carry The Complete FreeBSD, which has (from memory) 3.3 :-)
It's a start