Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify how digital signatures are to be crafted on Type-2 #30

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 17 additions & 2 deletions draft.md
Original file line number Diff line number Diff line change
Expand Up @@ -131,8 +131,23 @@ An [AppImage] which conforms to the type 2 image format:
* **MUST NOT** rely on any specific file name extension, although it is **RECOMMENDED** that the file name extension `.AppImage` is used whenever a file name extension is desired. Futher it is **RECOMMENDED** to follow the naming scheme `ApplicationName-$VERSION-$ARCH.AppImage` in cases in which it is desired to convey this information in the file name
* **SHOULD** not be encapsulated in another archive/container format during download or when stored
* **MUST** work when spaces are used in its own filesystem path, in its own file name and in paths and filenames it uses internally
* **MAY** embed [update information] in the ELF section `.upd_info`. If the information in this location is not in one of the known [update information] formats, then it **SHOULD** be empty and/or be ignored
* **MAY** embed a digital signature in the ELF section `.sha256_sig`. If this section exists then it **MUST** either be empty (filled with `0x00` padding) or contain a valid digital signature of the sha256 of the AppImage assuming the ELF section `.sha256_sig` being filled with `0x00` padding ([why?](https://github.com/probonopd/AppImageKit/issues/238#issuecomment-249412813))
* **MAY** embed [update information] in the ELF section `.upd_info`. The information in this location is not in one of the known [update information] formats, then it **SHOULD** be empty and/or be ignored
* **MAY** embed a digital signature in the ELF section `.sha256_sig`. If this section exists then it **MUST** **EITHER** be empty (filled with `0x00` padding) **OR** begin with an OpenGPG ASCII Armored block as defined per [RFC 4880](https://tools.ietf.org/html/rfc4880) containing a detached signature. Trailing space SHOULD be filled with `0x00` padding. ([why?](https://github.com/probonopd/AppImageKit/issues/238#issuecomment-249412813))
* If present, the ELF **SHOULD** contain a section `.sha256_sig_ign` with a comma-separated list of sections that should not be part of the GPG signature. If the section is not present, an implementation using this information **MUST** behave as if it had as content `.sha256_sig,.upd_info` Trailing space on this section, if any, **MUST** be filled with `0x00` padding. This section **MUST NOT** include `.sha256_sig_ign` itself, and **SHOULD NOT** include any standard ELF sections present (such as `.code` or `.data`). Any implementation conforming to this signature procedure **MUST NOT** include `.sha256_sig_ign` even if present in the source, but **MUST** include any other section.
* If present, the digital signature **MUST** be calculated by transforming all ELF sections mentioned in `.sha256_sig_ign`. The transformation requires to keep the sections the same size, but get all their bytes replaced by `0x00` for the purposes of calculating the signature. Even if it is not specified, the section `.sha256_sig` **MUST** be considered part of the `.sha256_sig_ign` section.
* The following subsection is non-normative.
* Please keep special attention to the following RFC note:

> Note that all these Armor Header Lines are to consist of a complete
line. That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text other than whitespace following them on the same
line.

* This means that a valid digital signature **MUST** begin with a newline character, and end with a newline character, and **SHOULD** be followed by as many `0x00` bytes as required in order to fill the ELF section.
* The signed plaintext **MUST** be the ASCII string that results from converting into hexadecimal notation the binary bytes of the SHA-256 hash of the ELF file when substituting the sections found in `.sha256_sig_ign` with `0x00` padding.

* **MUST** contain the magic hex `0x414902` at offset 8 ([why?](https://github.com/probonopd/AppImageKit/issues/144))

### Contents of the image
Expand Down