CVS commit logs removed by CVS update
To my big surprise I found that "cvs update" removed all the CVS logs from "/usr/cvs/CVSROOT-*/commitlogs/*" (collection cvsroot-all). While I do use SVN to keep source and ports updated on my system, I was used to scan the CVS log files for commit messages of interest, to locate commit messages where I did not remember the affected files, and to have much faster access to recent commit messages than via "svn log" (or when off-line ...). Now I'd like to know, whether the log files have been removed as a side effect of cleaning up after the security incident, or whether they were deemed unnecessary remains from ancient CVS times? Best regards, STefan PS: I do have backups of the log files, but I'm really annoyed by these files being deleted on my system when I wanted to check for new information that might have been added to them ... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
В Sat, 17 Nov 2012 15:00:06 -0500 grarpamp пишет: > 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 LOL And how will this help Linux? http://lwn.net/Articles/457142/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Sat, 17 Nov 2012 21:11:43 +0100, Ivan Klymenko wrote: В Sat, 17 Nov 2012 15:00:06 -0500 grarpamp пишет: 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. LOL And how will this help Linux? http://lwn.net/Articles/457142/ In the first comment on the article you link to, you find this: http://www.linux.com/news/featured-blogs/171-jonathan-corbet/491001-the-cracking-of-kernelorg where the OPs view is susbstantiated. ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On 17 Nov 2012 21:00, "Michael Ross" wrote: > > On Sat, 17 Nov 2012 21:11:43 +0100, Ivan Klymenko wrote: > >> В Sat, 17 Nov 2012 15:00:06 -0500 >> grarpamp пишет: >> >>> 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. >>> > >> LOL And how will this help Linux? >> http://lwn.net/Articles/457142/ > > > In the first comment on the article you link to, you find this: > > http://www.linux.com/news/featured-blogs/171-jonathan-corbet/491001-the-cracking-of-kernelorg > > where the OPs view is susbstantiated. Yes, but git doesn't work with our workflow. It's been discussed several times, and changing to a tool that doesn't work for us (and is GPL btw) is no good at all. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Jumbo Packet fail.
On 11/17/2012 5:32 PM, Zaphod Beeblebrox wrote: I recently started using an iSCSI disk on my ZFS array seriously from a windows 7 host on the network. The performance is acceptable, but I was led to believe that using Jumbo packets is a win here. My win7 motherboard adapter did not support jumbo frames, so I got one that did... configured it, etc. Just in case anyone cares, the motherboard had an 82567V-2 (does not support jumbo frames) and I added in an intel 82574L based card. Similarly, I configured em0 on my FreeBSD host to have an MTU of 9014 bytes (I also tried 9000). The hardware on the FreeBSD 9.1RC2 side is: em0: port 0xdc00-0xdc1f mem 0xfcfe-0xfcff,0xfcfc-0xfcfd irq 16 at device 0.0 on pci3 pciconf -lv identifies the chipset as 82572EI Now... my problem is that the windows machine correctly advertises an MSS of 8960 bytes in it's SYN packet while FreeBSD advertises 1460 in the syn-ack. [1:42:342]root@vr:/usr/local/etc/istgt> ifconfig em0 em0: flags=8843 metric 0 mtu 9014 options=4019b ether 00:15:17:0d:04:a8 inet 66.96.20.52 netmask 0xffe0 broadcast 66.96.20.63 inet6 fe80::215:17ff:fe0d:4a8%em0 prefixlen 64 scopeid 0x5 inet6 2001:1928:1::52 prefixlen 64 inet 192.168.221.2 netmask 0xff00 broadcast 192.168.221.255 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active I have tested this with both ipv4 and ipv6 connections between the win7 host and the FreeBSD server. win7 always requests the larger mss, and FreeBSD the smaller. Did you reboot or alter the existing route so it also uses the higher MTU? I realize that need is not obvious. Check netstat -rni. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Jumbo Packet fail.
On Sat, Nov 17, 2012 at 6:54 PM, Adam McDougall wrote: > On 11/17/2012 5:32 PM, Zaphod Beeblebrox wrote: [my description of MTU not having effect on MSS, deleted] > Did you reboot or alter the existing route so it also uses the higher MTU? I > realize that need is not obvious. Check netstat -rni. O I C. I understand why it is, but it's a small surprise to me. This brings up a related issue: The syntax for things I don't do often with route and friends (I suppose I would include netstat and sometimes even ifconfig) is difficult to remember and difficult to discern. As an example, going from your first post, I might want to do something like: route change 192.168.221.84 mtu 9014 ... but this doesn't work. In fact, part of this problem is that the route doesn't have an easy to specify destination, but it's also because it's not clear how to indicate the mtu change. It's similarly hard to specify ipv6 addresses for route et. al. And the man pages are of little help here. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
[snip] 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. 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. Those who want to use git can use it, right now. Honest. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Sat, Nov 17, 2012 at 11:55 PM, Adrian Chadd wrote: > Those who want to use git can use it, right now. Honest. Yup: https://github.com/freebsd/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
[trimmed some of the lists]
Chris Rees wrote:
> ... git doesn't work with our workflow.
I'm sure the workflow itself is documented somewhere, but is
there a good writeup of _how_ git doesn't work with it, e.g. what
capabilit{y,ies} is/are missing? Seems this might be of interest
to the git developers, not because they necessarily want to support
FreeBSD as such, but as an example of a real-world workflow that git
currently does not handle well.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Sat, Nov 17, 2012 at 11:05:40PM -0800, Perry Hutchison wrote:
> [trimmed some of the lists]
>
> Chris Rees wrote:
> > ... git doesn't work with our workflow.
>
> I'm sure the workflow itself is documented somewhere, but is
> there a good writeup of _how_ git doesn't work with it, e.g. what
> capabilit{y,ies} is/are missing? Seems this might be of interest
> to the git developers, not because they necessarily want to support
> FreeBSD as such, but as an example of a real-world workflow that git
> currently does not handle well.
Git would work well with our workflow. It supports the centralized
repository model, which the project employs right now.
The biggest issues, assuming the project indeed decides to move to Git
right now, are the migration costs, both in the term of the technical
efforts needed, and the learning curve for the most population of the
committers.
Relatively minor problem, at least with the current rate of the commits,
would be a commit race, when the shared repo head forwarded due to the
parallel commit. The issue should be somewhat mitigated by the Git
allowance to push a set of changes in one push.
pgpOinOOg50ux.pgp
Description: PGP signature
