Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
Zach Leslie xaque...@gmail.com wrote: http://www.fossil-scm.org/ l I'm not fossil user, but it's BSD licensed in written in C. Also, this particular tool bails out on the unix philosophy, with its web gui, ticket tracker etc. Do one thing. Do it well. I would argue that git bails on that as well, but that's a different discussion. Whether or not fossil does one thing depends on which one thing you pick. If the one thing is version control, you're right. However version control is just one aspect of a larger task that does't have a common name. But if you look at systems designed for managing projects with source, you'll see they universally provide web uis, issue trackers, and wikis. Due you trash IDE's because they provide tools that are useful for doing software development instead of limiting themselves to being text editors? That fossil provides all of those things in a single relatively small program is a major win - at least for small projects (which is the fossil target). On the other hand, the fossil project does stay focused on the core task. They will reject a change proposal because it's not part of that task. That said, much as I like fossil (it's my goto VCS) I don't think it would be a good choice for FreeBSD. We're not a small project - we have people who are willing to devote time to things like an external wiki and isse tracker. Nuts, we have (had?) repos in four different VCSs! Those features in fossil are purposely kept simple since they're meant for doing one thing, not as general-purpose tools for lots of things. The issue tracker doesn't support branching issues, which is liable to cause problems in a large project. The FreeBSD wiki's are used for lots of things other than just project documents. The web ui - well, that's probably useable as is. But that one thing isn't a deal maker. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Mon, Nov 19, 2012 at 07:08:13PM -0800, Zach Leslie wrote: http://www.fossil-scm.org/ I'm not fossil user, but it's BSD licensed in written in C. Baptise Daroussin probably could tell us more about fossil pro and cons. This misses one of of the main points raised in the original post. The proliferation of git as a revision control system. Also, this particular tool bails out on the unix philosophy, with its web gui, ticket tracker etc. Do one thing. Do it well. Look at the internal of fossil and how things are done in fossil and you would understand that the last sentence is totally wrong. Fossil has really nice features that could nicely fits with FreeBSD workflows and greatly improves it. It has most of the new shiny feature everyone can expect from a dvcs, but it also has it drawbacks: The converted repositories (I did convert docs, src and ports) with full history kept: branches, tags, etc. is huge and the first clone would be painful to do. On the other side you have multiple working copies open on the same clone which is really nice. Some of the operations can be slow, Jörg Sonnenberger wrote an analysis about this one the fossil wiki, but don't remember the link sorry. From my testing, apart from the do we really need a new scm question? I am a big fan of fossil and find it easier and cleaner than all the other scm I know, I use git for pkgng and other projects, I use a lot mercurial on some other area, and fossil remains my favorite :). But I really don't think it could fit FreeBSD's requirements as it is now. but there are lots of room of improvements. The learning curve to fossil is probably really easy. On of the last thing is that fossil lacks keyword expansion. That said I'm happy with svn on FreeBSD, I still from time to time do conversion of out different tree to fossil for fun, but no more and I won't advocate for any vcs change. Bapt pgppBxhkxmBDd.pgp Description: PGP signature
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
19.11.2012 14:34, Ivan Voras wrote: On 17/11/2012 22:48, Chris Rees wrote: (and is GPL btw) Since we're discussing it, Mercurial is BSDL-ed, and apparently has proper crypto signing using GPG: http://mercurial.selenic.com/wiki/FAQ#FAQ.2FTechnicalDetails.How_do_Mercurial_hashes_get_calculated.3F :%s/BSD/LGP/ http://mercurial.selenic.com/about/ -- Sphinx of black quartz, judge my vow. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Mon, Nov 19, 2012 at 4:34 AM, Ivan Voras ivo...@freebsd.org wrote: On 17/11/2012 22:48, Chris Rees wrote: (and is GPL btw) Since we're discussing it, Mercurial is BSDL-ed, and apparently has proper crypto signing using GPG: http://mercurial.selenic.com/wiki/FAQ#FAQ.2FTechnicalDetails.How_do_Mercurial_hashes_get_calculated.3F http://selenic.com/repo/hg/file/fd903f89e42b http://selenic.com/repo/hg/file/fd903f89e42b/COPYING GNU GENERAL PUBLIC LICENSE http://selenic.com/repo/hg/file/fd903f89e42b/COPYING#l2Version 2, June 1991 http://selenic.com/repo/hg/file/fd903f89e42b/COPYING#l3 In their repository , it is GPL v2 . Is there any other place which specifies its license as BSDL ? Thank you very much . Mehmet Erol Sanliturk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Mon, Nov 19, 2012 at 1:47 PM, Volodymyr Kostyrko c.kw...@gmail.com wrote: 19.11.2012 14:34, Ivan Voras wrote: On 17/11/2012 22:48, Chris Rees wrote: (and is GPL btw) Since we're discussing it, Mercurial is BSDL-ed, and apparently has proper crypto signing using GPG: http://mercurial.selenic.com/wiki/FAQ#FAQ.2FTechnicalDetails.How_do_Mercurial_hashes_get_calculated.3F :%s/BSD/LGP/ http://mercurial.selenic.com/about/ Even if it was BSD licensed, Mercurial has a huge dependency: Python; and Git is Perl-based. So neither of them is ideal, IMHO. If at all, we'd need a lean and mean distributed SCM program like Mercurial or Git, but written in C that we could add to base. Any volunteers? -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Mon, Nov 19, 2012 at 5:10 AM, C. P. Ghost cpgh...@cordula.ws wrote: On Mon, Nov 19, 2012 at 1:47 PM, Volodymyr Kostyrko c.kw...@gmail.com wrote: 19.11.2012 14:34, Ivan Voras wrote: On 17/11/2012 22:48, Chris Rees wrote: (and is GPL btw) Since we're discussing it, Mercurial is BSDL-ed, and apparently has proper crypto signing using GPG: http://mercurial.selenic.com/wiki/FAQ#FAQ.2FTechnicalDetails.How_do_Mercurial_hashes_get_calculated.3F :%s/BSD/LGP/ http://mercurial.selenic.com/about/ Even if it was BSD licensed, Mercurial has a huge dependency: Python; and Git is Perl-based. So neither of them is ideal, IMHO. If at all, we'd need a lean and mean distributed SCM program like Mercurial or Git, but written in C that we could add to base. Any volunteers? -cpghost. -- Cordula's Web. http://www.cordula.ws/ http://mercurial.selenic.com/wiki/License http://selenic.com/hg/file/tip/COPYING http://mercurial.selenic.com/about/ Mercurial is free software licensed under the terms of the GNU General Public License Version 2 http://www.gnu.org/licenses/gpl-2.0.txt or any later version. No one of them above mentions BSD license , or dual license , etc. Thank you very much . Mehmet Erol Sanliturk Similar projects ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
http://www.fossil-scm.org/ I'm not fossil user, but it's BSD licensed in written in C. Baptise Daroussin probably could tell us more about fossil pro and cons. -- Regards, Alexander Yerenkow ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
There's a git repository. It's public. You can look at what goes into the FreeBSD git clone to get your assurance that things aren't being snuck in. People are using it, right now. I've always been confused by this. Which source repo is the true source of truth? To obtain the FreeBSD source, you can use CVS, SVN, or Git? Do all have the same level of support? Are they all up to date? Honestly, I'd rather see subversion grow this kind of cryptographic signing of each commit in the short term then migrate everyone over to git. How much effor would their really be involved, considering your link to the FreeBSD source repo on github. Converting the repos to me seems like it would be the bulk of it, and that work is already done. Help me understand please. Also, local branching and merging is amazing. -- Zach ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
http://www.fossil-scm.org/ I'm not fossil user, but it's BSD licensed in written in C. Baptise Daroussin probably could tell us more about fossil pro and cons. This misses one of of the main points raised in the original post. The proliferation of git as a revision control system. Also, this particular tool bails out on the unix philosophy, with its web gui, ticket tracker etc. Do one thing. Do it well. -- Zach ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 19 November 2012 22:04, Zach Leslie xaque...@gmail.com wrote: I've always been confused by this. Which source repo is the true source of truth? This changed a few months ago when ports and doc switched. As of now: - SVN is *the* source of truth. - CVS is exported from svn. It will eventually go away - git is exported from svn. It will remain as an option for developers (including myself). To obtain the FreeBSD source, you can use CVS, SVN, or Git? Do all have the same level of support? Are they all up to date? SVN is *always* up to date. We try really hard to keep the others up to date, but fail at times. Also, local branching and merging is amazing. +1 - but one can always use git-svn. -- Eitan Adler ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Sun, Nov 18, 2012 at 1:57 AM, Garrett Wollman woll...@bimajority.org wrote: the various good uses for nyms. There are no such uses on the FreeBSD mailing-lists; if you wish for anyone to pay attention to you, then use a real name. Otherwise, FOAD. -GAWollman It appears you have not reviewed the mailing list archives, otherwise you would have found many such nym holders engaging in good participation. However I do thank you for your opinion, and for your delightful and unwarranted private abuse. A good day to you indeed, Sir. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Sun, Nov 18, 2012 at 6:59 AM, grarpamp grarp...@gmail.com wrote: joerg_wun...@uriah.heep.sax.de You don't even have a name Your domain indicates Germany, please have a chat with CCC.de about the various good uses for nyms. And consult your library for some fine historical use cases. If that's counter to your beliefs, you are free to show us the way and post all your personal infos to the list. Uh-oh grarpamp, I hope you realize whom you're trying to lecture here! Joerg Wunsch is a highly appreciated long-time FreeBSD contributor and was member of the Core Team for a long time (I met him in person in the 90-ies and he's a very kind person). I wouldn't dismiss his advice lightly, unless I had a very good reason. Now, back to our regular programming. Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
grarpamp the various good uses for nyms. cpgh...@cordula.ws I hope you realize whom you're trying to lecture here! Joerg Wunsch is a highly appreciated long-time FreeBSD contributor Of course. No one here has any question as to anyone's FreeBSD participation. That would be silly :) I merely contest the suggestion that nyms have little to no utility, that people need moderate their usage alone in public, and that those using them are somehow lessers. I won't fail to defend general anti-nym opinion or guidance, particularly when wafted in this general direction. Now, back to our regular programming. Yes, about this lack of a self-authenticating repo, etc. [1] It is good to see some discussion forming around it :) [1] Or whatever it may better be called. Put another way... we can't yet say, in the strong cryptographic sense, that anyone has a true copy of the repo. Or that the repo is itself internally tamper free and/or tamper proof. And so on as applied down the production and distribution chain. The repo does face certain risks. And Git appears as if it may be one way to mitigate them. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
I won't fail to defend general anti-nym opinion or guidance d-oh, s/defend/defend against/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
http://www.freebsd.org/news/2012-compromise.html http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key This is not about this incident, but about why major opensource projects need to be using a repository that has traceable, verifiable, built-in cryptographic authentication. Any of hundreds of committer and admin accounts could be compromised with the attacker silently editing the repo. The same applies to any of those accounts going rogue. Backtrack diffing from a breach to 'see what changed' is not the ideal option. You really need to be using a strong repo so that any attack on it is null from the start. Another problem is bit rot wherever it may occur... disk, hardware, the wire, EMP and other systems. As it is now, we have no way to verify that what we get on pressed CD's, ISO's, FTP sites, torrents, etc is strongly linked back to the original repo. Signing over a hash of the ISO is *not* the same as including the strong repo hash (commit) that was used to build the release and then signing over that and the ISO. We can't know that our local repository updates match the master. ports.tar.gz has no authentication either. Nor does anything in the entire project that originates from the current SVN/CVS repo... webpages, docs, tools, source tarballs, etc. The FTP packages aren't signed, and there are weak MD5's used in various parts of the install/package tools, mirrors, etc. We can't trade hashes amongst people. It's all just a bunch of random bits that someone may or may not have signed over. And even if signed they still wouldn't be strongly linked back to the master repo. Having such a disconnect at the root of everything you do is simply not good practice these days. And these days, Git is what people and projects are moving to, and its rate of adoption and prevalence have essentially won out over all the rest in the new 'revision control 2.0 world'. And knowing Git is now more or less essential if you want to participate in a wide variety of community development, ref: github, etc. The FreeBSD project needs to be providing both itself, and its users and benefactors with verifiable assurance that its repository, and any copies and derived products, are authentic and intact. Don't argue against such a repository feature, or the cost to move, or bury your head in the sand by saying it could never happen to us... Take this as a real opportunity to lead amongst the major opensource projects like Linux, and among the BSD's (like DragonFly has), and move to Git. Once the root is fixed, you can push out secure distribution and update models from there. It all starts at the root and can't be done without it. https://www.kernel.org/pub/software/scm/git/docs/git-fsck.html Verifies the connectivity and validity of the objects in the database http://git-scm.com/about/info-assurance The data model that Git uses ensures the cryptographic integrity of every bit of your project. Every file and commit is checksummed and retrieved by its checksum when checked back out. It's impossible to get anything out of Git other than the exact bits you put in. It is also impossible to change any file, date, commit message, or any other data in a Git repository without changing the IDs of everything after it. This means that if you have a commit ID, you can be assured not only that your project is exactly the same as when it was committed, but that nothing in its history was changed. https://en.wikipedia.org/wiki/Git_(software) The Git history is stored in such a way that the id of a particular revision (a commit in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. The structure is similar to a hash tree, but with additional data at the nodes as well as the leaves. Some references... http://git-scm.com/ https://github.com/ http://gitweb.dragonflybsd.org/dragonfly.git https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
joerg_wun...@uriah.heep.sax.de You don't even have a name Your domain indicates Germany, please have a chat with CCC.de about the various good uses for nyms. And consult your library for some fine historical use cases. If that's counter to your beliefs, you are free to show us the way and post all your personal infos to the list. spamming a large number of FreeBSD mailinglists with your advocacy? This topic would benefit from the review and involvement of users (questions), committers (hackers), security (security), and distribution (hubs). -- Never trust an operating system you don't have sources for. ;-) As well summarized by this (your signature) ... sources you can't verify to the master are, also, sources you can't trust. fi...@ukr.net LOL And how will this help Linux? http://lwn.net/Articles/457142/ How will what help Linux? Please quote a relevant snippet instead of the entire message. Seems pretty clear from the above link that having hashes/crypto as an intrinsic feature of the SCM tool does in fact help Linux. If you're asking about distribution of things traceable back to the master repo, at least your security officer can sign the initial repository commit and then include the various distribution keys and subsequent updates, signed tags, etc in the repo. utis...@gmail.com Yes, but git doesn't work with our workflow. There's usually a larger than head sized sandbox near everyone's local neighborhood. Will people elect to visit it, or to learn, grow, and change for the better? Prioe workflow is often forced by and derived from the tools being used. Different tools could enable different, more useful workflows. SVN required workflow change from CVS, people managed just fine. It's been discussed several times I will look for these. Can you point to a couple main threads? [git] ... is GPL btw FreeBSD does not include this sort-of-BSD licensed SCM tool in its base either... # https://svn.apache.org/repos/asf/subversion/trunk/LICENSE # ls /*bin/svn /usr/*bin/svn ls: No such file or directory But it does include this GPL licensed one... # http://cvs.savannah.gnu.org/viewvc/cvs/ccvs/COPYING?revision=HEAD # ls /*bin/cvs /usr/*bin/cvs' /usr/bin/cvs And of course we have this in use as well... # perforce http://www.perforce.com/purchase/pricing-licensing So it seems license is not an obstacle to inclusion, and certainly not the use via ports, of any particular SCM with the FreeBSD project. rsimmo...@gmail.com https://github.com/freebsd/ adr...@freebsd.org You can look at what goes into the FreeBSD Git clone to get your assurance that things aren't being snuck in. The same could be said for the CVS clone. Again... Any copy of something that is itself not verifiable provides no such assurance. Those who want to use git can use it, right now. Honest. Yes, Git does seem to me to be leading the other distributed, hash based, SCM tools such as Hg. Thus Git is suggested. Yes, Git would fill the purpose. I only suggest Git, as to some other choices that use hashes (as usual, please verify with current releases)... https://en.wikipedia.org/wiki/Comparison_of_revision_control_software But this is not really about using Git in particular... These replies are all dodging around the base issue raised... - That FreeBSD has no verifiable source repo - Which is not only a problem for the repo itself, but for everything attempted to be spawned downstream off of that root (no verifiable distribution system/tools distributing that repo, etc). Sorry to reply to these sorts of replies this way, but please, this isn't a troll or a shed. No need to do that around the issue raised. Hash [ :-) ] it out and solve it. Why wait for a costlier breach? Why not provide the assurance beforehand? No better time than now. g...@ross.cx http://www.linux.com/news/featured-blogs/171-jonathan-corbet/491001-the-cracking-of-kernelorg Yes, another good link outlining the issue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Sun, 18 Nov 2012 00:59:54 -0500, grarpamp wrote: Never trust an operating system you don't have sources for. ;-) As well summarized by this (your signature) ... sources you can't verify to the master are, also, sources you can't trust. Unless. of couse, you are able to use the source Luke and spot malicious portions by yourself. This of course is usually possible to subsets only, and mostly to the gurus of our guild. The ordinary user won't be able to do this. fi...@ukr.net LOL And how will this help Linux? http://lwn.net/Articles/457142/ How will what help Linux? Please quote a relevant snippet instead of the entire message. Seems pretty clear from the above link that having hashes/crypto as an intrinsic feature of the SCM tool does in fact help Linux. The article's headline is kernel.org compromised, and the significant part (as of August 2011!) is: Earlier this month, a number of servers in the kernel.org infrastructure were compromised. We discovered this August 28th. While we currently believe that the source code repositories were unaffected, we are in the process of verifying this and taking steps to enhance security across the kernel.org infrastructure. However, this is a Linux problem, not a FreeBSD one, regarding repository infrastructure. utis...@gmail.com Yes, but git doesn't work with our workflow. There's usually a larger than head sized sandbox near everyone's local neighborhood. Will people elect to visit it, or to learn, grow, and change for the better? In many contexts, better _depends_. Prioe workflow is often forced by and derived from the tools being used. That is _one_ (valid!) way to see it. Another way is that tools will be chosen according to established workflows, or tools will adapt those workflows to better support them. Different tools could enable different, more useful workflows. SVN required workflow change from CVS, people managed just fine. If the required programs will be integrated in the OS, accompanied by proper documentation, and the backend infrastructures being instantiated, up and running, I don't see a big problem. Unlike in other OS countries, FreeBSD people are able to adapt to new methods and tools. [git] ... is GPL btw FreeBSD does not include this sort-of-BSD licensed SCM tool in its base either... # https://svn.apache.org/repos/asf/subversion/trunk/LICENSE # ls /*bin/svn /usr/*bin/svn ls: No such file or directory But it does include this GPL licensed one... # http://cvs.savannah.gnu.org/viewvc/cvs/ccvs/COPYING?revision=HEAD # ls /*bin/cvs /usr/*bin/cvs' /usr/bin/cvs And of course we have this in use as well... # perforce http://www.perforce.com/purchase/pricing-licensing So it seems license is not an obstacle to inclusion, and certainly not the use via ports, of any particular SCM with the FreeBSD project. As far as I know, FreeBSD team puts much work into getting the OS into a BSD license only state, making it more appealing to commercial use where the (often so called) rape me license BSDL is very welcome. But as for being part of the OS installation, you are right: Whatever tool will be required (or at least suggested) for the purpose of managing CVS-like functionality for sources and the ports collection should be part of the basic installation. That's why pkg_add -r cvsup-without-gui (if I remember correctly) has been the way in the past, but then, a rewrite called csup became part of the default installation, so you could use the known cvs command _and_ have a nice integration with system functionality, like entries in /etc/make.conf and configuration files for _how_ to update sources, ports, documentation and so on (e. g. in /etc/sup, with /usr/share/examples/cvsup/ as examples), so make update would do whatever you wanted. Exactly that kind of productive (!) behaviour is what I would expect (or at least wish) for any replacement of CVS, be it SVN or Git. Sorry to reply to these sorts of replies this way, but please, this isn't a troll or a shed. No need to do that around the issue raised. Hash [ :-) ] it out and solve it. With some salt, please. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 18/11/2012 05:21, Robert Simmons wrote: Yup: https://github.com/freebsd/ There's also git.freebsd.org. -- Bruce Cran ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
