From sacadmin Tue Jul 29 17:06:44 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6U06i85017128 for ; Tue, 29 Jul 2008 17:06:44 -0700 (PDT) Received: from rosseau (rosseau.SFBay.Sun.COM [129.146.228.252]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m6U06ieo909429 for ; Tue, 29 Jul 2008 17:06:44 -0700 (PDT) Date: Tue, 29 Jul 2008 17:07:13 -0700 From: Stephen Hahn To: psarc@sac.sfbay.sun.com Subject: 2008/190 pkg(5) preinception materials Message-ID: <20080730000713.GA2132@eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Solaris Kernel Development; Sun Microsystems, Inc. User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 443 I've placed two sets of slides and our current manual pages in the preinception.materials subdirectory. The outline is the set of topics I expect to discuss (plus others, I'm sure) as we go through the review sequence; the requirements are the overview from the 2008.11 teleconference in June. Any subset of these should be able to be the basis for a healthy discussion. - Stephen -- sch@sun.com http://blogs.sun.com/sch/ From Aarti.Pai@sun.com Tue Jul 29 17:20:29 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6U0KTtc017673 for ; Tue, 29 Jul 2008 17:20:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6U0KSDD027009 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 29 Jul 2008 17:20:29 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4S00M03MA40R00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jul 2008 18:20:28 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4S0061NMA4QKB0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jul 2008 18:20:28 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6U0KSVD017175 for ; Wed, 30 Jul 2008 00:20:28 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4S00401M6QHK00@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jul 2008 18:20:28 -0600 (MDT) Received: from [192.168.1.104] ([76.21.4.117]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4S00LZMM9TFL90@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jul 2008 18:20:21 -0600 (MDT) Date: Tue, 29 Jul 2008 17:20:09 -0700 From: Aarti Pai Subject: [Fwd: 2008/190 pkg(5) preinception materials] Sender: Aarti.Pai@sun.com To: lsarc-ext@sun.com Message-id: <488FB3B9.9020909@Sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_p0XznW9Qgv6SkYVGJggPmg)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17pre (Windows/20080713) Status: RO Content-Length: 4098 This is a multi-part message in MIME format. --Boundary_(ID_p0XznW9Qgv6SkYVGJggPmg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT fyi --Boundary_(ID_p0XznW9Qgv6SkYVGJggPmg) Content-type: message/rfc822; name="2008/190 pkg(5) preinception materials.eml" Return-path: Received: from fe-amer-10.sun.com ([192.18.109.80]) by amer4-mail1.central.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K4S0087VLPEVN90@amer4-mail1.central.sun.com>; Tue, 29 Jul 2008 18:08:02 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4S00901LCMCI00@mail-amer.sun.com> (ORCPT psarc-interest@sun.com); Tue, 29 Jul 2008 18:08:02 -0600 (MDT) Received: from phys-amer4-2.central.sun.com ([129.147.157.51]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K4S000DTLPE16E0@mail-amer.sun.com> (ORCPT psarc-interest@sun.com); Tue, 29 Jul 2008 18:08:02 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by amer4-mail1.central.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K4S0087TLPEVN90@amer4-mail1.central.sun.com> (ORCPT psarc-interest@sun.com); Tue, 29 Jul 2008 18:08:02 -0600 (MDT) Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6U081PP022464; Tue, 29 Jul 2008 17:08:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6U07Y9A046693; Tue, 29 Jul 2008 18:07:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4S00C03LOLFH00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jul 2008 17:07:33 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4S0029CLOLNH60@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jul 2008 17:07:33 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6U07X8o022224; Tue, 29 Jul 2008 17:07:33 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6U06i85017128 for ; Tue, 29 Jul 2008 17:06:44 -0700 (PDT) Received: from rosseau (rosseau.SFBay.Sun.COM [129.146.228.252]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m6U06ieo909429 for ; Tue, 29 Jul 2008 17:06:44 -0700 (PDT) Date: Tue, 29 Jul 2008 17:07:13 -0700 From: Stephen Hahn Subject: 2008/190 pkg(5) preinception materials To: psarc@sac.sfbay.sun.com Message-id: <20080730000713.GA2132@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. X-Envelope-from: Aarti.Pai@Sun.COM X-Envelope-to: lsarc-ext <@smarthost.sun.com:lsarc-ext@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 User-Agent: Mutt/1.5.17 (2007-11-01) Original-recipient: rfc822;psarc-interest@sun.com I've placed two sets of slides and our current manual pages in the preinception.materials subdirectory. The outline is the set of topics I expect to discuss (plus others, I'm sure) as we go through the review sequence; the requirements are the overview from the 2008.11 teleconference in June. Any subset of these should be able to be the basis for a healthy discussion. - Stephen -- sch@sun.com http://blogs.sun.com/sch/ --Boundary_(ID_p0XznW9Qgv6SkYVGJggPmg)-- From sacadmin Wed Jul 30 12:11:06 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6UJB6TU026779 for ; Wed, 30 Jul 2008 12:11:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6UJB65c012931; Wed, 30 Jul 2008 12:11:06 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4U00L072MH8G00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jul 2008 12:11:05 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4U00KLS2MG7N00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jul 2008 12:11:05 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6UJB4PH016848; Wed, 30 Jul 2008 19:11:04 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4U00501155X100@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) ; Wed, 30 Jul 2008 13:11:04 -0600 (MDT) Received: from [129.145.154.105] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4U000MF2MCILE0@mail-amer.sun.com>; Wed, 30 Jul 2008 13:11:01 -0600 (MDT) Date: Wed, 30 Jul 2008 12:10:59 -0700 From: Aarti Pai Subject: Meeting Minutes for PSARC - 07/30/2008 - [2008/190] Sender: Aarti.Pai@sun.com To: psarc@sun.com, lsarc@sun.com Cc: Stephen Hahn Reply-to: Aarti.Pai@sun.com Message-id: <4890BCC3.109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 603 Minutes/Audio for PSARC meeting 07/30/2008 are now available: - Open ARC Business: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080730.arcbiz.open Audio: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080730.arcbiz.open.mp3 - Open Preinception Case : pkg(5) - Image Packaging System (IPS) (2008/190) Minutes: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080730.2008.190.preinception Audio: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080730.2008.190.preinception.mp3 Please contact me directly if you require any corrections/modifications to these minutes. Aarti From sacadmin Wed Jul 30 12:11:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6UJB6TW026779 for ; Wed, 30 Jul 2008 12:11:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6UJB65c012931; Wed, 30 Jul 2008 12:11:06 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4U00L072MH8G00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jul 2008 12:11:05 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4U00KLS2MG7N00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jul 2008 12:11:05 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m6UJB4PH016848; Wed, 30 Jul 2008 19:11:04 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4U00501155X100@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) ; Wed, 30 Jul 2008 13:11:04 -0600 (MDT) Received: from [129.145.154.105] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4U000MF2MCILE0@mail-amer.sun.com>; Wed, 30 Jul 2008 13:11:01 -0600 (MDT) Date: Wed, 30 Jul 2008 12:10:59 -0700 From: Aarti Pai Subject: Meeting Minutes for PSARC - 07/30/2008 - [2008/190] Sender: Aarti.Pai@sun.com To: psarc@sun.com, lsarc@sun.com Cc: Stephen Hahn Reply-to: Aarti.Pai@sun.com Message-id: <4890BCC3.109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 603 Minutes/Audio for PSARC meeting 07/30/2008 are now available: - Open ARC Business: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080730.arcbiz.open Audio: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080730.arcbiz.open.mp3 - Open Preinception Case : pkg(5) - Image Packaging System (IPS) (2008/190) Minutes: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080730.2008.190.preinception Audio: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080730.2008.190.preinception.mp3 Please contact me directly if you require any corrections/modifications to these minutes. Aarti From Darren.Reed@sun.com Wed Jul 30 12:45:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6UJjNbK028395 for ; Wed, 30 Jul 2008 12:45:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6UJiorf001786 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 30 Jul 2008 20:45:22 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4U00C1747JQ200@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 30 Jul 2008 12:45:19 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4U00B4V47I6340@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 30 Jul 2008 12:45:18 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6UJjHEG021255 for ; Wed, 30 Jul 2008 19:45:17 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4U008013ZMCM00@fe-emea-09.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 30 Jul 2008 20:45:17 +0100 (BST) Received: from [129.146.106.55] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4U00H4047GEH30@fe-emea-09.sun.com>; Wed, 30 Jul 2008 20:45:17 +0100 (BST) Date: Wed, 30 Jul 2008 12:45:16 -0700 From: Darren Reed Subject: Re: PSARC/2008/190 - Preinception IPS Sender: Darren.Reed@sun.com To: sch@sun.com Cc: PSARC-EXT Message-id: <4890C4CC.9040402@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 631 Stephen, I've updated the issues files with the questions from the meeting this morning and made a brief note of the answers that I could remember. There were two questions I had from the discussion that I didn't bring up at the time: djr-3 Can package authorities be discovered rather than configured? djr-5 If multiple catalogues/depots are available, how does IPS choose which one to use if they are publishing conflicting information? For djr-3, I'm thinking along the lines of using multicast discovery on your local LAN or corporate WAN/LAN or maybe clues via DHCP or even a special DHCP tag or ... Darren From Nicolas.Williams@sun.com Wed Jul 30 13:05:57 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6UK5vQW029441 for ; Wed, 30 Jul 2008 13:05:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6UK5sqh013173; Wed, 30 Jul 2008 14:05:54 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4U0040B55UBR00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jul 2008 13:05:54 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4U00KYO55T7M50@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jul 2008 13:05:53 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m6UK5rbV006432; Wed, 30 Jul 2008 15:05:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m6UK5rxl006431; Wed, 30 Jul 2008 15:05:53 -0500 (CDT) Date: Wed, 30 Jul 2008 15:05:53 -0500 From: Nicolas Williams Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <4890C4CC.9040402@Sun.COM> To: Darren Reed Cc: sch@sun.com, PSARC-EXT Mail-followup-to: Darren Reed , sch@sun.com, PSARC-EXT Message-id: <20080730200552.GL25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1116 On Wed, Jul 30, 2008 at 12:45:16PM -0700, Darren Reed wrote: > djr-3 Can package authorities be discovered rather than configured? Why is this even necessary? The install media can take care of setting the correct authorities on an installed image. Also, discovery doesn't get you past authorization: the image owner needs to decide whether the discovered authorities are authorized. [In an enterprise environment] You'd need to authenticate the source of the discovered authorities to get past such interaction, and that's hard. > djr-5 If multiple catalogues/depots are available, how does IPS choose > which one to use if they are publishing conflicting information? I thought that authority preference was part of the answer, but there is a single preferred authority, so if you have more than one authority associated with an image then interaction seems required. No? > For djr-3, I'm thinking along the lines of using multicast discovery on > your local LAN or corporate WAN/LAN or maybe clues via DHCP or > even a special DHCP tag or ... None of those being authenticated... :( Nico -- From MAILER-DAEMON Wed Jul 30 20:12:16 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6V3CFsQ015690 for ; Wed, 30 Jul 2008 20:12:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6V3C26Z021397; Thu, 31 Jul 2008 04:12:13 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4U00101OWCWW00@brm-avmta-1.central.sun.com>; Wed, 30 Jul 2008 21:12:12 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4U000YGOWBQEC0@brm-avmta-1.central.sun.com>; Wed, 30 Jul 2008 21:12:11 -0600 (MDT) Received: from rosseau (rosseau.SFBay.Sun.COM [129.146.228.252]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m6V3CB2O322178; Wed, 30 Jul 2008 20:12:11 -0700 (PDT) Date: Wed, 30 Jul 2008 20:12:41 -0700 From: Stephen Hahn Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <4890C4CC.9040402@Sun.COM> To: Darren Reed Cc: PSARC-EXT Message-id: <20080731031241.GD1048@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1326 * Darren Reed [2008-07-30 19:45]: > Stephen, > > I've updated the issues files with the questions from the meeting > this morning and made a brief note of the answers that I could > remember. > > There were two questions I had from the discussion that I didn't > bring up at the time: > > djr-3 Can package authorities be discovered rather than configured? > > djr-5 If multiple catalogues/depots are available, how does IPS choose > which one to use if they are publishing conflicting information? > > For djr-3, I'm thinking along the lines of using multicast discovery on > your local LAN or corporate WAN/LAN or maybe clues via DHCP or > even a special DHCP tag or ... Yes, we think multicast discovery is very interesting for discovering local depots. We'd also like to have a means for one repository to offer pointers to other interesting repositories, although this could be as simple as a package with a bunch of authority definitions. We'll discuss djr-5 and get a proper response, but fully adversarial repositories, presumably with legitimate cryptographic tokens, hasn't been a focus. Our model has been trust signed metadata, distrust contents. We could go further into what "trust" means, I suppose. - Stephen -- sch@sun.com http://blogs.sun.com/sch/ From gdamore@sun.com Wed Jul 30 20:41:13 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6V3fCol015791 for ; Wed, 30 Jul 2008 20:41:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6V3f3JU029390 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 31 Jul 2008 04:41:12 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4U00B01Q8NPS00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 30 Jul 2008 20:41:11 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4U009CHQ8NUA10@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 30 Jul 2008 20:41:11 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6V3fBl5026586 for ; Wed, 30 Jul 2008 20:41:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4U00L01Q6WF400@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 30 Jul 2008 20:41:11 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4U00KBHQ8M6I80@fe-sfbay-10.sun.com>; Wed, 30 Jul 2008 20:41:10 -0700 (PDT) Date: Wed, 30 Jul 2008 20:36:30 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <20080731031241.GD1048@eng.sun.com> Sender: Garrett.Damore@sun.com To: Stephen Hahn Cc: Darren Reed , PSARC-EXT Message-id: <4891333E.5020704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1607 Stephen Hahn wrote: > * Darren Reed [2008-07-30 19:45]: > >> Stephen, >> >> I've updated the issues files with the questions from the meeting >> this morning and made a brief note of the answers that I could >> remember. >> >> There were two questions I had from the discussion that I didn't >> bring up at the time: >> >> djr-3 Can package authorities be discovered rather than configured? >> >> djr-5 If multiple catalogues/depots are available, how does IPS choose >> which one to use if they are publishing conflicting information? >> >> For djr-3, I'm thinking along the lines of using multicast discovery on >> your local LAN or corporate WAN/LAN or maybe clues via DHCP or >> even a special DHCP tag or ... >> > > Yes, we think multicast discovery is very interesting for discovering > local depots. We'd also like to have a means for one repository to > offer pointers to other interesting repositories, although this could > be as simple as a package with a bunch of authority definitions. > > We'll discuss djr-5 and get a proper response, but fully adversarial > repositories, presumably with legitimate cryptographic tokens, hasn't > been a focus. Our model has been trust signed metadata, distrust > contents. We could go further into what "trust" means, I suppose. > Yes, a discussion of trust is relevant here. I also would prefer to see a model where nested signing or multiple signing is possible. Also, management of the trust anchor(s) is something I'd like to see more fully discussed. -- Garrett > - Stephen > > From MAILER-DAEMON Wed Jul 30 21:32:13 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6V4WCOx017105 for ; Wed, 30 Jul 2008 21:32:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6V4W8wa014527; Thu, 31 Jul 2008 05:32:08 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4U00E1NSLK9Y00@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Jul 2008 21:32:08 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4U009AGSLIUM30@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Jul 2008 21:32:06 -0700 (PDT) Received: from rosseau (rosseau.SFBay.Sun.COM [129.146.228.252]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m6V4W6w7327054; Wed, 30 Jul 2008 21:32:06 -0700 (PDT) Date: Wed, 30 Jul 2008 21:32:35 -0700 From: Stephen Hahn Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <4891333E.5020704@sun.com> To: "Garrett D'Amore" Cc: Darren Reed , PSARC-EXT Message-id: <20080731043234.GG1048@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 1022 * Garrett D'Amore [2008-07-31 03:41]: > I also would prefer to see a model where nested signing or multiple > signing is possible. So, as I pointed out during the discussion, changing a package's tags or its contents would be interpreted by most package publishers as "not my package anymore", and I would expect them to not be interested in seeing their signature propagate on after their package has been manipulated. I suppose I based that assumption on the fact that the signing support on SysV is single certificate, and was added relatively recently (S10, maybe an S9 update as well)--meaning that the requirements are still reasonably up-to-date. I am having difficulty formulating a use case where nested or multiply signed packages are needed, and in which the consumer makes different decisions when distinct subsets of the signing entities cannot be independently verified. Maybe someone has an example? - Stephen -- sch@sun.com http://blogs.sun.com/sch/ From John.Plocher@sun.com Wed Jul 30 23:18:09 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6V6I8U2021067 for ; Wed, 30 Jul 2008 23:18:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6V6I3bA015872 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 31 Jul 2008 07:18:08 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4U00J0BXI3P600@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 30 Jul 2008 23:18:03 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4U0091RXI2UN70@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 30 Jul 2008 23:18:02 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6V6I2FH001262 for ; Wed, 30 Jul 2008 23:18:02 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4U00001XF2Q500@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 30 Jul 2008 23:18:02 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4U000D5XI2AX00@fe-sfbay-10.sun.com>; Wed, 30 Jul 2008 23:18:02 -0700 (PDT) Date: Wed, 30 Jul 2008 23:18:02 -0700 From: John Plocher Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <20080731043234.GG1048@eng.sun.com> Sender: John.Plocher@sun.com To: Stephen Hahn Cc: "Garrett D'Amore" , PSARC-EXT , Darren Reed Message-id: <4891591A.7090505@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 647 Stephen Hahn wrote: > I am having difficulty formulating a use case where nested or multiply > signed packages are needed, Imagine that IT Sets up a depot of their own, and fills it with a "mirror" of the official packages. Furthermore, because the upstream repo they are mirroring has lots of versions of things in it, they wish to add metadata to selected packages that says "Recommended by your local IT department". To do this, they would take a version of (say) the "Official" Mozilla package and add their own metadata to it. In this use case, adding metadata to a package does not necessarily invalidate its authenticity. -John From gdamore@sun.com Thu Jul 31 09:29:43 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VGTgNI011117 for ; Thu, 31 Jul 2008 09:29:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6VGTe1U026064 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 31 Jul 2008 09:29:42 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4V00E07PTI1X00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 10:29:42 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4V007QTPTH2V50@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 10:29:41 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6VGTe4C028022 for ; Thu, 31 Jul 2008 09:29:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4V00E01PP4GU00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 09:29:40 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4V000NVPT3YO50@fe-sfbay-09.sun.com>; Thu, 31 Jul 2008 09:29:27 -0700 (PDT) Date: Thu, 31 Jul 2008 09:24:45 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <4891591A.7090505@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Stephen Hahn , PSARC-EXT , Darren Reed Message-id: <4891E74D.3060800@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <4891591A.7090505@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1607 John Plocher wrote: > Stephen Hahn wrote: >> I am having difficulty formulating a use case where nested or multiply >> signed packages are needed, > > Imagine that IT Sets up a depot of their own, and fills it with a > "mirror" > of the official packages. Furthermore, because the upstream repo they > are mirroring has lots of versions of things in it, they wish to add > metadata > to selected packages that says "Recommended by your local IT department". > > To do this, they would take a version of (say) the "Official" Mozilla > package > and add their own metadata to it. > > In this use case, adding metadata to a package does not necessarily > invalidate > its authenticity. > > -John Right. And furthermore, for many people in the organization, if they don't have the original IT dept's root cert, they can at least still validate that bits properly came from some trusted (Sun, or wherever) source. The other thing is that Sun (or some other support organization) might insist on verifying that the bits installed were the same bits they delivered. Having the IT department break the thing apart and resign it (thus invalidating the original signatures) might compromise the ability of different support organizations to be confident in the delivered bits. The only time I would have a concern is if the metadata could somehow change the behavior of a package, where IT's "tagging" somehow could alter the behavior of the package. In that case, I'd worry more. I've not heard that the meta data involved can do this, but perhaps I'm missing something. -- Garrett From Darren.Reed@Sun.COM Thu Jul 31 10:16:39 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VHGdnx012569 for ; Thu, 31 Jul 2008 10:16:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6VHGcVa014108 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 31 Jul 2008 10:16:39 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4V00503RZPJW00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 10:16:37 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4V00DEGRZNGR80@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 10:16:36 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6VHGZPo021653 for ; Thu, 31 Jul 2008 17:16:35 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4V00001RTXYI00@fe-emea-09.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 18:16:35 +0100 (BST) Received: from [129.146.106.55] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4V00JQ3RZM3020@fe-emea-09.sun.com>; Thu, 31 Jul 2008 18:16:35 +0100 (BST) Date: Thu, 31 Jul 2008 10:16:34 -0700 From: Darren Reed Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <20080731031241.GD1048@eng.sun.com> Sender: Darren.Reed@Sun.COM To: Stephen Hahn Cc: PSARC-EXT Message-id: <4891F372.1080704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2013 Stephen Hahn wrote: >* Darren Reed [2008-07-30 19:45]: > >>Stephen, >> >>I've updated the issues files with the questions from the meeting >>this morning and made a brief note of the answers that I could >>remember. >> >>There were two questions I had from the discussion that I didn't >>bring up at the time: >> >>djr-3 Can package authorities be discovered rather than configured? >> >>djr-5 If multiple catalogues/depots are available, how does IPS choose >> which one to use if they are publishing conflicting information? >> >>For djr-3, I'm thinking along the lines of using multicast discovery on >>your local LAN or corporate WAN/LAN or maybe clues via DHCP or >>even a special DHCP tag or ... >> > > Yes, we think multicast discovery is very interesting for discovering > local depots. We'd also like to have a means for one repository to > offer pointers to other interesting repositories, although this could > be as simple as a package with a bunch of authority definitions. > > We'll discuss djr-5 and get a proper response, but fully adversarial > repositories, presumably with legitimate cryptographic tokens, hasn't > been a focus. Our model has been trust signed metadata, distrust > contents. We could go further into what "trust" means, I suppose. > Thanks for taking these up, I'll look forward to seeing what you guys come up with. The main goal of these two is if I have my laptop that moves between home and Sun, it is highly likely that in the future there will be a depot on SWAN and highly unlikely I will have my own at home. My thoughts are that ips should be able to use the "closest" or "best" depot without me having to tell it every time I plugin. If this can be automated, it is important to have some analysis of the various threat models, from the adversarial to simply "old data" depot, that arise. Some of this may have ties with NWAM but I'm reluctant to suggest that this project should be dependant on NWAM. Cheers, Darren From bart.smaalders@sun.com Thu Jul 31 11:31:07 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VIV60Y016163 for ; Thu, 31 Jul 2008 11:31:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6VIUtXK005192; Fri, 1 Aug 2008 02:31:02 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4V00M2FVFPL900@brm-avmta-1.central.sun.com>; Thu, 31 Jul 2008 12:31:01 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4V007B6VFO2VC0@brm-avmta-1.central.sun.com>; Thu, 31 Jul 2008 12:31:00 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6VIV0ZA013904; Thu, 31 Jul 2008 18:31:00 +0000 (GMT) Date: Thu, 31 Jul 2008 11:30:59 -0700 From: Bart Smaalders Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <20080731043234.GG1048@eng.sun.com> To: Stephen Hahn Cc: "Garrett D'Amore" , Darren Reed , PSARC-EXT Message-id: <489204E3.1080203@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 754 Stephen Hahn wrote: > I am having difficulty formulating a use case where nested or multiply > signed packages are needed, and in which the consumer makes different > decisions when distinct subsets of the signing entities cannot be > independently verified. Maybe someone has an example? Multiply signed packages are useful, as others have pointed out, to permit systems to require multiple signatures, or permit alternate signatures. The easiest way to do this is to omit all signatures from the hash; adding a new signature would then not invalidate previous ones. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Nicolas.Williams@sun.com Thu Jul 31 12:12:50 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VJCnrq017589 for ; Thu, 31 Jul 2008 12:12:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m6VJCd1K019738; Fri, 1 Aug 2008 03:12:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4V00505XD8FF00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jul 2008 12:12:44 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4V00JGIXD8EWE0@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jul 2008 12:12:44 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m6VJCh5N006960; Thu, 31 Jul 2008 14:12:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m6VJChFH006959; Thu, 31 Jul 2008 14:12:43 -0500 (CDT) Date: Thu, 31 Jul 2008 14:12:43 -0500 From: Nicolas Williams Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <489204E3.1080203@Sun.COM> To: Bart Smaalders Cc: Stephen Hahn , "Garrett D'Amore" , Darren Reed , PSARC-EXT Mail-followup-to: Bart Smaalders , Stephen Hahn , Garrett D'Amore , Darren Reed , PSARC-EXT Message-id: <20080731191243.GZ25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1455 On Thu, Jul 31, 2008 at 11:30:59AM -0700, Bart Smaalders wrote: > Stephen Hahn wrote: > > I am having difficulty formulating a use case where nested or multiply > > signed packages are needed, and in which the consumer makes different > > decisions when distinct subsets of the signing entities cannot be > > independently verified. Maybe someone has an example? > > Multiply signed packages are useful, as others have pointed out, to > permit systems to require multiple signatures, or permit alternate > signatures. I proposed having one signature by the pkg submitter, and one by the publication service. The former vouching for the contents of the package while the latter would vouch for the dependency and other such analysis. That would allow you to separate the publication service from the repository itself, thus making the repository OS- and platform-neutral (since it's the publication service that inherently isn't). OTOH, it might require folding OS and platform information into the URLs, at least for the catalog. > The easiest way to do this is to omit all signatures from the > hash; adding a new signature would then not invalidate previous ones. It might be useful to be able to include some signatures in the material signed by any one signature -- "nested signatures" --, as well as to omit some -- "parallel signatures." The publication service's signature should include any signatures in the submitted pkg. Nico -- From carlsonj@phorcys.east.sun.com Thu Jul 31 12:45:09 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VJj96l018233 for ; Thu, 31 Jul 2008 12:45:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6VJj4JR039456; Thu, 31 Jul 2008 13:45:05 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4V00K0VYV4Q400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 Jul 2008 12:45:04 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4V00G1GYV3UB20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 Jul 2008 12:45:03 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m6VJj3gd021074; Thu, 31 Jul 2008 15:45:03 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m6VJj34a021071; Thu, 31 Jul 2008 15:45:03 -0400 (EDT) Date: Thu, 31 Jul 2008 15:45:03 -0400 From: James Carlson Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <20080731191243.GZ25547@Sun.COM> To: Nicolas Williams Cc: Bart Smaalders , PSARC-EXT , Stephen Hahn , "Garrett D'Amore" , Darren Reed Message-id: <18578.5695.30811.549469@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <20080731191243.GZ25547@Sun.COM> Status: RO Content-Length: 1703 Nicolas Williams writes: > On Thu, Jul 31, 2008 at 11:30:59AM -0700, Bart Smaalders wrote: > > Multiply signed packages are useful, as others have pointed out, to > > permit systems to require multiple signatures, or permit alternate > > signatures. > > I proposed having one signature by the pkg submitter, and one by the > publication service. The former vouching for the contents of the package > while the latter would vouch for the dependency and other such analysis. Do you really mean at most two signatures? This means that if we have (say) a package created and signed by Sun, then included into a repository signed by BigRepoCompany, then no local IT group could sign again to say "this is the version of the package from BigRepoCompany that you should be using here." Or, if IT did that, the BigRepoCompany signature would have to come off, and the end user would lose whatever value that signature had. If the number of signatures is greater than 1, I suspect it's just "N." > > The easiest way to do this is to omit all signatures from the > > hash; adding a new signature would then not invalidate previous ones. > > It might be useful to be able to include some signatures in the material > signed by any one signature -- "nested signatures" --, as well as to > omit some -- "parallel signatures." I don't understand the usage case for nested signatures (don't I just care about the bits delivered?), but at least parallel signatures ought to be offered. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Thu Jul 31 12:56:47 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VJulAO018694 for ; Thu, 31 Jul 2008 12:56:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6VJudt9042516; Thu, 31 Jul 2008 13:56:39 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4V0050FZEEF100@brm-avmta-1.central.sun.com>; Thu, 31 Jul 2008 13:56:38 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4V001HZZEDY920@brm-avmta-1.central.sun.com>; Thu, 31 Jul 2008 13:56:37 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m6VJubJp007057; Thu, 31 Jul 2008 14:56:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m6VJua7V007056; Thu, 31 Jul 2008 14:56:36 -0500 (CDT) Date: Thu, 31 Jul 2008 14:56:36 -0500 From: Nicolas Williams Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <18578.5695.30811.549469@gargle.gargle.HOWL> To: James Carlson Cc: Bart Smaalders , PSARC-EXT , Stephen Hahn , "Garrett D'Amore" , Darren Reed Mail-followup-to: James Carlson , Bart Smaalders , PSARC-EXT , Stephen Hahn , Garrett D'Amore , Darren Reed Message-id: <20080731195636.GD25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <20080731191243.GZ25547@Sun.COM> <18578.5695.30811.549469@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1067 On Thu, Jul 31, 2008 at 03:45:03PM -0400, James Carlson wrote: > Nicolas Williams writes: > > I proposed having one signature by the pkg submitter, and one by the > > publication service. The former vouching for the contents of the package > > while the latter would vouch for the dependency and other such analysis. > > Do you really mean at most two signatures? No, rather, at least two signatures. > > > The easiest way to do this is to omit all signatures from the > > > hash; adding a new signature would then not invalidate previous ones. > > > > It might be useful to be able to include some signatures in the material > > signed by any one signature -- "nested signatures" --, as well as to > > omit some -- "parallel signatures." > > I don't understand the usage case for nested signatures (don't I just > care about the bits delivered?), but at least parallel signatures > ought to be offered. As I imagine it the publication service would sign the manifest and the signature of the manifest by the submitter. That would make it a nested signature. From carlsonj@phorcys.east.sun.com Thu Jul 31 13:09:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VK9FVN019468 for ; Thu, 31 Jul 2008 13:09:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6VK8uI3005153; Thu, 31 Jul 2008 21:09:08 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4V00601ZZ7AD00@brm-avmta-1.central.sun.com>; Thu, 31 Jul 2008 14:09:07 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4V001D3ZZ5YH30@brm-avmta-1.central.sun.com>; Thu, 31 Jul 2008 14:09:05 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m6VK94bQ021125; Thu, 31 Jul 2008 16:09:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m6VK94hY021122; Thu, 31 Jul 2008 16:09:04 -0400 (EDT) Date: Thu, 31 Jul 2008 16:09:04 -0400 From: James Carlson Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <20080731195636.GD25547@Sun.COM> To: Nicolas Williams Cc: PSARC-EXT , Stephen Hahn , Bart Smaalders , "Garrett D'Amore" , Darren Reed Message-id: <18578.7136.852333.93635@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <20080731191243.GZ25547@Sun.COM> <18578.5695.30811.549469@gargle.gargle.HOWL> <20080731195636.GD25547@Sun.COM> Status: RO Content-Length: 1040 Nicolas Williams writes: > > I don't understand the usage case for nested signatures (don't I just > > care about the bits delivered?), but at least parallel signatures > > ought to be offered. > > As I imagine it the publication service would sign the manifest and the > signature of the manifest by the submitter. That would make it a nested > signature. My question was "why." What does it gain the publication service to sign someone else's signature? It means only that some third party can't remove or alter that other (upstream) signature, but if someone were to do that, how is that alteration the publication service's problem? Why should he care? (It almost sounds to me like you might be trying to build in the option for some kind of licensing system, but I'm not quite seeing how it would work.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Nicolas.Williams@sun.com Thu Jul 31 13:15:27 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VKFRNZ019763 for ; Thu, 31 Jul 2008 13:15:27 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6VKFIH2048477; Thu, 31 Jul 2008 14:15:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W0001B09LU500@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 Jul 2008 13:15:21 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W00G0509JUK40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 Jul 2008 13:15:20 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m6VKFJ4o007084; Thu, 31 Jul 2008 15:15:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m6VKFJl9007083; Thu, 31 Jul 2008 15:15:19 -0500 (CDT) Date: Thu, 31 Jul 2008 15:15:19 -0500 From: Nicolas Williams Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <18578.7136.852333.93635@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-EXT , Stephen Hahn , Bart Smaalders , "Garrett D'Amore" , Darren Reed Mail-followup-to: James Carlson , PSARC-EXT , Stephen Hahn , Bart Smaalders , Garrett D'Amore , Darren Reed Message-id: <20080731201519.GG25547@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <20080731191243.GZ25547@Sun.COM> <18578.5695.30811.549469@gargle.gargle.HOWL> <20080731195636.GD25547@Sun.COM> <18578.7136.852333.93635@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1436 On Thu, Jul 31, 2008 at 04:09:04PM -0400, James Carlson wrote: > Nicolas Williams writes: > > > I don't understand the usage case for nested signatures (don't I just > > > care about the bits delivered?), but at least parallel signatures > > > ought to be offered. > > > > As I imagine it the publication service would sign the manifest and the > > signature of the manifest by the submitter. That would make it a nested > > signature. > > My question was "why." What does it gain the publication service to > sign someone else's signature? It means only that some third party > can't remove or alter that other (upstream) signature, but if someone > were to do that, how is that alteration the publication service's > problem? Why should he care? I don't have a terribly good reason for this. I was going on the instinct that it could be useful to know who submitted the pkg to the publication service. OTOH, if you're replacing the signatures you might as well re-submit for publication, in which case you'll get a new signature from that service. I.e., that third party can just as well have their own publication service. So I don't see nesting the signatures here as particularly harmful. > (It almost sounds to me like you might be trying to build in the > option for some kind of licensing system, but I'm not quite seeing how > it would work.) The thought hadn't entered my mind. I too don't see how it would work. From gdamore@sun.com Thu Jul 31 13:33:42 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VKXgO2020018 for ; Thu, 31 Jul 2008 13:33:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6VKXZvC016994 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 31 Jul 2008 13:33:42 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W00813144B100@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 14:33:40 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W001ZD144Y940@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 14:33:40 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6VKXes5000618 for ; Thu, 31 Jul 2008 13:33:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4W00F010YEFA00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 13:33:39 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4W00DC41427PG0@fe-sfbay-09.sun.com>; Thu, 31 Jul 2008 13:33:38 -0700 (PDT) Date: Thu, 31 Jul 2008 13:28:55 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <489204E3.1080203@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: Stephen Hahn , Darren Reed , PSARC-EXT Message-id: <48922087.4020403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1250 Bart Smaalders wrote: > Stephen Hahn wrote: > >> I am having difficulty formulating a use case where nested or multiply >> signed packages are needed, and in which the consumer makes different >> decisions when distinct subsets of the signing entities cannot be >> independently verified. Maybe someone has an example? > > Multiply signed packages are useful, as others have pointed out, to > permit systems to require multiple signatures, or permit alternate > signatures. > > The easiest way to do this is to omit all signatures from the > hash; adding a new signature would then not invalidate previous ones. > > - Bart > The concern was that the meta data that would be added was also signed. Certainly the *contents*, as well as critical portions of meta data (dependencies and anything else that might impact how the software is installed or behavior) probably could be covered by a single hash. Other meta data (yes, OurBigEnterprise-IT-Dept blesses this package, on Jun 5, 2020...) may also need a separate signature, covering the meta data, and the aforementioned hash. (So it sounds like we might want to classify meta-data somewhat. Those that don't change after a package is created, and those that do.) - Garrett From Darren.Reed@sun.com Thu Jul 31 15:34:23 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VMYNnx024756 for ; Thu, 31 Jul 2008 15:34:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6VMYFZu027758 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 31 Jul 2008 23:34:21 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W00G016P77200@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 15:34:19 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W00GQP6P6UKA0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 15:34:19 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6VMYIKP010116 for ; Thu, 31 Jul 2008 22:34:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4W00M016JODY00@fe-emea-09.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 23:34:18 +0100 (BST) Received: from [129.146.106.55] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4W00J3I6P41B20@fe-emea-09.sun.com>; Thu, 31 Jul 2008 23:34:18 +0100 (BST) Date: Thu, 31 Jul 2008 15:34:16 -0700 From: Darren Reed Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <48922087.4020403@sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore" Cc: Bart Smaalders , Stephen Hahn , PSARC-EXT Message-id: <48923DE8.1020204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <48922087.4020403@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1615 Garrett D'Amore wrote: > Bart Smaalders wrote: > >> Stephen Hahn wrote: >> >>> I am having difficulty formulating a use case where nested or >>> multiply >>> signed packages are needed, and in which the consumer makes different >>> decisions when distinct subsets of the signing entities cannot be >>> independently verified. Maybe someone has an example? >> >> >> Multiply signed packages are useful, as others have pointed out, to >> permit systems to require multiple signatures, or permit alternate >> signatures. >> >> The easiest way to do this is to omit all signatures from the >> hash; adding a new signature would then not invalidate previous ones. >> >> - Bart >> > The concern was that the meta data that would be added was also signed. > > Certainly the *contents*, as well as critical portions of meta data > (dependencies and anything else that might impact how the software is > installed or behavior) probably could be covered by a single hash. > > Other meta data (yes, OurBigEnterprise-IT-Dept blesses this package, > on Jun 5, 2020...) may also need a separate signature, covering the > meta data, and the aforementioned hash. > > (So it sounds like we might want to classify meta-data somewhat. > Those that don't change after a package is created, and those that do.) I agree with Garret here in that the metadata should have a separate signature/hash to that for the actual file data being delivered. This is similar to what we do with PGP and hashes of files. In light of this, is there merit in introducing a schema that defines the metadata and its signature? Darren From bart.smaalders@sun.com Thu Jul 31 16:34:48 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VNYmsS025715 for ; Thu, 31 Jul 2008 16:34:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6VNYija040531; Thu, 31 Jul 2008 17:34:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W000099HW4A00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 Jul 2008 16:34:44 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W00G899HWUDD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 Jul 2008 16:34:44 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m6VNYhlp022008; Thu, 31 Jul 2008 23:34:43 +0000 (GMT) Date: Thu, 31 Jul 2008 16:34:43 -0700 From: Bart Smaalders Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <48922087.4020403@sun.com> To: "Garrett D'Amore" Cc: Stephen Hahn , Darren Reed , PSARC-EXT Message-id: <48924C13.6040902@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <48922087.4020403@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2034 Garrett D'Amore wrote: > Bart Smaalders wrote: >> Stephen Hahn wrote: >> >>> I am having difficulty formulating a use case where nested or multiply >>> signed packages are needed, and in which the consumer makes different >>> decisions when distinct subsets of the signing entities cannot be >>> independently verified. Maybe someone has an example? >> >> Multiply signed packages are useful, as others have pointed out, to >> permit systems to require multiple signatures, or permit alternate >> signatures. >> >> The easiest way to do this is to omit all signatures from the >> hash; adding a new signature would then not invalidate previous ones. >> >> - Bart >> > The concern was that the meta data that would be added was also signed. > > Certainly the *contents*, as well as critical portions of meta data > (dependencies and anything else that might impact how the software is > installed or behavior) probably could be covered by a single hash. > > Other meta data (yes, OurBigEnterprise-IT-Dept blesses this package, on > Jun 5, 2020...) may also need a separate signature, covering the meta > data, and the aforementioned hash. > > (So it sounds like we might want to classify meta-data somewhat. Those > that don't change after a package is created, and those that do.) > > - Garrett > I don't understand. What is wrong with simply allowing multiple signature by the simple expedient of not including signatures in the hash. This is a very natural thing to do, since it simply requires removing all signatures from the manifest and then computing the hash. Doing otherwise means that a hierarchal manifest of arbitrary nesting depth is required; this complexity doesn't seem to be justified by any real requirements. There's plenty of track to be laid on this project w/o adding more for the use of invisible trains. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From gdamore@sun.com Thu Jul 31 16:57:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6VNvNuG026607 for ; Thu, 31 Jul 2008 16:57:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m6VNvCDU026333 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 1 Aug 2008 00:57:22 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W00I0LAJLCX00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 16:57:21 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W00C5SAJKLYA0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 16:57:20 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m6VNvKGv021765 for ; Thu, 31 Jul 2008 16:57:20 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4W00B01AAP4I00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 16:57:20 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4W00JDGAJKLU60@fe-sfbay-10.sun.com>; Thu, 31 Jul 2008 16:57:20 -0700 (PDT) Date: Thu, 31 Jul 2008 16:52:37 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <48924C13.6040902@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: Stephen Hahn , Darren Reed , PSARC-EXT Message-id: <48925045.2050906@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <48922087.4020403@sun.com> <48924C13.6040902@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3309 Bart Smaalders wrote: > Garrett D'Amore wrote: >> Bart Smaalders wrote: >>> Stephen Hahn wrote: >>> >>>> I am having difficulty formulating a use case where nested or >>>> multiply >>>> signed packages are needed, and in which the consumer makes >>>> different >>>> decisions when distinct subsets of the signing entities cannot be >>>> independently verified. Maybe someone has an example? >>> >>> Multiply signed packages are useful, as others have pointed out, to >>> permit systems to require multiple signatures, or permit alternate >>> signatures. >>> >>> The easiest way to do this is to omit all signatures from the >>> hash; adding a new signature would then not invalidate previous ones. >>> >>> - Bart >>> >> The concern was that the meta data that would be added was also signed. >> >> Certainly the *contents*, as well as critical portions of meta data >> (dependencies and anything else that might impact how the software is >> installed or behavior) probably could be covered by a single hash. >> >> Other meta data (yes, OurBigEnterprise-IT-Dept blesses this package, >> on Jun 5, 2020...) may also need a separate signature, covering the >> meta data, and the aforementioned hash. >> >> (So it sounds like we might want to classify meta-data somewhat. >> Those that don't change after a package is created, and those that do.) >> >> - Garrett >> > > I don't understand. > > What is wrong with simply allowing multiple signature by the simple > expedient of not including signatures in the hash. This is a very > natural thing to do, since it simply requires removing all signatures > from the manifest and then computing the hash. > > Doing otherwise means that a hierarchal manifest of arbitrary nesting > depth is required; this complexity doesn't seem to be justified by > any real requirements. > > There's plenty of track to be laid on this project w/o adding more for > the use of invisible trains. The problem is whether meta data needs to be covered by the hash (and signature) or not. Lets see if I can explain more fully. Sun delivers package A, and signs it, [A,sun] Sun support only guarantees support for packages that are signed. The customers IT organization wants to ensure that only "blessed packages" are installed. And maybe they want to provide some additional data, such as the date it was blessed, who blessed it, and perhaps limitations upon the packages use. So they want to take [A,sun] and make it [[A,sun],it] Now if you only allow multiple signatures in parallel over a common hash, the problem is that the customer's IT metadata isn't covered by the signature. (Unless the customer invents some other packing and distribution format, which I think we want to avoid.) An alternative approach might be to have separate signatures, so that you have: let pkg deliverables = A let SHA[A] = H let Sun's meta data for A = Msun let customer IT dept's metadata for A = Mcustomer let signed copy of x using Sun's key = [x,sun] let signed copy of x using Customer's key = [x,customer] So Sun delivers: A + [H + Msun, sun] The customer's IT department serves up: A + [H + Msun,sun] + [H + Msun + Mcustomer, customer] This preserves the cryptographic integrity of both Msun and Mcustomer. -- Garrett > > - Bart > > > > > From bart.smaalders@sun.com Thu Jul 31 21:00:24 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7140Nfw001632 for ; Thu, 31 Jul 2008 21:00:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7140I2Z036868; Thu, 31 Jul 2008 22:00:20 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W00709LSJFJ00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jul 2008 21:00:19 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W000AJLSJ4S40@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jul 2008 21:00:19 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m7140IjR025285; Fri, 01 Aug 2008 04:00:18 +0000 (GMT) Date: Thu, 31 Jul 2008 21:00:18 -0700 From: Bart Smaalders Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <48925045.2050906@sun.com> To: "Garrett D'Amore" Cc: Stephen Hahn , Darren Reed , PSARC-EXT Message-id: <48928A52.1020403@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <48922087.4020403@sun.com> <48924C13.6040902@Sun.COM> <48925045.2050906@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 4439 Garrett D'Amore wrote: > Bart Smaalders wrote: >> Garrett D'Amore wrote: >>> Bart Smaalders wrote: >>>> Stephen Hahn wrote: >>>> >>>>> I am having difficulty formulating a use case where nested or >>>>> multiply >>>>> signed packages are needed, and in which the consumer makes >>>>> different >>>>> decisions when distinct subsets of the signing entities cannot be >>>>> independently verified. Maybe someone has an example? >>>> >>>> Multiply signed packages are useful, as others have pointed out, to >>>> permit systems to require multiple signatures, or permit alternate >>>> signatures. >>>> >>>> The easiest way to do this is to omit all signatures from the >>>> hash; adding a new signature would then not invalidate previous ones. >>>> >>>> - Bart >>>> >>> The concern was that the meta data that would be added was also signed. >>> >>> Certainly the *contents*, as well as critical portions of meta data >>> (dependencies and anything else that might impact how the software is >>> installed or behavior) probably could be covered by a single hash. >>> >>> Other meta data (yes, OurBigEnterprise-IT-Dept blesses this package, >>> on Jun 5, 2020...) may also need a separate signature, covering the >>> meta data, and the aforementioned hash. >>> >>> (So it sounds like we might want to classify meta-data somewhat. >>> Those that don't change after a package is created, and those that do.) >>> >>> - Garrett >>> >> >> I don't understand. >> >> What is wrong with simply allowing multiple signature by the simple >> expedient of not including signatures in the hash. This is a very >> natural thing to do, since it simply requires removing all signatures >> from the manifest and then computing the hash. >> >> Doing otherwise means that a hierarchal manifest of arbitrary nesting >> depth is required; this complexity doesn't seem to be justified by >> any real requirements. >> >> There's plenty of track to be laid on this project w/o adding more for >> the use of invisible trains. > > The problem is whether meta data needs to be covered by the hash (and > signature) or not. > > Lets see if I can explain more fully. > > Sun delivers package A, and signs it, [A,sun] > > Sun support only guarantees support for packages that are signed. > > The customers IT organization wants to ensure that only "blessed > packages" are installed. And maybe they want to provide some additional > data, such as the date it was blessed, who blessed it, and perhaps > limitations upon the packages use. So they want to take [A,sun] and > make it [[A,sun],it] > > Now if you only allow multiple signatures in parallel over a common > hash, the problem is that the customer's IT metadata isn't covered by > the signature. (Unless the customer invents some other packing and > distribution format, which I think we want to avoid.) > > An alternative approach might be to have separate signatures, so that > you have: > > let pkg deliverables = A > let SHA[A] = H > let Sun's meta data for A = Msun > let customer IT dept's metadata for A = Mcustomer > let signed copy of x using Sun's key = [x,sun] > let signed copy of x using Customer's key = [x,customer] > > So Sun delivers: > > A + [H + Msun, sun] > > The customer's IT department serves up: > > A + [H + Msun,sun] + [H + Msun + Mcustomer, customer] > > This preserves the cryptographic integrity of both Msun and Mcustomer. > > -- Garrett > >> >> - Bart >> >> >> >> >> > Since each action can contain arbitrary attributes, the customer's signature action can contain whatever data he wants; the packaging system happily ignores that which it doesn't know about so he can add new attributes to his signature ad nauseam. This would mean that any actions that are signatures are simply ignored when computing the hash for signing purposes. Each signature can carry whatever extra data (within reason, of course) is deemed necessary by the signer. If the customer is worried about retrieving these packages from a repo run by a hostile which is attempting to edit his meta data, we can always include just the signature being generated (minus the hash value) in the hash. Thus, each signature stands alone, but if present cannot be altered w/o detection. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From gdamore@Sun.COM Thu Jul 31 21:21:19 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m714LIoC002324 for ; Thu, 31 Jul 2008 21:21:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m714LHXq041289 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 31 Jul 2008 22:21:18 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W0080BMRHFB00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 21:21:17 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W000W4MRG4W40@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 21:21:17 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m714LGIn000675 for ; Thu, 31 Jul 2008 21:21:16 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4W00101MMU1T00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 31 Jul 2008 21:21:16 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4W00KZRMRFCQ90@fe-sfbay-10.sun.com>; Thu, 31 Jul 2008 21:21:16 -0700 (PDT) Date: Thu, 31 Jul 2008 21:16:33 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <48928A52.1020403@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Bart Smaalders Cc: Stephen Hahn , Darren Reed , PSARC-EXT Message-id: <48928E21.5050803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <48922087.4020403@sun.com> <48924C13.6040902@Sun.COM> <48925045.2050906@sun.com> <48928A52.1020403@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 4853 Bart Smaalders wrote: > Garrett D'Amore wrote: >> Bart Smaalders wrote: >>> Garrett D'Amore wrote: >>>> Bart Smaalders wrote: >>>>> Stephen Hahn wrote: >>>>> >>>>>> I am having difficulty formulating a use case where nested or >>>>>> multiply >>>>>> signed packages are needed, and in which the consumer makes >>>>>> different >>>>>> decisions when distinct subsets of the signing entities cannot be >>>>>> independently verified. Maybe someone has an example? >>>>> >>>>> Multiply signed packages are useful, as others have pointed out, to >>>>> permit systems to require multiple signatures, or permit alternate >>>>> signatures. >>>>> >>>>> The easiest way to do this is to omit all signatures from the >>>>> hash; adding a new signature would then not invalidate previous ones. >>>>> >>>>> - Bart >>>>> >>>> The concern was that the meta data that would be added was also >>>> signed. >>>> >>>> Certainly the *contents*, as well as critical portions of meta data >>>> (dependencies and anything else that might impact how the software >>>> is installed or behavior) probably could be covered by a single hash. >>>> >>>> Other meta data (yes, OurBigEnterprise-IT-Dept blesses this >>>> package, on Jun 5, 2020...) may also need a separate signature, >>>> covering the meta data, and the aforementioned hash. >>>> >>>> (So it sounds like we might want to classify meta-data somewhat. >>>> Those that don't change after a package is created, and those that >>>> do.) >>>> >>>> - Garrett >>>> >>> >>> I don't understand. >>> >>> What is wrong with simply allowing multiple signature by the simple >>> expedient of not including signatures in the hash. This is a very >>> natural thing to do, since it simply requires removing all signatures >>> from the manifest and then computing the hash. >>> >>> Doing otherwise means that a hierarchal manifest of arbitrary nesting >>> depth is required; this complexity doesn't seem to be justified by >>> any real requirements. >>> >>> There's plenty of track to be laid on this project w/o adding more for >>> the use of invisible trains. >> >> The problem is whether meta data needs to be covered by the hash (and >> signature) or not. >> >> Lets see if I can explain more fully. >> >> Sun delivers package A, and signs it, [A,sun] >> >> Sun support only guarantees support for packages that are signed. >> >> The customers IT organization wants to ensure that only "blessed >> packages" are installed. And maybe they want to provide some >> additional data, such as the date it was blessed, who blessed it, and >> perhaps limitations upon the packages use. So they want to take >> [A,sun] and make it [[A,sun],it] >> >> Now if you only allow multiple signatures in parallel over a common >> hash, the problem is that the customer's IT metadata isn't covered by >> the signature. (Unless the customer invents some other packing and >> distribution format, which I think we want to avoid.) >> >> An alternative approach might be to have separate signatures, so that >> you have: >> >> let pkg deliverables = A >> let SHA[A] = H >> let Sun's meta data for A = Msun >> let customer IT dept's metadata for A = Mcustomer >> let signed copy of x using Sun's key = [x,sun] >> let signed copy of x using Customer's key = [x,customer] >> >> So Sun delivers: >> >> A + [H + Msun, sun] >> >> The customer's IT department serves up: >> >> A + [H + Msun,sun] + [H + Msun + Mcustomer, customer] >> >> This preserves the cryptographic integrity of both Msun and Mcustomer. >> >> -- Garrett >> >>> >>> - Bart >>> >>> >>> >>> >>> >> > > Since each action can contain arbitrary attributes, the customer's > signature action can contain whatever data he wants; the packaging > system happily ignores that which it doesn't know about so he can > add new attributes to his signature ad nauseam. > > This would mean that any actions that are signatures are simply > ignored when computing the hash for signing purposes. Each signature > can carry whatever extra data (within reason, of course) is deemed > necessary by the signer. > > If the customer is worried about retrieving these packages from a repo > run by a hostile which is attempting to edit his meta data, we can > always include just the signature being generated (minus the hash value) > in the hash. > > Thus, each signature stands alone, but if present cannot be altered w/o > detection. I think you want the hash value in the signed portion. Otherwise, how do you keep someone from reattaching a different signed meta data from a "bad" package to a "good" package? Possibly all you need is just the hash signature. I still don't really understand whether meta data can alter the behavior of the software (either the installed software or the installation software itself) -- can it? - Garrett > > - Bart > > > From Darren.Moffat@sun.com Fri Aug 1 02:00:22 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7190L6n009889 for ; Fri, 1 Aug 2008 02:00:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7190J0x020789 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 1 Aug 2008 17:00:20 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4W00I03ZOIVO00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Aug 2008 03:00:18 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4W00E8VZOHS130@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Aug 2008 03:00:18 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7190He8029762 for ; Fri, 01 Aug 2008 09:00:17 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4W00301YUFV900@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Aug 2008 10:00:17 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4W000IFZOE5C90@fe-emea-10.sun.com>; Fri, 01 Aug 2008 10:00:16 +0100 (BST) Date: Fri, 01 Aug 2008 10:00:14 +0100 From: Darren J Moffat Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <489204E3.1080203@Sun.COM> Sender: Darren.Moffat@sun.com To: Bart Smaalders Cc: Stephen Hahn , "Garrett D'Amore" , Darren Reed , PSARC-EXT Message-id: <4892D09E.4010309@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 755 Bart Smaalders wrote: > Stephen Hahn wrote: > >> I am having difficulty formulating a use case where nested or multiply >> signed packages are needed, and in which the consumer makes different >> decisions when distinct subsets of the signing entities cannot be >> independently verified. Maybe someone has an example? > > Multiply signed packages are useful, as others have pointed out, to > permit systems to require multiple signatures, or permit alternate > signatures. > > The easiest way to do this is to omit all signatures from the > hash; adding a new signature would then not invalidate previous ones. Which is exactly how elfsign works (even though we do not currently use the multiple signature capability). -- Darren J Moffat From bart.smaalders@sun.com Fri Aug 1 10:10:20 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m71HAJem024848 for ; Fri, 1 Aug 2008 10:10:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m71HADvV012024; Sat, 2 Aug 2008 01:10:14 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4X0060JMD0A600@brm-avmta-1.central.sun.com>; Fri, 01 Aug 2008 11:10:13 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4X00MTFMD0NK80@brm-avmta-1.central.sun.com>; Fri, 01 Aug 2008 11:10:12 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m71HACwr004168; Fri, 01 Aug 2008 17:10:12 +0000 (GMT) Date: Fri, 01 Aug 2008 10:10:11 -0700 From: Bart Smaalders Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <48928E21.5050803@sun.com> To: "Garrett D'Amore" Cc: Stephen Hahn , Darren Reed , PSARC-EXT Message-id: <48934373.50405@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <48922087.4020403@sun.com> <48924C13.6040902@Sun.COM> <48925045.2050906@sun.com> <48928A52.1020403@Sun.COM> <48928E21.5050803@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2443 Garrett D'Amore wrote: >> Since each action can contain arbitrary attributes, the customer's >> signature action can contain whatever data he wants; the packaging >> system happily ignores that which it doesn't know about so he can >> add new attributes to his signature ad nauseam. >> >> This would mean that any actions that are signatures are simply >> ignored when computing the hash for signing purposes. Each signature >> can carry whatever extra data (within reason, of course) is deemed >> necessary by the signer. >> >> If the customer is worried about retrieving these packages from a repo >> run by a hostile which is attempting to edit his meta data, we can >> always include just the signature being generated (minus the hash value) >> in the hash. >> >> Thus, each signature stands alone, but if present cannot be altered w/o >> detection. > > I think you want the hash value in the signed portion. Otherwise, how > do you keep someone from reattaching a different signed meta data from a > "bad" package to a "good" package? > > Possibly all you need is just the hash signature. > > I still don't really understand whether meta data can alter the behavior > of the software (either the installed software or the installation > software itself) -- can it? > > - Garrett The signed portion of the manifest would consist of all the entries in the manifest (actions) aside from signatures, _plus_ any metadata included in the signature being generated. Thus signatures cannot be spoofed or exchanged, but they may generated by anyone w/ a key and added to the manifest. They cannot be altered w/o invalidating that signature. The rest of the manifest cannot be altered either w/o invalidating all signatures. For example, suppose the manifest consists of: set name=fmri value=pkg:/cheeseshop@1.0 dir group=sys mode=0755 owner=root path=/scripts file b0b7615454f3a3ec0d0d159677618bbb476052e0 group=bin mode=0444 owner=root path=scripts/cheeseshop.txt signature .... and you wish to sign it again with the additional meta data of airspeed_of_unladen_swallow=20 then the complete hashed text would include the manifest text minus the already present signature but including the airspeed_of_unladen_swallow=20 in a canonical format. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Darren.Moffat@sun.com Fri Aug 1 11:13:12 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m71IDC6l027907 for ; Fri, 1 Aug 2008 11:13:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m71IDAAK062083 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 1 Aug 2008 12:13:11 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4X00503P9ZI500@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Aug 2008 11:13:11 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4X00JVXP9Y7Y60@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Aug 2008 11:13:11 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m71IDAxA021526 for ; Fri, 01 Aug 2008 18:13:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K4X00501P3K5700@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Aug 2008 19:13:10 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K4X000T0P9WIYE0@fe-emea-09.sun.com>; Fri, 01 Aug 2008 19:13:10 +0100 (BST) Date: Fri, 01 Aug 2008 19:13:08 +0100 From: Darren J Moffat Subject: Re: PSARC/2008/190 - Preinception IPS In-reply-to: <48934373.50405@Sun.COM> Sender: Darren.Moffat@sun.com To: Bart Smaalders Cc: "Garrett D'Amore" , PSARC-EXT , Stephen Hahn , Darren Reed Message-id: <48935234.1070902@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4890C4CC.9040402@Sun.COM> <20080731031241.GD1048@eng.sun.com> <4891333E.5020704@sun.com> <20080731043234.GG1048@eng.sun.com> <489204E3.1080203@Sun.COM> <48922087.4020403@sun.com> <48924C13.6040902@Sun.COM> <48925045.2050906@sun.com> <48928A52.1020403@Sun.COM> <48928E21.5050803@sun.com> <48934373.50405@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 2415 Bart Smaalders wrote: > Garrett D'Amore wrote: >>> Since each action can contain arbitrary attributes, the customer's >>> signature action can contain whatever data he wants; the packaging >>> system happily ignores that which it doesn't know about so he can >>> add new attributes to his signature ad nauseam. >>> >>> This would mean that any actions that are signatures are simply >>> ignored when computing the hash for signing purposes. Each signature >>> can carry whatever extra data (within reason, of course) is deemed >>> necessary by the signer. >>> >>> If the customer is worried about retrieving these packages from a repo >>> run by a hostile which is attempting to edit his meta data, we can >>> always include just the signature being generated (minus the hash value) >>> in the hash. >>> >>> Thus, each signature stands alone, but if present cannot be altered w/o >>> detection. >> I think you want the hash value in the signed portion. Otherwise, how >> do you keep someone from reattaching a different signed meta data from a >> "bad" package to a "good" package? >> >> Possibly all you need is just the hash signature. >> >> I still don't really understand whether meta data can alter the behavior >> of the software (either the installed software or the installation >> software itself) -- can it? >> >> - Garrett > > The signed portion of the manifest would consist of all the entries in > the manifest (actions) aside from signatures, _plus_ any metadata > included in the signature being generated. > > Thus signatures cannot be spoofed or exchanged, but they may generated > by anyone w/ a key and added to the manifest. They cannot be altered > w/o invalidating that signature. The rest of the manifest cannot be > altered either w/o invalidating all signatures. > > For example, suppose the manifest consists of: > > set name=fmri value=pkg:/cheeseshop@1.0 > dir group=sys mode=0755 owner=root path=/scripts > file b0b7615454f3a3ec0d0d159677618bbb476052e0 group=bin mode=0444 > owner=root path=scripts/cheeseshop.txt > signature .... > > and you wish to sign it again with the additional meta data of > airspeed_of_unladen_swallow=20 > > then the complete hashed text would include the manifest text > minus the already present signature but including the > airspeed_of_unladen_swallow=20 in a canonical format. This makes perfect sense to me. -- Darren J Moffat