Contributed by phessler on from the if-ya-break-cvs-we-hunt-ya-and-break-yer-legs dept.
Currently implemented commands include: add, annotate, checkout, commit, diff, init, update, tag, status, log, and version. Others will be implemented as needed (or as diffs come in).
cvsd (the daemon process) is already chroot'd and privsep'd, and will support a 'local' anoncvs user (i.e. not requiring one on the local system). ACLs will also be implemented, allowing the admin to restrict access to users, or groups. There are also plans for async repo updates, in which a commit is propagated to certain mirrors within minutes, rather than waiting for an out of band process to kick off. Atomic commits are a TODO item, but won't happen until after all of the base features are complete.
(Comments are closed)
By FSCKER (84.31.5.200) on
Comments
By Anonymous Coward (66.131.114.202) on
OpenYourPocket? ;-)
By Anonymous Coward (24.201.62.155) on
By Anonymous Coward (205.240.34.204) on
Comments
By FSCKER (84.31.5.200) on
Comments
By Anonymous Coward (141.157.218.58) on
Comments
By FSCKER (84.31.5.200) on
Comments
By Michael Knudsen (82.150.71.100) on
httpd was forked long ago when ASF started allowing unfree licenses in the code.
By jose (204.181.64.2) on http://monkey.org/~jose/
Comments
By Anonymous Coward (141.157.218.58) on
Comments
By Anonymous Coward (217.227.65.140) on
By Nate (24.112.240.105) on
Comments
By Brad (216.138.200.42) brad at comstyle dot com on
By kami petersen (217.215.10.111) on
how about OpenSMTPD?
Comments
By Anonymous Coward (69.197.92.181) on
Comments
By Anonymous Coward (84.31.5.200) on
Comments
By Anonymous Coward (69.197.92.181) on
By henning (80.86.183.226) on
By kami petersen (217.215.84.114) on
where does it say that all that OpenBSD developers and users care about is the default install? you can't do shit with default install. and is cvs server isn't really on by default. or BGPD. NTPD wasnt on before either.
are you denying that sendmail and apache are the two weakest points of exposure in common use on OpenBSD boxen today? of course these are huge tasks but probably not too far fetched since:
* they are huge lumps of ancient code.
* they are written by Sam van Else.
* they are suitable for the standard OpenBSD security tricks.
and by the way, for the ostrich above, here's a painful reminder.
Comments
By Anonymous Coward (217.215.84.114) kami petersen on
where does it say that all that OpenBSD developers and users care about is the default install? you can't do shit with default install. and is cvs server isn't really on by default. or BGPD. NTPD wasnt on before either.
are you denying that sendmail and apache are the two weakest points of exposure in common use on OpenBSD boxen today? of course these are huge tasks but probably not too far fetched since:
* they are huge lumps of ancient code.
* they are written by Sam van Else.
* they are suitable for the standard OpenBSD security tricks.
and by the way, for the ostrich above, here's a painful reminder.
By Nuintari (64.246.97.5) on
Comments
By Anonymous Coward (203.217.30.86) on
Comments
By dan (80.178.221.196) on
And where can i find the manpage?
By Frank Denis (213.41.131.17) f@00f.net on http://www.00f.net
By Christopher (24.229.80.6) on
Looking at top on my very meager gateway, it is taking up way more ram for what it does than the rest. Twice as much as each apache child process, almost 3 times as much as sendmail, and about the same as bind9 running authoritative for a few zones and caching for internal hosts. I just don't understand what the DHCP client is doing with all that ram =)
It's about an order of magnitude more than the DHCP server!
Comments
By Anonymous Coward (63.193.246.134) on
By Anonymous Coward (24.102.88.31) on
OpenBSD team being frustrated with how others do things and doing it themselves. Sure the team does do a much better job than the others... but this does hurt consistency and relevance of (unofficial) standards. Sure some of this work actually becomes a standard (openssh is the perfect example), but this is not always the case.
Microsoft destroys standards too, but their reasons are rooted in $money$. OpenBSD seems to destroy standards for quality reasons. A much more noble cause, but it still hurts the standards.
Comments are most welcome...
Comments
By Brad (216.138.200.42) brad at comstyle dot com on
Comments
By original commenter (24.102.88.31) on
Comments
By Otto Moerbeek (213.84.84.111) otto@drijf.net on http://www.drijf.net
It's not a problem of the tools itself but of the usage of these commands. If you stick to to Posix mandated flags, you should be ok. We try to be explicit about deviations or additions to Posix. A problem seems to be that some people regard certain GNU extensions to commands as being standard,
One of the goald of OpenCVS is to be a replacement of GNU cvs, the de facto standard. Additions will be documented as such, and so you can decide for yourself if you want to use them.
By Jean-Francois Brousseau (70.48.129.71) jfb at openbsd dot org on
By djm@ (218.214.226.34) on
Comments
By Nate (24.112.240.105) on
Comments
By henning (80.86.183.226) henning@ on
By Anonymous Coward (213.118.35.44) on
Comments
By Brad (67.69.154.28) brad at comstyle dot com on
Comments
By Anonymous Coward (213.118.35.44) on
Comments
By Anonymous Coward (68.124.60.213) on
That would be *anger*, not "hatred".
By Mathieu Sauve-Frankel (207.134.69.164) msf@openbsd.org on http://www.openbsd.org
While subversion's license is BSDish, Subversion depends on the Apache portable runtime, which has the same unacceptable license as Apache 2.
Comments
By Anonymous Coward (213.118.35.44) on
By Michael Knudsen (82.150.71.100) on
You don't throw away eight years of revision history because you like another SCM tool better.
Comments
By Anonymous Coward (68.202.41.228) on
By Chas (147.154.235.51) on
I came across this commentary on OpenNTPd when reading the OpenCVS announcement on slashdot a few days ago.
Are these valid points?
Comments
By Ash'aman (212.135.28.58) on
Comments
By djm@ (203.217.30.86) on
Comments
By Ash'aman (80.42.116.139) on
By krh (207.75.179.180) on
Well, I don't know these things in detail, but...
As far as I can tell, some of his points are valid, and others are not. I don't know what aspects of the NTP protocol OpenNTPd does and does not implement, but here is what strikes me as important omissions: Server authentication, lack of which can be a security hazard; and disciplining of the local clock, which helps you keep better time (and that's the whole point, after all).
On the other hand, I find some of his arguments unconvincing: Detection of falsetickers assumes, practically speaking, not only a lot less trust in the NTP system, but also that you regularly use multiple sources of time. This may be important if you want to have the most accurate time possible, but most people just pick one server and go with it. Broadcast, manycast, and multicast modes assume that processing NTP requests causes a big slowdown. This may be true with the ISC NTP daemon, but I have faith in the OpenBSD developers. ntptrace is a debugging tool. I don't know if the NTP messages it uses are part of the standard protocol or are ISC specific (if the latter, he has no ground to stand on), but, from a practical perspective, they're unnecessary. And most people will never use a reference clock, so while they may be handy I doubt there's any immediate need to implement them.
At least one of his arguments, about portability, is completely wrong. I looked inside the ISC NTP daemon once. I can fully understand his concerns about codebase divergence, because that is what has happened to ISC's ntpd, even though it has not officially forked. Everything is controlled by large masses of system-specific ifdef's. I had trouble even finding main(), because some of the systems they support do not, so far as I could tell, call main() to start with, and others require bizarre startup rituals, and they work around this with ifdef's and multiple copies of main() and xxx_main() for various systems xxx, all in one mostly undocumented file. I suspect that the cross-platform compatibility techniques he refers to are ugly hacks. I concede that they may be portable, but I refuse to think they are the right way to do things.
He quotes someone else as saying that Theo and Henning wrote OpenNTPd for themselves. I don't think that's a bad thing. If he's so concerned about some sort of electronic social justice, he should write code that I'm not scared to use.
Comments
By Charles Hill (216.229.170.65) on
OpenNTPd looks nice for the small server or desktop user who just wants his clocks to match to the minute, or maybe second. You're right, most people just pick a time server and forget about it.
However, for use where time sync is absolutely critical, it isn't the right tool for that job. Things like telephone networks, WANs, and scientific work frequently need super accurate timing to work properly. I fought with Verizon's DSL provisioning system in the New England area for a week before finding out their time sync was FUBAR. We ended up installing a couple Stratum-1 GPS receivers in different locations and getting everything properly synced. The analog phone network lives and dies by time sync.
As for your comment on broadcast, multicast, etc. possibly being an issue with the ISC daemon... no. The issue is not with the daemon, but with network traffic on large and widespread networks. It is a bandwidth and latency issue, not software issue. Syncing 10,000 machines over 10 States using three different time servers, with different speed links (T1, 56k FR, GbE, etc.) and it would become painfully apparant.
My main problem is I like the Open tools (BSD, SSH, etc.) because not only of their attention to security, but the anal-compulsive attention to making it the best possible product in terms of bug-free and security. OpenNTPd seems more along the lines of the "good enough" mentality, not keeping with the rest of the Open family.
Of course, it is a new product and may just need time to mature. I hope this is the case.
By Anonymous Coward (69.197.92.181) on
By henning (80.86.183.226) on
let's pick a few p(o)ints out of the endless amount of content-free bla bla bla on that page:
<quote>
They do not implement any of the standard server authentication methods. They do use a "cookie" scheme to try to help ensure that the client really does get a response back from the server it sent a query to, but that's as far as they go. Since NTP is done via UDP, it is trivially easy to spoof these packets -- you could easily conduct a man-in-the-middle attack, feeding back the cookie they sent in the way they expect to receive it, and make the client think whatever you wanted them to think
</quote>
Brad clearly does not know what he is talking about here.
Please let us look at how compicated an attack is, and what you gain.
-You need to be able to sniff traffic between the client and the server.
-You need to be able to reply faster than the real server (of course the cookie is invalidated after use)
these are two hard to meet requirements, making it hard for an attacker.
but what do you gain?
you got us ONE WRONG ANSWER, that will not survive the following filter steps.
Now if you could send us faled replies from all servers, yes, we're in trouble. But if I am in the position (network-wise mainly) to do that, do I botehr with time? Don't I attack dns instead? And... does the md5 auth they do really help? Not too much - it is weak. Now, if you want really great secure time, shouldn't you better use IPsec between your client and your server?
fact is, their md5 scheme is not really in use.
<quote>
They do not implement any of the standard NTP algorithms to detect "falsetickers"
</quote>
fact is, we don't need to, as we can filter out the falstickers' answers in a later step. I detailed that in my slides for OpenCON 04.
<quote>
They do not implement any of the standard NTP algorithms to discipline the computer clock
</quote>
true.
fact is, that really belongs into the kernel, and we'll do something like that.
another fact is that you don't really need it. I mean, please, just look at the offsets we reach. We are limited by the system clock's resolution. Every discussion about accuracy is completely pointless form that point on, I repeat: the limiting factor is the SYSTEM CLOCK'S RESOLUTION.
<quote>
They do not implement the standard broadcast, multicast, or manycast server modes.
</quote>
so?
let's face some facts.
they'r enot really in use anyway.
they are not needed. all that babbeling about server load is pretty hilarious, we're talking one tiny ntp packet every few secodns to every few seconds to minutes, and the replies are easy to form. I cannot even really measure the cpu load ~100 clients cause on the slowest vax i could find.
so what are those mdoes good for? fact is, they are not needed for the majority, and our implementation is for a majority.
There might be some cases where it makes sense - if you're one of them, go ahead, run ntpd.org.
<quote>
They break ntptrace.
</quote>
that is simnply wrong.
<brahe@sebulba:2>$ ntptrace -n ntp.bsws.de
80.86.183.81: stratum 2, offset -0.102511, synch distance 0.01460
193.79.237.14: stratum 1, offset 0.007542, synch distance 0.00000, refid 'GPS'
<quote>
Portability. Looking at the Project Home Page, they say:
Managing the distribution of OpenNTPD is split into two teams. One team does strictly OpenBSD-based development, aiming to produce code that is as clean, simple, and secure as possible. We believe that simplicity without the portability "goop" allows for better code quality control and easier review. The other team then takes the clean version and makes it portable, by adding the portability "goop" so that it will run on many operating systems.
</quote>
yeah yeah, that must be bad, as this is exactly the sam emodel OpenSSH uses...
<quote>
As of the time of this writing, the portable version of OpenNTPd runs on five OSes (in alphabetical order: FreeBSD, Linux, MacOS X, NetBSD, and OpenBSD).
</quote>
he already missed solaris back then, and HP-UX was added later.
Those are the OSes we know OpenNTPD to run on. It should be easy to port to any unix-ish platform.
I love that paragraph in brad's rant, it so clearly shows that he doesn't understand a shit about portability.
He completely misses that this model allows for clean and thus easy to audit source code... oh well, that has been explained to death, and everybody but brad understands.
<quote>
They do not implement any reference clocks,
</quote>
that is, hardware clocks.
yes, true.
that was started and abandoned later on. maybe someone picks it up.
is it really that important for the majority of users? I say no.
oooooh, and teh best of it all:
<quote>
Their entire configuration file currently supports just three basic options</quote>
he says it as that was a bad thing :)
the opposite is true: simple configuration is good. all those stupid buttons almost nooned ever needs just complicate configuration for the majority...
please look at to where the model brad praises lead us: most unixish machines on the 'net have UNSYNCHORNIZED CLOCKS!
THOSE machines are our primary focus.
ntpd.org's stupid penis^Wfeature race and shitloads of buttons and extra modes and ignorance for security problems, an dlast not least the license fuckup, lead us to that situation. An implemetation that Just Works was overdue. And in fact, in the standard OpenNTPD install, you just need to start the daemon to get a synchronized clock, without ever touching the config file.
Comments
By gwyllion (134.58.253.113) on
By David Schwartz (206.171.168.138) on
DS
Comments
By henning (213.128.133.133) on
Comments
By djm@ (218.214.226.34) on