This is a concept to increase the overall security of the ArchLinux distribution by providing a proposal on how PKGBUILDs should be used. This list might not be complete nor meet your personal opinions. If you have any suggestions, let me know.

To sum up the main security relevant steps everyone should take are:

• Only use sha512sums (beside optional upstream message digests)
• Use PGP fingerprints when possible
• Use https sources when possible
• Sign the PKGBUILD with your PGP key
• (Optional) Add a link to this guideline to spread the idea

"A checksum is a small-sized datum from a block of digital data for the purpose of detecting errors which may have been introduced during its transmission or storage." Source

The data could be downloaded with some bytes flipped that causes the package to not built at all or produce a wrong binary.

Integrity covers data corruption also.

Even CRC32 could be used as a solution. The current integrity check is adequate for corruption detection, but is inadequate for data integrity checks.

• None

"In information security, data integrity means maintaining and assuring the accuracy and completeness of data over its entire life-cycle. This means that data cannot be modified in an unauthorized or undetected manner. [...] Information security systems typically provide message integrity in addition to data confidentiality." Source

Server cracks and MitM attacks could lead to the fetching of tampered source files that are used for package building. This can be dangerous when older packages must be rebuilt automatically. Using a weak hash function's message digests for verification could lead to the use of tampered source files without us noticing that.

Each source file is validated against a provided hash from the PKGBUILD file. Accepted hashed are: md5, sha1, sha256, sha512. Appart from that if a pgp signature is provided its authenticity ensures its integrity also. Most packages currently rely on known to be weak hash function algorithms (md5 and sha1).

The usage of weak hash function algorithms (md5 and sha1) must be avoided. sha512 must become the default. If upstream uses message digests of weak hash function algorithms, the message digests of those can also be included in the PKGBUILD files, and those message digests should be seen as an additional check.

As said weak hash algorithms could lead to modified sources. Especially for reproduceable builds (AUR and official) it is essential to ensure that the sources are not modified at all. A server side hack or MITM could easily lead to an attack of a package when being built. History has shown that those hacks are not uncommon.

This is especially a problem as not every upstream source signes their tarballs. Strong hashes are not essential if pgp signatures are provided, but it can sometimes be more handy to validate a hash instead of a pgp signature.

Stronger hashes have no disadvantages, they can only improve security.

• Replace/add sha512sums to PKGBUILDs
• Add optional upstream hashes if provided
• Use hashes for local package files, also for .install files
• Implement a warning inside namcap or even better in makepkg
• Update the wiki
• Also provide sha512sums for the iso downloads
• Default integrity check in makepkg.conf to sha512

"In information security, message authentication or data origin authentication is a property that a message has not been modified while in transit (data integrity) and that the receiving party can verify the source of the message." Source

Provided sources from upstream may not be from the orinal software author. You cannot validate the origin of the software unless you trust the hosting server for the first initital download. Integrity also does not cover this risk as the hash could also have been modified.

PGP signatures can be used to validate the authors authenticity.

A lot more upstream sources provide PGP signatures which are not yet used by the PKGBUILD. PGP signatures should be used whenever possible.

Also it should be a requirement to use 4096-bit or larger keys whenever possible.

PGP signatures ensure integrity and authenticity at the same time and therefore improve the overall security of the package sources. Using larger keys results in stronger security also protecting against attacks in the future.

None

• Add PGP signatures to PKGBUILDs wherever possible
• Check if upstream .sig files are available for existing packages
• namcap should warn us that a pgp fingerprint is not being used?

• Each PKGBUILD gets signed with the maintainers signature
• Ensures no tampering of the sha512sum or pgp source signatures can be made

PKGBUILDS contain source hashes and their PGP signature. The PKGBUILD requires a high level of trust as it could be easily tampered with wrong hashes/PGP signatures (weakest spot).

Currently there is no way to verify the PKGBUILDs authenticity. You need to trust the ArchLinux git server.

PKGBUILDs should be signed with the maintainers PGP key, similar to the packages themselves or the upstream sources.

TODO makepkg --source --sign

This ensures the PKGBUILD was validated by the packager. Users should be still careful when weak hash algorithms are used inside the (signed) PKGBUILD. It would only require an additional signature generation inside communitypkg.

None

• Inform users about the PKGBUILD signature inside the wiki/main page
• Add the signature to the build system e.g. communitypkg
• Implement a warning inside namcap if no signature is used?

"In information security, confidentiality "is the property, that information is not made available or disclosed to unauthorized individuals, entities, or processes" (Excerpt ISO27000)." Source

There are sources that cannot be trusted 100% (non-https upstream-controlled servers and the use of mirrors that are not controlled by upstream). This is not only a problem because of MITM spoofing attacks but also because of privacy reasons that everyone can analyze what you are downloading.

Not all sources use https yet.

PKGBUILDs should use https whenever possible.

It does and cannot replace the importance of integrity and authenticity but gives the user the certainty that nobody else can listen to his traffic.

TODO http cache was mentioned on the mailing list

• Check the sources containing http/ftp and check for https
• Implement a warning inside namcap if no https is used?