Discussion:
[GNU-linux-libre] Help users to verify their downloads
Donald Robertson
2018-06-18 12:37:20 UTC
Permalink
Hello all,

We've recently received some feedback from users concerned about
verifying their downloads of free distros. They want to make sure that
what they've downloaded is actually the distro, and not something that
has been modified in some way. Some distros already provide ways for
users to check their downloads, but it isn't universal. I know Trisquel
provides md5, sha1, sha256, and gpg for their users to verify downloads,
and I think it is a good practice for every distro. Could I get help in
checking what other distros are providing for this issue, and working to
encourage all distros to provide such options? Thank you all for any
help you can provide, and let me know if you have any questions.
--
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56
Andreas Grapentin
2018-06-18 14:11:12 UTC
Permalink
Hello Donald,

parabola provides Sha512 and Whirlpool checksums for all downloadable
images, and all images are gpg signed, so users concerned about the
validity of the files can verify them easily.

Additionally, all packages downloaded using the system installed package
manager are signed with a trusted set of maintainer keys, and packages
without matching signatures are automatically rejected in the default
configuration.

Hope this helps,
Andreas
Post by Donald Robertson
Hello all,
We've recently received some feedback from users concerned about
verifying their downloads of free distros. They want to make sure that
what they've downloaded is actually the distro, and not something that
has been modified in some way. Some distros already provide ways for
users to check their downloads, but it isn't universal. I know Trisquel
provides md5, sha1, sha256, and gpg for their users to verify downloads,
and I think it is a good practice for every distro. Could I get help in
checking what other distros are providing for this issue, and working to
encourage all distros to provide such options? Thank you all for any
help you can provide, and let me know if you have any questions.
--
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56
--
Luke Shumaker
2018-06-19 05:36:29 UTC
Permalink
On Mon, 18 Jun 2018 10:11:12 -0400,
Post by Andreas Grapentin
Additionally, all packages downloaded using the system installed package
manager are signed with a trusted set of maintainer keys, and packages
without matching signatures are automatically rejected in the default
configuration.
Additionally, even if the user disables GPG signature checking (tamper
detection), the package manager will still use sha256sum checking
(error detection).
--
Happy hacking,
~ Luke Shumaker
bill-auger
2018-06-19 00:47:11 UTC
Permalink
for the benefit of anyone reading who is not entirely familiar with these tools
mentioned (md5, sha, gpg) - allow me to make some important distinctions - if
the concerned users who prompted this thread are not reading this list, i
suggest someone should bring these distinctions to their attention

on the one hand there are checksums, often in files named MD5SUMS, SHA256SUMS,
and similar - these are mainly useful to verify that the downloaded files are
complete and were not damaged in transit - downloading over bittorrent offers
this same level of robustness intrinsically without the separate checksum file,
thus releiving the user of that manual step - however, this is a very weak form
of validation in respect to the concern donald raised - anyone with a completed
download could modify it and create a new checksum that will match the modified
file - that is also possible on a torrent network (the checksums are in the
.torrent file); but the result would be two clearly distinguishable and
unrealated files with each coupled to their own .torrent metadata file - if any
case, there is no way to know who authored that file or it's metadata

on the other hand, files that were signed with a GPG key are attributable to the
person who authored it; even if it is delivered over some other channel by some
other person - the GPG key of the person who signed the file can be verified
against the list of official developers as published on the distro's website -
the signature will be as valid whether the file was downloaded directly from the
distro's website, or over bittorrent, or from any other source - if someone
modifies that file and then publishes the modified version, the original
signature of the distro developer would not be valid against the modified
version - that person could sign it with their own GPG key; but that would
obviously be not one of the official keys published on the distro's website

so in short, checksums only verify that a download was received in tact without
error, while a GPG signature verifyies the authenticity of the person who
published it - the level of confidence that i suspect this thread was asking for
can only be provided by a signature - checksums are far less significant and
indeed optional when a signature is provuded; as the signature verifies the
file's integrity also
Andreas Grapentin
2018-06-19 05:45:40 UTC
Permalink
Post by bill-auger
so in short, checksums only verify that a download was received in tact without
error, while a GPG signature verifyies the authenticity of the person who
published it - the level of confidence that i suspect this thread was asking for
can only be provided by a signature - checksums are far less significant and
indeed optional when a signature is provuded; as the signature verifies the
file's integrity also
I would like to add here that is quite common to sign the *checksum* of
a file, instead of the file itself. Since creating the signature is
computationally more expensive than (most) checksum algorithms, this
reduces the system load on both sides of the trust chain, while
providing basically the same result.

-A


--
Ineiev
2018-06-19 05:55:35 UTC
Permalink
Post by bill-auger
on the one hand there are checksums, often in files named MD5SUMS, SHA256SUMS,
and similar
...
Post by bill-auger
anyone with a completed
download could modify it and create a new checksum that will match the modified
file
...
Post by bill-auger
on the other hand, files that were signed with a GPG key are attributable to the
person who authored it
...
Post by bill-auger
the original
signature of the distro developer would not be valid against the modified
version - that person could sign it with their own GPG key; but that would
obviously be not one of the official keys published on the distro's website
Perhaps you should also explain how MITMing files with checksums on distro's
site differs from MITMing the official keys on the same site.
bill-auger
2018-06-19 06:18:34 UTC
Permalink
Ineiev's comment raises another good point - this would be a good candidate for
a GNU article if there is not one already

the point being that community building is itself a tool to this end - it can be
recommended that rather than trusting implicitly in anything that your web
browser shows you, one could invest some time investigating some side-channels
such as IRC and mailing lists where they could become familiar first-hand with
the developers and other users of their operating system; and perhaps verify the
key fingerprints found on the web with other users, and adding them to their
personal keyring before downloading anything
John Sullivan
2018-06-19 11:34:26 UTC
Permalink
Post by bill-auger
Ineiev's comment raises another good point - this would be a good candidate for
a GNU article if there is not one already
the point being that community building is itself a tool to this end - it can be
recommended that rather than trusting implicitly in anything that your web
browser shows you, one could invest some time investigating some side-channels
such as IRC and mailing lists where they could become familiar
first-hand with
the developers and other users of their operating system; and perhaps verify the
key fingerprints found on the web with other users, and adding them to their
personal keyring before downloading anything
Also, always use https for signature files, keys, checksums.
Ludovic Courtès
2018-06-20 14:18:51 UTC
Permalink
Hello Donald & all,

GNU Guix uses signed tags and commits on its Git repository, which is
where package definitions are, and release files on alpha.gnu.org are
also GPG-signed by one of the maintainers.

Pre-built binaries for packages, which are opt-in, are also signed.
It’s up to the user to decide whether or not to trust binaries provided
by, say, hydra.gnu.org:

https://www.gnu.org/software/guix/manual/html_node/Substitute-Server-Authorization.html

Most of our package builds are bit-reproducible so users can “challenge”
servers that provide binaries—i.e., check whether they provide the same
binaries as other servers or the same as those they built locally:

https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html

Ludo’.
Donald Robertson
2018-06-20 17:17:36 UTC
Permalink
Post by Ludovic Courtès
Hello Donald & all,
GNU Guix uses signed tags and commits on its Git repository, which is
where package definitions are, and release files on alpha.gnu.org are
also GPG-signed by one of the maintainers.
Pre-built binaries for packages, which are opt-in, are also signed.
It’s up to the user to decide whether or not to trust binaries provided
https://www.gnu.org/software/guix/manual/html_node/Substitute-Server-Authorization.html
Most of our package builds are bit-reproducible so users can “challenge”
servers that provide binaries—i.e., check whether they provide the same
https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html
Ludo’.
Thanks for this info. Looking over the discussion thus far I'm thinking
that what we really ought to do is put together some documentation on
some best practices for free distros. Things that aren't really freedom
issues, but are important for making sure everyone can get the best out
of the program. I don't want to end up where we sort things out now for
currently endorsed distros and then forget to ever bring the issue back
up in the future. So I think it makes sense to put something up in a
public place that distros can refer to going forward.

In addition to the topic we've been discussing I've had some other
issues brought up, such as making sure that distro maintainers keep in
contact, and what to do when a maintainer is handing the project off to
a new maintainer. A lot of this stuff is addressed for GNU Maintainers
in the Information for Maintainers of GNU Software
<https://www.gnu.org/prep/maintain/html_node/index.html>, but I think we
could make a much smaller document on the LibrePlanet wiki that could be
similarly useful for distro maintainers.

Does that all make sense?
--
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56
Denis 'GNUtoo' Carikli
2018-06-22 17:05:31 UTC
Permalink
On Wed, 20 Jun 2018 13:17:36 -0400
Post by Donald Robertson
Things that aren't really freedom
issues, but are important for making sure everyone can get the best
out of the program.
In my opinion it's somehow related as this makes sure the users gets
the correct binaries, which they can get the corresponding source code
from the distribution.

Having the ability for users to check if this is the case (either by
verifying the signatures or by taking advantage of reproducible builds)
enables certain users to check if the binaries and the source code
matches.

This increase the risk (of being caught) for the people
secretly modifying the binaries, which increase the
chance for user not checking the binary they download to get
non-secretly modified binaries.
Post by Donald Robertson
but I think we could make a much smaller document on the LibrePlanet
wiki that could be similarly useful for distro maintainers.
That would be a very good idea.

I had in mind something similar with much broader scope, which would be
some comparison of free software distribution guidelines (FSDG)
compliant GNU/Linux distributions.

It would list some information such as:
- which architecture does the distribution support
- what are the minimum hardware requirements to use the distribution if
such information is available
- what mechanism are in place to make sure the binaries matches the
source code (signed releases, reproducible builds)
- What security systems it supports (selinux, apparmor)
- what kind of users it's targeted at (for instance Trisquel is meant
to be easy to use while Parabola is for advanced users or people
that want to learn to become advanced users)
- if the distribution is self-hosted or not and what kind of usages
or machines it's targetted at (proteanoOS and libreCMC)
- what kind of release system (rolling releases, stables releases)

Would such thing be welcome on the Libreplanet wiki?

Denis.
Dmitry Samoyloff
2018-06-25 00:09:31 UTC
Permalink
Post by Denis 'GNUtoo' Carikli
I had in mind something similar with much broader scope, which would be
some comparison of free software distribution guidelines (FSDG)
compliant GNU/Linux distributions.
- which architecture does the distribution support
- what are the minimum hardware requirements to use the distribution if
such information is available
- what mechanism are in place to make sure the binaries matches the
source code (signed releases, reproducible builds)
- What security systems it supports (selinux, apparmor)
- what kind of users it's targeted at (for instance Trisquel is meant
to be easy to use while Parabola is for advanced users or people
that want to learn to become advanced users)
- if the distribution is self-hosted or not and what kind of usages
or machines it's targetted at (proteanoOS and libreCMC)
- what kind of release system (rolling releases, stables releases)
I'd add:

- Init system(s) of the distro.
Post by Denis 'GNUtoo' Carikli
Would such thing be welcome on the Libreplanet wiki?
I'm sure it would also be great to maintain such a comparison table at the
Wikipedia to reach the wider audience.

--
I'm an FSF member -- Help us support software freedom!
<http://www.fsf.org/jf?referrer=7253>
bill-auger
2018-06-25 05:18:22 UTC
Permalink
Post by Denis 'GNUtoo' Carikli
Would such thing be welcome on the Libreplanet wiki?
its a wiki so you can add anything you like to it; but no one will see new pages
unless there are links pointing to it from elsewhere - so probably the more
important question is: "where might such page it fit among the network of wiki
links?"

i responded to this because it reminded me just a few months ago someone made a
"distros comparison" page on the parabola wiki that was very much as you
described - it was brought to my attention when someone posted a freedom bug
because it compared and linked to non-FSDG distros such as devuan and fedora -
the thought of such a table had cross my mind in the past; but upon seeing one
filled out, i realized that it was not as valuable as i had imagined

most of the distinctions such a table can make are only interesting to advanced
users (such as the init system), or else utterly vacuous (such as the default
desktop); so it probably would not have the value you are imagining - aspects
that are meaningful to casual users will tend to be of the superficial or even
fallacious sort like:

Parabola - Minimalistic, bare-bones, nerdy
Trisquel - Intuitive, full featured, users-friendly

just to be clear, i mean that this is fallacious because in a single command
(install MATE), one could transform their parabola system into one that is every
bit as "Intuitive, full featured, users-friendly" as a default trisquel system -
and conversely in a single command (remove X), one could transform
their trisquel system into one that is every bit as "Minimalistic, bare-bones,
nerdy" as a default parabola system - that is really not a very important
distinction to make, yet there is little more than that to note that is of
significance to most users

IMHO the only distinguishing property of most distros that is any real
importance to most users is the release cycle - but parabola already had a
dedicated article explaining that general topic[1] (Rolling-vs-LTS); so in the
end i decided that there was little value in the information that such a table
presented and deleted it entirely

at the time, i did co-incidentally mention that this sort of comparison
table may be suitable for the libreplanet or FSD wiki, if someone wanted to re-
create it there omitting the non-FSDG distros - the wiki code is still there is
you want it

my suggestion would be to simply denote each FSDG distro as "rolling", "lts", or
"static" directly on the FSDG distros list page beside their logos, perhaps with
a link to an external article explaining that distinction - the parabola
article, for example, does not mention read-only "static" live distros (such as
dynebolic and musix); but it could be easily expanded to include that class of
distro

the main topic of this thread (verification) is perhaps deserving of a dedicated
article; but a simple table on its own denoting for example, guixsd as having
the "reproducible" property would be not very meaningful without a corresponding
article explaining the concept at some length such as the 'rolling-vs-lts'
article


[1]:https://wiki.parabola.nu/Rolling_vs._LTS
Jean Louis
2018-06-25 09:33:20 UTC
Permalink
Post by Denis 'GNUtoo' Carikli
On Wed, 20 Jun 2018 13:17:36 -0400
Post by Donald Robertson
Things that aren't really freedom
issues, but are important for making sure everyone can get the best
out of the program.
In my opinion it's somehow related as this makes sure the users gets
the correct binaries, which they can get the corresponding source code
from the distribution.
Having the ability for users to check if this is the case (either by
verifying the signatures or by taking advantage of reproducible builds)
enables certain users to check if the binaries and the source code
matches.
This increase the risk (of being caught) for the people
secretly modifying the binaries, which increase the
chance for user not checking the binary they download to get
non-secretly modified binaries.
Post by Donald Robertson
but I think we could make a much smaller document on the LibrePlanet
wiki that could be similarly useful for distro maintainers.
That would be a very good idea.
In general, placing the hashes along the files is
not enough for security that package is genuine.

Hash would signify only that the expected file
that was checked on the server, by the uploader or
publisher, have arrived on the local computer.

When somebody can change a package on the server,
then they can also change the hash that lie next
to the package that was downloaded.

Hashes thus don't give security that package was
not tampered.

PGP signature along the package would give more
security, but even that is not secure if user does
not understand or know it.

It is possible to upload or publish PGP signatures
for email addresses that do not belong to the
uploader of such PGP signature.

It is possible to create PGP keys without having
control over those email addresses.

And there are so many maintainers of packages.

That means there are so many PGP keys.

If I receive PGP key from the same server, and PGP
signature, and package from same server, then
verification means just nothing.

PGP security works only if the key have been
verified with the trusted party who issued it.

So in order to verify the key, I would need to
call developer, or SMS him, or otherwise use
communication channel that is trusted (even this
is not absolute), and then by exchanging
fingerprints, I would know I have his true PGP
key.

Only thereafter I can use his public PGP key to
verify that package have been signed by his public
PGP key.

So when requesting any security feature for
packages to be placed for downloading, let us not
dwell in some illusions of security.

If users don't know how to verify PGP fingerprints
with the issues of the PGP key, and it is anyway
unlikely that any serious percentage would be
doing so, then we are wasting time by creating
apparent security.

Jean Louis
bill-auger
2018-06-25 11:15:21 UTC
Permalink
Post by Jean Louis
If users don't know how to verify PGP fingerprints
with the issues of the PGP key, and it is anyway
unlikely that any serious percentage would be
doing so, then we are wasting time by creating
apparent security.
it is why package managers such as apt and pacman run the verifications
implicitly so that the user does not need to know how it is done - i think this
discussion was prompted more in terms of downloading ISOs and installers - to
this ill add to that the parabola ISO can actually be made by any user of a
parabola system - one simply installs the 'parabolaiso' package and runs a
single command to generate a pristine ISO

of course you need an existing arch or parabola system to bootstrap this but
perhaps your neighbor has one but this ties Jean's reply into the one i posted a
few days ago showing that a community user-base can itself be a security feature
as long as someone in the community can advise and assist others and those
others know where to ask

the guix "blob-challenge" is another example of this
Jean Louis
2018-06-25 11:38:50 UTC
Permalink
Post by bill-auger
Post by Jean Louis
If users don't know how to verify PGP fingerprints
with the issues of the PGP key, and it is anyway
unlikely that any serious percentage would be
doing so, then we are wasting time by creating
apparent security.
it is why package managers such as apt and
pacman run the verifications implicitly so that
the user does not need to know how it is done
It ends up in believing and not assurance.

If user did not verify fingerprints, by some other
communication line, in reality nothing have been
really secured, we have got belief only, and not
assurance.

Servers can be compromised and they do get
ocassionally compromised.

Example is where full distribution have been compromised:
https://www.techrepublic.com/article/why-the-linux-mint-hack-is-an-indicator-of-a-larger-problem/

pacman or other package manager verifies that the
package have been signed by the referenced PGP
key.

For user, especially if user does not know
nothing, it really means nothing. Because there is
no true security there.

If you don't know which door in your house is
closed or open that does not mean your doors are
closed and you are safe, just because you don't
know it.

Server can be compromised and package databases
can be compromised.

PGP keys can be published without any connection
between the actual key controller and the email
address or PGP identity.

There are few fake PGP identities of RMS in PGP
servers for example.

It gives some feeling or assurance, it does not
give security.

It all ends up with the trust based on belief into
the domain and servers, and that the domain and
its servers where packages aor package databases
located are trusted.

But there is no assurance whatsoever to know if
the that domain was cracked, as we all do not have
any access to domain.

So believe into maintainers who maintain their
domains and servers that nothing was compromised.

Which means there is no security at all.

We base the downloads of free software on trust,
not on security.

All these facts shall be made known by each
distribution:

- that hashes help only to verify that expected
file arrived from server to local computer, and
says nothing about the genuity of the package or
that it is not compromised, and that it is valid
only when the original file would be signed by
PGP key and such PGP key fingerprints verified
between the user and the real key owner

- that PGP signatures cannot be assurance of any
security unless fingerprints have been verified
by independent communication line with the key
owner

For more info:
https://gnupg.org/faq/gnupg-faq.html#how_do_i_verify_signed_packages
Post by bill-auger
Get a copy of the author’s public certificate and
import it to your keyring. It’s important to get
the author’s certificate through a trusted
source. On the internet, anyone can be pretend to
be anyone. Particularly, be careful if the
certificate you have doesn’t match the one used
for prior code releases.
Now when knowing this, what users do often is
following (not all users):

- in the first place does not know and does not
have easy access to the information WHO is the
maintainer of the package or controller of the
PGP key, information exists, but is not easy
accessible

- does not get copy of author's public
certificate, but rather relies on domain and
server or distribution itself, probably does not
even know the URL from where packages are
downloaded, and certainly does not import the
certificate into his own keyring, but let it to
pacman or package manager to handle it,

- does not use the trusted source, but simply
trusts everything, user is naive, and we shall
make it clear to them that no absolute security
exists that package was not compromised

- does not understand that something like
***@example.com can be faked by just
anybody and that everybody can make PGP key for
any email address in the world

- does not verify if the certificate is recent or
changed in comparison to prior code releases

- and does not know how to use GnuPG

And when package databases and such software is
held on mirrors, then even the worse opportunity
to get compromised software.

Conclusion is that all the efforts that package
maintainers are doing can be futile by one single
server compromise and changes to the package
databases.

Jean
Patrick McDermott
2018-06-25 23:46:04 UTC
Permalink
Post by Jean Louis
If I receive PGP key from the same server, and PGP
signature, and package from same server, then
verification means just nothing.
OpenPGP public keys are normally pushed to a pool of key servers. So
you can get the key from a different server.
Post by Jean Louis
PGP security works only if the key have been
verified with the trusted party who issued it.
So in order to verify the key, I would need to
call developer, or SMS him, or otherwise use
communication channel that is trusted (even this
is not absolute), and then by exchanging
fingerprints, I would know I have his true PGP
key.
Only thereafter I can use his public PGP key to
verify that package have been signed by his public
PGP key.
This is not very practical, or even sufficient. It can verify a key,
but it doesn't authenticate the key's owner. How secure is the method
by which you found the phone number? How do you know that the voice on
the other end is that of the maintainer? You can't very easily verify
someone's identity by phone, especially in a publicly reproducible way
(ask a question with a secret answer, and the answer is no longer
secret, because an impersonator could get and repeat the same answer).

OpenPGP has a more effective and distributed solution to this: the web
of trust. Maintainers meet people who verify their identities in person
and sign their keys (ideally either shared in full or identified by a
full fingerprint or a sufficiently large ID). The people who meet the
maintainers meet other people to have their identities verified and keys
signed, and so on. If a user has met some people and verified and
signed some keys, then there is likely to be at least one trust path
somewhere, through N degrees of separation, that leads to the maintainer
of the downloaded software they want to verify. GnuPG looks for such
trust paths when using a key to verify a signature.

In practice, this doesn't always work out, because not all users go
around to key-signing parties to connect themselves into the web of
trust. Such people could instead look up a maintainer on their favorite
key server and look for a key that has numerous signatures from keys
that in turn have numerous signatures. It's far from ideal but better
than nothing.
Post by Jean Louis
So when requesting any security feature for
packages to be placed for downloading, let us not
dwell in some illusions of security.
If users don't know how to verify PGP fingerprints
with the issues of the PGP key, and it is anyway
unlikely that any serious percentage would be
doing so, then we are wasting time by creating
apparent security.
The perfect is the enemy of the good. Sure, perfect security is
impossible, but that doesn't mean we should give up on having any
security at all. Security is not a binary thing; it's a matter of best
efforts, defense in depth, and deterring an attacker at least long
enough that they give up.

As long as the threat model and weaknesses are considered (i.e. not
having a false sense of perfect security), any level of security is
better than none.
--
Patrick McDermott, CEO
Libiquity
Putting customers in control of high-quality technologies
http://www.libiquity.com/
Jean Louis
2018-06-26 08:15:07 UTC
Permalink
Post by Patrick McDermott
Post by Jean Louis
If I receive PGP key from the same server, and PGP
signature, and package from same server, then
verification means just nothing.
OpenPGP public keys are normally pushed to a pool of key servers. So
you can get the key from a different server.
Post by Jean Louis
PGP security works only if the key have been
verified with the trusted party who issued it.
So in order to verify the key, I would need to
call developer, or SMS him, or otherwise use
communication channel that is trusted (even this
is not absolute), and then by exchanging
fingerprints, I would know I have his true PGP
key.
Only thereafter I can use his public PGP key to
verify that package have been signed by his public
PGP key.
This is not very practical, or even sufficient. It can verify a key,
but it doesn't authenticate the key's owner. How secure is the method
by which you found the phone number? How do you know that the voice on
the other end is that of the maintainer? You can't very easily verify
someone's identity by phone, especially in a publicly reproducible way
(ask a question with a secret answer, and the answer is no longer
secret, because an impersonator could get and repeat the same answer).
OpenPGP has a more effective and distributed solution to this: the web
of trust. Maintainers meet people who verify their identities in person
and sign their keys (ideally either shared in full or identified by a
full fingerprint or a sufficiently large ID). The people who meet the
maintainers meet other people to have their identities verified and keys
signed, and so on. If a user has met some people and verified and
signed some keys, then there is likely to be at least one trust path
somewhere, through N degrees of separation, that leads to the maintainer
of the downloaded software they want to verify. GnuPG looks for such
trust paths when using a key to verify a signature.
In practice, this doesn't always work out, because not all users go
around to key-signing parties to connect themselves into the web of
trust. Such people could instead look up a maintainer on their favorite
key server and look for a key that has numerous signatures from keys
that in turn have numerous signatures. It's far from ideal but better
than nothing.
I know.

Majority of users will not know.

In regards to number of signatories in the web of
trust, in matter of minutes it is posssible for
anybody to create PGP keys, such as

***@example.com

and sign that key with multiple other keys, and
upload the key which was verified by web of
trust. I can sign such key with multiple other
fake keys.

We are back at the fact that
Post by Patrick McDermott
Post by Jean Louis
So when requesting any security feature for
packages to be placed for downloading, let us not
dwell in some illusions of security.
If users don't know how to verify PGP fingerprints
with the issues of the PGP key, and it is anyway
unlikely that any serious percentage would be
doing so, then we are wasting time by creating
apparent security.
The perfect is the enemy of the good. Sure, perfect security is
impossible, but that doesn't mean we should give up on having any
security at all. Security is not a binary thing; it's a matter of best
efforts, defense in depth, and deterring an attacker at least long
enough that they give up.
As long as the threat model and weaknesses are considered (i.e. not
having a false sense of perfect security), any level of security is
better than none.
It is not.

It is well known that security is only as strong
as its weakest link.

In this case, it is as secure as possibility to
enter some GNU/Linux server and compromise it. To
enter the server is very weak link.

I have been maintaining servers since decades. And
have launched multiple servers. Backdoors,
intruders, spammers, game players, all kinds of
people enter remote servers, and thousands of them
attempt to enter the servers worldwide.

How do we know that:

- maintainers don't have "friends" in their houses
who have access to their computers, they can
read passwords, they can implement backdoors,

- how do we know which password policies
maintainers use in general? Maybe their
passwords are too simple and can be cracked. I
don't believe each maintainer of distributions
is aware of security. We have recently seen Blag
distribution being removed for not being
updated. To me that is security issue.

- how do we know that maintainers truly know their
hosting system? That it is safe from other
people?

- how do we know the maintainers of distribution?

There are many more such questions.

To rely on hashes which are located on mirror
servers, like for example Digitalocean is doing
so, is simply no security at all. It is just
mechanism to make sure that file that was checked
before downloading is the same file downloaded.

It does not say anything about the genuity of the
file.

To rely on PGP signatures, which we did not check,
well that is by PGP standard incorrect, so if we
do so, that means there is no security at
all.

To rely on "web of trust" by standard requires me
to know those people in the web of trust, that is
why there is trust, if I know them, and who they
are, I can trust that key belongs to one person.

Just to see the list of numerous people who signed
a key is not "web of trust", it is just list of
numerous people who signed a key, nothing
else.

Instead:

In my opinion it would be good enough to trust to
the domain from where packages are taken, for
example:

- trusting Hyperbola.info domain for example, or
gnu.org

- all package databases to be downloaded from
there

- all PGP signatures, hashes to be downloaded from
there

- problem is with mirrors, so the above
information would be used to verify that
packages on mirrors are genuine by using hashes,
and by using GPG

- that the trusted domain keeps system of tracking
users, and a log, so prove to public that was
not compromised, or otherwise to show policies
on how the original domain is maintained and
controlled, policies for maintainers, who is
really accessesing and who is really responsible
for publishing of those packages

And then to implement such security system
centrally.

Security is only as strong as its weakest link.

Jean

Patrick McDermott
2018-06-25 05:44:02 UTC
Permalink
Hello,
Post by Donald Robertson
We've recently received some feedback from users concerned about
verifying their downloads of free distros. [...] Could I get help in
checking what other distros are providing for this issue, and working to
encourage all distros to provide such options?
I'll answer this for ProteanOS. Tl;dr: This is partially done but
important parts are still in progress.

First, I'll provide some background on how ProteanOS is distributed.
Unlike many other distributions, there are no self-contained live,
installer, or flashable system images. The official way to install
ProteanOS is to cross-install from another distribution using "prokit",
an installer package (and more) similar to debootstrap in Trisquel and
gNewSense. prokit downloads a set of individual packages from a package
archive mirror to construct a bootable (or chroot'able) system.
Packages in that system are then managed by opkg. The package archive
is managed by "pro-archman", similar to reprepro in Trisquel/gNewSense.

Now, about download verification. prokit is distributed alongside MD5
and SHA-256 checksums and an OpenPGP signature. prokit and opkg in turn
both check the integrity of all downloaded packages using both MD5 and
SHA-256 checksums (generated by pro-archman). So checksumming at least
is done, and the installer package is signed.

However, prokit and ProteanOS's opkg binaries currently don't do any
signature verification, nor does pro-archman generate signatures on the
archive. There are a few things to be done to accomplish that, and this
work is in progress.

First, the GPGME library and its dependencies need to be packaged in
ProteanOS so signature checking can be enabled in opkg. In 2014 [1][2]
I did some of that packaging and offered the rest of the packages as
low-hanging fruit for anyone interested.

Next, pro-archman needs to gain the ability to sign package archive
index files. (Those index files contain the MD5 and SHA-256 checksums
of package files, completing the chain of trust to the packages
themselves.) And finally prokit needs to be modified to verify index
file signatures (once the implementation design is finalized).

I updated and summarized the remaining work in a wiki page [3] last
year (plus some small changes shortly ago). Progress is admittedly
slow, but package verification is a priority in ProteanOS.


Also, since Denis brought it up in this thread, I'll mention that build
reproducibility is also something I'd like to get done in ProteanOS. I
actually started looking into it a bit way back in July 2013 [4] (before
it was cool!) as a QA measure to validate architecture port bootstraps.
At that time, it looked like ProteanOS actually wasn't too far off from
being reproducible, although the distribution has grown a lot in the
years since and I haven't checked binary differences recently.

It likely won't happen anytime soon, as I currently have a few higher
priorities in ProteanOS right now (including signatures) and a complete
reproducibility implementation will likely require some extra tooling
work to track and replicate build environments (installed package
versions, SOURCE_DATE_EPOCH, etc.). But it's on my radar.


[1]: http://lists.proteanos.com/proteanos-dev/2014/06/msg00001.html
[2]: http://lists.proteanos.com/proteanos-dev/2014/09/msg00001.html
[3]: http://www.proteanos.com/dev/archive/signing/
[4]: http://lists.proteanos.com/proteanos-dev/2013/07/msg00002.html
--
Patrick McDermott, CEO
Libiquity
Putting customers in control of high-quality technologies
http://www.libiquity.com/
Loading...