Mail archive

Re: [alpine-devel] What could be done to make Alpine distribution more secure

From: Natanael Copa <>
Date: Tue, 23 Feb 2016 11:02:53 +0100

On Mon, 22 Feb 2016 19:19:54 +0100
Der Tiger <> wrote:

> Hi Alba,
> > I'll start with the obvious HTTPS support. The download links on
> > all point to a HTTP link.
> Going SSL won't give the downloader any relevant additional security,
> since the connection between the server and the downloading client isn't
> a likely point of attack. Such a Man in the Middle attack is far too
> much effort only to corrupt the transferred ISO image. It is much easier
> to take the same approach the Mint hackers took, and attack the website,
> directly. SSL won't help your there.
> To make the website hacking-proof, the entire content would have to be
> on a physically read-only medium (e.g. DVD-R), but I doubt any admin to
> be willing to handle such hassle.

We don't use any web application server for main website. It is
generated static pages. So you will not be able to exploit some
wordpress vulnerability to hack the site.

> > The certificate is only valid for the following names:
> >,
> The Alpine website uses several sub-domains and the certificate would
> therefore have to be a wildcard certificate in order to be valid on all
> sub-levels. Those wildcard certificates are considerably more expensive
> than any generic certificate.

letsencrypt might be an option.

> > HTTPS Everywhere installed. Shouldn't it always be preferred?
> Only, if you can trust the server certificate and you want to transfer
> data, that would give any listener valuable information. SSL does
> neither hide your IP address, nor your connection state. Surfing the
> Alpine website and downloading an Alpine ISO hardly counts as valuable
> information.
> SSL only hides (too some degree) the information inside the connection,
> but not the connection itself. To accomplish a fully encrypted
> connection, you need tools like VPN. Furthermore, most certificates can
> be faked, spoofed and even most certificate authorities (CA) are not to
> be trusted, if it comes to critical data. The entire certificate system
> has already collapsed due to the system requiring all CAs to be
> trustworthy. If one CA fails, the entire system falls apart. And today,
> there are more untrustworthy CAs than trustworthy ones.
> Offering checksums to every downloaded file does only verify the file's
> consistency with the original file, but does not prevent any tampering
> with the files stored on the server. Because, lets face it, if someone
> is able to hack the website and replaces the downloadable files, he/she
> is certainly qualified to modify the online displayed checksums,
> accordingly.
> The only way known to me to ensure the file contents validity is to
> offline encrypt the file with a private key and hardcode the public
> de-cryption key into the static part of the website. Any modifications
> to the file alone lets the de-cryption fail, while the public key can't
> be modified without locally accessing the web sever.

We cryptographically sign the content of every package (public keys are
in /etc/apk/keys). So we do verify that the package content is not
tampered with.

If you also check the pgp signature of the iso image, then you can be
relatively sure that the content you get is the the same as was
generated on the build servers, regardless if you get it over encrypted
transport or not.


Received on Tue Feb 23 2016 - 11:02:53 UTC