OpenBSD Journal

OpenCVS is imported into the OpenBSD tree

Contributed by phessler on from the if-ya-break-cvs-we-hunt-ya-and-break-yer-legs dept.

Several readers have written in to mention that OpenCVS has recently hit the OpenBSD tree. Current plans are to keep what's good about cvs, fix the rest, and then start adding goodies. The first major goal is to be a drop-in replacement for GNU cvs. Please read the README for caveats, and any gotchas. Right now local mode does not work, so you'll have to run it over ssh ( '-d user@server:/cvs' rather than '-d /cvs' ). It goes without saying that local mode will be added at a later time.

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)


Comments
  1. By FSCKER (84.31.5.200) on

    Very nice... OpenSSH, OpenBGPD, OpenCVS ... what's next?

    Comments
    1. By Anonymous Coward (66.131.114.202) on

      > Very nice... OpenSSH, OpenBGPD, OpenCVS ... what's next?
      OpenYourPocket? ;-)

    2. By Anonymous Coward (24.201.62.155) on

      You missed OpenNTPd - just wished they had named it OpenNTP instead though...

    3. By Anonymous Coward (205.240.34.204) on

      OpenHTTPD

      Comments
      1. By FSCKER (84.31.5.200) on

        Yeah, I thought of that, but does the Apache License permit it to be forked under the BSD license?

        Comments
        1. By Anonymous Coward (141.157.218.58) on

          you do realise that all of the new OpenBSD projects are complete re-writes, don't you? They are not forks, so the Apache license is not applicable if they were to go out and start the OpenHTTPD project...

          Comments
          1. By FSCKER (84.31.5.200) on

            Yes offcourse they are rewrites, however the person I responded to was probably referring to the recent changes to Apache in the CVS tree, wich is headed into a forked version of Apache 1.3, instead of being completely rewritten, from my point of view. Therefor I asked if the Apache license permits a fork to be released under the BSD license.

            Comments
            1. By Michael Knudsen (82.150.71.100) on

              httpd was forked long ago when ASF started allowing unfree licenses in the code.

          2. By jose (204.181.64.2) on http://monkey.org/~jose/

            not entirely true. openssh started with the ssh.com 1.2.12 codebase, which was the last free codebase. while it's been largely rewritten and extended (ie for SSH-2.0 protocol support), this shows that not all open* projects start out with fresh code.

            Comments
            1. By Anonymous Coward (141.157.218.58) on

              my comment was about "the new code", not OpenSSH. OpenNTPD, OpenBGPD, &c. are complete re-writes, which is what I was refering too.

              Comments
              1. By Anonymous Coward (217.227.65.140) on

                if we already split hairs, we should do it all the way: OpenBPGD is not a re-write, it's new software.

            2. By Nate (24.112.240.105) on

              Yeah, I think if the OpenBSD team were to do a webserver it would likely be a fork of thttpd, though it would be great to see a Huron project (Huron were a different native American people). Would be even better with Huron able to run Apache modules. Well, a guy can dream.

              Comments
              1. By Brad (216.138.200.42) brad at comstyle dot com on

                lighttpd would be a better starting point.

    4. By kami petersen (217.215.10.111) on

      by now it seems reasonable to expect the next remote root exploit to affect OpenBSD users would come with the mail... it seems to be no secret that sendmail is only kept because it is the only full-blown mta with a reasonable license.

      how about OpenSMTPD?

      Comments
      1. By Anonymous Coward (69.197.92.181) on

        That's a remarkably dumb statement. Sendmail is localhost only by default, and when is the last remote root exploit for sendmail?

        Comments
        1. By Anonymous Coward (84.31.5.200) on

          At least two that are not known to the public. I'm not gonna try to prove anything, but if you are going to run an mailserver, pick Exim. It's simply safer.

          Comments
          1. By Anonymous Coward (69.197.92.181) on

            Yeah, that's pretty credible. And seriously, of all the sendmail alternatives, exim has the worst security track record.

          2. By henning (80.86.183.226) on

            please do not ever run Exim. It is worse than sendmail 8 years ago.

        2. 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
          1. By Anonymous Coward (217.215.84.114) kami petersen on

            [link fixed, sorry]

            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.

    5. By Nuintari (64.246.97.5) on

      I love to see a new implmentation of OSPF, I'm not too fond of Zebra.

      Comments
      1. By Anonymous Coward (203.217.30.86) on

        http://xbsd.dk/xospf/index.html

        Comments
        1. By dan (80.178.221.196) on

          When is it gonna be released?
          And where can i find the manpage?

    6. By Frank Denis (213.41.131.17) f@00f.net on http://www.00f.net

      Opensubversion ?

    7. By Christopher (24.229.80.6) on

      OpenDHClient?

      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
      1. By Anonymous Coward (63.193.246.134) on

        IMHO, the world will be a better place if everyone purges ISC bloatware from their boxen once and for all, and if Brad Knowles learns to shut his fscking gob. The latter's record of deceit on the DNS issue is such that it is amazing that any sensible person should even consider listening to his regurgitations.

  2. By Anonymous Coward (24.102.88.31) on

    Don't get me wrong... I love OpenBSD and the excellent work they do... but don't you think that there is a trend emerging?

    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
    1. By Brad (216.138.200.42) brad at comstyle dot com on

      If would be nice if you would point out WHAT standards are being ``destroyed'' ?

      Comments
      1. By original commenter (24.102.88.31) on

        I speak of unofficial standards. I am not referring to IETF. Those are official or explicit standards. For example, do you suppose that your (so called) portable script which calls cvs on some environments and opencvs on others will work perfectly everywhere? What about when opencvs adds some nifty feature? And suddenly your script that worked beautifully from cygwin to openbsd, now suddenly breaks on cygwin. These sort of problems often show up between GNU and BSD userland utilities. I am still looking forward to using opencvs though.

        Comments
        1. By Otto Moerbeek (213.84.84.111) otto@drijf.net on http://www.drijf.net

          These sort of problems often show up between GNU and BSD userland utilities.

          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.

        2. By Jean-Francois Brousseau (70.48.129.71) jfb at openbsd dot org on

          After seeing the amount of misinformation that has been circulating regarding OpenCVS in the last weeks, I believe it's time I come out of my cave and debunk some of the stuff out there. First, let's make something clear: I did not rewrite CVS for licensing issues. CVS is a relatively large piece of software and its internals aren't very well documented, so I had to have better reasons to damage my brain. If you take a moment to look at the CVS source code (gnu/usr.bin/cvs/src), you will quickly realize that, as Niklas Hallqvist said it best, it has become write-only code. There comes a point in the life of a software where it is best to start some parts over, and I believe you get close to this point when half of the comments in the code raise questions instead of answering ones. I have heard a lot of people whine that we should really be moving to Subversion because it is the logical successor to CVS, and that OpenCVS will only slow the migration. To this, I reply one of the first lessons I learned when I started working on OpenBSD: "Why fix it if it's not broken?". CVS is still the most widely used version control system for open source projects and is in use in a LOT of companies. It has been doing the job for a long time and very well at that. And I really don't see the point of getting rid of the repository format. We are not looking for new amazing as-seen-on-TV version control features, just a clean and safer CVS implementation. Now about compatibility, notice one of the three main goals on the OpenCVS web site: Stay as compatible as possible with GNU cvs without compromising the security of the system. Obviously, we will have a particular focus on making sure that opencvs behaves like gnu cvs whenever it can. The problems related to security are mostly related to the connection method used (i.e. pserver) and the authentication mechanism. Command-line options will stay the same (some might have no effect, but it will be documented). As for new features, OpenCVS can detect upon connection to a server what version of CVS the server is running, so it will be able to make use of any special features we add without breaking compatibility for other CVS implementations. Hope this answers some questions, -jf

    2. By djm@ (218.214.226.34) on

      These are implementations of standard protocols, so I don't understand what you mean about "destroying standards". Competing implementations are good for everyone, and even an IETF requirement for protocol acceptance.

      Comments
      1. By Nate (24.112.240.105) on

        I think he refers to CARP not being VRRP and OpenNTPd not being NTPd.

        Comments
        1. By henning (80.86.183.226) henning@ on

          OpenNTPD is a perfectly fine NTP implementation. Don't let soem idiots with an agenda fool you.

        2. By Anonymous Coward (213.118.35.44) on

          I think he was referring to "except when particular features reduce the overall security of the system". I personally think this is a good development. However, I wonder, why CVS and not SVN? I personally prefer SVN, so saying "because the openbsd devs like CVS better" is good enough for me.

          Comments
          1. By Brad (67.69.154.28) brad at comstyle dot com on

            The OpenBSD source code is in a CVS repo. What the f#$k is so hard to understand about that? If we wanted to use crappy Subversion then we would.

            Comments
            1. By Anonymous Coward (213.118.35.44) on

              So much hatred into one post. Are you too thick to formulate a non-insulting reply? Or is that simply too much to ask?

              Comments
              1. By Anonymous Coward (68.124.60.213) on

                > " So much hatred into one post."

                That would be *anger*, not "hatred".

          2. By Mathieu Sauve-Frankel (207.134.69.164) msf@openbsd.org on http://www.openbsd.org

            Here's one good reason the OpenBSD project will NEVER consider using stock subversion.
            While subversion's license is BSDish, Subversion depends on the Apache portable runtime, which has the same unacceptable license as Apache 2.

            Comments
            1. By Anonymous Coward (213.118.35.44) on

              That explains it, thanks.

          3. 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
            1. By Anonymous Coward (68.202.41.228) on

              Indeed, you'd use a conversion tool to import your history. (although the tools available to go from CVS to SVN are, arguably, imperfect at the moment)

  3. 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
    1. By Ash'aman (212.135.28.58) on

      There is also this updated entry

      Comments
      1. By djm@ (203.217.30.86) on

        And a rebuttal

        Comments
        1. By Ash'aman (80.42.116.139) on

          Nice one!

    2. 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
      1. By Charles Hill (216.229.170.65) on

        A couple thoughts.

        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.

      2. By Anonymous Coward (69.197.92.181) on

        Theo and henning? Alexander Guy wrote it, henning used the bgpd server code and Alexander's ntp code to make the daemon. Alexander also seems to have stopped working on it, and I've seen it claimed that he stopped because he disagrees with openntpd's minimal, good enough approach. Anyone know if there's any truth to this rumor?

    3. By henning (80.86.183.226) on

      no, it is entirely bullshit.
      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
      1. By gwyllion (134.58.253.113) on

        Why were hardware clocks abandoned? Lack of testing by users?

      2. By David Schwartz (206.171.168.138) on

        The system clock resolution on modern x86 systems using Pentium processors is on the order of a billionth of a second. The TSC (processor instruction clock cycle counter) can (and on many operating systems *is*) used to add an offset to the time of the last clock interrupt.

        DS

        Comments
        1. By henning (213.128.133.133) on

          kernel tick frequency is 100 Hz. Period.

          Comments
          1. By djm@ (218.214.226.34) on

            1khz may be nicer for ALTQ scheduling

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]