blob: bee1651e72a0f82cc6f0f8540b6a215a37f1d692 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
<?xml version="1.0" encoding="UTF-8"?>
<guide self="general-concepts/manifest/">
<chapter>
<title>Manifest</title>
<section>
<title>Generating the Manifest</title>
<body>
<p>
In the tree, every package has a <c>Manifest</c> file. This file lives
in the same directory as the ebuilds for the package. The <c>Manifest</c> file
contains digests (the current list can be found in <c>metadata/layout.conf</c>
as <c>manifest-hashes</c>) and file size data for every distfile used
by the package. This is used to verify integrity upon fetching them.
</p>
<p>
To generate the <c>Manifest</c>, use <c>ebuild foo.ebuild manifest</c> or
<c>pkgdev manifest -m</c>. You may want to set <c>GENTOO_MIRRORS=</c> while
calling it to fetch distfiles from their original locations immediately.
</p>
</body>
<subsection>
<title>Thin and thick Manifests</title>
<body>
<p>
There are two kinds of Manifest files in Gentoo: thin Manifests that are used
in the development repositories, and thick Manifests that are distributed
via rsync to end users. Thin Manifests are described above.
</p>
<p>
Thick Manifests add checksums for all files in the repository, and an OpenPGP
signature. This provides both for integrity and authenticity checking when
the repository is transmitted over insecure channels. Thick Manifests
are automatically generated on Gentoo Infrastructure, and require no specific
action from developers.
</p>
</body>
</subsection>
<subsection>
<title>Updating <c>Manifest</c> files</title>
<body>
<p>
Updating existing entries within a manifest must be done with care. Upstream
changing the tarball in-place without a new filename could be an innocent
respin of the tarball, or it could indicate either the previous or the new
tarball is malicious.
</p>
<p>
Developers should diff the old and new versions of the distfile, comparing
the two, and note the differences in the commit message updating the
<c>Manifest</c> to indicate both what happened (if any context is known) and
also what differences between the two distfiles have been ascertained.
</p>
<p>
Please note that if upstream made any changes affecting the built
package or it had substantial differences, you need to also bump the ebuild's
revision. Finally, remember to remove the ebuilds that are associated with the
old distfile, or regenerate their checksums in <c>Manifest</c>, if there
are any. This is necessary because these ebuilds will cause checksum
mismatch errors as the checksum recorded in the manifest file no
longer matches the computed checksum of the fetched distfile.
</p>
<p>
Special care is also required with regard to
<uri link="::general-concepts/mirrors/#Replacing Automatically Mirrored Files">
mirrors</uri>.
</p>
</body>
</subsection>
</section>
</chapter>
</guide>
|
GitWeb