* git-pasky: gitXnormid.sh overhaul
From: Rene Scharfe @ 2005-04-16 16:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Hello,
I just couldn't stand all the calls to grep and other external tools in
gitXnormid.sh and started rewriting it in a knee-jerk reaction.
You said in a private conversation that you don't like to include things
like ${var#stuff} to stay "sh compatible", while OTOH you favour $(cmd)
over `cmd`. Both are POSIX extensions of the classical Bourne Shell
syntax (see e.g. http://docs.hp.com/en/B2355-90046/ch15s03.html for a
feature comparision between POSIX shell, Bourne Shell and Korn Shells on
HP-UX). For reference, The Open Group publishes its IEEE Std 1003.1
standard (vulgo: POSIX) on this website:
http://www.opengroup.org/onlinepubs/009695399/toc.htm. So which shell
do you want to target with your git scripts?
This time I tested the script. :] It copes with invalid IDs,
non-existing valid IDs, abbreviated IDs, an omitted ID, valid IDs, with
tags and branch names. I also made sure the script runs with bash, ash,
pdksh, zsh and bash --posix (all on SuSE 9.2).
I changed the way an ID is verified. The script now tries to find tags
and branches first by looking for .git/tags/<id> and .git/HEAD.<id> and
after that looking inside .git/objects for a match. That's faster and
now I can safely give a branch a name consisting of 40 hex digits. :-)
The script follows in plain text format, not as a patch. Your and my
version share only very few lines, so this way it's easier to review.
I'll send you a patch if and when you're ready to apply it, ok?
Thanks,
Rene
--- 8< ---
#!/bin/sh
#
# Internal: Normalize the given ID to a tree ID.
# Copyright (c) Petr Baudis, 2005
#
# Takes an arbitrary ID as a parameter. -c tells it to give
# a commit id rather than tree id.
usage() {
echo "Usage: $0 [-c] [tree-id | commit-id | tag | branch]"
exit 2
}
get_first_word() {
if read one two; then
echo "$one"
return 0
fi
return 1
}
expand_hash() {
hashdir=${SHA1_FILE_DIRECTORY:-.git/objects}
filename=${1#??}
dirname=${1%${filename}}
first=true
for file in "${hashdir}/${dirname}/${filename}"*; do
[ -f "$file" ] || return 1
if $first; then
hash=${dirname}${file##*/}
first=false
else
return 1
fi
done
$first && return 1
echo "$hash"
}
get_tree_id() {
cat-file commit "$1" | while read tag hash; do
if [ "$tag" = "tree" ]; then
echo "$hash"
return
fi
done
}
type=tree
case "$1" in
-c) type=commit; shift;;
-*) usage;;
esac
if [ ! "$1" ]; then
if [ ! -f ".git/HEAD" ]; then
echo "$0: file .git/HEAD not found"
usage
fi
id=$(get_first_word <".git/HEAD")
elif [ -f ".git/tags/$1" ]; then
id=$(get_first_word <".git/tags/$1")
elif [ -f ".git/HEAD.$1" ]; then
id=$(get_first_word <".git/HEAD.$1")
else
id=$(expand_hash "$1")
fi
if [ $? != 0 ]; then
echo "$0: invalid ID: $1" >&2
exit 1
fi
if [ "$type" = "tree" ]; then
tree_id=$(get_tree_id "$id" 2>/dev/null)
[ "$tree_id" ] && id=$tree_id
fi
if [ $(cat-file -t "$id") != "$type" ]; then
echo "$0: invalid ID: $id" >&2
exit 1
fi
echo "$id"
^ permalink raw reply
* Introductions
From: Zed A. Shaw @ 2005-04-16 16:50 UTC (permalink / raw)
To: git
Hi,
Just a short message to introduce myself and give a shameless plug. I'm
Zed A. Shaw and I'm the author of a little unknown SCM called FastCST
(http://www.zedshaw.com/projects/fastcst ). While I doubt that Linus
would ever adopt fastcst as his tool (and I probably wouldn't want him
too since it's not quite ready for prime time) I did find many of the
discussions on the list so far very interesting.
Some sent me Linus' message about wanting to do a diff on the whole
source tree, and just thought I'd mention that I already tried this in
FastCST. FastCST uses a suffix array to construct a delta (not a diff),
so I thought it might be possible to simply apply the delta algorithm to
the entire source tree and get very small changesets.
It worked on small source trees, but when it came to the Linux 2.6 tree
it choked hard. Even with an efficient suffix array implementation,
you're talking about performing a diff/delta on 225M of source. Added
to the problem is that you have to track file locations within the
massive blob. In the end, it also wasn't much more efficient from a
size/space/time perspective so I dropped it.
My current solution to Linus' problem is to use an inverted index to
process all the sources and revisions on the fly as they are created.
Using the inverted index, I'm able to VERY quickly find any chunk of
source in files or revisions. This lets me track things like how
functions move through the files, where chunks of code moved to, etc.
In the end this turns out to be much more efficient (7 seconds on my
computer to find all references to "sprintf" in the Linux 2.6 source) as
I can use the super small deltas for distributing changes, and give
developers a means tracking content changes across "the world" in a
simple search format.
Anyway, just thought I'd throw in my experiences attempting what Linus
is talking about. I actually agree with him that rename tracking isn't
that great, but I've come to the conclusion that tracking renames is
actually a specific case of just a general search problem. Different
strokes for different folks I guess.
Other than that, I'm mostly interested in reading the messages and
probably won't write anything unless people ask me directly for
something. Thanks!
Zed A. Shaw
^ permalink raw reply
* Re: [PATCH 3/2] merge-trees script for Linus git
From: Linus Torvalds @ 2005-04-16 16:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504160820320.7211@ppc970.osdl.org>
On Sat, 16 Apr 2005, Linus Torvalds wrote:
>
> Having slept on it, I think I'll merge all the trivial cases that don't
> involve a file going away or being added. Ie if the file is in all three
> trees, but it's the same in two of them, we know what to do.
Junio, I pushed this out, along with the two patches from you. It's still
more anal than my original "tree-diff" algorithm, in that it refuses to
touch anything where the name isn't the same in all three versions
(original, new1 and new2), but now it does the "if two of them match, just
select the result directly" trivial merges.
I really cannot see any sane case where user policy might dictate doing
anything else, but if somebody can come up with an argument for a merge
algorithm that wouldn't do what that trivial merge does, we can make a
flag for "don't merge at all".
The reason I do want to merge at all in "read-tree" is that I want to
avoid having to write out a huge index-file (it's 1.6MB on the kernel, so
if you don't do _any_ trivial merges, it would be 4.8MB after reading
three trees) and then having people read it and parse it just to do stuff
that is obvious. Touching 5MB of data isn't cheap, even if you don't do a
whole lot to it.
Anyway, with the modified read-tree, as far as I can tell it will now
merge all the cases where one side has done something to a file, and the
other side has left it alone (or where both sides have done the exact same
modification). That should _really_ cut down the cases to just a few files
for most of the kernel merges I can think of.
Does it do the right thing for your tests?
Linus
^ permalink raw reply
* Re: Re: Merge with git-pasky II.
From: Simon Fowler @ 2005-04-16 16:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: David Lang, git
In-Reply-To: <20050416160333.GF19099@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Sat, Apr 16, 2005 at 06:03:33PM +0200, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 05:55:37PM CEST, I got a letter
> where Simon Fowler <simon@himi.org> told me that...
> > On Sat, Apr 16, 2005 at 05:19:24AM -0700, David Lang wrote:
> > > Simon
> > >
> > > given that you have multiple machines creating files, how do you deal with
> > > the idea of the same 'unique id' being assigned to different files by
> > > different machines?
> > >
> > The id is a sha1 hash of the current time and the full path of the
> > file being added - the chances of that being replicated without
> > malicious intent is extremely small. There are other things that
> > could be used, like the hostname, username of the person running the
> > program, etc, but I don't really see them being necessary.
>
> Why not just use UUID?
>
Hey, everything else in git seems to use sha1, so I just copied
Linus' sha1 code ;-)
All I wanted was something that had a good chance of being unique
across any potential set of distributed repositories, to avoid the
chance of accidental clashes. A sha1 hash of something that's not
likely to be replicated is a simple way to do that.
Simon
--
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Re: Merge with git-pasky II.
From: Linus Torvalds @ 2005-04-16 16:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: Simon Fowler, David Lang, git
In-Reply-To: <20050416160333.GF19099@pasky.ji.cz>
On Sat, 16 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 05:55:37PM CEST, I got a letter
> where Simon Fowler <simon@himi.org> told me that...
>
> > The id is a sha1 hash of the current time and the full path of the
> > file being added - the chances of that being replicated without
> > malicious intent is extremely small. There are other things that
> > could be used, like the hostname, username of the person running the
> > program, etc, but I don't really see them being necessary.
>
> Why not just use UUID?
Note that using anything that isn't data-related totally destroys the
whole point of the object database. Remember: any time we don't uniquely
generate the same name for the same object, we'll waste disk-space.
So adding in user/machine/uuid's to the thing is always a mistake. The
whole thing depends on the hash being as close to 1:1 with the contents as
humanly possible.
There's also the issue of size. Yes, I could have chosen sha256 instead of
sha1. But the keys would be almost twice as big, which in turn means that
the "tree" objects would be bigger, and that the "index" file would be
bigger.
Is that a huge problem? No. We can certainly move to it if sha1 ever shows
itself to be weak. But I really think we are much better off just
re-generating the whole tree and history at that point, rather than try to
predict the future.
The fact is, with current knowledge, sha1 _is_ safe for what git uses it
for, for the forseeable future. And we have a migration strategy if I'm
wrong. Don't worry about it.
Almost all attacks on sha1 will depend on _replacing_ a file with a bogus
new one. So guys, instead of using sha256 or going overboard, just make
sure that when you synchronize, you NEVER import a file you already have.
It's really that simple. Add "--ignore-existing" to your rsync scripts,
and you're pretty much done. That guarantees that a new evil blob by the
next mad scientist out to take over the world will never touch your
repository, and if we make this part of the _standard_ scripts, then
dammit, security is in good _practices_ rather than just relying blindly
on the hash being secure.
In other words, I think we could have used md5's as the hash, if we just
make sure we have good practices. And it wouldn't have been "insecure".
The fact is, you don't merge with people you don't trust. If you don't
trust them, they have a much easier time corrupting your repository by
just creating bugs in the code and checking that thing in. Who cares about
hash collisions, when you can generate a kernel root vulnerability by just
adding a single line of code and use the _correct_ hash for it.
So the sha1 hash does not replace _trust_. That comes from something else
altogether.
Linus
^ permalink raw reply
* Re: Re: Merge with git-pasky II.
From: Petr Baudis @ 2005-04-16 16:03 UTC (permalink / raw)
To: Simon Fowler; +Cc: David Lang, git
In-Reply-To: <20050416155536.GX4488@himi.org>
Dear diary, on Sat, Apr 16, 2005 at 05:55:37PM CEST, I got a letter
where Simon Fowler <simon@himi.org> told me that...
> On Sat, Apr 16, 2005 at 05:19:24AM -0700, David Lang wrote:
> > Simon
> >
> > given that you have multiple machines creating files, how do you deal with
> > the idea of the same 'unique id' being assigned to different files by
> > different machines?
> >
> The id is a sha1 hash of the current time and the full path of the
> file being added - the chances of that being replicated without
> malicious intent is extremely small. There are other things that
> could be used, like the hostname, username of the person running the
> program, etc, but I don't really see them being necessary.
Why not just use UUID?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Simon Fowler @ 2005-04-16 15:55 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0504160518310.21837@qynat.qvtvafvgr.pbz>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
On Sat, Apr 16, 2005 at 05:19:24AM -0700, David Lang wrote:
> Simon
>
> given that you have multiple machines creating files, how do you deal with
> the idea of the same 'unique id' being assigned to different files by
> different machines?
>
The id is a sha1 hash of the current time and the full path of the
file being added - the chances of that being replicated without
malicious intent is extremely small. There are other things that
could be used, like the hostname, username of the person running the
program, etc, but I don't really see them being necessary.
Simon
--
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: SHA1 hash safety
From: ross @ 2005-04-16 15:49 UTC (permalink / raw)
To: C. Scott Ananian; +Cc: omb, David Lang, Ingo Molnar, git
In-Reply-To: <Pine.LNX.4.61.0504161040310.29343@cag.csail.mit.edu>
On Sat, Apr 16, 2005 at 10:58:15AM -0400, C. Scott Ananian wrote:
> Even given the known weaknesses in MD5, it would take much more than a
> million documents to find MD5 collisions. I can only conclude that the
> hash was being used incorrectly; most likely truncated (my wild-ass guess
> would be to 32 bits; a collision is likely with > 50% probability in a
> million document store for a hash of less than 40 bits).
I've also seen non thread-safe GUID generation, using MD5m hit collisions:
but of course that was due to the fact that the code had thread safety
issues, not because anyone actually ever hit a MD5 collision...
Of course there are constructed cases of MD5 collision, but those are
pretty disinteresting. Give me two files that have useful content and
the same hash, and then I'll be impressed.
Linus has already weighed in that he doesn't give a crap. All the
crypto-babble about collision whitepapers is uninteresting without a
repo that has real collisions. git is far too cool as is - prove I
should be concerned.
--
Ross Vandegrift
ross@lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
^ permalink raw reply
* Re: Re: SHA1 hash safety
From: C. Scott Ananian @ 2005-04-16 15:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: omb, David Lang, Ingo Molnar, git
In-Reply-To: <20050416151116.GC19099@pasky.ji.cz>
On Sat, 16 Apr 2005, Petr Baudis wrote:
>> I know the current state of the art here. It's going to take more than
>> just hearsay to convince me that full 128-bit MD5 collisions are likely.
>
> http://cryptography.hyperlink.cz/MD5_collisions.html
OK, OK, I spoke too sloppily. Let me rephrase:
It's going to take more than just hearsay to convince me that full
128-bit MD5 collisions *IN ARBITRARILY CHOSEN DOCUMENTS* are likely.
I could add, "WITHOUT SPECIAL EFFORT BY AN ATTACKER".
But you're right, I was too busy thrashing around with the basic
probability cluestick to carefully distinguish MD5 (in which *collisions*
can be found fairly easily now by an attacker, although not *preimages*)
and SHA1 (which is what git is actually using, and still requires 2^69
hash computations to collide).
And note again that these are not preimage attacks. Even with MD5, an
attacker can't arbitrarily change existing code in the Linux kernel by
creating a malicious file with the same MD5 hash.
But extreme caution is necessary, because both of these hash mechanisms
have been shown to be weak, and algorithms grow weaker with time, not
stronger.
I think the only conclusion that can be made is that "one should not rely
on the hash for security". And I don't believe that we are. We should be
careful to continue saying "branch 46f<mumble> *in Linus' tree*" instead
of just "branch 46f<mumble>" and assuming that that is unique. The
security is provided by Linus' control over his repository, not by the
hash.
--scott
[The 'MD5 collisions in 15 minutes on a laptop' paper did surprise me. I
vaguely remember hearing about this before, but I'd forgotten just how
broken MD5 is. It's still a fine *hash* function; just not a terribly
good *cryptographically secure* hash function.]
Israel PBSUCCESS $400 million in gold bullion President Nader jihad
RNC LPMEDLEY agent HTKEEPER Cheney SEQUIN SARANAC Clinton biowarfare
( http://cscott.net/ )
^ permalink raw reply
* Re: Re: Re: Re: write-tree is pasky-0.4
From: Petr Baudis @ 2005-04-16 15:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0504151709180.7211@ppc970.osdl.org>
Dear diary, on Sat, Apr 16, 2005 at 02:22:45AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
>
>
> On Sat, 16 Apr 2005, Petr Baudis wrote:
> >
> > But otherwise it is great news to me. Actually, in that case, is it
> > worth renaming it to Cogito and using cg to invoke it? Wouldn't be that
> > actually more confusing after it gets merged? IOW, should I stick to
> > "git" or feel free to rename it to "cg"?
>
> I'm perfectly happy for it to stay as "git", and in general I don't have
> any huge preferences either way. You guys can discuss names as much as you
> like, it's the "tracking renames" and "how to merge" things that worry me.
:-)
> I think I've explained my name tracking worries. When it comes to "how to
> merge", there's three issues:
>
> - we do commonly have merge clashes where both trees have applied the
> exact same patch. That should merge perfectly well using the 3-way
> merge from a common parent that Junio has, but not your current "bring
> patches forward" kind of strategy.
My current "bring patches forward" strategy is only very interim, to
have something working well enough for me to merge with you. I will
gladly change it to use merge-tree*, when it is done. (Or read-tree -m -
I will yet have to have a look, but it looks extremely promising.)
> - I _do_ actually sometimes merge with dirty state in my working
> directory, which is why I want the merge to take place in a separate
> (and temporary) directory, which allows for a failed merge without
> having any major cleanup. If the merge fails, it's not a big deal, and
> I can just blow the merge directory away without losing the work I had
> in my "real" working directory.
Ok. But still, especially when you do some nontrivial conflicts
resolving, how do you check if it even compiles after the merge? Or do
you just commit it and possibly fix the compilation in another commit?
> - reliability. I care much less for "clever" than I care for "guaranteed
> to never do the wrong thing". If I have to fix up some stuff by hand,
> I'll happily do so. But if I can't trust the merge and have to _check_
> things by hand afterwards, that will make me leery of the merges, and
> _that_ is bad.
>
> The third point is why I'm going to the ultra-conservative "three-way
> merge from the common parent". It's not fancy, but it's something I feel
> comfortable with as a merge strategy. For example, arch (and in particular
> darcs) seems to want to try to be "clever" about the merges, and I'd
> always live in fear.
I agree and I would like to achieve the same. I too think the three-way
merge from the common parent is the best way to go for now.
> And, finally, there's obviously performance. I _think_ a normal merge with
> nary a conflict and just a few tens of files changed should be possible in
> a second. I realize that sounds crazy to some people, but I think it's
> entirely doable. Half of that is writing the new tree out (that is a
> relative costly op due to the compression). The other half is the "work".
Being written in shell, there is plenty of space for optimization - from
using bash internals instead of textutils to rewriting parts of it in C.
My priority now is to get it right first, though. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Johannes Schindelin @ 2005-04-16 15:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <1113580881.27227.73.camel@hades.cambridge.redhat.com>
Hi,
On Fri, 15 Apr 2005, David Woodhouse wrote:
> But if it can be done cheaply enough at a later date even though we end
> up repeating ourselves, and if it can be done _well_ enough that we
> shouldn't have just asked the user in the first place, then yes, OK I
> agree.
The repetition could be helped by using a cache.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/2] merge-trees script for Linus git
From: Linus Torvalds @ 2005-04-16 15:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vis2ncf8j.fsf@assigned-by-dhcp.cox.net>
On Sat, 16 Apr 2005, Junio C Hamano wrote:
>
> LT> NOTE NOTE NOTE! I could make "read-tree" do some of these nontrivial
> LT> merges, but I ended up deciding that only the "matches in all three
> LT> states" thing collapses by default.
>
> * Understood and agreed.
Having slept on it, I think I'll merge all the trivial cases that don't
involve a file going away or being added. Ie if the file is in all three
trees, but it's the same in two of them, we know what to do.
That way we'll leave thigns where the tree itself changed (files added or
removed at any point) and/or cases where you actually need a 3-way merge.
> The userland merge policies need ways to extract the stage
> information and manipulate them. Am I correct to say that you
> mean by "ls-files -l" the extracting part?
No, I meant "show-files", since we need to show the index, not a tree (no
valid tree can ever have the "modes" information, since (a) it doesn't
have the space for it anyway and (b) we refuse to write out a dirty index
file.
>
> LT> I should make "ls-files" have a "-l" format, which shows the
> LT> index and the mode for each file too.
>
> You probably meant "ls-tree". You used the word "mode" but it
> already shows the mode so I take it to mean "stage". Perhaps
> something like this?
>
> $ ls-tree -l -r 49c200191ba2e3cd61978672a59c90e392f54b8b
> 100644 blob fe2a4177a760fd110e78788734f167bd633be8de COPYING
> 100644 blob b39b4ea37586693dd707d1d0750a9b580350ec50:1 man/frotz.6
> 100644 blob b39b4ea37586693dd707d1d0750a9b580350ec50:2 man/frotz.6
> 100664 blob eeed997e557fb079f38961354473113ca0d0b115:3 man/frotz.6
Apart from the fact that it would be
show-files -l
since there are no tree objects that can have anything but fully merged
state, yes.
> Assuming that you would be working on that, I'd like to take the
> dircache manipulation part. Let's think about the minimally
> necessary set of operations:
>
> * The merge policy decides to take one of the existing stage.
>
> In this case we need a way to register a known mode/sha1 at a
> path. We already have this as "update-cache --cacheinfo".
> We just need to make sure that when "update-cache" puts
> things at stage 0 it clears other stages as well.
>
> * The merge policy comes up with a desired blob somewhere on
> the filesystem (perhaps by running an external merge
> program). It wants to register it as the result of the
> merge.
>
> We could do this today by first storing the "desired blob"
> in a temporary file somewhere in the path the dircache
> controls, "update-cache --add" the temporary file, ls-tree to
> find its mode/sha1, "update-cache --remove" the temporary
> file and finally "update-cache --cacheinfo" the mode/sha1.
> This is workable but clumsy. How about:
>
> $ update-cache --graft [--add] desired-blob path
>
> to say "I want to register mode/sha1 from desired-blob, which
> may not be of verify_path() satisfying name, at path in the
> dircache"?
>
> * The merge policy decides to delete the path.
>
> We could do this today by first stashing away the file at the
> path if it exists, "update-cache --remove" it, and restore
> if necessary. This is again workable but clumsy. How about:
>
> $ update-cache --force-remove path
>
> to mean "I want to remove the path from dircache even though
> it may exist in my working tree"?
Yes.
> Am I on the right track?
Exactly.
> You might want to go even lower level by letting them say
> something like:
>
> * update-cache --register-stage mode sha1 stage path
>
> Registers the mode/sha1 at stage for path. Does not look at
> the working tree. stage is [0-3]
I'd prefer not. I'd avoid playing games with the stages at any other level
than the "full tree" level until we show a real need for it.
Let's go with the known-needed minimal cases that are high-level enough to
make the scripting simple, and see if there is any reason to ever touch
the tree any other way.
Linus
^ permalink raw reply
* Re: Re: SHA1 hash safety
From: Petr Baudis @ 2005-04-16 15:11 UTC (permalink / raw)
To: C. Scott Ananian; +Cc: omb, David Lang, Ingo Molnar, git
In-Reply-To: <Pine.LNX.4.61.0504161040310.29343@cag.csail.mit.edu>
Dear diary, on Sat, Apr 16, 2005 at 04:58:15PM CEST, I got a letter
where "C. Scott Ananian" <cscott@cscott.net> told me that...
> On Sat, 16 Apr 2005, Brian O'Mahoney wrote:
>
> >(1) I _have_ seen real-life collisions with MD5, in the context of
> > Document management systems containing ~10^6 ms-WORD documents.
>
> Dude! You could have been *famous*! Why the
> aitch-ee-double-hockey-sticks didn't you publish this when you found it?
> Seriously, man.
>
> Even given the known weaknesses in MD5, it would take much more than a
> million documents to find MD5 collisions. I can only conclude that the
> hash was being used incorrectly; most likely truncated (my wild-ass guess
> would be to 32 bits; a collision is likely with > 50% probability in a
> million document store for a hash of less than 40 bits).
>
> I know the current state of the art here. It's going to take more than
> just hearsay to convince me that full 128-bit MD5 collisions are likely.
> I believe there are only two or so known to exist so far, and those were
> found by a research team in China (which, yes, is fairly famous among the
> cryptographic community now after publishing a paper consisting of little
> apart from the two collisions themselves).
http://cryptography.hyperlink.cz/MD5_collisions.html
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: space compression (again)
From: C. Scott Ananian @ 2005-04-16 15:11 UTC (permalink / raw)
To: Martin Uecker; +Cc: git
In-Reply-To: <20050416143905.GA10370@macavity>
On Sat, 16 Apr 2005, Martin Uecker wrote:
> The right thing (TM) is to switch from SHA1 of compressed
> content for the complete monolithic file to a merkle hash tree
> of the uncompressed content. This would make the hash
> independent of the actual storage method (chunked or not).
It would certainly be nice to change to a hash of the uncompressed
content, rather than a hash of the compressed content, but it's not
strictly necessary, since files are fetched all at once: there's not 'read
subrange' operation on blobs.
I assume 'merkle hash tree' is talking about:
http://www.open-content.net/specs/draft-jchapweske-thex-02.html
..which is very interesting, but not quite what I was thinking.
The merkle hash approach seems to require fixed chunk boundaries.
The rsync approach does not use fixed chunk boundaries; this is necessary
to ensure good storage reuse for the expected case (ie; inserting a single
line at the start or in the middle of the file, which changes all the
chunk boundaries).
Further, in the absence of subrange reads on blobs, it's not entirely
clear what using a merkle hash would buy you.
--scott
WASHTUB supercomputer security Mk 48 justice ODUNIT radar COBRA JANE
SSBN 731 BATF KUJUMP SECANT operation class struggle SYNCARP KGB ODACID
( http://cscott.net/ )
^ permalink raw reply
* Re: full kernel history, in patchset format
From: Francois Romieu @ 2005-04-16 15:08 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20050416131528.GB19908@elte.hu>
Ingo Molnar <mingo@elte.hu> :
[...]
> the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a
> script that will apply all the patches in order and will create a
> pristine 2.6.12-rc2 tree.
127 weeks of bk-commit mail for the 2.6 branch alone since october 2002
provides more than 44000 messages here. The figures are surprisingly
different.
> it needed many hours to finish, on a very fast server with tons of RAM,
> and it also needed a fair amount of manual work to extract it and to
> make it usable, so i guessed others might want to use the end result as
> well, to try and generate large GIT repositories from them (or to run
> analysis over the patches, etc.).
Has anyone already compared the (split/digested) content of the ChangeLog
file with the commit messages ? It raises the interesting question of
inserting the merge messages/patches in the sequence at the right place
but I'd like to know if someone met other issues.
--
Ueimor
^ permalink raw reply
* Re: SHA1 hash safety
From: C. Scott Ananian @ 2005-04-16 14:58 UTC (permalink / raw)
To: omb; +Cc: David Lang, Ingo Molnar, git
In-Reply-To: <4261132A.3090907@khandalf.com>
On Sat, 16 Apr 2005, Brian O'Mahoney wrote:
> (1) I _have_ seen real-life collisions with MD5, in the context of
> Document management systems containing ~10^6 ms-WORD documents.
Dude! You could have been *famous*! Why the
aitch-ee-double-hockey-sticks didn't you publish this when you found it?
Seriously, man.
Even given the known weaknesses in MD5, it would take much more than a
million documents to find MD5 collisions. I can only conclude that the
hash was being used incorrectly; most likely truncated (my wild-ass guess
would be to 32 bits; a collision is likely with > 50% probability in a
million document store for a hash of less than 40 bits).
I know the current state of the art here. It's going to take more than
just hearsay to convince me that full 128-bit MD5 collisions are likely.
I believe there are only two or so known to exist so far, and those were
found by a research team in China (which, yes, is fairly famous among the
cryptographic community now after publishing a paper consisting of little
apart from the two collisions themselves).
Please, let's talk about hash collisions responsibly. I posted earlier
about the *actual computed probability* of finding two files with an SHA-1
collision before the sun goes supernova. It's 10^28 to 1 against.
The recent cryptographic works has shown that there are certain situations
where a decent amount of computer work (2^69 operations) can produce two
sequences with the same hash, but these sequences are not freely chosen;
they've got very specific structure. This attack does not apply to
(effectively) random files sitting in a SCM.
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
That said, Linux's widespread use means that it may not be unimaginable
for an attacker to devote this amount of resources to an attack, which
would probably involve first committing some specially structured file to
the SCM (but would Linus accept it?) and then silently corrupting said
file via a SHA1 collision to toggle some bits (which would presumably Do
Evil). Thus hashes other than SHA1 really ought to be considered...
...but the cryptographic community has not yet come to a conclusion on
what the replacement ought to be. These attacks are so new that we don't
really understand what it is about the structure of SHA1 which makes them
possible, which makes it hard to determine which other hashes are
similarly vulnerable. It will take time.
I believe Linus has already stated on this list that his plan is to
eventually provide a tool for bulk migration of an existing SHA1 git
repository to a new hash type. Basically munging through the repository
in bulk, replacing all the hashes. This seems a perfectly adequate
strategy at the moment.
--scott
WASHTUB Panama Minister Moscow explosives KUGOWN hack Marxist LPMEDLEY
genetic immediate radar SCRANTON COBRA JANE KGB Shoal Bay atomic Bejing
( http://cscott.net/ )
^ permalink raw reply
* BK -> git export done
From: Thomas Gleixner @ 2005-04-16 15:57 UTC (permalink / raw)
To: git
Hi folks,
I managed finally to export the complete kernel history into git format
The resulting number of objects is ~ 500000
The required disk space is ~ 3.2 GiB
We also tracked the blob/tree/commit references in a SQL database. We
will post a SQL dump when the database is in a bit better shape. This
should make history tracking quite simple.
I currently figure out a way to post the data. My poor DSL line is a bit
too slow :)
tglx
^ permalink raw reply
* Re: git-pasky file mode handling
From: Petr Baudis @ 2005-04-16 14:56 UTC (permalink / raw)
To: Russell King; +Cc: git, torvalds
In-Reply-To: <20050416104559.A12943@flint.arm.linux.org.uk>
Dear diary, on Sat, Apr 16, 2005 at 11:45:59AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> Hi,
Hello,
> It seems that there's something weird going on with the file mode
> handling. Firstly, some files in the git-pasky repository have mode
> 0664 while others have 0644.
>
> Having pulled from git-pasky a number of times, with Petr's being the
> "tracked" repository, I now find that when I do an update-cache --refresh,
> it complains that the files need updating, despite show-diff showing no
> differences. Investigating, this appears to be because the file modes
> are wrong for a number of the files. All my files do not have group
> write.
this is was a problem with git apply, which did not apply mode changes
correctly until recently. If you have no local changes,
checkout-cache -f -a
should fix this. Hopefully.
> I notice in the changelog what appears to be a dependence on the umask.
> If this is so, please note that git appears to track the file modes,
> and any dependence upon the umask is likely to screw with this tracking.
I personally don't think I like the mode tracking at all. Some people
(Linus?) may want to have group +w. Other people (me) have their default
group as 'users', and I definitively don't want everyone to be able to
write to the files. :-)
I think we should track only whether the file is executable or not.
Linus?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: full kernel history, in patchset format
From: David Mansfield @ 2005-04-16 14:55 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20050416133513.GA21678@elte.hu>
Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>
>>the patches contain all the existing metadata, dates, log messages and
>>revision history. (What i think is missing is the BK tree merge
>>information, but i'm not sure we want/need to convert them to GIT.)
>
>
> author names are abbreviated, e.g. 'viro' instead of
> viro@parcelfarce.linux.theplanet.co.uk, and no committer information is
> included (albeit commiter ought to be Linus in most cases). These are
> limitations of the BK->CVS gateway i think.
>
Glad to hear cvsps made it through! I'm curious what the manual fixups
required were, except for the binary file issue (logo.gif).
As to the actual email addresses, for more recent patches, the
Signed-off should help. For earlier ones, isn't their some script which
'knows' a bunch of canonical author->email mappings? (the shortlog
script or something)?
Is the full committer email address actually in the changeset in BK? If
so, given that we have the unique id (immutable I believe) of the
changset, could it be extracted directly from BK?
David
^ permalink raw reply
* Re: space compression (again)
From: Martin Uecker @ 2005-04-16 14:39 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0504151210590.7211@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
On Fri, Apr 15, 2005 at 12:11:43PM -0700, Linus Torvalds wrote:
> On Fri, 15 Apr 2005, C. Scott Ananian wrote:
> >
> > So I guess I'll have to implement this and find out, won't I? =)
>
> The best way to shup somebody up is always to just do it, and say "hey, I
> told you so". It's hard to argue with numbers.
The right thing (TM) is to switch from SHA1 of compressed
content for the complete monolithic file to a merkle hash tree
of the uncompressed content. This would make the hash
independent of the actual storage method (chunked or not).
Martin
--
One night, when little Giana from Milano was fast asleep,
she had a strange dream.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: Junio C Hamano @ 2005-04-16 14:28 UTC (permalink / raw)
To: David Roundy; +Cc: git, darcs-devel
In-Reply-To: <20050416132231.GJ2551@abridgegame.org>
>>>>> "DR" == David Roundy <droundy@abridgegame.org> writes:
DR> 1) Would this actually be a good idea?
I think it is sensible, especially if you are doing a lot of
comparison between the working area and the pristine.
DR> 3) Is it likely that git will switch to not using global
DR> variables for active_cache, active_nr and active_alloc?
DR> 4) Would there be interest in creating a libgit?
These are related. I have seen some people interested in
libifying it, and encapsulating those globals would naturally
fall out of it. My impression from the list however is that a
lot more people are interested in the upper SCM layer than the
git layer right now. And git layer, although solid enough to
host itself, is still slushy. A couple of days ago dircache
format was changed from host to network endian. Last night
Linus made another change to dircache format, which fortunately
is upward compatible if you stay within pathnames shorter than
2^12 bytes ;-). Another problem I see for somebody to pick up
and start libifying things right now is that, although there is
one central person on the SCM side (Petr Baudis), git layer is
still fractured between Linus and Petr.
Petr syncs with Linus often and he seems to be doing a good job
at keeping track of public patches, but the git layer Linus
works on does not have some patches Petr collected or wrote
himself. In time, a better coordination would emerge, of
course, but the project is still young at this moment. Stay
tuned ;-).
^ permalink raw reply
* Issues with higher-order stages in dircache
From: Junio C Hamano @ 2005-04-16 14:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vis2ncf8j.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
JCH> So what's next?
Here is my current thinking on the impact your higher-order
stage dircache entries would have to the rest of the system and
how to deal with them.
* read-tree
- When merging two trees, i.e. "read-tree -m A B", shouldn't
we collapse identical stage-1/2 into stage-0?
* update-cache
- An explicit "update-cache [--add] [--remove] path" should
be taken as a signal from the user (or Cogito) to tell the
dircache layer "the merge is done and here is the result".
So just delete higher-order stages for the path and record
the specified path at stage 0 (or remove it altogether).
- "update-cache --refresh" should just ignore a path that has
not been merged, Maybe say "needs merge", just like "needs
update" [*1*].
- "update-cache --cacheinfo" should get an extra "stage"
argument. Unmerged state is typically produced by running
"read-tree -m", but the user or Cogito can do it by hand
with this if he wanted to.
- I do not think we need a separate "remove the entry for
this path at this stage" thing. That is only necessary if
the user or Cogito is doing things by hand (as opposed to
"read-tree -m"), which should be a very rare case. He can
always do "update-cache --remove" followed by "update-cache
--cacheinfo" to obtain the desired result if he really
wanted to. For that, "update-cache --force-remove" may
come in handy.
* show-diff
- What should we do about unmerged paths? Showing diffs
between the combinations (1->2), (1->3), and (2->3) that
exist may not be a bad idea. It would not be confusing
because by definition dircache with higher-order stages is
a merge temporary directory and the user should not have a
working file there to begin with.
I think the current implementation does a very bad thing:
repeating the same diff as many times as it has
higher-order stages for the same path.
* checkout-cache
- When checkout-cache is run with explicit paths that are
unmerged, what should we do? What does that mean in the
first place? One use scenario I can think of is that the
user or Cogito wants the contents at all three stages, in
order to run a merge tool on them. From this point of
view, checking out all the available stages for the path
makes sense.
My "cunning plan" is to drop ".1-$file", ".2-$file", and
".3-$file" in the working directory. How does that sound?
- When checkout-cache -a is run, presumably the user wants to
check out everything to verify (e.g. build-test) the
result. In this case, we should skip unmerged paths, give
a warning, and check out only the merged ones.
[Footnotes]
*1* Unrelated note. Who is the intended consumer of this "needs
update" message? Should we make it machine readable with
'-z' flag as well? Otherwise, shouldn't it go to stderr?
Currently it goes to stdout.
^ permalink raw reply
* Re: full kernel history, in patchset format
From: Ingo Molnar @ 2005-04-16 13:35 UTC (permalink / raw)
To: git
In-Reply-To: <20050416131528.GB19908@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> the patches contain all the existing metadata, dates, log messages and
> revision history. (What i think is missing is the BK tree merge
> information, but i'm not sure we want/need to convert them to GIT.)
author names are abbreviated, e.g. 'viro' instead of
viro@parcelfarce.linux.theplanet.co.uk, and no committer information is
included (albeit commiter ought to be Linus in most cases). These are
limitations of the BK->CVS gateway i think.
Ingo
^ permalink raw reply
* Proposal for simplification and impovement of the git model
From: Luca Barbieri @ 2005-04-16 13:35 UTC (permalink / raw)
To: git, torvalds
In this message, a method to simplify and at the same time make more
powerful the git abstraction is presented.
I believe that the enhancements I propose make git adhere even more to
its "spirit" and make it more intuitive.
The proposal makes it much easier to build an SCM over git, obtaining in
particular the following advantages:
- Blob and tree objects become symmetric
- Commit objects are removed (their data is put inside tree objects)
- Commit comments are per-file
- A tree in a repository looks like a repository itself, with full
version information (now only the one mentioned in the commit object has
version information)
- File and directory renames are tracked
- Renames are tracked regardless of the way they are made (even with cp
and rm)
- Commit comments can be updated at any time by whoever made the change
- Doing the "blame" operation is trivial
- Minimizing disk space usage (at the expense of speed) by storing diffs
is easily doable
The basic idea is that rather than having single blob or tree revisions
as the base concept, the abstract base unit is the whole set of
modifications, with comments, leading to that state.
Of course, tracking that would be extremely space-inefficient, so we
instead track the current file contents, plus the public key of the
author and the hashes of all parents.
This is implemented with the following changes to git:
- The commit object is removed
- Each tree must have a ".git-commit" file that contains the information
previously in the commit object (only for immediate children, thus
having a ".git-commit" file in each directory), but with the author
public key instead of the comments
- Each blob will be hashed as the blob contents plus an header in a
canonical format that contains data similar to the data in the
".git-commit" file
- When checked out, the blob header is put in a C/C++ comment, a #
comment, or if the file format is unknown, in an extended attribute or a
separate file
An example of a C/C++ file with metadata is the following:
// @parent<SHA1_OF_PARENT1> @parent<SHA1_OF_PARENT2>
// @author<FINGERPRINT_OF_AUTHOR_PUBLIC_KEY>
#include <stdlib.h>
int main(int argc, char** argv)
{
printf("Hello, world!\n");
return 0;
}
Note that @parent<> and @author<> in checked out files are NOT the same
of the ones in the repository but are crafted so that there is a single
@parent pointing to the repository file and @author is taken from
$HOME/.gitrc
- When the file is checked in, the header is parsed and removed.
* If there is a single parent, its header is added and the resulting
buffer is hashed and compared with the parent's hash. If equal, the file
is unchanged and not committed.
* Otherwise, the header data is added in a canonical format and the
buffer is hashed and committed
- A new class of objects is added, that is not named by their hash, but
rather by a public key (or fingerprint of it), a timestamp and a name.
The object is correct if and only if the contents plus name and
timestamp are signed with the private key corresponding to public key in
the name.
Object names are formatted as "<id>/<name>/<args>" where <url> is an
uuid or url that makes the <id>/<name> unique, <name> is the name, and
<args> is additional data.
File names formatted like "git/c/<sha1>" are interpreted as commit
comments for object <sha1>.
- For storage or network transmission purposes, a binary diff against
the parents can be stored instead of the contents af an object. This
will of course require to walk the whole history to rebuild it, but
smarter schemes are possible (e.g. "keyframes", "jump diffs", etc.).
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: Ingo Molnar @ 2005-04-16 13:31 UTC (permalink / raw)
To: git, darcs-devel
In-Reply-To: <20050416132231.GJ2551@abridgegame.org>
* David Roundy <droundy@abridgegame.org> wrote:
> 2) Will a license be chosen soon for git? Or has one been chosen, and
> I missed it? I can't really include git code in darcs without a
> license. I'd prefer GPLv2 or later (since that's how darcs is
> licensed), but as long as it's at least compabible with GPLv2, I'll be
> all right.
there's a license in the latest code, it's GPLv2. Here's the COPYING
file:
---------------
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
HOWEVER, in order to allow a migration to GPLv3 if that seems like
a good idea, I also ask that people involved with the project make
their preferences known. In particular, if you trust me to make that
decision, you might note so in your copyright message, ie something
like
This file is licensed under the GPL v2, or a later version
at the discretion of Linus.
might avoid issues. But we can also just decide to synchronize and
contact all copyright holders on record if/when the occasion arises.
Linus Torvalds
----------------------------------------
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
\f
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
\f
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
\f
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
\f
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
\f
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox