Index of /dist/META

Icon  Name                    Last modified      Size  Description
[PARENTDIR] Parent Directory - [DIR] etc/ 2018-03-27 07:50 - [   ] ASF 2018-03-24 06:06 312 [TXT] ASF-key.txt 2018-03-25 10:12 3.2K [TXT] ASF.asc 2018-03-24 06:06 819 [   ] Makefile 2018-03-27 07:50 816 [   ] ROOT 2018-04-08 08:30 12K [TXT] ROOT.asc 2018-04-08 08:30 181 [   ] config 2018-04-08 08:28 541 [   ] mk-root 2018-04-10 06:10 10K
/dist/META/ -- introduction

  End-users download ASF artifacts. An end-user wants to be
  certain that the artifact is endorsed by the ASF.
  We assume that the end-user is prepared to trust :
  -- a ASF company PGP key,
  -- anything signed by the ASF key,
  -- and (a priori) nothing else.

  Each ASF artifact is signed by some release manager [RM].
  For example

    artifact  : /dist/PROJ/foo.tar.gz
    signature : /dist/PROJ/foo.tar.gz.asc
    signed by : key deadbeefdeadbeef --

  Why should an end-user believe that /dist/PROJ/foo.tar.gz
  is endorsed by the ASF ?

  For an end-user it is easy to check the signature, and establish
  that it was created by key deadbeefdeadbeef <>.
  For an end-user is almost impossible to establish that (RM) is authorised to release and sign artifact
  Actually, the end-user doesn't care which RM signed the artifact.
  The end-user just wants be certain that the artifact is endorsed
  by the ASF.

  How do we bridge the gap between "signed by key deadbeefdeadbeef
  (" and "endorsed by the ASF" ?
  We present the end-user with a hierachical model of the ASF :

  -- the ASF authorises PMC's to release artifacts
  -- a PMC authorises certain RM's to release certain artifacts

  The "endorsements" are stored in META files :
  -- a META file has lines like "key KEY1 signs PATH" ;
  -- a META file is signed by, say, "KEY2 -- META-SIGNER".
  -- meaning : META-SIGNER authorises (the owner of) KEY1
     to sign artifact PATH,
  -- as endorsement : META-SIGNER endorses artifact PATH,
     if signed by KEY1.
  -- the "endorsements" in a META file are useless, unless
     the META file is endorsed elsewhere (higher in the tree).

  Directory /dist/META/ contains the ASF's root-of-authority files.
  These files authorise /dist/$pmc/META files, which in turn
  authorise artifacts in /dist/$pmc/ etc.

  In short, this is how it works :

   -- /dist/META/ASF is endorsed (signed) by the ASF-key
   -- /dist/META/ASF endorses /dist/META/ROOT
   -- /dist/META/ROOT endorses /dist/$pmc/META
   -- /dist/$pmc/META endorses /dist/$pmc/artifacts
   -- /dist/$pmc/META endorses /dist/$pmc/sub/META
   -- /dist/$pmc/sub/META endorses /dist/$pmc/sub/artifacts
   -- etc

  Technically :
  -- Actually, when a META file contains a line like :
        key KEY signs PATH
     the PATH is interpreted as a prefix.
     The line authorises KEY to sign files PATH*.
     This makes the META files denser, and more resilient
     to change (the addition/removal of releases).
  -- The prefix is interpreted relative to the META file, so file
     authorises KEY to sign files

  More info :

/dist/META/ -- Files

  -- ASF-key.txt : public ASF company key 36625D435EF870E1
  -- ASF      : specifies which keys may sign file ROOT
  -- ASF.asc  : must be created with ASF-key 36625D435EF870E1
  -- ROOT     : specifies which keys may sign /dist/$pmc/META
  -- ROOT.asc : must be signed by a key listed in file ASF

  Aside :
    It would be more logical to have file /dist/META, /dist/META.asc
    -- META signed by the company key
    -- authorising /dist/$pmc/META files
    The problem with such a setup is that it requires using
    the company key each time /dist/META changes.
    To avoid that we could introduce /dist/ROOT, /dist/ROOT.asc,
    as above, resulting in 4 extra (meta) files in /dist/.
    To avoid clutter in /dist/, these 4 files are placed in dist/META/,
    and prefixes in META/ASF, META/ROOT are relative /dist/.