It was imported by copying the repository files that jfb@ has been working in his own cvs tree. You can still get the history from "cvs log", so why is this a problem?
probably not, unless you can be bothered to type public key challenges and responses (they can be long). If you are concerned about password authentication, use skey.
I'm... pissed off that I heard of this only
yesterday, and not 4 weeks ago or so when they
started; so much for their "live cvs mails"
If you follow CVS, then you should already know that most imports are done once a subproject is already at a certain level of maturity. That is what happened with opencvs.
[of subversion]
Plus I don't trust databases.
subversion-1.1 doesn't need them. it can use the filesystem for storage
i should disclose that i am embittered from five years of bashing my head against it, trying to make it work for all the obsure uses that people put it to in portable openssh:)
1) Poorly-specified - there are several ambuiguities in the spec, some with security implications if you get it wrong.
2) Implementation differences between Linux-PAM, Sun PAM and OpenPAM - as a direct result of (1) above.
3) Useless broken API which is completely blocking (i.e it prompts for an expects to receive the password/response in a single function call) - making is near-useless for a network application without major trickery
4) Broken design that requires loadable modules which are encouraged by the API to pass opaque data behind the back of the calling application
5) Total lack of separation between policy and mechanism - users are expected to configure policy by specifying which loadable modues are loaded using a silly and restrictive grammar.
6) Zero standardisation for modules or their arguments. As a result, everyone implements things a little bit differently.
If the same class of people are doing opencvs then should we assume that the only safe environment to run opencvs will be OpenBSD, until otherwise proven?
The "class of people" responsible for the bug in portable OpenSSH was me and nobody else - so please don't impugne the other OpenBSD developers.
The fact that the 3.7.1 hole was not exploitable on OpenBSD was due to the fact that the bug related to PAM authentication, which OpenBSD doesn't use (for good reason).
BTW, the bug was a logic error that could have been made in any language, so the standard Slashdolt cry of "C is insecure, use XXX" wouldn't have saved you.
gcc isn't perfect, but it isn't nearly as annoyingly bad as some of the other stuff we have to use. More importantly, it doesn't have to deal with untrusted network data (like cvs does).
A BSD licensed cc would be nice, but an absolute crapload of work - especially renovating all those programs and ports that depend on gccisms (some of which are perfectly reasonable)
In the last two months I have written my first two Python extensions (and a Perl one). It isn't too hard - it is a little confusing until you get your head around the refcounting and type API, but then it is very easy and quite elegant.
Of course, swig makes is trivial for some tasks, but the code that I was working with wasn't a brilliant fit.
IMO is it a little bit easier to write Python extensions than Perl ones.
I don't understand why this hydrogen production method requires the unobtainium of a high-temperature nuclear reactor - it sounds like the breakthrough is in the electrolysis method. Couldn't this be applied to (say) a solar furnace?
The pf integration is quite self-contained. It could be easily disabled or modifed to work with iptables, though I don't think iptables supports the fast radix-tree table lookups that pf does (maybe there is a module though).
Interfacing with the kernel routing table is highly platform-dependant, there is not avoiding that. Beyond this, if someone wants to make a port, most of the necessary glue can be lifted from OpenSSH's libopenbsd-compat or Darren Tucker's OpenNTPd port - someone just needs to do the work:)
Many, many sites use BGP at less that 8Gbps aggregate throughput - hell I know of several sites that still run partial feeds over ISDN BRI. I just don't see where you get the idea that BGP is only for core routers.
The crap about Geiger counters seems to indicate the author seems more interested in studly buzzwords than actually developing practical solutions. A soundcard with nothing plugged in is a perfectly acceptable source of entropy, the problem is just in accurately estimating the rate. Also, many chipsets and an increasing number of CPUs include hardware random number generators which can be used too.
Have you read the Postfix license? In particular clause 4. It is really scary for anyone distributing Postfix and is the reason why OpenBSD refuse to consider it for inclusion in the base system. So like another MTA: great software, crap license.
Is that REALLY a major issue with todays larger memory sizes?
I don't know for you, but it does matter to me.
And isn't it just a little shaddy to compare a statically liked app to a dynamic app?
You have this backwards. Staticly linked binaries would normally be expected to be *bigger* than dynamic ones. Static BSD/bin/sh is half the size of a dynamic/bin/bash.
I suppose you mean getopt_long and not getopt (which IIRC originated in BSD). I suspect that if you use BSD for a while, you may find that you have less need to for the --long-options because the documentation is usually much better on BSD systems (and not suffed into those atrocious info files). If you value terseness or you have to write portable shell scripts, then you probably won't want to use the --long-options anyway.
$ ls -l/bin/ksh -r-xr-xr-x 3 root bin 319788 Aug 29 01:09/bin/ksh $ ldd/bin/ksh /bin/ksh: ldd:/bin/ksh: not a dynamic executable $ file/bin/ksh /bin/ksh: ELF 32-bit LSB executable, Intel 80386, version 1, for OpenBSD, statically linked, stripped
bash is over 80% larger, even without taking into account the libraries that it must pull in. Yes, bash has more features, but I don't miss them using ksh. The other tools are similar in their minimalism.
Re:where are the IPv6 native ISPs?
on
IPv6 is Here
·
· Score: 1
Ditto Melbourne, Australia - No ISP I have asked has plans to offer even experimental native access to consumers. Most didn't even understand the question. Fortunately there are some nearby migration brokers, but they all use the awful TSP client - no public static 6over4 or IPsec tunnel brokers:(
It is interesting to see posts like this turn up on Slashdot and other fora. These posts are tendentious, often personally insulting and usually written by someone who is obviously pretty closely involved with whatever group they are ranting about from behind their cover of anonymity. Why be anonymous in cases like this? Don't you have the guts to put your name to your accusations? Do you really think that you will change things you don't like by spewing venom anonymously?
Slashdot Mirror
It was imported by copying the repository files that jfb@ has been working in his own cvs tree. You can still get the history from "cvs log", so why is this a problem?
probably not, unless you can be bothered to type public key challenges and responses (they can be long). If you are concerned about password authentication, use skey.
I'm ... pissed off that I heard of this only
yesterday, and not 4 weeks ago or so when they
started; so much for their "live cvs mails"
If you follow CVS, then you should already know that most imports are done once a subproject is already at a certain level of maturity. That is what happened with opencvs.
[of subversion] Plus I don't trust databases.
subversion-1.1 doesn't need them. it can use the filesystem for storage
i should disclose that i am embittered from five years of bashing my head against it, trying to make it work for all the obsure uses that people put it to in portable openssh :)
1) Poorly-specified - there are several ambuiguities in the spec, some with security implications if you get it wrong.
2) Implementation differences between Linux-PAM, Sun PAM and OpenPAM - as a direct result of (1) above.
3) Useless broken API which is completely blocking (i.e it prompts for an expects to receive the password/response in a single function call) - making is near-useless for a network application without major trickery
4) Broken design that requires loadable modules which are encouraged by the API to pass opaque data behind the back of the calling application
5) Total lack of separation between policy and mechanism - users are expected to configure policy by specifying which loadable modues are loaded using a silly and restrictive grammar.
6) Zero standardisation for modules or their arguments. As a result, everyone implements things a little bit differently.
Those are just the ones off the top of my head.
If the same class of people are doing opencvs then should we assume that the only safe environment to run opencvs will be OpenBSD, until otherwise proven?
The "class of people" responsible for the bug in portable OpenSSH was me and nobody else - so please don't impugne the other OpenBSD developers.
The fact that the 3.7.1 hole was not exploitable on OpenBSD was due to the fact that the bug related to PAM authentication, which OpenBSD doesn't use (for good reason).
BTW, the bug was a logic error that could have been made in any language, so the standard Slashdolt cry of "C is insecure, use XXX" wouldn't have saved you.
gcc isn't perfect, but it isn't nearly as annoyingly bad as some of the other stuff we have to use. More importantly, it doesn't have to deal with untrusted network data (like cvs does).
A BSD licensed cc would be nice, but an absolute crapload of work - especially renovating all those programs and ports that depend on gccisms (some of which are perfectly reasonable)
The point of the rewrite it to have a secure, readable replacement for CVS. The license thing is just a bonus.
Why would you use anything other than ssh?
I don't know where you got that idea.
I lay my bike down to activate the induction sensor in our basement carpark so I can raise the security door :)
In the last two months I have written my first two Python extensions (and a Perl one). It isn't too hard - it is a little confusing until you get your head around the refcounting and type API, but then it is very easy and quite elegant.
Of course, swig makes is trivial for some tasks, but the code that I was working with wasn't a brilliant fit.
IMO is it a little bit easier to write Python extensions than Perl ones.
I don't understand why this hydrogen production method requires the unobtainium of a high-temperature nuclear reactor - it sounds like the breakthrough is in the electrolysis method. Couldn't this be applied to (say) a solar furnace?
The pf integration is quite self-contained. It could be easily disabled or modifed to work with iptables, though I don't think iptables supports the fast radix-tree table lookups that pf does (maybe there is a module though).
Interfacing with the kernel routing table is highly platform-dependant, there is not avoiding that. Beyond this, if someone wants to make a port, most of the necessary glue can be lifted from OpenSSH's libopenbsd-compat or Darren Tucker's OpenNTPd port - someone just needs to do the work :)
Many, many sites use BGP at less that 8Gbps aggregate throughput - hell I know of several sites that still run partial feeds over ISDN BRI. I just don't see where you get the idea that BGP is only for core routers.
I think that you have been lied to. see here (and the discussion that ensues).
The crap about Geiger counters seems to indicate the author seems more interested in studly buzzwords than actually developing practical solutions. A soundcard with nothing plugged in is a perfectly acceptable source of entropy, the problem is just in accurately estimating the rate. Also, many chipsets and an increasing number of CPUs include hardware random number generators which can be used too.
Have you read the Postfix license? In particular clause 4. It is really scary for anyone distributing Postfix and is the reason why OpenBSD refuse to consider it for inclusion in the base system. So like another MTA: great software, crap license.
Is that REALLY a major issue with todays larger memory sizes?
I don't know for you, but it does matter to me.
And isn't it just a little shaddy to compare a statically liked app to a dynamic app?
You have this backwards. Staticly linked binaries would normally be expected to be *bigger* than dynamic ones. Static BSD /bin/sh is half the size of a dynamic /bin/bash.
Brilliant.
I suppose you mean getopt_long and not getopt (which IIRC originated in BSD). I suspect that if you use BSD for a while, you may find that you have less need to for the --long-options because the documentation is usually much better on BSD systems (and not suffed into those atrocious info files). If you value terseness or you have to write portable shell scripts, then you probably won't want to use the --long-options anyway.
Compare:
bash is over 80% larger, even without taking into account the libraries that it must pull in. Yes, bash has more features, but I don't miss them using ksh. The other tools are similar in their minimalism.
Ditto Melbourne, Australia - No ISP I have asked has plans to offer even experimental native access to consumers. Most didn't even understand the question. Fortunately there are some nearby migration brokers, but they all use the awful TSP client - no public static 6over4 or IPsec tunnel brokers :(
It is interesting to see posts like this turn up on Slashdot and other fora. These posts are tendentious, often personally insulting and usually written by someone who is obviously pretty closely involved with whatever group they are ranting about from behind their cover of anonymity. Why be anonymous in cases like this? Don't you have the guts to put your name to your accusations? Do you really think that you will change things you don't like by spewing venom anonymously?