| Message ID | E1RauNd-0008W1-02@tytso-glaptop.cam.corp.google.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Wed, Dec 14, 2011 at 11:20 AM, Theodore Ts'o <tytso@mit.edu> wrote: > > There is a signed tag tytso-for-linus-20111214 covering these patches, > which fix a potential hang, crash (on big endian), and data corruption > bugs which show up when using fsx and/or Hugh's kernel compile/mm > torture test. Ok, since I build my own git versions, I have one that can pull signed tags and automatically verifies them and saves the signed tag information as part of the commit object. Which is all fine, but your tag-names are just ugly. I could edit the end result (another advantage of the new git version - it starts the editor automatically), but I decided to not do so, and instead use this as a "teaching moment" for everybody. Everybody: you can now create a signed tag, and just point me at it. You don't even have to have a separate branch for me to pull any more, just the signed tag is fine. So it would actually be nicer if you used temporary tag names the way you use temporary branch names when you ask me to pull. The tag *content* will be saved from now on (unless I screw up while traveling or something and pull with a machine that has an older git version), so there's very little advantage in then saving the tags separately by having ugly tag-names with long lifetimes. I pushed out, so you can see this in action in the current git tree by doing [torvalds@i5 linux]$ git show --abbrev-commit 2240a7bb479c to see the normal commit message. And then to see the actual saved-away signed tag information, do [torvalds@i5 linux]$ git cat-file commit 2240a7bb479c which should all work with old versions of git too - it's just the merger that needs a new version of git. It's easy to parse: it's the standard "git tag" format, except it is indented by a space to show that it's part of the header (and then the first empty line is what ends the commit object headers). So you can basically do something like git cat-file commit 2240a7bb479c | awk '/^mergetag /,/^$/ { print }' | sed 's/^mergetag//' | sed 's/^ //' to re-create the tag object, and then you can verify it (the part *before* the "-----BEGIN PGP SIGNATURE-----" line should match the signature inside the PGP signature - trivial format). It got verified when I pulled it (the gpg verification output shows up as part of the comments in the commit message editing thing), but using the above you can now verify it after-the-fact too, without having access to your original tag object - since the data is embedded in the git merge commit. Hmm? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 14, 2011 at 06:50:07PM -0800, Linus Torvalds wrote: > On Wed, Dec 14, 2011 at 11:20 AM, Theodore Ts'o <tytso@mit.edu> wrote: > > > > There is a signed tag tytso-for-linus-20111214 covering these patches, > > which fix a potential hang, crash (on big endian), and data corruption > > bugs which show up when using fsx and/or Hugh's kernel compile/mm > > torture test. > > Ok, since I build my own git versions, I have one that can pull signed > tags and automatically verifies them and saves the signed tag > information as part of the commit object. Cool! Does it save enough that GPG signature information can be verified later? I'm a little fuzzy on what is covered by the signature which gets verified when you run the command "git verify-tag tytso-for-linus-20111214". Better yet, does the new version of git have a command that will automatically verify the digital signature found in a merge commit? And this isn't in 1.7.8 yet, right? I'd have to build version of git based on the next branch to play with this new signatury goodness? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 15, 2011 at 11:08 AM, Ted Ts'o <tytso@mit.edu> wrote: > > Cool! Does it save enough that GPG signature information can be > verified later? Yes, it saves the whole tag object data, and the verification really is very simple. Do the command line I suggested: git cat-file commit 2240a7bb479c | awk '/^mergetag /,/^$/ { print }' | sed 's/^mergetag//' | sed 's/^ //' (ok, that can almost certainly be done smarter, but it's a step-by-step trivial thing: the "awk" line to get everything in the commit object header 'mergetag' line to tne end of the commit header (empty line), followed by removing the "mergetag" part, followed by removing the continuation space at the beginning of the line. Now, save the end result to a file, and then split the file so that the gpg signature part (-----BEGIN PGP SIGNATURE----- etc) is in "file.sign", and the part before it, which in this case is object 5a0dc7365c240795bf190766eba7a27600be3b3e type commit tag tytso-for-linus-20111214 tagger Theodore Ts'o <tytso@mit.edu> 1323890113 -0500 tytso-for-linus-20111214 is in the file "file", and now you can just do [torvalds@i5 linux]$ gpg --verify file.sign file gpg: Signature made Wed 14 Dec 2011 11:15:13 AM PST using RSA key ID C11804F0 gpg: Good signature from "Theodore Ts'o <tytso@mit.edu>" gpg: aka "Theodore Ts'o <tytso@debian.org>" gpg: aka "Theodore Ts'o <tytso@google.com>" > I'm a little fuzzy on what is covered by the > signature which gets verified when you run the command "git verify-tag > tytso-for-linus-20111214". Better yet, does the new version of git > have a command that will automatically verify the digital signature > found in a merge commit? See above, the pgp signature logic is *really* simple: it's literally "the pgp signature at the end covers everything up until the pgp signature part". And it's unambiguous even in the case of multiple lines of "-----BEGIN PGP SIGNATURE-----" - you just need to take the last block. Whether we do that right in the actual implementation, I have no idea, but the thing is at least designed to allow that. This all literally used to be a couple of lines of shell script in the original git implementation of "git verify-tag". You can just go to the git sources, and do git log -p -- git-verify-tag.sh to see that old historic implementation, of course. Here's the very original one: #!/bin/sh . git-sh-setup || die "Not a git archive" tag=$(git-rev-parse $1) || exit 1 git-cat-file tag $tag > .tmp-vtag || exit 1 cat .tmp-vtag | sed '/-----BEGIN PGP/Q' | gpg --verify .tmp-vtag - || exit 1 rm -f .tmp-vtag which gets it wrong for the case of multiple lines of "BEGIN PGP", but whatever. > And this isn't in 1.7.8 yet, right? I'd have to build version of git > based on the next branch to play with this new signatury goodness? If you actually want to merge signed tags with the save-the-tag-info feature, yes. It's in the current master branch of git, but not in any released version yet. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Ted Ts'o <tytso@mit.edu> writes: > Cool! Does it save enough that GPG signature information can be > verified later? I'm a little fuzzy on what is covered by the > signature which gets verified when you run the command "git verify-tag > tytso-for-linus-20111214". Better yet, does the new version of git > have a command that will automatically verify the digital signature > found in a merge commit? > > And this isn't in 1.7.8 yet, right? I'd have to build version of git > based on the next branch to play with this new signatury goodness? The 'master' branch as of this week has the topic merged. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Junio C Hamano <gitster@pobox.com> writes: > Ted Ts'o <tytso@mit.edu> writes: > ... >> And this isn't in 1.7.8 yet, right? I'd have to build version of git >> based on the next branch to play with this new signatury goodness? > > The 'master' branch as of this week has the topic merged. Also please notice that the original "pull request" said: Hi Linus, There is a signed tag tytso-for-linus-20111214 covering these patches,... Please pull, - Ted The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50: Linux 3.2-rc5 (2011-12-09 15:09:32 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev Andrea Arcangeli (1): ext4: avoid hangs in ext4_da_should_update_i_disksize() ... shortlog output ... that mentions where the work forked, but does _not_ mention what tip commit of "dev" branch to expect. Updated "git request-pull" command will have that information, and also gives the tag name you already pushed out to your publishing repository instead of the branch name "dev" when producing the "... available in the git repository at:" information. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds <torvalds@linux-foundation.org> writes: > On Wed, Dec 14, 2011 at 11:20 AM, Theodore Ts'o <tytso@mit.edu> wrote: >> >> There is a signed tag tytso-for-linus-20111214 covering these patches, >> which fix a potential hang, crash (on big endian), and data corruption >> bugs which show up when using fsx and/or Hugh's kernel compile/mm >> torture test. > > Ok, since I build my own git versions, I have one that can pull signed > tags and automatically verifies them and saves the signed tag > information as part of the commit object. Just a note. The new feature was broken when the pull has conflict that needs to be resolved and concluded with "git commit". The version of git from 'master' as of today should have a fix, but older ones forgot to record the mergetag in the resulting commit object. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Linus, There is a signed tag tytso-for-linus-20111214 covering these patches, which fix a potential hang, crash (on big endian), and data corruption bugs which show up when using fsx and/or Hugh's kernel compile/mm torture test. Please pull, - Ted The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50: Linux 3.2-rc5 (2011-12-09 15:09:32 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev Andrea Arcangeli (1): ext4: avoid hangs in ext4_da_should_update_i_disksize() Paul Mackerras (1): ext4: Fix crash due to getting bogus eh_depth value on big-endian systems Theodore Ts'o (2): ext4: fix ext4_end_io_dio() racing against fsync() ext4: display the correct mount option in /proc/mounts for [no]init_itable Yongqiang Yang (4): ext4: avoid potential hang in mpage_submit_io() when blocksize < pagesize ext4: correctly handle pages w/o buffers in ext4_discard_partial_buffers() ext4: remove a wrong BUG_ON in ext4_ext_convert_to_initialized ext4: handle EOF correctly in ext4_bio_write_page() fs/ext4/extents.c | 3 +- fs/ext4/inode.c | 54 +++++++++------------------------------------------- fs/ext4/page-io.c | 12 +++++++++++ fs/ext4/super.c | 17 +++++++-------- 4 files changed, 31 insertions(+), 55 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html