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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
// Copyright (C) 2021 The Qt Company Ltd.
// Copyright (C) 2019 Luxoft Sweden AB
// Copyright (C) 2018 Pelagicore AG
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
/*!
\page appman-packager.html
\title Packager
\brief A command-line utility to create and sign application packages.
\ingroup qtappman-tools
The \c{appman-packager} is a command-line utility that can be used by the developer to manage
installation packages. This utility can also be used as a signing and verification tool on an
app-store backend server. This tool is meant for use on the developer's desktop machine or
packaging server, but \b not on the target device.
Currently, the application manager supports unsigned packages, packages that are signed by the
developer only (development mode), and packages that are signed by a trusted app-store. The
\c{appman-packager} can create all these variations with the following commands:
Please also see the \l{Package Installation} documentation for more in-depth information about
package installations.
\table
\header
\li Command
\li Arguments
\li Description
\row
\li \span {style="white-space: nowrap"} {\c create-package}
\li \c{<package>}
\c{<source directory>}
\li Creates a new package named \a package from the application in \a{source directory}. The
directory needs to at least contain an \l{Manifest definition}{\c info.yaml} as well as an
\c{icon.png} file.
The tool will do a sanity-check on the \c info.yaml file before actually creating the
package.
All normal files and directories in the source directory will be copied into package. The
only meta-data that is copied from the filesystem is the filename, and the user's
eXecutable-bit. The following options are supported:
\c{--verbose}: Dump the package's meta-data header and footer information to stdout.
\c{--json}: Output in JSON format instead of YAML.
\c{--extra-metadata} or \c{-m}: Add the given YAML snippet on the command line to the
packages's \c extra meta-data (see also PackageManager::taskRequestingInstallationAcknowledge).
\c{--extra-metadata-file} or \c{-M}: Add the given YAML file to the
packages's \c extra meta-data (see also PackageManager::taskRequestingInstallationAcknowledge)
\c{--extra-signed-metadata} or \c{-s}: Add the given YAML snippet on the command line to the
packages's \c extraSigned meta-data (see also PackageManager::taskRequestingInstallationAcknowledge)
\c{--extra-signed-metadata-file} or \c{-S}: Add the given YAML file to the
packages's \c extra meta-data (see also PackageManager::taskRequestingInstallationAcknowledge)
\c{--pre-package-command} or \c{-p}: Use the given script to prepare the files that are copied
into the package. The script will be called with the path to each file in the source
directory, and it should return a non-zero exit code. The script can be used to setup
the correct file permissions or add IMA file signatures.
All of the extra-meta-data options are merged together, so all options can be used together
and each option can also be given multiple times. The signed fields are added to the
package's digest, so that they cannot be changed once the package has been signed. The
normal fields can however be changed even after package signing: an example would be an
appstore-server adding custom tags.
\row
\li \span {style="white-space: nowrap"} {\c dev-sign-package}
\li \c{<package>}
\c{<signed-package>}
\c{<certificate>}
\target packager-dev-sign-package
\li Takes the input \c package, adds a developer signature and writes the output to
\c signed-package. You need to supply a \c certificate in PKCS#12 format.
If a password for the PKCS#12 certificate is required, it can be supplied via the
\c{-p} / \c{--password} option. The same password mechanisms as in the OpenSSL command-line
tool are supported.
\list
\li \b{pass:}\e{passwd}\br
The password is set as \e passwd. Use this format only when security is not a
concern, because this method exposes the password to system utilities.
\li \b{env:}\e{var}\br
The password is taken from the environment variable \e var. As with the \b{pass:}
mechanism above, the password is visible to system utilities.
\li \b{file:}\e{path}\br
The password is read from the file at \e path. Reading stops at the first newline
character.
\li \b{fd:}\e{number}\br
The password is read from the file descriptor specified by \e number in the same
way as specified for \b file above. Please note, that this option is not supported
on Windows.
\li \b{stdin}\br
The password is read from standard input in the same way as specified for \b file
above. If possible, this will directly access the console and disable echoing for
better security.
\endlist
The following additonal options are supported:
\c{--verbose}: Dump the package's meta-data header and footer information to stdout.
\c{--json}: Output in JSON format instead of YAML.
\row
\li \span {style="white-space: nowrap"} {\c dev-verify-package}
\li \c{<package>}
\c{<ca-certificates...>}
\li Reads the input \c package and tries to verify the developer signature using the given \c
ca-certificates. The following options are supported:
\c{--verbose}: Print details regarding the verification to stdout.
\row
\li \span {style="white-space: nowrap"} {\c store-sign-package}
\li \c{<package>}
\c{<signed-package>}
\c{<certificate>}
\li Takes the input \c package, adds a store signature and writes the output to
\c signed-package. You need to supply a \c certificate in PKCS#12 format.
If a password for the PKCS#12 certificate is required, it can be supplied via the
\c{-p} / \c{--password} option. See the \l{packager-dev-sign-package}{dev-sign-package}
documentation above for details.
The following additonal options are supported:
\c{--hardware-id}: Bind the resulting package to the given hardware ID, so the package
can only be installed on this specific hardware.
\c{--verbose}: Dump the package's meta-data header and footer information to stdout.
\c{--json}: Output in JSON format instead of YAML.
\row
\li \span {style="white-space: nowrap"} {\c store-verify-package}
\li \c{<package>}
\c{<ca-certificates...>}
\c{<device-id>}
\li Reads the input \c package and tries to verify the store signature using the given \c
ca-certificates. The following options are supported:
\c{--json}: Output in JSON format instead of YAML.
\endtable
The \c{appman-packager} naturally supports the standard Unix \c{--help} command-line option.
*/
|
