From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS8075 65.52.0.0/14 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from BLU004-OMC2S14.hotmail.com (blu004-omc2s14.hotmail.com [65.55.111.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 9C01D2018E for ; Thu, 25 Aug 2016 03:57:39 +0000 (UTC) Received: from NAM04-SN1-obe.outbound.protection.outlook.com ([65.55.111.72]) by BLU004-OMC2S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 24 Aug 2016 20:57:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0uK3auPq7pniS2pGN69XnzDacXRg4Ee/4bF5kLruDnk=; b=ENWPRTk4ZDAa09eibBhxeL7EFEGOmdsSBS/5li5ieCrlOuZpOsXqr/trYh2w4d1jossHHS4I5ujIFfQM45qyClFToH1KRUP32ekO45EnsbEgj+H6CMc2P8DhNzgRe3sssx8c1OJX4IGr5mjMd1NNQBAUcqex2Hql7KDsWvCXOG0Nuvuc2p3LldYcddeTBP+uT6fUZ3Qf5ayOKSSfco6Nj5KFDXgavb2cRV8NuAjBm6nIIjMTe0+YOA6wiykoJk1kuJr5ogYBA/aUOXP9lFsisqoItg73fjhK6BTnIADcEPXEECWaKF2ASxOSxmSn8CcgRZ64zCHSHb/Dufnc47HBWw== Received: from CO1NAM04FT023.eop-NAM04.prod.protection.outlook.com (10.152.90.54) by CO1NAM04HT052.eop-NAM04.prod.protection.outlook.com (10.152.91.98) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6; Thu, 25 Aug 2016 03:57:37 +0000 Received: from DM5PR17MB1353.namprd17.prod.outlook.com (10.152.90.59) by CO1NAM04FT023.mail.protection.outlook.com (10.152.90.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Thu, 25 Aug 2016 03:57:36 +0000 Received: from DM5PR17MB1353.namprd17.prod.outlook.com ([10.173.134.15]) by DM5PR17MB1353.namprd17.prod.outlook.com ([10.173.134.15]) with mapi id 15.01.0587.013; Thu, 25 Aug 2016 03:57:36 +0000 From: Arif Khokar To: Johannes Schindelin , Philip Oakley CC: Duy Nguyen , Jeff King , Stefan Beller , "meta@public-inbox.org" , "git@vger.kernel.org" , Eric Wong , =?iso-8859-2?Q?Jakub_Nar=EAbski?= Subject: Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path] Thread-Topic: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path] Thread-Index: AQHR/oTQoDDm3GKhNU2i1oir7XokSA== Date: Thu, 25 Aug 2016 03:57:36 +0000 Message-ID: References: <20160819150340.725bejnps6474u2e@sigill.intra.peff.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 10.152.90.59) smtp.mailfrom=hotmail.com; gmx.de; dkim=none (message not signed) header.d=none;gmx.de; dmarc=fail action=none header.from=hotmail.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.com discourages use of 10.152.90.59 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.90.59;IPV:NLI;CTRY:;EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:CO1NAM04HT052;H:DM5PR17MB1353.namprd17.prod.outlook.com;FPR:;SPF:None;LANG:en; x-microsoft-exchange-diagnostics: 1;CO1NAM04HT052;6:M0kH163FuiSRIC77PmyS383PIUIl/PEPjuB6K2iY2TZ18evpw7QpHle4FcMNKQfSWc58lGzFjqrUyS48HJvEW+JaECXQk82cJPSVmCEWDWwDUfMFRJGjic1LiokN/gy9xxNKmaYxIphdQBIu8I9nKp6UfdbpvP/VHoTJpwRN+roDMdyTdns/KRi3dRDyDNaYtpOLu6c6hp0m3w2AXeRBr8TDI8V4oWasHZm5/huGqWdwcW4UKAYjXYblGk1FZ93ghjGddlIvcDQ210Fquie7lL3JVrvhssYSsxILIE+ZTd+urF2vfAMjUzE+F8da0SXpHG2Aegz3JuyZpA8C7TSElA==;5:giBdDgNVnlMePe33C1qjHya8gYstgKWdESb+UJGDYASLJewbdwndakxkJSAv+PByaYbWKQcBykl0nBpwL3E6DOJBhvnWnCHTq5N8wJAbGXLFcpDYr70U+NBsf3XOCw5p35ogc0rc3LxQ3oY2wiz6fg==;24:Asy842kdtfagtDOPEAlu1SKBwVvnjliOpvIx73+2sRr2BXBDp0oC1JrguLaBgQuU5TCjij9E8eZCizSrhBqW9WdKCO5IR3apInntAkinzaU=;7:MwhS4fdZbg/LJSx+3eByZZ9P7Ad4lj4vYb4y8i+0aLSg5JFC2V3ZzWv2pA+niCIT4AsfcX1+z4D7n4pIRvNdogbBQIPaZsa/0q/NQZOafgAUrmKkbPvN1rtUYqtxOBaO+FaKemtcSYcyyBNaFAIcz60QyvymXHT98wkFzU8D+w2yZQNd2THF2YuKo8jcXlxm8qEsxd2v4iWU8/7O2LsHSe+6TaUn0InIDhlErEc49szxnFknQ0Bke3E7uNDPpcLr x-ms-office365-filtering-correlation-id: bf80cea3-3e0e-4227-5583-08d3cc9bf2a2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(1601124038)(1601125047);SRVR:CO1NAM04HT052; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:CO1NAM04HT052;BCL:0;PCL:0;RULEID:;SRVR:CO1NAM04HT052; x-forefront-prvs: 0045236D47 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 03:57:36.4914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT052 X-OriginalArrivalTime: 25 Aug 2016 03:57:38.0904 (UTC) FILETIME=[D25F1580:01D1FE84] List-Id: On 08/24/2016 09:04 AM, Johannes Schindelin wrote: > Hi Philip, > > On Mon, 22 Aug 2016, Philip Oakley wrote: >> I do note that dscho's patches now have the extra footer (below the thre= e >> dashes) e.g. >> >> Published-As: https://github.com/dscho/git/releases/tag/cat-file-filters= -v1 >> Fetch-It-Via: git fetch https://github.com/dscho/git cat-file-filters-v1 > I considered recommending this as some way to improve the review process. > The problem, of course, is that it is very easy to craft an email with an > innocuous patch and then push some malicious patch to the linked > repository. It should be possible to verify the SHA1 of the blob before and after=20 the patch is applied given the values listed near the beginning of the=20 git diff output. So, for instance, if I apply the malicious patch to my=20 local repository, the SHA1 of the resulting blob would not match what=20 was listed in at least one of the diffs. But whether that is sufficient for verification depends on the work=20 flow. Are patches typically applied on the blob that corresponds to the=20 first SHA1 value listed in the diff for that file?